How we assess
Every applicant goes through 5 gates: application, an AI-assisted screen, a live technical assessment scored by a practice lead, a client-fit interview, and reference and credential checks. The questions below come from the live assessment. We score answers on reasoning and trade-offs, not on recalling definitions.
20 technical questions with model-answer hints
Questions 1–10 (role-specific)
Question 1: How do you decide between Bloc and Riverpod for a new app?
Model-answer hint
Team size, testability, tolerance for boilerplate; documents the decision; no tribalism.
Question 2: What happens when setState is called high in a deep widget tree?
Model-answer hint
Rebuild scope, const constructors, splitting widgets, selectors to limit rebuilds.
Question 3: How do you make an app fully RTL-correct?
Model-answer hint
Directionality, EdgeInsetsDirectional, AlignmentDirectional, mirroring icons only where meaningful, tests in both locales.
Question 4: Where do you store an access token on the device?
Model-answer hint
flutter_secure_storage backed by Keychain / Keystore, never SharedPreferences; refresh handling.
Question 5: When do you write a platform channel?
Model-answer hint
No maintained plugin or a native-only SDK; covers method channels, error handling and threading.
Question 6: A long list janks while scrolling. What do you check?
Model-answer hint
ListView.builder, image caching, DevTools frame chart, expensive builds, isolates for heavy work.
Question 7: How do you implement deep links that survive a login screen?
Model-answer hint
App Links / Universal Links, router guards, storing the pending route, testing cold and warm starts.
Question 8: Describe your release pipeline.
Model-answer hint
Flavours, code signing, Codemagic or Fastlane, staged rollout, crash monitoring, versioning policy.
Question 9: How do you test a Flutter feature?
Model-answer hint
Unit tests for logic, widget tests, golden tests for Arabic layouts, integration tests on real devices.
Question 10: A national-ID login times out. What should the app do?
Model-answer hint
Clear message, retry path, clean session state, logging without personal data.
Questions 11–20 (Mobile & Web core)
Question 11: How do you estimate a feature when requirements are still unclear?
Model-answer hint
break it down, name the unknowns, run a short spike, give a range and re-estimate as you learn.
Question 12: How do you integrate national-ID login such as Nafath or UAE Pass safely?
Model-answer hint
standard redirect or app-to-app flow, state and nonce checks, secure token storage, expiry and failure paths.
Question 13: What goes into your definition of done for a user-facing feature?
Model-answer hint
tests, accessibility checks, analytics events, error states, documentation, feature flag.
Question 14: How do you set and enforce a performance budget?
Model-answer hint
Core Web Vitals or startup targets measured on mid-range devices, with CI checks that fail on regression.
Question 15: How do you release safely to millions of users?
Model-answer hint
feature flags, staged rollout, crash and error monitoring, fast rollback, store review planning.
Question 16: How do you handle offline or unreliable connectivity?
Model-answer hint
local caching, optimistic updates with conflict handling, retries with backoff, clear user feedback.
Question 17: What do you check before an app starts handling payments?
Model-answer hint
PCI scope, tokenisation, idempotency, webhooks, reconciliation, provider sandbox tests.
Question 18: How do you keep dependencies and SDKs secure and current?
Model-answer hint
lockfiles, automated update pull requests, vulnerability scanning, licence checks, removing unused packages.
Question 19: A design cannot be built as drawn. What do you do?
Model-answer hint
early feasibility review, alternatives with trade-offs, design-system components, a shared decision with the designer.
Question 20: How do you review a colleague’s pull request?
Model-answer hint
correctness, readability, tests and security; small PRs; clear blocking versus non-blocking comments.
Interviewer tip: Ask for a real example after every answer. Strong candidates describe what they built, what broke and what they changed.
Practical task
90-minute live build in a provided Flutter starter. Implement a bilingual “service request” screen with form validation, an Arabic / English toggle that flips layout direction, a mocked API call with loading and error states, and secure storage of the returned token. Include 2 widget tests and one golden test in Arabic. Scored on architecture, RTL correctness, error handling and test quality.
How to run it Share the brief 24 hours ahead or run it live. Ask the candidate to talk through trade-offs as they work; reasoning matters more than a finished artefact.
Red flags our practice leads watch for
- Stores tokens or personal data in SharedPreferences.
- Hard-codes left and right padding and text alignment.
- Cannot explain why a widget rebuilds.
- Has never taken an app through App Store review personally.
- Universal flag: Vague answers that never reach a concrete system, number or decision the candidate personally owned.
The scorecard we use
Score each dimension 1–4 (1 = no evidence, 2 = partial, 3 = solid, 4 = exceptional):
| Dimension | Weight | What a 4 looks like |
|---|---|---|
| Technical depth, production judgement and security | 40% | Explains how and why, designs for failure and sensitive data, and knows each tool’s limits |
| Practical task and problem solving | 30% | Delivers a working solution with tests and documented decisions |
| Communication and documentation | 20% | Explains clearly to technical and non-technical audiences, in English or Arabic |
| References and regional context | 10% | References confirm the claimed scope; knows the frameworks and data-residency rules that apply |
Pass bar: weighted average of 3.0 out of 4 or higher, with no dimension below 2. The practice lead approves the final result.