How to Detect AI Cheating in UX Designer Case Study Interview
A UX designer case study interview is where a candidate walks through a design problem — often their own portfolio work or a live design prompt — and explains their process. The specific threat here is a candidate using an LLM in real time to generate the design rationale (user research framing, why a particular flow was chosen, how trade-offs were weighed) for a case study they either didn't actually do the reasoning for, or one that's entirely fabricated. Because case studies reward articulate storytelling, this format is especially exploitable — an LLM can produce polished UX-speak ("we prioritized reducing cognitive load by consolidating the flow") that sounds convincing without the candidate having made a single real design decision.
Observable Tells
| Tell | What It Looks Like | Why It Matters |
|---|---|---|
| Buzzword-dense, detail-light narrative | Heavy use of UX terminology (heuristics, cognitive load, information architecture) without a single concrete anecdote | Real practitioners default to specific stories; generated rationale defaults to vocabulary |
| Can't reconstruct the decision timeline | Vague or shifting answer when asked what came first — user interviews, wireframes, or the final flow | Genuine case studies have a memorable, defensible sequence; fabricated ones don't |
| Perfect justification for every choice | No design decision is described as a compromise, mistake, or thing they'd do differently | Real design work always involves trade-offs; an unbroken narrative of correctness is a red flag |
| Eyes reading during open-ended narrative | Steady gaze toward a fixed off-camera point while narrating the 'story' portion, not the visuals | Suggests a written script (possibly LLM-generated) is being read rather than recalled |
| Screen/portfolio doesn't match the verbal story | Described process steps aren't reflected in the actual artifacts shown (no research notes, no iteration history) | A fabricated narrative often can't be backed by the underlying work |
Interviewer Script: What to Watch For
- Ask for the messiest part of the project first — the thing that didn't work, or a stakeholder disagreement. Genuine case studies produce specific, textured answers here; fabricated ones stall or deflect to generic 'we iterated.'
- Request to see raw artifacts (research notes, early sketches, Figma version history), not just the polished final deck — real process leaves a paper trail.
- Ask the candidate to redesign one screen live, on the spot, with a new constraint (e.g., 'now design this for a screen reader user'). This can't be pre-generated and tests actual design thinking in real time.
- Watch for reading-pattern gaze during the narrative portion via AI Meeting Proctor, especially when the candidate transitions from showing visuals to describing rationale.
- Ask 'what would you change if you did this again' — genuine designers have a ready, specific answer; fabricated case studies often can't generate genuine self-critique convincingly.
What Evidence to Capture
For a defensible hiring record, capture and timestamp the following the moment something looks off — don't rely on memory after the call ends.
- Screen recording of the portfolio walkthrough, including any raw artifacts shown
- Gaze-pattern alerts during the narrative segments, time-aligned to specific questions
- The live redesign exercise output and the candidate's real-time reasoning for it
- Notes on any inconsistency between the verbal story and the artifacts actually shown
- Version history or file metadata from the design tool, if accessible, corroborating the claimed timeline
Which Neuroxa Product Covers This
AI Meeting Proctor
Case study interviews are live conversational rounds where the risk is scripted or AI-generated rationale being read during the narrative portion, not a submitted file. AI Meeting Proctor's gaze and window-focus tracking through the live call highlights exactly when a candidate shifts from natural recall to reading, giving interviewers a concrete signal to probe further rather than a vague feeling that something 'sounded off.'
FAQs
Is it wrong for a candidate to prepare notes for their own case study?
No — preparing talking points about your own real work is normal and expected. The concern is rationale generated by AI for work the candidate didn't actually reason through, which the live redesign exercise and raw-artifact request are designed to surface.
What if the candidate genuinely used AI tools as part of their real design process?
That's increasingly common and often fine — ask them to be explicit about where AI assisted (e.g., generating research synthesis) versus where the design judgment was theirs, and evaluate the judgment specifically.
How do I evaluate a candidate who's simply not a strong public speaker?
Weak delivery with strong, specific, textured answers about the messy parts of a project is a very different profile from smooth delivery with vague or shifting details. Judge specificity, not polish.
Should we require candidates to share their screen with editable source files, not just a PDF?
Yes, where practical — asking for the working file (Figma, not a static export) makes it much harder to present fabricated process as real.
What about candidates presenting a team project as solely their own?
Ask directly what specific decisions were theirs versus the team's, and probe for a disagreement they had with a teammate — genuine contributors can usually answer this specifically.
Related Pages
- UX Designer Phone Screen
- UX Designer Zoom Panel Interview
- Product Manager Async Video Interview
- Financial Analyst Case Study Interview
Ready to stop guessing? See how Neuroxa.ai's AI Meeting Proctor works and add defense-in-depth — identity, environment, and behavior signals — to every round of your hiring process.