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: What changed between WCAG 2.1 and 2.2?
Model-answer hint
New criteria such as focus not obscured, target size minimum, dragging movements, accessible authentication, redundant entry; 4.1.1 Parsing removed.
Question 2: When should you avoid ARIA?
Model-answer hint
Native HTML first; bad ARIA is worse than none; gives concrete misuse examples.
Question 3: How do you make a custom dropdown accessible?
Model-answer hint
Combobox / listbox pattern, keyboard support, focus management, announcements; prefers native select where possible.
Question 4: What can automated tools not detect?
Model-answer hint
Meaningful alt text, logical focus and reading order, error context; most issues need manual checks.
Question 5: How do you handle focus after a route change in a single-page app?
Model-answer hint
Move focus to the main heading, announce the page title, keep skip links working.
Question 6: How do you test mixed Arabic and English content with a screen reader?
Model-answer hint
lang attributes on spans, dir handling, numbers, voice switching in VoiceOver and NVDA.
Question 7: How do you prioritise 300 audit findings?
Model-answer hint
User impact on critical journeys, frequency, legal exposure, effort; component-level fixes first.
Question 8: How do you meet accessible authentication under WCAG 2.2?
Model-answer hint
No cognitive tests without an alternative; allow paste and password managers; passkeys.
Question 9: What belongs in an accessibility statement?
Model-answer hint
Conformance level, known limitations, contact route, enforcement procedure, review date.
Question 10: How do you persuade a team that sees accessibility as overhead?
Model-answer hint
Component-level wins, legal and market facts, user recordings, small fixes inside the sprint.
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
Timebox 2 hours. Audit a provided bilingual sign-up flow (web) against WCAG 2.2 AA using automated tools and a screen reader. Deliver the top 10 issues ranked by impact with success-criterion references, then fix 3 of them in the provided code and add one axe-core test in Playwright.
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
- Relies solely on automated scanners or overlay widgets.
- Adds ARIA roles everywhere instead of using native elements.
- Cannot operate a screen reader without guidance.
- Reports issues without code-level remediation advice.
- 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.