Where a UX decision has to survive an edge case
Picture a multi-step signup form where a business account needs two extra fields a personal account doesn't, and a promo code field should only appear if the referral source equals a specific value. You're asked to write out the actual rules, not sketch a wireframe, but state precisely which fields show, hide, or become required under which conditions.
That's a real design decision, and it's also exactly the kind of logic that quietly breaks once an edge case shows up, two conditions overlapping, a field that should reset when an earlier answer changes. This challenge is graded on whether your written rules actually account for exactly that.
What gets covered
Sessions use the written challenge format, working through the conditional logic of a real interaction, form branching, error-state triggers, or the rules behind a multi-step flow, graded by an AI interviewer assessing whether your stated rules hold up against situations you didn't explicitly account for. Difficulty levels and hints are available.
This is distinct from a coding exercise; nothing here asks you to write executable code, only to reason precisely enough that the logic could be handed to an engineer without ambiguity. It's also distinct from resume-based practice, which asks about a project you've already shipped rather than handing you a fresh logic problem to solve on the spot.
Scoring
What scoring weighs here
Technical reflects whether your stated logic actually resolves correctly across edge cases, not just whether the happy path sounds reasonable. Communication matters just as much, since a designer who can state a rule precisely enough for an engineer to build it without a follow-up meeting is demonstrating a real, specific skill that a vague description of intent doesn't.
Frequently asked questions
Do I need to know how to code for this interview type?
No. It uses the written challenge format, reasoning through conditional logic in plain, precise language, not writing executable code.
What kind of problems come up in a UX technical session?
Conditional logic behind a real interaction, which fields show or hide based on an earlier answer, what triggers an error state, or how a multi-step flow should branch.
How is my answer actually graded if there's no code running?
An AI interviewer evaluates whether your stated rules hold up against edge cases beyond the obvious path, grading rigor and precision the way a senior reviewer would read a written analysis, not by executing anything.
Is this different from the comprehensive type's research and accessibility questions?
Yes. Comprehensive mixes research methodology with accessibility and stakeholder questions. This type is narrowly about conditional interaction logic, graded for correctness across edge cases.
Why would a UX designer need to practice this instead of an engineer?
Because the ambiguity usually starts on the design side. A rule stated loosely in a design file is what leaves an engineer guessing later, and this challenge grades whether the rule was precise enough to begin with.
Related pages
Practice the logic behind a real interaction
Work through a written conditional-logic challenge and get it graded on precision, not just judged on how it sounds.