AI Mock Interview — Spec

This document specifies how the app runs an AI-driven mock interview using the drill banks in this folder (portfolio-walkthrough.md, app-critique.md, design-exercise.md, design-concepts.md, behavioral.md). It's a behavior spec for the future app — there's no app yet — written so the drills, frameworks, and rubrics already in the repo are everything the AI needs.

Goal

Give the learner realistic, repeatable interview practice with structured feedback, approximating a human design interviewer within the self-serve model. This is what turns "I read about interviews" (Topic 10) into "I've practiced the portfolio walkthrough and the whiteboard out loud, dozens of times." Design interviews are spoken and visual — the learner narrates a case study, critiques an app, or thinks aloud over a whiteboard — so the AI's job is to make them perform the reasoning, not recite it.

Session flow

1. Choose a mode: a single question, or a full mock that mirrors a real on-site loop (e.g., 1 portfolio-walkthrough + 1 design-exercise + 1 app-critique or design-concepts + 1–2 behavioral), optionally filtered by type, concept, or difficulty.
2. Ask a question. The AI poses a drill's prompt verbatim and waits — it does not reveal the Framework, Model answer, or Rubric.
3. Let the learner answer, thinking aloud (typed or spoken). Thinking aloud is the deliverable in design interviews — the AI should expect a narrated walkthrough, not a one-line answer. The AI may give one light nudge if the learner is stuck or silent (e.g., "Who's this for, and what problem are they stuck on?" / "Before you sketch screens — what would you clarify?"), mirroring a real interviewer — but never feeds the answer.
4. Optionally probe with a follow-up a real interviewer would ask ("Why that option and not the others?" / "How would you test that?" / "What would you cut?"). For portfolio-walkthrough and app-critique, the AI may push back on a decision (as those banks' hard drills do) to test composure — receiving critique without defensiveness is itself a scored signal.
5. Score and give feedback against the drill's Rubric when the learner finishes.

Scoring & feedback

• Evaluate the answer against the drill's Rubric signals and the Framework structure. Produce: an overall rating (e.g., Needs work / Solid / Strong), per-criterion notes (what was good, what was missing), and 2–3 concrete, actionable improvements.
• Only after scoring, optionally show the Model answer as a reference — never before.
• Be specific and kind: cite what the learner actually said. The aim is improvement, not a grade.
• Watch for the classic misses the rubrics encode, by bank:
  • Portfolio walkthrough — jumping straight to final screens, narrating every pixel, never centering a real user, no research or testing in the story, no problem→research→process→solution→testing→outcome arc, or getting defensive under pushback.
  • App critique — vague "I'd make it nicer" taste over a structured heuristic read, no concrete user/task, fixing before diagnosing the root cause, or critiquing aesthetics while ignoring usability.
  • Design exercise — drawing screens before clarifying the goal and user, skipping divergence (one idea dressed up as options), piling on steps without noticing friction, never naming a test plan or success metric.
  • Design concepts — jargon-as-answer (vocabulary without the why), no concrete example, conflating terms (IA vs. visual design, component vs. design system), or ignoring the trade-off/accessibility constraint.
  • Behavioral — not using STAR, telling a vague story with no specific situation or measurable result, taking no personal ownership ("we" with no "I"), or no reflection on what they learned.

Repeat & improve loop

• Each session draws a fresh question (avoid immediate repeats) so practice isn't memorized — and the portfolio walkthrough especially should be rehearsed many times until the story is fluent, not the script.
• Track which rubric criteria the learner repeatedly misses across sessions and surface a "focus next on…" summary (e.g., "you often skip clarifying the user before sketching," or "you defend decisions with taste instead of user evidence").
• Tie into the syllabus (../role.md): mock-interview checkpoints recommend specific drill types by stage — design-concepts and behavioral early (they reinforce Topics 3–9 craft), app-critique and design-exercise once the UX/UI core is covered, and a fluent portfolio-walkthrough over the capstone case study before the job hunt (Topic 10).

Guardrails

• The AI is a coach, not a gatekeeper — encourage retrying and re-narrating until the walkthrough flows.
• Never expose the rubric/model answer before the learner attempts the question.
• Keep feedback grounded in the rubric; don't invent criteria.
• Critique the reasoning and structure, not visual taste — these drills score process and articulation, not whether the learner's hypothetical UI is pretty.

Inputs the AI uses (already in the repo)

• The drill prompt (the question), its Framework (ideal structure), Model answer (reference), and Rubric (evaluation signals) — from the five drill files in this folder.
• For portfolio-walkthrough, the learner's own capstone case study (../capstone/) is the natural material to narrate.
• No additional data needed; the content is the spec.