Tell me about inheriting a project that was already failing. What did you do in your first week?

How to answer

Sierra’s April 2026 post on its redesigned engineering interviews says the process aims to capture initiative, ownership, judgment, system understanding and product thinking. ^[1]Source 1The AI-native interview (Vijay Iyengar, Arya Asemanfar, Angie Wang)PublisherSierraSource typecompany blog An inherited failure tests the first three, and “first week” tells you where the interviewer will look: at what you did before changing anything.

Tell the week in this order:

1. What you inherited, as facts. What was promised, what existed, the number or date that said it was failing, and why it reached you. One sentence, no verdict on the people before you.
2. Who you talked to, and in what order. A short call to the sponsor on day one: you own it now, and here is when they hear a diagnosis. Then the previous owner, for the inherited story, and the people using the thing, to test it. The sponsor call buys the week; watching users work tells you the cause.
3. What you measured yourself. A baseline you built instead of trusting the status report, and the real cause it showed.
4. The reset. The follow-up you promised the sponsor: the cause, the new plan, what you cut, and the measure they could judge you on.
5. The first visible change. Something small the customer could see by Friday, made safely, and what you left alone.

Say the diagnosis as one line that contradicts the inherited story: “Everyone said the routing was wrong; the override log said the scheduler was missing two facts.” It proves you diagnosed before you prescribed. Name the fix in a clause; let the interviewer ask for the design.

The trap is the hero rewrite: in week one you threw it out and started again, which sounds decisive and shows no diagnosis. The second is blame: describe the previous owner as you would want to be described.