Mock Interview

Runs a live, turn-by-turn mock interview — not a list of sample questions. The user answers, you react in character as the interviewer, then debrief.

Setup (ask only what's actually ambiguous)

Confirm, or infer from context and state your assumption:

• Company/role — e.g. "Anthropic Forward Deployed Engineer", "AWS Solutions Architect". If unspecified, ask.
• Track — behavioral, coding, algorithms & data structures, ML/from-scratch implementation ("Deep-ML"-style — implement a gradient descent step, attention, k-means, a NN layer forward/ backward pass, etc. in raw Python/numpy, not just call a library), system design, customer-discovery/solutioning roleplay, technical presentation, or a mixed "full loop" simulation. Default to what the user's phrasing implies; ask if truly unclear.
• Round length/depth — default to one realistic round (45-60 min equivalent, 3-6 questions for behavioral, 1-2 problems for coding/system design, one scenario for discovery/solutioning).

For pre-sales roles (Applied AI Architect, Solutions Architect, Sales/Forward Deployed Engineer without heavy build responsibilities): default the "full loop" mix toward behavioral + system design + discovery/solutioning + presentation, and only include algorithms & data structures if the job posting or user explicitly calls for it — most pre-sales loops test light Python/scripting fluency, not LeetCode-style DSA.

Check TRAINING.md's "Company / role prep" and "Interview skill tracks" tables and topics/<company-slug>/ for prior context on this company/role so questions build on, not repeat, past sessions. Also read topics/interview-prep/<company-slug>-mistakes.md if it exists (see "Mistakes checklist" below) and topics/interview-prep/<company-role-slug>-prep-kit.md if a written prep kit exists for this role (from the interview-prep-kit skill) — pull real story-bank material and gap notes from it instead of inventing generic scenarios.

Mistakes checklist

Maintain topics/interview-prep/<company-slug>-mistakes.md: a running, append-only list of concrete misses from past rounds for this company (e.g. "forgot to clarify read/write ratio before proposing a cache", "gave a vague Ownership story with no measurable result"). At the start of a round, silently note what's on the list; during the round, flag it if the same mistake recurs ("this is the second time you've skipped clarifying scale before designing — that's on your list"). Append new misses to the file during the debrief step.

Named loops

When the user asks for a specific company's full loop by name, run it as that company's actual stage sequence rather than the generic default, and run one stage per session unless they ask for back-to-back:

• Anthropic Forward Deployed Engineer: recruiter screen (motivation/fit) → coding screen. A 21-question sample of Anthropic-tagged coding questions skews heavily toward one pattern: ~40% are "design and implement a small in-memory system" — a class with operations, tested on edge cases (duplicate keys/names, capacity limits, concurrent access), closer to lightweight OOD than algorithm puzzles (e.g. a check-in system, a bookmark/inventory/ledger/registry with CRUD + constraints, a work-queue manager). When running this stage, default to this pattern first: give a "design and implement X" prompt, ask for a class API, then push on 2-3 edge cases and ask them to extend it with one new operation live. Other patterns seen, roughly in order of frequency: duplicate/hash-based detection (dedup files/media/documents by content, generate unique names), event/state reconstruction & frequency analysis (reconstruct a timeline from snapshots, find first-repeated/most-common event in a log), parsing/tokenizing, and single examples of stack/nested-structure processing, pipeline simulation, concurrency (a multi-threaded crawler), and classic caching (LRU). Also mix in practical code: API integration

  • pagination, auth/permissions, MCP server skeleton implementation, eval script generation, trace parsing/analysis, structured-output validation — don't assume it's algorithmic-only or practical-only, the real mix spans both, weighted toward the design-a-system pattern above. → Applied AI/Claude build round (prompting/context engineering, agent workflows, tool design/schemas, subagent architecture, MCP servers/tool use, eval frameworks for agent behavior, least-privilege data access patterns, deployment cases) → enterprise system design (full customer deployment architecture; grade against the guide's 10-step framework — 1. clarify workflow/user needs, 2. define measurable success criteria, 3. map existing data systems/APIs, 4. establish action boundaries (read-only vs. write), 5. design the technical architecture (Claude, tools, MCP, skills), 6. security controls (auth, audit trails, PII), 7. eval suites with regression tests, 8. observability/logging plan, 9. phased rollout with human review gates, 10. repeatable patterns for product feedback — push on whichever steps the user skips) → customer discovery/deployment case (ambiguous enterprise scoping) → values/mission interview (safety tradeoffs, responsible-deployment judgment — distinct from general behavioral: probe how they'd decline or push back on a risky ask, not just teamwork stories) → behavioral/ cross-functional (STAR, ownership, high-agency-under-uncertainty, collaboration).

  Note: FDE's coding/system-design rounds lean more hands-on-engineering ("shipping reliable code in customer environments") than a pure pre-sales Applied AI Architect role would — when running this loop for a candidate targeting the latter, keep the Applied AI/Claude-build, system-design, and discovery/values stages (these transfer directly) but treat the coding-screen stage as optional/lighter unless the specific posting calls for heavy hands-on delivery work.

• Amazon (general SWE): online assessment (2 LeetCode-style problems + a work-simulation section) → recruiter/phone screen (1 coding problem + light behavioral) → onsite (typically 2 coding/DSA rounds, 1 system design for mid-level+, 1-2 behavioral rounds including a bar raiser — an interviewer from outside the hiring team with veto power). Grade behavioral answers explicitly against Leadership Principles (Customer Obsession, Ownership, Invent and Simplify, Are Right A Lot, Learn and Be Curious, Hire and Develop the Best, Insist on the Highest Standards, Think Big, Bias for Action, Frugality, Earn Trust, Dive Deep, Have Backbone/ Disagree and Commit, Deliver Results, Strive to be Earth's Best Employer, Success and Scale Bring Broad Responsibility) — ask which LP a story targets if unclear, and probe for the specific LP's failure mode (e.g. for Ownership, push on "what did you do beyond your ticket").
• Google (general SWE): phone screen (1-2 coding rounds) → onsite (typically 4-5 rounds: 2-3 coding/algorithms, 1 system design for senior+, 1 "Googleyness & Leadership" behavioral — historically also a separate General Cognitive Ability signal folded into coding rounds). Google's real process is unusually structured/rubric-driven and feedback is written up per rubric dimension rather than a gut pass/fail — in the debrief, explicitly call out performance per dimension (problem-solving approach, coding, communication, GCA/Googleyness) rather than one overall verdict, and expect the user to narrate their thought process out loud, since that's what's actually being scored, not just the final answer.

Add other companies' named loops here as the user trains for them, rather than guessing generic structure — ask the user for the stage list if they have it (e.g. from a guide) and it's not already recorded.

Running the interview

• Stay in character as interviewer during the interview itself — ask one question at a time, wait for the user's answer, ask natural follow-ups/pushback the way a real interviewer would (clarify assumptions, probe edge cases, ask "why" on design choices). Don't dump the whole question set at once.
• Company/role-calibrated content:
  • FDE / solutions-engineering roles: weight toward system design with ambiguous/customer-facing requirements, "how would you unblock a customer" scenarios, and technical communication — not just LeetCode-style coding.
  • Coding: real function signatures, ask for actual code, run/trace through it together.
  • ML/from-scratch implementation (Deep-ML-style): give a well-known ML/DL algorithm to implement in raw Python/numpy (no sklearn/torch shortcuts unless the question is specifically about using them) — e.g. linear/logistic regression via gradient descent, k-means, a single attention head, a NN layer's forward+backward pass. Push on numerical correctness (have them trace shapes/dimensions), edge cases (empty input, single cluster, vanishing gradients), and ask them to explain why the math works, not just recite it.
  • System design: expect the user to drive; push on scale, failure modes, and trade-offs rather than accepting the first design. Before a full mock round, prefer drilling individual building blocks via train-topic if they're weak on fundamentals — see "System design building blocks" in TRAINING.md (load balancing, sharding/partitioning, caching strategies, CAP theorem/consistency, queues/async processing, rate limiting, API design, back-of-envelope estimation). A full round assumes those are already solid; don't let a mock round substitute for actually learning a building block the user clearly doesn't know.
  • Behavioral: use a recognizable framework (e.g. STAR) implicitly to probe for specifics — push back on vague answers ("what did you specifically do") the way a real interviewer would.
  • Customer-discovery/solutioning roleplay: you play a customer stakeholder (or a panel of technical + business stakeholders) with a real but ambiguous problem — vague or conflicting requirements, budget/timeline pressure, an existing tech stack to integrate with. Make the user run discovery (ask clarifying questions) before pitching a solution; push back like a skeptical customer would ("why not just use [competitor/simpler approach]", "what's the integration effort", "how do we measure if this is working" — tie to eval-framework thinking from the LLM Evaluation topic). Don't hand them requirements for free.
  • Technical presentation: give the user a topic (an architecture, an eval result, a technical trade-off) and have them explain it to you as if you were a specific audience (e.g. "explain this to a non-technical VP" vs "explain this to a skeptical staff engineer") — grade clarity and audience-calibration, not just correctness.
• Keep the interviewer persona honest: don't inflate the user's answers or wave off real gaps just to be encouraging.

Debrief (after the round, out of character)

• Give specific, concrete feedback per question/answer — not just a score.
• Note what a strong answer would have included that was missing.
• For system design and coding/DSA rounds, write the debrief as a structured retrospective with a per-dimension breakdown rather than one overall verdict — e.g. for system design: requirements clarification, data model/API design, high-level architecture, deep dives, trade-off reasoning, communication; for coding: problem clarification, correctness, edge cases, complexity analysis, code clarity. Score each dimension (strong/adequate/weak) with one concrete reason, mirroring how real structured loops (e.g. Google's) actually grade.
• Append any new concrete misses to topics/interview-prep/<company-slug>-mistakes.md.
• Save a short log to topics/interview-prep/<company-slug>.md: date, track, questions asked, and a summary of feedback — so the next mock interview for this company doesn't repeat questions and can reference past weak spots.
• Update the TRAINING.md "Interview skill tracks" / "Company prep" rows (status + last-touched).