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: Walk us through a project where research changed your direction.
Model-answer hint
Specific evidence, what changed, impact; not a list of process steps.
Question 2: How do you frame a vague request such as “redesign the dashboard”?
Model-answer hint
Asks who uses it, which decisions it supports and current metrics; problem statement before pixels.
Question 3: How do you measure whether a design worked?
Model-answer hint
Success metrics agreed upfront, analytics, usability measures, qualitative feedback.
Question 4: How do you work inside a design system you disagree with?
Model-answer hint
Uses it, documents gaps, proposes changes through the contribution model.
Question 5: How do you design for Arabic and English at the same time?
Model-answer hint
Mirroring rules, typography pairing, text expansion, directional icons, testing with native readers.
Question 6: Which WCAG 2.2 criteria affect your daily design work?
Model-answer hint
Contrast, target size, focus visible and not obscured, consistent help, accessible authentication.
Question 7: How do you handle conflicting stakeholder feedback?
Model-answer hint
Returns to goals and evidence, tests alternatives, makes trade-offs explicit.
Question 8: What does a good handoff contain?
Model-answer hint
Components, tokens, states, edge cases, responsive and RTL notes, presence during build.
Question 9: Tell us about a design you shipped that failed.
Model-answer hint
Honest account, what was learned, what changed in their process.
Question 10: Engineering capacity is cut in half. How do you re-plan?
Model-answer hint
Core user value, smallest testable slice, sequencing the rest.
Questions 11–20 (Design core)
Question 11: How do you decide what to research before designing?
Model-answer hint
biggest unknowns and riskiest assumptions first; method matched to the question and the timeline.
Question 12: How do you turn research findings into design decisions?
Model-answer hint
synthesis into insights, prioritised opportunities, a traceable link from evidence to design.
Question 13: How do you design for users with low digital literacy?
Model-answer hint
plain language, familiar patterns, fewer steps, forgiving inputs, testing with those users.
Question 14: How do you design within strict regulatory or legal constraints?
Model-answer hint
involve compliance early, treat mandatory content as requirements, offer plain-language alternatives, record approvals.
Question 15: How do you include people with disabilities in research and testing?
Model-answer hint
recruitment through partner organisations, assistive-technology set-ups, accessible materials, fair incentives.
Question 16: How do you present design work to executives?
Model-answer hint
problem and goal first, options with trade-offs, evidence, a clear decision request.
Question 17: How do you use generative AI tools in your workflow responsibly?
Model-answer hint
exploration and speed, human refinement, licensing and brand rules, no confidential data in prompts.
Question 18: How do you design error states and edge cases?
Model-answer hint
list failure modes, give clear recovery guidance, preserve user input, test with real data.
Question 19: How do you keep quality high when deadlines are tight?
Model-answer hint
protect critical journeys, reuse system components, agree what is deferred, record design debt.
Question 20: How do you work with engineers while a feature is being built?
Model-answer hint
available for questions, reviews preview builds, pragmatic adjustments, shared ownership of quality.
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 3 hours. Redesign the onboarding flow of a provided bilingual banking app. Deliver a problem statement, a user flow, 4 key screens in English and Arabic built from the supplied component library, and a 1-page plan for testing the design with 5 users, including success metrics.
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
- Portfolio shows final visuals with no reasoning.
- Designs in English only and “flips” for Arabic at the end.
- Routinely detaches components instead of working with the system.
- Cannot name a metric their work moved.
- 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.