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 structure design tokens?
Model-answer hint
Primitive, semantic and component layers; naming conventions; theming and mode support.
Question 2: How do you decide whether a pattern belongs in the system?
Model-answer hint
Reuse across teams, stability, contribution criteria; local components are allowed.
Question 3: How do you release changes without breaking products?
Model-answer hint
Semantic versioning, changelogs, deprecation windows, codemods, migration guides.
Question 4: How do you keep Figma and code in sync?
Model-answer hint
Token pipeline, shared naming, Storybook as reference, Code Connect, regular audits.
Question 5: A team keeps detaching components. What do you do?
Model-answer hint
Finds the gap, fixes or extends the component, uses detachment data; support, not policing.
Question 6: How do you build RTL support into components?
Model-answer hint
Logical properties, direction-aware icons, type scales per script, tests in both directions.
Question 7: Which accessibility checks belong at component level?
Model-answer hint
Keyboard, focus, ARIA patterns, contrast tokens, target sizes; documented per component.
Question 8: Which metrics prove a design system’s value?
Model-answer hint
Adoption and coverage, delivery time, defect reduction, consistency audits, team satisfaction.
Question 9: How would you set up multi-brand theming?
Model-answer hint
Brand token sets mapped onto semantic tokens, shared components, governance per brand.
Question 10: Tell us about a system decision you reversed.
Model-answer hint
Evidence, communication, how the migration was handled.
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. Given 2 brand style guides and a Figma file of inconsistent buttons and inputs, design a token architecture that supports both brands, light and dark modes, and Arabic and English. Rebuild the button and text-field components with variants and states, and write a 1-page governance proposal for contributions and releases.
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
- Treats the design system as a UI kit with no code counterpart.
- No experience with versioning or deprecation.
- Ignores accessibility at component level.
- Describes adoption as something to enforce rather than earn.
- 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.