How to Hire Flutter Developers: What to Test and What to Avoid

Knowing how to hire Flutter developers is mostly knowing what to test. A typical process asks widget questions, hires the person who answers them, then meets the first native integration, a handheld scanner or a background location update, and finds nobody who can write the Kotlin and Swift on the other side of it. The tests below come from Flutter products Sigi Technologies has shipped to both stores, including Bix Delivery and 3DLogistiX Mobile.

How to hire Flutter developers: what the process has to prove

• Flutter draws its own user interface and is written in Dart, so the hiring signal is Dart fluency and framework judgment, not JavaScript experience.
• Flutter’s own state management documentation says the best choice depends on the app’s complexity, the team’s preferences and the specific problems being solved, so a candidate should defend a choice rather than name a package.
• Platform channels are where Flutter hiring most often fails: the channel is Dart on one side and Kotlin or Swift on the other, and somebody has to write both.
• Performance claims mean nothing unless they were measured in profile mode on a real device, because Flutter’s documentation says application performance can be janky in debug mode.
• A live store listing is stronger evidence than a repository, because Apple rejects binaries that crash or show obvious technical problems and Google Play requires a video demonstration before granting background location access.
• Flutter was used by 9.4% of the 45,841 developers who answered that question in the 2024 Stack Overflow Developer Survey, against 8.4% for React Native, so the candidate pool is real but small.

What skills should you look for in a Flutter developer?

A Flutter developer is an engineer who builds applications in the Dart language using Flutter’s widget framework, which renders its own interface instead of wrapping platform controls, and ships those applications to more than one platform from a single codebase. The framework choice itself is covered in Flutter vs React Native. What follows assumes the choice is already made and the job is to assess a person.

Dart, not only widgets

The Dart language documentation covers variables and type inference, classes, mixins, interfaces and abstract classes, exceptions, async and await, and null safety. Ask about the asynchronous parts. A candidate who cannot explain the difference between a Future and a Stream will write UI code that blocks. Ask about isolates too: Flutter’s guidance on background work describes isolates as Dart’s model for multithreading, noting that an isolate does not share memory with the main program.

A state management choice the candidate can defend

Flutter’s list of state management approaches names setState for ephemeral widget state, ValueNotifier and InheritedNotifier, and InheritedWidget and InheritedModel for passing state down the tree, then points at the community packages. The page opens by saying state management is a complex topic and adds that the best choice often depends on the app’s complexity, the team’s preferences and the specific problems you need to solve. So the question is not which package the candidate likes. It is what they would lose by picking a different one.

Platform channels and the native code behind them

Flutter’s documentation describes platform channels as named channels that carry asynchronous messages between Flutter and platform-specific code, through MethodChannel, BasicMessageChannel and EventChannel. The same page carries a rule candidates forget: when invoking channels on the platform side destined for Flutter, invoke them on the platform’s main thread. Ask for a channel they wrote and what the Kotlin or Swift side looked like. A candidate who has never opened the native side is a fine app developer and a risk on any product with hardware, printers, background audio or a vendor software development kit.

Performance measured, not asserted

Flutter’s build modes documentation states plainly that application performance can be janky in debug mode and that performance should be measured in profile mode on an actual device. The performance best practices page sets the target at frames rendering well under 16ms, and under 8ms as 120fps devices spread, then names the pitfalls: the Opacity widget in animations, unnecessary saveLayer calls, clipping during animation, and repetitive or costly work inside build methods. Ask a candidate to describe one jank problem they diagnosed. The answer should contain a device, a mode and a tool, not an adjective.

App size is the same test in a different form. Flutter’s guidance on measuring app size says debug builds are not representative of production size, and gives the tools that are: the --analyze-size flag available since Flutter 1.22, the DevTools app size tool for reading the resulting breakdown, the Android vitals app size tab in Play Console, and Xcode’s app thinning size report on iOS. A candidate who knows their release size and where they read it has shipped something.

Testing discipline

Flutter’s testing overview separates unit tests of a single function or class, widget tests of one widget and its interactions, and integration tests of a complete app on a real device or emulator. It publishes the tradeoff as a table: confidence rises from low to highest across those three, and so do maintenance cost and dependencies, while execution speed drops from quick to slow. A good candidate can say which of their flows sit at which level and why. A weak one says tests are on the backlog.

What actually mattered on the Flutter apps Sigi shipped

Interview question lists are generic because they are written from documentation. These six points come from Flutter products that went through store review, and they are where a hire either holds up or does not.

• Two apps from one codebase. Bix Delivery ships a customer app and a driver app from a single Flutter codebase, and both reached the App Store in January 2026. Trim does the same with Trim and Trim Business across four store listings. Ask a candidate how they keep shared components, versioning and release cadence honest across two apps.
• Hardware through the platform layer. 3DLogistiX Mobile does barcode scanning for receiving, put-away, picking, packing and cycle counts using the device camera or an integrated handheld scanner on the warehouse floor. That is platform channel work, not widget work.
• Location and presence in the background. On Antrak, the driver job feed is a geospatial query around the driver’s live position, with Firebase carrying push and online and offline presence. Background location is the feature most likely to be broken by a candidate who has only built foreground screens.
• Server-authoritative state. Bix models every delivery as a state machine on the backend and the apps render only the state the server reports. LinMo enforces event capacity on the server so two members cannot book the last place at once. Ask where the candidate puts business rules.
• Release and store review as part of the job. The Antrak driver app went through Google Play review and publication under Sigi’s developer account, LinMo drives store releases from the same GitHub Actions pipeline that builds the apps, and 3DLogistiX Mobile has been live on the App Store since May 2025. Someone has to own signing, review responses and rollbacks.
• Feature parity on both platforms. LinMo was built as a single Flutter codebase precisely so every booking flow and calendar screen was written and tested once. A candidate who has only shipped Android will not have felt the iOS half of that promise.

What Flutter developer interview questions are worth asking?

Eight questions, each with the shape of a strong answer. All are hard to fake and easy to score.

• Which state management approach did your last production app use, and what would you change now? A strong answer names a cost, not a favorite.
• Walk me through a platform channel you wrote. What was on the Kotlin or Swift side, and which thread did it call back on?
• Describe one jank problem you diagnosed. A strong answer names a device, profile mode and a tool, then a fix such as removing work from a build method.
• What is covered by your widget tests, and what only appears in integration tests? A strong answer trades confidence against maintenance cost deliberately.
• How large is your current release build, and where did you read that number?
• What did App Store or Play review reject, and what did you change? Everyone who has shipped has a rejection story.
• Where do business rules live in your apps, and what happens when the server and the app disagree?
• What background work have you shipped: location, uploads or scheduled tasks? What broke first?

What take-home or pairing exercise should you set?

Set one small exercise, timebox it to three hours, and offer a 90-minute pairing session on the same brief for candidates who will not do unpaid work. Pay for anything longer than two hours. The brief: a two-screen Flutter app against any public JSON API, with a list, a detail view, explicit loading, empty and error states, one platform-specific behavior such as a runtime permission prompt, and one widget test.

Model the screens on something you actually run. The Bix Driver active delivery screen above is a list, a detail view, a status change and a location permission in one place. Grade the submission on five things, in this order:

1. Where state lives. Is it held above the widgets that read it, or scattered through setState calls in the tree?
2. What happens with no network. Turn airplane mode on before you read a line of code.
3. Whether failures are surfaced. An error swallowed into a spinner is the single most common defect in take-home submissions.
4. Whether the widget test asserts behavior rather than the existence of a widget.
5. Whether the README explains one tradeoff they made and one thing they would do with more time. This predicts code review conversations better than the code does.

How do you evaluate a Flutter developer’s portfolio?

Ask for live store links rather than repositories, then install the app. Store review is an external check the candidate cannot self-certify. Apple’s App Store Review Guidelines state that submissions should be final versions, that the app must be tested on-device for bugs and stability before submission, and that Apple will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems. Guideline 4.2 adds that an app must go beyond a repackaged website.

Google Play adds a second external check on exactly the feature that trips up inexperienced Flutter teams. Its policy on background location access requires a permissions declaration form, a prominent in-app disclosure shown before the runtime permission, a privacy policy on an active URL, and a video that demonstrates the feature being activated from the background, because the review team must be able to verify that the app offers the declared feature. A candidate who has been through that process will tell you how long it took. Check version history and last update dates too: an app shipped once and abandoned proves less than one maintained across releases.

What are the red flags when hiring a Flutter developer?

• Answers every architecture question with a package name. The tradeoff, not the library, is the skill.
• Has never seen the native side of a platform channel, on a product that needs hardware, payments terminals, printers or background audio.
• Quotes performance numbers from a debug build, which Flutter’s own documentation says is not representative.
• Offers screen recordings and private repositories instead of a store listing, on a role whose job is shipping to stores.
• Proposes a rewrite before reading the existing codebase.
• Treats tests as optional because the user interface changes too often, which is an argument for widget tests rather than against them.
• Cannot describe a single store rejection, policy declaration or signing problem. That usually means the release was somebody else’s job.

Should you hire in-house, a freelancer or a team?

One app with a straightforward backend is a job for one senior Flutter developer plus a backend developer. Two apps from one codebase, as on Bix and Trim, is a pod: mobile engineers, a backend engineer, design and quality assurance working to one release cadence. The engagement shapes are compared in staff augmentation vs dedicated team vs outsourcing, and the pod-shaped version of the same problem is set out in staffing a frontend pod. On budget, published contractor rate benchmarks vary too widely by region to quote. Plan by scope instead. Sigi’s cost guide puts a simple app at $40k to $80k, a standard app at $80k to $180k, and a complex multi-surface product at $150k to $350k and above. Those are typical-scope estimates, not quotes.

Sigi Technologies does this work as well as writing about it. The Flutter apps named in this guide were built by Sigi teams, so hiring Flutter developers through Sigi is one option if you would rather assess a team with shipped store listings. If you are building the capability in-house, run the process above.

In what order should you run the hiring process?

1. Write the job description around the product, naming the native integrations, the background work and the platforms, rather than listing framework buzzwords.
2. Screen on store links first. No listing means a longer technical stage, not an automatic rejection.
3. Run a 45-minute technical conversation using the eight questions above, and score the reasoning rather than the vocabulary.
4. Set the three-hour take-home, or the 90-minute pairing session, and grade it against the five criteria above.
5. Do a short code review together on their submission. How someone receives feedback is the best available predictor of how they will work.
6. Check one reference who shipped with them, and ask specifically who owned the store release.

Related reading

The framework decision behind this role is covered in Flutter vs React Native, and budget planning in how much it costs to build a mobile app. For the shipped products this guide draws on, read the Bix Delivery courier platform case study and the 3DLogistiX warehouse platform case study. On engagement models, see staff augmentation vs dedicated team vs outsourcing. Commercial scope sits on Sigi’s mobile app development service and IT staffing service, or talk to Sigi about a specific Flutter role.