Tell me about a time you removed complexity rather than adding a feature.
What they are really testing: Whether you can resist the instinct to build. Deletion is undervalued and hard to do safely, so a real example here is a strong senior signal.
A real interview question
Tell me about a time you removed complexity rather than adding a feature.
What most people say
drag me
“I deleted a lot of old code and config that nobody was using anymore.”
No cost, no evidence it was unused, and no measured outcome. It sounds like tidying, and without proof of disuse it also sounds risky, since the interesting question is how you knew it was safe.
The follow-ups they ask next
How did you know the unused paths were genuinely dead?
Instrument first and measure over a period long enough to cover monthly and quarterly jobs, then disable with a loud error before deleting so anything missed surfaces immediately and recoverably.
Someone objects that they might need one of those overrides one day.
Ask for a concrete case. Speculative needs are cheap to satisfy later from git history, and carrying unused abstraction has a real ongoing cost paid by everyone.
What the interviewer is listening for
- Instruments before deleting
- Respects why the complexity existed
- Quantifies onboarding and build-time improvements
What sinks the answer
- Deletes on assumption
- Dismisses the original authors
- No measured outcome
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“We had [complexity X] costing [concrete cost: onboarding, build time, incidents]. It existed because [it solved a real problem once]. I [instrumented usage and found most paths were dead], built [a thin replacement for the used ones], [ran both in parallel then disabled before deleting]. Result: [measured improvement].”
Keep going with behavioural
Mid
Tell me about a time you broke production. What happened and what did you do?
Mid
Tell me about a time you disagreed with a developer about how something should be deployed.
Mid
Tell me about a time you were on call and it went badly.
Mid
Tell me about a mistake that cost the company money.
Mid
Walk me through a time you inherited a system nobody understood. Where did you start?
Mid
Tell me about something repetitive you automated. How did you decide it was worth it?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free