Practise the Two-Week Delivery Round

Seven boxes in a row are easy to draw in an hour, but the round is won by showing which boxes are enforced gates and naming honestly which parts are not built.

The two-week delivery prompt rewards a candidate who treats it as an operating-model question in the first two minutes and spends the deep dive on gates and reuse. This lesson lays out a 60-minute plan, then a set of practice prompts to answer aloud before checking the outline.

Objectives:

• run the 60-minute round with a time budget and a framing sentence;
• ask the clarifying questions that change the design, and anchor on a measurable case;
• handle the scale, trade-off and close questions, and answer the common follow-ups.

The prompt, from the DevRev interview preparation guide: design a delivery framework that takes a customer from scoping doc to deployed AI agent in under two weeks.

Open by naming what kind of question it is. In substance: this is an operating-model question, not a software architecture one; anyone can draw a pipeline of seven boxes; the signal is whether each box is an enforced gate or a status someone reports honestly; so the design makes the gates code rather than trust. That framing names the real test, shows the candidate noticed the question is different, and sets up the deep dive.

Write the time budget in the corner of the board.

Five questions move the design. Is "two weeks" a hard SLA or a target? That decides whether a failed gate means slip the date or abort and re-scope. Who owns go/no-go: the FDA, the account team or the customer? That decides the allowed role on the final gate. What is genuinely reusable across customers? The library works for the fiftieth customer of a proven type, much less for a new type. What happens when a gate fails outright, not late: pause or terminate? Is this for one team or the whole organisation? That decides whether the library is a shared, versioned asset or tribal knowledge.

Then scope out loud: the pipeline is a state machine with role-gated checkpoints and a library behind each stage, and the infrastructure-provisioning layer under "configure, do not code" is named but not designed.

Anchor on Northwind Logistics: a tier-1 support triage agent over Zendesk, Confluence and Salesforce, with metrics agreed in writing before day 1. First-response time under 5 minutes on the top three ticket categories, and zero-edit sends on 60% of eligible tickets by week 4. Both are measurable from timestamps and edit history. Say early that a metric this clean is a condition of intake, because refusing unmeasurable requests is the cheapest high-signal idea in the design.

List the entities before the boxes: engagement, stage, gate, principal (a role), artefact, accelerator asset, escalation, metric. Then narrate one engagement in words. A request arrives; intake checks it is measurable and has an SME, or refuses. Accepted, it enters scoping on day 1. Each later stage sits behind a named gate that only the authorised role can sign. Each stage pulls from the library before building anything. On day 14, if the metrics were met, the sponsor signs go/no-go and the engagement deploys with a runbook and dashboards.

Only then draw the pipeline, labelling every gate with who signs it. The full diagram is in Role-Gated Stage Gates.

Announce where the risk is. Seven stages in order is not a hard problem. The hard parts are making "done" checkable rather than "time passed", and making the library real enough that week two does not turn into bespoke code.

For gates, contrast a naive checkbox with a sign-off that checks role, requires evidence and enforces order. The FDA closing their own security gate is the delivery version of a model enforcing its own access control.

For reuse, give the number: reuse rate is reused pulls over total pulls, and Northwind's is 83%. Then say what the library honestly is not. Its entries are named assets, not real connector code or a real evaluation harness. The evaluate stage asserts a score rather than calling a harness. The gate mechanism is real; one piece of evidence behind it is not yet.

Scale here is not chunk count; it is one FDA running six engagements at once. The state machine does not change with portfolio size, because each engagement has the same gates. What is hard is capacity: how many engagements one person can carry before gates queue behind their calendar rather than the customer. That needs real engagement-duration data before designing, just as cache sizing needs real query logs.

Warning: claiming all four risk mitigations are built invites the follow-up that exposes the one that is not. Show three real checks and name the missing scope-change control. An honest gap survives probing; an overclaim does not.

Summarise in three sentences: every transition sits behind a role-gated decision, not a status field; assets are pulled before anything is built, and that ratio is tracked; and the risk mitigations are checks in code, with the missing one named.

Then give the forward-deployed close. Rolling this out internally, week one is not all seven stages. Pick the two gates most often skipped under deadline pressure, which in the source author's experience are the golden-set sign-off and the rollback test, and make only those structurally unskippable. That proves the risky claim, that gates as code change behaviour, before anyone debates the other five.

Good questions to ask the interviewer: what the real accelerator library looks like today, whether code, templates or tribal knowledge; where two weeks has actually broken down, and at which gate; who owns go/no-go in practice; and how many engagements one FDA usually carries. With a laptop, show the gate table and the negative-control case rather than live-coding. The strongest evidence is the decision trace: which gate blocked, who owned it, what evidence was missing, and how the plan recovered.

1. "Restate the problem in one breath." A repeatable delivery pipeline, not a one-off plan, where speed comes from a reusable library and safety from role-gated checkpoints, so two weeks is an outcome of the process. → Delivery as a Repeatable Process

2. "Why not just put more engineers on it?" Two weeks is repeatable only if most of each stage already exists. Headcount buys one heroic delivery, not a process. → Delivery as a Repeatable Process

3. "Can a senior architect sign off security to save a day?" No. Wrong role is a hard deny with no seniority exception; only the security reviewer signs that gate. → Role-Gated Stage Gates

4. "The security gate passed. Does that mean adversarial testing happened?" Not unless the evidence is a required checklist. Free text cannot prove it. → Securing the Delivery Process

5. "Day 14 arrives and the metrics are not met. Has the framework failed?" No. No-go is a legitimate outcome, and the log shows which gate stopped it and why. → Role-Gated Stage Gates

6. "How would you know the process is productised and not heroic?" Track the accelerator reuse rate across engagements; a rising custom-build count means the date will slip. → Risk Checks and Delivery Metrics

7. "What should never be a two-week engagement?" One with no measurable metric or no customer SME. Rejecting those is part of the framework. → Risk Checks and Delivery Metrics

The interviewer reads the prompt. The candidate opens with the framing: operating model, gates as code. They ask whether two weeks is a hard SLA. Suppose the interviewer says it is a target. A failed gate will slip the date rather than abort. They ask who owns go/no-go; suppose the answer is the customer's sponsor. So the final gate's allowed role is the executive sponsor. They state the provisioning layer is out of scope.

Then they anchor on Northwind's two metrics and note intake would refuse anything vaguer. Eight minutes in, the interviewer knows the design's shape, its scope boundary and the first high-signal idea, before a single box is drawn. Every remaining phase builds on answers already given.

• Frame the prompt as an operating-model question in the first two minutes, and keep a written time budget.
• Ask the five questions that change gates and roles, and anchor on a case with measurable metrics.
• Write nouns, narrate one engagement, then draw the pipeline with every signer labelled.
• Spend the deep dive on enforced gates and a measured reuse rate, and say what is not yet real.
• Treat scale as capacity per FDA, defend three trade-offs, and close with the two gates to enforce first.

1. Why ask whether two weeks is a hard SLA or a target? It decides what a failed gate means: slip the date, or abort and re-scope.

2. Which two gates should be made unskippable first in an internal rollout, and why? The golden-set sign-off and the rollback test, the two most often skipped under pressure in the source's experience. Enforcing them first proves gates as code change behaviour.

3. What is the scale question for this system? Not data volume but portfolio: how many engagements one FDA can carry before gates queue behind their calendar. It needs real duration data before design.