SkilsMVP
BootcampInterview prep

AI Mock Interview — Spec

AI Mock Interview — Spec

This document specifies how the app runs an AI-driven mock interview using the drill banks in this folder (test-this-scenario.md, qa-fundamentals.md, bug-reporting-and-quality.md, behavioral-and-collaboration.md, automation-and-api-awareness.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 QA interviewer within the self-serve model. This is what turns "I read about the QA interview" (Topic 10) into "I've practiced the classic 'how would you test…' question dozens of times." The whole point of a QA screen is to watch how you think — this lets the learner rehearse thinking aloud, out loud, until it's a habit.

Session flow

  1. Choose a mode: a single question, or a full mock (e.g., 1 test-this-scenario + 1 qa-fundamentals + 1 bug-reporting + 1 behavioral, optionally adding an automation/API-awareness question), 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.
  3. Let the learner answer, ideally thinking aloud (typed or spoken). The AI may give one light nudge if the learner is stuck or silent (e.g., "What categories of tests would you run — happy path, then what?"), mirroring a real interviewer — but never feeds the answer.
  4. Optionally probe with a follow-up a real interviewer would ask ("What's an edge case there?" / "What's the severity vs. the priority of that bug?" / "What would you do if the developer says it's not a bug?").
  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:
    • Test-this-scenario: only covering the happy path; no negative/edge cases; ignoring usability, performance, or different conditions (browser, network, data); not structuring the answer into categories out loud; jumping to one test instead of being systematic.
    • QA-fundamentals: fuzzy definitions; confusing severity vs. priority, regression vs. retesting, verification vs. validation, or smoke vs. sanity; reciting a term without saying why it matters on a real team.
    • Bug-reporting-and-quality: a report that isn't reproducible (no clear steps, no expected vs. actual, no environment); no severity/priority; blaming language instead of factual, blameless reporting.
    • Behavioral-and-collaboration: not using STAR; vague stories with no concrete result; handling a developer disagreement with ego instead of staying factual and collaborative; not centering the learner's own actions.
    • Automation-and-api-awareness: over-claiming coding skill, or under-selling awareness; not knowing where automation fits (regression, repetitive checks) or what an API/status code is at a conceptual level.

Repeat & improve loop

  • Each session draws a fresh question (avoid immediate repeats) so practice isn't memorized — especially important for "how would you test X," where the thinking pattern should transfer to any new X (a pen, a login page, an elevator, a vending machine).
  • Track which rubric criteria the learner repeatedly misses across sessions and surface a "focus next on…" summary (e.g., "you usually cover the happy path but skip negative and edge cases," or "you keep mixing up severity and priority").
  • Tie into the program: mock-interview checkpoints recommend specific drill types by week (e.g., qa-fundamentals and test-this-scenario early to build the mindset, then bug-reporting and behavioral before the job hunt, with automation-and-api-awareness as a stretch).

Guardrails

  • The AI is a coach, not a gatekeeper — encourage retrying. A QA interview rewards a thorough, methodical mindset, so reward structure and breadth even when a specific answer is imperfect.
  • Never expose the rubric/model answer 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), its Framework (ideal structure), Model answer (reference), and Rubric (evaluation signals) — from the five drill files in this folder.
  • No additional data needed; the content is the spec.