AI Mock Interview — Spec

This document specifies how the app runs an AI-driven mock interview using the drill banks in this folder (sql-technical.md, case-study.md, metrics-and-analysis.md, stakeholder-storytelling.md, behavioral.md). It's a behavior spec for the future app — there's no app yet — written so the drills 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 mock interviewer within the self-serve model. This is what turns "I read about data-analyst interviews" (Topic 11, Landing the Job) into "I've practiced them dozens of times" — across the live SQL screen, the take-home/case study, the metrics conversation, and the behavioral round.

Session flow

1. Choose a mode: a single question, or a full mock that mirrors a real loop (e.g., 1 SQL technical + 1 case study + 1 metrics-and-analysis + 1 stakeholder-storytelling + 1 behavioral), optionally filtered by type 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. For SQL drills it presents the table schema/scenario as given and asks for a query; for case studies it states the business situation and the dataset assumptions.
3. Let the learner answer, ideally thinking aloud (typed query, or spoken reasoning for a case). The AI may give one light nudge if the learner is stuck or silent (e.g., "What grain is one row in that table?" / "What's the decision this analysis informs?"), mirroring a real interviewer — but never feeds the answer or writes the SQL for them.
4. Optionally probe with a follow-up a real interviewer would ask ("How would this query behave with NULLs / duplicates?" / "Why that metric and not retention?" / "How would you explain this to a non-technical VP?").
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 or wrote (quote the exact clause of their SQL, the metric they chose, the line they'd say to the stakeholder). The aim is improvement, not a grade.
• Watch for the classic misses each bank's rubric encodes:
  • SQL technical — wrong join type or fan-out from a many-to-many join, missing/incorrect GROUP BY, filtering in WHERE vs HAVING, ignoring NULLs and duplicates, no handling of ties or date boundaries, an unreadable query with no aliases or CTEs.
  • Case study — not clarifying the question or success criteria, no plan before diving in, ignoring data caveats (sampling, missing data, confounders), confusing correlation with causation, no clear recommendation tied back to the business decision.
  • Metrics & analysis — no clear metric definition (numerator/denominator, grain, time window), no segmentation or baseline, not distinguishing a real change from noise, no guardrail/counter-metric, jumping to a cause without checking the data.
  • Stakeholder storytelling — leading with method instead of the answer, no "so what," wrong altitude for the audience, no recommendation or next step, charts that don't support the claim.
  • Behavioral — not using STAR, no quantified impact, vague "we" instead of "I," no reflection or lesson learned.

Repeat & improve loop

• Each session draws a fresh question (avoid immediate repeats) so practice isn't memorized.
• Track which rubric criteria the learner repeatedly misses across sessions and surface a "focus next on…" summary (e.g., "you often forget to handle NULLs in your joins," or "you lead with method before the headline").
• Tie into the program (../program.md): mock-interview checkpoints recommend specific drill types by week (e.g., behavioral early; SQL technical throughout; case study, metrics-and-analysis, and stakeholder-storytelling before the job hunt).

Guardrails

• The AI is a coach, not a gatekeeper — encourage retrying.
• Never expose the rubric/model answer (or write the learner's SQL) before the learner attempts the question.
• Keep feedback grounded in the rubric; don't invent criteria.

Inputs the AI uses (already in the repo)

• The drill prompt (the question, plus any table schema or business scenario), its Framework (ideal structure or query approach), Model answer (reference solution), and Rubric (evaluation signals) — from the five drill files in this folder.
• No additional data needed; the content is the spec.