Interview Drills — Frameworks & Methodology

Open-ended interview questions. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). These drills prove fluency in the vocabulary — agile vs. waterfall, Scrum, Kanban, the lifecycle, critical path, risk vs. issue, RAG. Practice thinking aloud, define the term crisply, then ground it in a real situation. The app can role-play these as mock interviews (see mock-interview.md).

The universal methodology structure: Define the concept in one clean sentence → explain why it exists / what problem it solves → give a concrete example from real work → state when you'd use it (and when you wouldn't). Define-then-apply beats reciting a definition.

D1

difficulty: easy
concept: agile-vs-waterfall What's the difference between agile and waterfall, and how would you decide which to use?
Framework: Define each in one sentence → name the core trade-off (predictability vs. adaptability) → give the decision rule (requirements certainty + cost of change) → an example of each → end with "match the method to the project, don't be dogmatic."
Model answer: "Waterfall runs phases in strict sequence — requirements, design, build, test, release — each finished before the next, with heavy up-front planning. Agile works in small increments, gets feedback often, and adapts. I choose by two questions: how fixed are the requirements, and how costly is change? Fixed and well-understood with expensive change — say a regulated or construction project — favors waterfall's predictability. Uncertain or evolving requirements where feedback is valuable — most software — favors agile. Many real projects are hybrids. The mature stance is methodology-aware, not dogmatic: the framework serves the goal of delivering value."
Rubric: Strong answers define both crisply, articulate the requirements-certainty / cost-of-change trade-off, and give a concrete example of each rather than declaring agile universally "better." Weak answers treat waterfall as simply bad, can't say when each fits, or recite the agile manifesto without a decision rule.

D2

difficulty: easy
concept: scrum-roles-artifacts-ceremonies Walk me through Scrum — its roles, artifacts, and ceremonies.
Framework: State Scrum is a specific framework for doing agile → the three roles and what each owns → the three artifacts → the sprint as the heartbeat → the ceremonies and each one's purpose → optionally a tool (burndown chart).
Model answer: "Scrum is the most common framework for running agile. Three roles: the Product Owner owns and prioritizes the backlog, the Scrum Master facilitates the process and removes blockers, and the Development Team builds the work. Three artifacts: the Product Backlog (everything that could be built, prioritized), the Sprint Backlog (the slice committed for this sprint), and the Increment (the working, done piece each sprint). The sprint — often two weeks — is the heartbeat. Ceremonies: Sprint Planning to commit the work, a ~15-minute Daily Standup to sync and surface blockers, the Sprint Review to demo the increment to stakeholders, the Retrospective to improve how the team works, and ongoing Backlog Refinement. A burndown chart tracks remaining work so the team sees if it's on pace."
Rubric: Strong answers get all three roles with what each owns, distinguish Product Backlog vs. Sprint Backlog, and tie each ceremony to its purpose (especially Review = demo to stakeholders vs. Retro = improve the process). Weak answers confuse the roles (e.g., "Scrum Master assigns tasks"), blur the two backlogs, or list ceremonies as a flat checklist with no purpose.

D3

difficulty: medium
concept: kanban-wip-limits Explain Kanban and WIP limits. When would you pick Kanban over Scrum?
Framework: Define Kanban (visualize and manage continuous flow on a board) → contrast with Scrum's fixed sprints → explain WIP limits and the principle behind them → say what they reveal (bottlenecks) → state the fit (continuous, unpredictable work) → note hybrids exist.
Model answer: "Kanban visualizes work as cards flowing across a board — To Do, In Progress, Done — and manages continuous flow rather than fixed sprints. Its power is the WIP limit: you cap how many items can sit in a column at once. That sounds counterintuitive but it's 'stop starting, start finishing' — it stops everyone juggling ten half-done things and forces the team to finish before pulling in more. A WIP cap also makes bottlenecks obvious: if 'In Progress' is jammed at its limit, the pile-up is visible immediately. I'd pick Kanban over Scrum when work arrives as a continuous, unpredictable stream — support, operations, on-call — where two-week sprint commitments feel artificial. Many teams blend the two as 'Scrumban.'"
Rubric: Strong answers state the WIP principle ("stop starting, start finishing"), explain that limits expose bottlenecks, and pick the continuous/unpredictable-flow context for Kanban over Scrum. Weak answers describe Kanban as "just a Trello board," think WIP limits mean doing less work, or can't articulate a situation where Kanban beats Scrum.

D4

difficulty: medium
concept: project-lifecycle Walk me through the phases of a project lifecycle and where projects typically go wrong.
Framework: Name the five phases in order → one line on the purpose of each → call out that Monitoring & Controlling runs alongside Execution → flag the classic failure mode (skipping initiation/planning, or skipping closure) → tie to a habit.
Model answer: "Five phases: Initiation defines why the project exists, its goal and scope, and whether it's worth doing. Planning works out how — tasks, schedule, budget, risks. Execution is the team doing the work while the project manager keeps it on track. Monitoring & Controlling runs in parallel with execution: comparing actual progress to the plan and adjusting when reality drifts. Closure confirms the deliverable is accepted, hands it over, and runs a retrospective. The classic failure is rushing into execution before properly initiating and planning — that's how teams build the wrong thing. The other is skipping closure, so the hardest-won lessons are never captured. Projects rarely go exactly to plan; managing the deviations is the real skill."
Rubric: Strong answers give all five phases in order, correctly note Monitoring & Controlling is concurrent with execution (not a later step), and name a real failure mode with the fix. Weak answers misorder the phases, treat monitoring as a discrete stage after execution, or omit closure/retrospective.

D5

difficulty: medium
concept: critical-path What is the critical path, and how do you use it to protect a deadline?
Framework: Define it (longest chain of dependent tasks → minimum project duration) → contrast critical-path tasks (no slack) vs. off-path tasks (slack/float) → explain how it changes where you focus attention → give a concrete management move → connect to honest scheduling.
Model answer: "The critical path is the longest chain of dependent tasks through the schedule — it sets the project's minimum possible duration. Tasks on it have zero slack: any slip there delays the whole project. Tasks off the path have float, so a small delay there is absorbed. Practically, this tells me where to spend my attention: I watch critical-path tasks closely and protect them first — if one's at risk I'll reallocate help to it before worrying about a task with slack. It also guides honest crashing decisions: to pull in the date you have to shorten the critical path, not just any task. And it keeps me realistic — promising a date shorter than the critical path is promising the impossible."
Rubric: Strong answers define it as the longest chain of dependent tasks setting minimum duration, correctly contrast slack on vs. off the path, and translate that into where to focus or how to crash. Weak answers call it "the most important tasks" or "the shortest path," miss the dependency/slack idea, or can't connect it to a real scheduling decision.

D6

difficulty: hard
concept: risk-vs-issue-rag A stakeholder asks why a project is flagged 'Amber' this week. Walk me through risk vs. issue and how you'd use RAG status to communicate.
Framework: Define risk vs. issue cleanly (potential future vs. already happened) → define RAG (red/amber/green health at a glance) → map the situation: amber = a serious risk or a contained issue threatening the plan → describe the response (assess by likelihood × impact, contingency, communicate early) → tie to the core habit of surfacing problems early.
Model answer: "First the distinction: a risk is a potential future problem; an issue is one that's already happened. Good risk management turns would-be issues into risks we planned for. RAG is a red/amber/green health summary so stakeholders see status at a glance — green is on track, amber is at risk or recovering, red is in trouble. I'd flag amber when a high-likelihood, high-impact risk has emerged or a real issue has hit but I have it contained. So I'd say: 'Amber because our key vendor signaled they may slip a week — that's a risk I've assessed as likely and high-impact. My contingency is to pull a backup vendor and I've built two days of slack on the critical path. I'm flagging it now, early, so there are no surprises.' The whole point of RAG and of risk management is to surface trouble before it becomes a crisis — that early, honest heads-up is what builds trust."
Rubric: Strong answers nail the risk-vs-issue distinction (potential vs. realized), define RAG accurately, and connect amber to a specific risk assessed by likelihood × impact with a contingency and an early, honest message. Weak answers conflate risk and issue, treat amber as vague "kind of behind," or describe status reporting with no assessment, no response plan, and no early-communication instinct.