Interview Drills — AI Mock Interview

Open-ended interview questions for the AI-driven mock interview. The app poses these drills verbatim and never reveals the Framework, Model answer, or Rubric while you answer — exactly as a real interviewer wouldn't hand you the scoring sheet. Each drill has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). Project/program interviews reward calm, organized thinking out loud: clarify the goal and the constraint, name the trade-off, and tie every answer back to delivery, communication, and risk.

How the mock interview runs: the AI draws drills from the four banks in this folder — behavioral.md, scenario-execution.md, frameworks-methodology.md, and project-deep-dive.md — and the representative drills below. It poses one prompt and waits, showing no rubric. If you stall, it gives one light nudge (e.g., "What would you clarify first, and who are the stakeholders?"), never the answer. It then probes with the follow-ups a real interviewer asks ("What did you do, specifically?" / "What if the deadline can't move?" / "What was on the critical path?"). When you finish, it scores against that drill's Rubric, gives per-criterion feedback (what landed, what was missing), names 2–3 concrete improvements, and ends with a "focus next on…" summary tracking the criteria you repeatedly miss across sessions. Only after scoring may it show the Model answer. The program recommends which drill types to practice by week — behavioral early, frameworks-methodology after Topics 5–6, scenario-execution after Topics 7–8, and the project-deep-dive once the capstone is underway, before the Topic 10 job hunt.

D1

difficulty: easy
concept: scenario-execution Walk me through what you'd actually do in your first two weeks running a project that's just been handed to you.
Framework: Start with initiation, not execution → clarify the goal and scope (what's in/out, what "done" means) → identify stakeholders and what each cares about → break the work into tasks and a rough schedule → surface the top risks → set a communication rhythm (standups, status reports). Emphasize understand before you act.
Model answer: "First I'd nail the goal and scope with the sponsor — what success means and what's explicitly out — because vague goals doom projects. Then I'd map stakeholders (who's affected, who has influence) and meet the team to understand the work. I'd build a rough task breakdown and schedule, list the top three risks, and set up a lightweight rhythm: a short daily standup and a weekly red/amber/green status. I'd resist diving into execution until the plan and the definition of done are agreed."
Rubric: Strong answers begin with initiation/planning (goal, scope, stakeholders) before execution, mention a definition of done, and set up communication. Weak answers jump straight to "assign tasks and start building," skip clarifying the goal, or never mention stakeholders or risks.

D2

difficulty: medium
concept: scenario-execution A stakeholder demands an extra feature that will blow the deadline, but the deadline is fixed. What do you do?
Framework: Don't say yes or no reflexively → clarify the request and why it matters → frame it with the triple constraint (scope/time/cost — you can't add scope while time and cost are fixed without sacrificing something) → present options (cut other scope, add resources, phase it for later, move the date) → recommend one and let the decision-maker choose → communicate the agreed trade-off.
Model answer: "I'd first understand why the feature matters — is it a must-have or a nice-to-have? Then I'd be honest about the trade-off: with time and budget fixed, adding scope means something else gives. I'd lay out options — drop a lower-priority item to make room, add a person if budget allows, or ship it in a fast follow after launch — with my recommendation. The stakeholder decides; I make the trade-off explicit and documented so no one is surprised later."
Rubric: Strong answers invoke the triple constraint, refuse to silently agree to the impossible, offer concrete options with a recommendation, and stress communicating the decision. Weak answers either cave ("I'd just make it work") or flatly refuse, without surfacing the trade-off or giving the stakeholder a real choice.

D3

difficulty: medium
concept: frameworks-methodology The daily standup on your team has turned into a 40-minute status meeting people dread. How do you fix it?
Framework: Diagnose what broke (it became a report-to-the-manager, not a team sync) → restate the purpose (a ~15-minute sync: done / doing / blockers) → re-establish the rules (time-box, standing, three questions, take deep-dives offline) → handle blockers in a separate "parking lot" after → measure improvement and adjust. Show you facilitate, not dominate.
Model answer: "A 40-minute standup usually means it's become a status report to me instead of a quick team sync. I'd reset the purpose: each person says what they did, what they'll do, and what's blocking them — that's it. Anything needing discussion goes to a parking lot we handle right after with only the relevant people. I'd time-box it to 15 minutes, keep it standing, and steer detailed problem-solving offline. After a week I'd check whether it feels useful and the team's getting their time back."
Rubric: Strong answers identify the anti-pattern (standup as status report), restate the standup's true purpose and the three questions, use a parking lot / take-it-offline tactic, and time-box. Weak answers just say "make it shorter" without changing the format, or treat the standup as a place for detailed problem-solving.

D4

difficulty: medium
concept: scenario-execution How do you manage risk on a project? Give me your process.
Framework: Define risk vs. issue (potential future problem vs. one already happened) → identify risks with the team ("what could derail this?") → assess each by likelihood × impact → plan a response for the serious ones (avoid / reduce / contingency) → track in a living risk register and revisit as the project evolves → give a concrete example.
Model answer: "Risk management is thinking about what could go wrong before it does. I brainstorm risks with the team, then rank each by likelihood and impact. For the high-likelihood, high-impact ones I plan a response — avoid it, reduce it, or have a contingency. For example, if a key contractor might be late, I'd line up a backup or build slack into the schedule. I keep all of this in a risk register I revisit regularly, so a foreseeable problem never blindsides us. The point is to look calm under pressure because I saw it coming."
Rubric: Strong answers give a clear process (identify → assess by likelihood × impact → respond → monitor), distinguish risk from issue, and ground it in a concrete example with a contingency. Weak answers are vague ("I just deal with problems as they come up"), skip prioritization, or treat risk management as pure reaction.

D5

difficulty: medium
concept: behavioral-star Tell me about a time a project went off track. What did you do?
Framework: Use STAR — Situation (the project and what went wrong), Task (what you were responsible for), Action (the specific steps you took to recover), Result (the outcome, ideally quantified) → emphasize early, honest communication and a concrete recovery move → end with a lesson learned. Tell a real, specific story, not a generic one.
Model answer: "Situation: I was coordinating a launch and two weeks in, a key dependency slipped a sprint, putting the date at risk. Task: I owned keeping it deliverable. Action: rather than hope it recovered, I flagged it to stakeholders early with options, re-sequenced the critical path so unblocked work continued, and pulled in a second person on the bottleneck. Result: we shipped only three days late instead of three weeks, and leadership trusted the heads-up. Lesson: surfacing the slip early — not at the deadline — is what protected the relationship."
Rubric: Strong answers follow STAR with a specific real story, center the candidate's own actions, quantify the result, and highlight early honest communication. Weak answers stay generic ("things were hard, I worked through it"), describe the team's actions rather than their own, skip the result, or reveal they hid the problem until it was too late.

D6

difficulty: hard
concept: behavioral-star Two senior stakeholders disagree on the project's priorities and it's blocking the team. You have no authority over either of them. How do you handle it?
Framework: Don't pick a side unilaterally → understand each side's underlying interest (talk to each separately) → bring the disagreement back to the shared goal and the data (impact, cost, risk of each path) → facilitate a decision: surface the trade-off, propose an option, get them in a room or escalate to a decision-maker if needed → document and communicate the decision so the team can move → note that leading without authority means influence, not orders.
Model answer: "I'd resist forcing my own call. First I'd meet each stakeholder one-on-one to understand what they actually need underneath the position. Then I'd reframe it around the shared goal and lay out the trade-offs with data — what each priority costs in time and risk. I'd propose an option and get them aligned, either in a short joint conversation or, if they're truly stuck, by escalating to whoever owns the decision. Once it's decided I document and broadcast it so the team unblocks. Without authority, my job is to create the clarity and the forum for a good decision, not to dictate one."
Rubric: Strong answers seek each side's underlying interest, anchor on the shared goal and data, facilitate or escalate toward a clear decision, and then communicate it — all while acknowledging influence-without-authority. Weak answers either impose their own preference, avoid the conflict and let it fester, or escalate immediately without first understanding both sides.