A technical interview can be going well right up until the moment the interviewer asks a quieter question:
“What would you do differently?”
Many candidates treat this like a trap. They either say they would change nothing, or reach for a safe line about being too detail-oriented. Neither tells an interviewer much.
What they are usually looking for is judgment. Can you look back at a real decision, understand the trade-offs, and improve your approach without becoming defensive?
That is a useful signal for an engineering team. Requirements move, customers surprise you, and a choice that made sense on Monday can look different after the release is live. Teams need people who can adapt thoughtfully.
Pick a decision with real trade-offs
You do not need a dramatic failure story. Choose a decision where two reasonable paths were available.
Maybe you shipped a small version of a feature instead of waiting for every edge case. Maybe you selected a familiar library because the deadline was tight. Maybe you focused on the main user flow and postponed an admin workflow that later caused extra support work.
The best answers are specific. Instead of saying, “I would communicate better,” describe the exact gap:
“I kept the product and engineering teams aligned, but I did not bring support into the release review early enough. After launch, they flagged a few confusing parts of the workflow that we could have caught before shipping.”
That says more than a polished weakness ever will. It shows you understand the work itself.
Give the original choice its context
Candidates often jump straight to what went wrong. That can make a thoughtful decision sound careless.
Explain why the choice made sense at the time:
“We had two weeks before a customer commitment and a small team. I limited the first release to the highest-volume workflow so we could learn from real usage rather than wait for a complete solution.”
You are not trying to prove that every earlier decision was correct. You are showing that you made a call using the information, time, and resources you had.
That is what good work looks like in practice. Perfect data and unlimited time are not part of most projects.
Describe the adjustment, not a personality flaw
Avoid vague self-criticism. “I am a perfectionist” and “I care too much” are familiar enough that they usually disappear from the interviewer’s memory immediately.
Talk about the small operating habit you would change next time.
For example:
“Next time, I would schedule a 30-minute review with support or a customer-facing teammate before launch. It would not expand the scope, but it would help us spot language and workflow issues that are hard to see from inside the product team.”
This answer is practical. It does not pretend the original approach was a disaster. It shows how you would make the next version stronger.
Finish with proof the lesson stuck
The last line is where a decent answer becomes convincing. Explain what changed in your work afterward:
“Since then, I have included a customer-facing review in early release planning. It has improved adoption of first releases without adding much delay.”
That is much stronger than “I learned a lot.” It connects reflection to a visible habit.
A four-part framework to practise
Before an interview, write down four short points for one real project:
- Decision: What did you choose?
- Context: Why did it make sense then?
- Adjustment: What would you change now?
- Lesson: What do you do differently because of it?
Do not memorise a speech. Say the four points out loud in a few different ways. The goal is to understand the story well enough to handle a follow-up such as, “Why did you not involve support earlier?” or “How would you know the extra review was worth the time?”
A script usually breaks under those questions. A real example, understood clearly, does not.
“What would you do differently?” is not an invitation to tear down your past work. It is a chance to show that you can learn, make decisions under constraints, and carry better habits into the next project.
Try the framework with one genuine example this week. You will quickly spot where your story is vague, where the original context is missing, and where your lesson needs to become more concrete.
Those are useful things to discover before the interview, not during it.
About LastRound AI: practical tools and practice for people preparing for real interviews. Learn more at lastroundai.com.
Top comments (0)