Watch: how to answer Delivery Manager interview scenarios
Sanjay Saini walks through what Delivery Manager interview panels test and how to answer. Then write your own answers below.
Answer in your own words before opening a model answer, by typing or by pressing Speak your answer. Your text is saved in this browser only and is never uploaded to us. Voice input uses your browser's speech service to turn speech into text; in Chrome that audio is processed by Google.
Voice input is not supported in this browser. Try Chrome, Edge or Safari, or use your keyboard's dictation (Windows + H on Windows, the microphone key on your phone keyboard).
No scenarios match that combination. Choose another topic or level.
Scenario 1RoleFoundation
What does a delivery manager do, and how is it different from a project manager or an engineering manager?
What the interviewer is testing: Is the role defined by outcomes, or by meetings and status reports?
Model answer, red flags and follow-up
A strong answer
A delivery manager owns predictable, healthy delivery across teams: flow, dependencies, risk, stakeholder expectations and release readiness. I do not own people's careers the way an engineering manager does, and I am not tied to a fixed scope the way a project manager often is. My job is to make delivery visible, so problems surface early, and to remove what slows it. The failure mode is becoming the person who chases updates and produces reports, which adds overhead without improving anything. If the teams could stop talking to me for a month and delivery got better, I was doing the job badly.
Answers that lose you the room
Describing the role as chasing status updates
Claiming to own technical decisions or people management
Defining success as producing reports on time
Expect this follow-up: Where does your role end and the engineering manager's begin?
Scenario 2PredictabilityPractitioner
Leadership says delivery is unpredictable. How do you make it predictable?
What the interviewer is testing: Evidence about the delivery system first, rather than pressure on the people in it.
Model answer, red flags and follow-up
A strong answer
I start with data, not exhortation: how long work actually takes, where it waits and what causes the surprises. In most cases unpredictability comes from too much work in progress, large items that hide uncertainty, and blockers that stay hidden for days. So I limit work in progress, help teams slice work smaller, make blockers visible the day they appear, and forecast from historical throughput instead of hopeful estimates. I also ask leadership what they mean by predictable, because a team that is right within a range is often more useful than one that gives precise dates and misses them.
Answers that lose you the room
Asking teams to estimate more carefully
Adding status meetings and tracking to increase control
Treating unpredictability as a team discipline problem
Expect this follow-up: Leadership wants a single date, not a range. How do you respond?
Scenario 3ForecastingPractitioner
A client asks for a delivery date for a large, uncertain scope. How do you forecast?
What the interviewer is testing: Honesty about uncertainty that still gives the client something they can plan with.
Model answer, red flags and follow-up
A strong answer
I give a range with a confidence level, built from the team's throughput history and a sized backlog, and I state the assumptions it rests on. A single date implies a precision that does not exist, and it becomes a promise the moment I say it. I agree checkpoints where we re-forecast as we learn, and I show which scope is firm and which is flexible, so the client can see what moves when the date is fixed. If the client needs a commitment, I offer a date for a defined core and a range for the rest, so the commitment is something we can honestly keep.
Answers that lose you the room
Giving a single date to end the conversation
Refusing to forecast because the scope is uncertain
Forecasting from optimistic estimates instead of history
Expect this follow-up: The client's board has already been told a date. What do you do?
Scenario 4DependenciesPractitioner
Three teams depend on each other and keep blocking one another. What do you do?
What the interviewer is testing: Do you reduce cross-team dependencies, or just coordinate around them?
Model answer, red flags and follow-up
A strong answer
I map the dependencies first, so everyone works from the same picture, then agree an owner and a date for each during planning and review them weekly. That gets us to managing them. The better outcome is having fewer of them, so I look at why the teams block each other: work sliced by component instead of by outcome, shared code with unclear ownership, or an interface that changes without notice. Changing the sequencing, the ownership or the interface reduces the coordination cost permanently. If the same three teams keep colliding, the team boundaries are part of the problem and I say so.
Answers that lose you the room
Managing the dependencies indefinitely with no attempt to reduce them
Escalating each block individually
Assuming the teams just need to communicate more
Expect this follow-up: You cannot change the team structure. What can you still do?
Scenario 5Acceptance DisputesPractitioner
The client's acceptance testing keeps raising defects your team considers new requirements. How do you resolve it?
What the interviewer is testing: Can you settle a scope dispute item by item and fix the upstream cause, instead of defending a contractual position?
Model answer, red flags and follow-up
A strong answer
I go through the items with the client's test lead one by one, rather than arguing about the category in general. Some will be genuine defects, and I accept those quickly, because conceding the clear ones earns credibility on the disputed ones. For the rest, the question is what the acceptance criteria said and whether they were ever specific enough to test against; where they were vague, the dispute is partly our fault for accepting them. I agree a simple triage with the client: defect, clarification or change, decided jointly in a short daily session, with changes going through the normal change process. Going forward, I get example-based acceptance criteria agreed before work starts, and I invite the client's testers to Sprint Reviews so they see the product long before formal acceptance testing.
Answers that lose you the room
Labelling everything a change request to protect the budget
Accepting everything as a defect to keep the client happy
Arguing categories instead of looking at the specific items
Waiting until formal acceptance testing for the client to see working software
Expect this follow-up: The client's test lead is new and was not part of the original requirements. How does that change your approach?
Scenario 6Client EscalationPractitioner
The client escalates angrily to your director about missed commitments. How do you respond?
What the interviewer is testing: Owning the problem and rebuilding trust, instead of defending yourself to your director.
Model answer, red flags and follow-up
A strong answer
I acknowledge the impact first, without defending myself, because the client's anger is usually about being surprised as much as about the miss. I get the facts, meet the client quickly and own what we got wrong, and I do not spend the meeting explaining whose fault it was. I bring a recovery plan with dates, agree how we will communicate progress from now on, and then follow up on that promise until trust returns. I also brief my director before the client does, so they are never caught out. Afterwards I look at what allowed the surprise, since that is the real fix.
Answers that lose you the room
Defending the team before understanding the client's concern
Delaying the meeting until there is a perfect plan
Letting the director handle it and staying out of view
Copying the whole team into a defensive email thread
Expect this follow-up: Part of the miss really was the client's fault. Do you say so?
Scenario 7Quality vs DeadlineAdvanced
The deadline is fixed but quality issues are piling up. What do you do?
What the interviewer is testing: A visible trade-off. Quietly cutting quality to hit the date is what interviewers are watching for.
Model answer, red flags and follow-up
A strong answer
I make the trade-off visible, because scope, quality and date cannot all be held at once and someone senior needs to choose which one moves. I show the defect trend and what shipping in this state will cost in support, rework and reputation, and I offer options: cut or defer lower-value scope, move the date, or ship a smaller release with the quality bar intact. I protect quality in the critical paths first, since a defect in a core journey costs far more than a missing minor feature. What I never do is hide defects or relabel them to hit a date.
Answers that lose you the room
Hiding or downgrading defects to hit the date
Refusing to ship on principle without offering options
Letting the team decide silently to cut testing
Expect this follow-up: The client insists on the date and the full scope. What do you do?
Scenario 8CapacityPractitioner
The team is overloaded but stakeholders keep asking for more. How do you handle it?
What the interviewer is testing: Protecting the team by making capacity visible and forcing a priority call.
Model answer, red flags and follow-up
A strong answer
I show real capacity and current commitments in a form stakeholders can see, then ask them to prioritise: what comes first, what waits and what stops. Without that visibility, every request looks free, and saying yes to all of them quietly turns into everything being late. I limit work in progress so the team finishes what it starts, and I take the trade-off conversation to whoever owns the priorities instead of asking the team to absorb it. Overloaded teams do not deliver more; they deliver less, later and with more defects.
Answers that lose you the room
Saying yes and asking the team to work harder
Turning down requests without showing the reasons
Letting the team decide priorities among stakeholder requests
Expect this follow-up: Two senior stakeholders each say their request is the top priority. What now?
Scenario 9MetricsFoundation
Which metrics do you use to track delivery health?
What the interviewer is testing: Do your metrics start conversations and connect to value, or do they judge people?
Model answer, red flags and follow-up
A strong answer
For flow: cycle time, throughput, work in progress and work item age. For predictability: how forecasts compared with what we delivered. For quality: escaped defects and change failure rate. And a regular read on team health. Those tell me whether delivery is healthy, but not whether it is delivering value, so I connect them to outcome measures; the four key value areas in Evidence-Based Management (current value, unrealised value, time to market and ability to innovate) are a good way to keep that link explicit with clients. I read trends, not single weeks, and use the numbers to start conversations, never to rank teams or people. Any metric that becomes a target gets gamed, so I pair speed with quality so neither improves at the other's expense.
Answers that lose you the room
Using velocity to compare teams
Tracking utilisation as a measure of productivity
Reporting a single metric with no context or trend
Never connecting delivery metrics to the value the client receives
Expect this follow-up: A team improves its cycle time sharply. What do you check before celebrating?
Scenario 10Go-livePractitioner
How do you prepare for a high-risk go-live?
What the interviewer is testing: Planning for failure as carefully as for success.
Model answer, red flags and follow-up
A strong answer
I agree readiness criteria in advance, so go or no-go is a decision against evidence rather than a mood in the room. We rehearse the deployment, confirm the rollback and communication plans, and name the decision makers and what would trigger a rollback. I make sure support and operations know what is changing and what to watch. After go-live I plan hypercare with clear ownership, monitoring and a defined exit, so the team is not on call indefinitely. The most useful question I ask beforehand is what would make us stop, since it is far easier to decide that calmly before launch than under pressure during it.
Answers that lose you the room
Deciding go or no-go on confidence rather than criteria
Having no tested rollback plan
Expect this follow-up: You are at 90 percent of the readiness criteria and the client wants to go live. What do you do?
Scenario 11Fixed-priceAdvanced
A fixed-price project is overrunning. What do you do?
What the interviewer is testing: Separating client-driven change from your own inefficiency, and acting early on both.
Model answer, red flags and follow-up
A strong answer
I quantify the overrun and its causes first, separating genuine scope changes from our own estimation error or inefficiency, because they lead to different conversations. Client-driven changes go through change requests. Our own overrun is a decision for our leadership: absorb it, re-plan to reduce it, or agree a reduced scope. I take options to the sponsor early rather than waiting for the numbers to speak, record every decision and communicate honestly. The temptation is to protect margin by cutting quality or hiding the position, and both make a bad situation much worse. I push for that internal conversation to happen early: an overrun raised in month two leaves room to renegotiate scope or phasing, while one discovered in month six usually leaves only the option of absorbing it.
Answers that lose you the room
Absorbing client changes without change requests
Hiding the overrun until the end of the project
Cutting testing to protect margin
Expect this follow-up: Half the overrun is scope the client added informally. How do you handle that conversation?
Scenario 12UtilisationAdvanced
Your account leadership wants every engineer billed at 100 percent utilisation. What is your position?
What the interviewer is testing: Do you understand flow well enough to explain, in commercial language, why fully loaded teams deliver slower?
Model answer, red flags and follow-up
A strong answer
I understand why: in a services business, billable utilisation is how the account makes money, and I do not pretend otherwise. But I explain what full utilisation does to delivery. As any system approaches full capacity, queues grow, so work waits longer, cycle time rises and the client sees slower delivery, not more of it. There is also no slack for incidents, learning or the improvement work the client indirectly pays for. I make the case with our own data, for example cycle time in the weeks we were most loaded, and I propose reporting what the client values: completed work and predictability. Where commercial targets are fixed, I look for billable work that also builds capacity, such as automation or knowledge transfer, rather than filling every hour with feature tickets.
Answers that lose you the room
Agreeing to 100 percent without explaining the delivery cost
Dismissing the commercial reality of a services business
Arguing from theory without the team's own data
Expect this follow-up: The account head says the client pays for hours, not outcomes. What do you say?
Scenario 13Working with ProductPractitioner
Product and engineering disagree on priorities and it stalls delivery. What do you do?
What the interviewer is testing: Facilitating a decision without taking sides or overriding either party.
Model answer, red flags and follow-up
A strong answer
I bring both to a shared view of goals, constraints and trade-offs, then use the outcome we committed to as the tie-breaker: which option moves it furthest. Often each side is defending something legitimate, such as a customer need or a risk, and putting both on the table exposes a sequencing solution. I agree who makes the call and by when, and I write down the decision and the reasons so it does not get relitigated every fortnight. If it stays stuck I escalate with options and a recommendation, not just the argument.
Answers that lose you the room
Taking engineering's side by default
Passing the conflict up without trying to resolve it
Letting the loudest voice decide
Expect this follow-up: They keep reopening the decision. What do you do?
Scenario 14Continuous ImprovementFoundation
How do you drive continuous improvement across delivery teams?
What the interviewer is testing: Improving the system through evidence and small experiments.
Model answer, red flags and follow-up
A strong answer
I use delivery data and retrospectives to find the biggest constraint, pick one or two changes with owners, and check whether they worked. Trying to fix everything at once fixes nothing. I share what works across teams and stop improvements that do not help. My job is to make problems visible and experiments cheap; changes teams choose themselves stick far better than changes imposed on them.
Answers that lose you the room
Running retrospectives that produce actions nobody follows up
Imposing the same process changes on every team
Expect this follow-up: A retrospective action has been raised three times and never done. What do you do?
Scenario 15Production IssueAdvanced
A major production incident hits during a release. How do you lead?
What the interviewer is testing: Restore service first, learn afterwards, and keep blame out of both.
Model answer, red flags and follow-up
A strong answer
Restoring service comes first. I make sure there is one incident lead, the right people are on the call and stakeholders get regular, honest updates so they are not chasing engineers for news. I keep the debate about cause separate from the work of recovery, and I decide early whether to roll back. Afterwards I run a blameless review, focused on how the system allowed the failure rather than on who pressed the button, and I track the actions to completion. The review is only worth doing if something changes as a result.
Answers that lose you the room
Hunting for who is to blame during the incident
Letting many people direct the response
Skipping the review or letting actions lapse
Expect this follow-up: The incident was caused by a shortcut you approved. How do you handle the review?
Scenario 16Change RequestsPractitioner
The client keeps sending changes outside the agreed scope. How do you handle them?
What the interviewer is testing: Change control that informs the client's decisions rather than obstructing them.
Model answer, red flags and follow-up
A strong answer
I assess each change for its effect on cost, time and risk and run it through the agreed change process. The point is not to refuse the change; it is to make its consequences visible so the client decides what to trade off, whether that is more time, more budget or removing something else. I keep a record so everyone can see the cumulative effect, because ten small changes look harmless one at a time. If the client is frustrated by the process, I make it lighter for small changes rather than skipping it.
Answers that lose you the room
Accepting small changes informally to keep the peace
Refusing changes without explaining the impact
Treating change control as a way to protect ourselves
Expect this follow-up: The change is small but the client is senior and insists on it now. What do you do?
Scenario 17Vendor TransitionAdvanced
You are taking over delivery of a live system from another vendor in eight weeks. How do you run the transition?
What the interviewer is testing: Can you plan a knowledge transfer around real operational risk, with exit criteria, rather than a pile of handover documents?
Model answer, red flags and follow-up
A strong answer
I treat it as risk reduction against a fixed end date, not a document handover. With the client and the outgoing vendor I agree a phased plan: shadow, where our people watch the outgoing team work; reverse shadow, where we do the work and they watch; then cutover with a defined period of support. Documents help, but the real knowledge sits in people's heads and in how incidents are actually handled, so I prioritise the areas that page people at night and the integrations nobody has touched in years. Each phase has exit criteria, such as handling a set number of real incidents unaided. I also remember the outgoing vendor is losing the contract, so I keep the relationship respectful and check that the client's contract gives them a reason to cooperate.
Answers that lose you the room
Relying on documentation as the main transfer method
No measurable exit criteria for each phase
Treating the outgoing vendor as an adversary
Changing the system before the team understands it
Expect this follow-up: Halfway through, the outgoing vendor's key engineer leaves. What do you do?
Scenario 18Mid-project Ramp-upAdvanced
You join a project mid-way and it is already in trouble. What do you do first?
What the interviewer is testing: Calm diagnosis before action, and honest communication about what you find.
Model answer, red flags and follow-up
A strong answer
I listen first: to the team, the client and the sponsors separately, because each will describe a different problem. I review the plan, the risks and the delivery data to find the real blockers, not the reported ones. Within the first couple of weeks I agree a short recovery plan with a few quick wins, so people see things improve. I am honest with stakeholders about what I have found, even if it is uncomfortable, because they will discover it anyway. What I avoid is arriving with a fixed diagnosis or reorganising everything before I understand why the team is doing what it is doing.
Answers that lose you the room
Arriving with a fixed diagnosis and reorganising immediately
Only talking to the sponsor
Promising a turnaround date in the first week
Expect this follow-up: After two weeks you find the plan cannot be recovered without moving the date. What do you do?
Scenario 19CrunchAdvanced
The team is being asked to work overtime to hit a date. What is your stance?
What the interviewer is testing: Protecting the team while taking the business need seriously.
Model answer, red flags and follow-up
A strong answer
I first check whether overtime will actually fix the problem, since if the constraint is a dependency or a decision, extra hours do nothing. Then I look at scope and date options with the sponsor. If a short burst is genuinely justified, it should be voluntary, time-boxed, openly agreed and followed by recovery time. What I protect the team from is repeated or open-ended crunch, because tired people make more mistakes, quality drops, and the best people leave. If crunch keeps recurring, the real problem is planning or scope and I say that to the sponsor directly.
Answers that lose you the room
Accepting overtime as the default response to pressure
Refusing overtime without discussing the business situation
Treating extra hours as free capacity in plans
Treating overtime as a free resource with no end date
Expect this follow-up: The team volunteers to do it because they feel responsible. What do you do?
Scenario 20Distributed DeliveryPractitioner
How do you deliver well with teams spread across time zones?
What the interviewer is testing: Designing for distance instead of hoping communication happens.
Model answer, red flags and follow-up
A strong answer
I design the way of working for distance instead of hoping it will work. Clear written communication, so decisions do not live in someone's head, a few hours of overlap protected for collaboration, documented decisions, shared dashboards and explicit hand-offs with defined expectations. I rotate meeting times so the same team is not always joining at midnight, and I invest in relationships, with an occasional in-person or video-first session, because trust makes asynchronous work far smoother. The biggest risk is one location becoming the real team and the other becoming a service, so I watch for that.
Answers that lose you the room
Treating the remote team as an execution service
Always scheduling meetings at the convenience of one location
Expect this follow-up: Work keeps stalling waiting for an answer from the other time zone. What do you change?
Scenario 21Cost ControlAdvanced
How do you keep delivery cost under control without hurting outcomes?
What the interviewer is testing: Linking cost to value rather than treating it as a number to shrink.
Model answer, red flags and follow-up
A strong answer
I track spend against value delivered, not spend on its own, because a cheap program that delivers nothing is not under control. I make waste and cost of delay visible: rework, waiting, features nobody uses, delayed benefits. Then I review the biggest cost drivers with the team and cut low-value work first. What I avoid are cuts that damage quality or reduce the team's capacity to learn, since those save money in this quarter and cost more in the next. The most effective cost control is usually finishing smaller pieces of work sooner, which reduces waste at the source.
Answers that lose you the room
Cutting the same percentage everywhere
Measuring cost without reference to value
Expect this follow-up: You are asked to cut 15 percent from the delivery budget. Where do you start?
Scenario 22Tech DebtPractitioner
Engineers want time for tech debt while the business wants features. How do you balance?
What the interviewer is testing: Translating tech debt into business terms and agreeing a steady arrangement.
Model answer, red flags and follow-up
A strong answer
I translate the debt into business terms: incidents it causes, the slowdown in cycle time, the risk of a major failure. Then I link individual items to outcomes the business cares about, so the request is not engineers asking for time off features. I agree a steady share of capacity rather than fighting over it each sprint, and I review the trade-off regularly with product and stakeholders. Where debt is blocking a specific delivery, I prioritise that piece first, since the case is strongest when it is tied to something the business is already waiting for.
Answers that lose you the room
Treating tech debt as engineers' self-indulgence
Agreeing to a large one-off cleanup that never gets scheduled
Letting debt accumulate because features always win
Expect this follow-up: The business refuses any capacity for debt this quarter. What do you do?
Scenario 23AI AccountabilityPractitioner
The client asks whether your team's code is written by AI and who is accountable when it fails. How do you answer?
What the interviewer is testing: Is accountability for AI-assisted work clearly human in your answer, and are you open with the client about how the tools are used?
Model answer, red flags and follow-up
A strong answer
Honestly and specifically. I tell them which AI tools the team uses and under what terms, and that our contract and approved tool list govern what client code and data those tools can see. Then I answer the accountability question directly: AI drafts, but a named engineer reviews and merges every change, and our company is accountable for what we deliver, exactly as before. I show what has changed in our quality controls, such as review standards, tests and security scans that apply regardless of who or what wrote the code. If the client has its own AI policy, I align to it in writing rather than assume. What I avoid is either hiding the tools or overselling them, because both damage trust when the truth comes out.
Answers that lose you the room
Suggesting the AI is responsible for AI-generated code
Hiding AI use from the client
Not knowing what client data the tools can access
Expect this follow-up: The client wants AI tools banned on their project. How do you respond?
Scenario 24Project RescueAdvanced
A project is failing and the client has lost confidence. How do you rescue it?
What the interviewer is testing: Stabilise, reset honestly, then rebuild trust through visible results.
Model answer, red flags and follow-up
A strong answer
I stabilise first: agree the real goal with the client, assess where we are honestly and stop everything that is not essential. Then I reset scope and plan with the client, not for them, set short milestones with visible results and communicate frequently and honestly. Trust returns through small commitments kept, not through a big promise. I also look hard at why the project failed, whether it is scope, team, environment or decision making, because rescuing without fixing the cause only buys a few weeks. And I am prepared to say when part of the original goal is no longer achievable. In the first two weeks I agree one small, visible deliverable the client cares about and make sure it lands, because a kept promise does more for confidence than any recovery plan document.
Answers that lose you the room
Promising a complete turnaround to calm the client
Continuing the original plan with more pressure
Rescuing the delivery without addressing why it failed
Expect this follow-up: The client wants to replace the team. How do you respond?
Scenario 25ExpectationsFoundation
How do you manage stakeholder expectations throughout delivery?
What the interviewer is testing: Early honesty rather than late apologies.
Model answer, red flags and follow-up
A strong answer
I agree outcomes and success measures early, report progress and risk in a consistent rhythm, and raise changes before they become surprises, since stakeholders forgive early bad news far more readily than late bad news. When something has to give, I show the trade-off rather than announce the result. Trust comes from a track record of small forecasts that came true.
Answers that lose you the room
Keeping bad news back until there is a fix
Over-promising to secure the engagement
Expect this follow-up: A stakeholder says they never agreed to the scope you delivered. What do you do?
Scenario 26Flow and BottlenecksPractitioner
Work items keep ageing in review and waiting for QA. How do you find and fix the bottleneck?
What the interviewer is testing: Do you look at where work waits, or push people to work faster?
Model answer, red flags and follow-up
A strong answer
I start by looking at where work waits rather than where people are busy, using ageing work in progress and time spent in each stage. If items sit in review, the cause might be too few reviewers, large pull requests, or review being treated as an interruption. If they sit in QA, it might be late testing, environment contention or batch releases. I show the team the picture and let them choose the experiment: smaller changes, a review rota, moving testing earlier. I then measure whether the wait time moves. Pushing people to work faster only fills the queue faster.
Answers that lose you the room
Asking the team to work faster
Adding a status meeting to chase the aged items
Treating the bottleneck as one person's performance problem
Expect this follow-up: You fix the review queue and the QA queue grows. What is happening?
Scenario 27Key Person RiskPractitioner
A key engineer resigns mid-project and few others understand their area. What do you do?
What the interviewer is testing: Managing the knowledge risk and delivery impact early, without panic.
Model answer, red flags and follow-up
A strong answer
I start with the person: understand their timeline, thank them properly and make the hand-over something they can do well rather than something forced. In parallel I identify exactly what only they know, then arrange pairing, documentation of the essentials and recorded walkthroughs of the risky areas, prioritising what the project needs first. I reassess the plan with the remaining team and tell the sponsor about the impact and any date effects before they hear it elsewhere. Afterwards I ask why we depended on one person, because that was a risk we should have been managing before the resignation.
Answers that lose you the room
Ignoring the risk until the last week
Trying to persuade the person to stay as the main plan
Expect this follow-up: They give two weeks' notice and the knowledge is deeply tacit. What do you prioritise?
Scenario 28Metrics MisuseAdvanced
A client wants weekly velocity reports and asks you to compare your team with their other vendors. What do you say?
What the interviewer is testing: Declining a harmful measure while still meeting the client's real need.
Model answer, red flags and follow-up
A strong answer
I would explain that velocity is a planning tool for the team, measured in units they define themselves, so it cannot be compared across teams, and using it that way makes it inflate rather than improve. Then I address what the client actually needs, which is confidence that value is arriving at a reasonable cost. I offer measures that can be compared or trusted: throughput of completed items, cycle time, predictability against forecast, quality and outcomes delivered. If I simply refuse, the client hears obstruction, so I offer something better that answers the same question.
Answers that lose you the room
Reporting velocity because the client asked
Refusing without offering an alternative
Letting the team inflate its estimates to look better
Sharing velocity privately to keep the client happy
Expect this follow-up: The client insists and says they will use it in the vendor review. What do you do?
Scenario 29AI and ExpectationsAdvanced
Since the team adopted AI coding tools, leadership expects delivery dates to be pulled in by 30 percent. How do you respond?
What the interviewer is testing: Separating a real productivity signal from a projection of it onto the whole delivery system.
Model answer, red flags and follow-up
A strong answer
I would take the expectation seriously and ask for evidence before agreeing to it. Faster code does not mean faster delivery if review, testing, integration and release are the bottlenecks, and they often become worse when more code arrives. I look at cycle time, throughput and quality across the whole flow before and after adoption, and show leadership what actually changed. If real gains appear, I use them to forecast better, not to squeeze dates. I propose a measured approach: keep the forecast on data, and report the gains as they show up rather than assuming them.
Answers that lose you the room
Accepting the 30 percent target and asking the team to hit it
Dismissing AI gains without measuring anything
Measuring only coding speed rather than end-to-end delivery
Expect this follow-up: Leadership says a competitor has already done it. How do you respond?
Scenario 30BehaviouralAdvanced
Tell me about a delivery that went wrong and what you would do differently.
What the interviewer is testing: Accountability for a delivery you were responsible for, with your own part named before anyone else's.
Model answer, red flags and follow-up
A strong answer
Structure it as the situation, what you expected, what actually happened, your own contribution to it and what you now do differently. Pick a real delivery with a measurable cost, such as a date you committed to on optimistic estimates, a dependency you let stay amber, or a client conversation you delayed. Credibility comes from locating your own part rather than blaming the client or the team, and from a specific change in your practice, such as forecasting in ranges or escalating earlier. Avoid the story that turns into a success in the last sentence.
Answers that lose you the room
A failure caused only by others
A story that resolves into a success
No concrete change in your own practice afterwards
Expect this follow-up: What would you have needed to see earlier to change the outcome?
0 of 30 attempted
Keep going
Practise the neighbouring roles, or see every question in one place.