In this article
Before you start
This question is one of the engineering manager interview questions that test ownership. You need two small ideas, both explained here.
Why interviewers ask this
The question is open on purpose, so the choice you make is part of the answer. The interviewer learns what you count as your best work, how much of it was truly yours and whether you can describe a result in numbers.
Large employers publish what they look for in this kind of story. Amazon, for example, lists Ownership and Deliver Results among its leadership principles. Many employers also use structured interviews, in which every candidate gets the same questions and answers are judged against a shared guide.
A weak answer describes a technology. A strong answer shows what you decided, what moved and what you would change. This page follows no company's private scoring; it is advice built on published principles and general interviewing practice.
Best-thing answers from first principles
- Ownership story
- An ownership story is a short account of one project in which you, not the team in general, made the key decisions, took the risks and answered for the outcome, so the listener can judge your own contribution.
- Impact statement
- An impact statement is a one-sentence claim that names a measured change caused by your work, such as a number before and after, so the result can be checked rather than taken on trust.
In plain words
Think of a restaurant critic asked for the best meal of the year. A good reply names one dish, says who cooked it, what made it work and what it cost. "Everything was lovely" tells the reader nothing. The analogy breaks in one place: a critic only judges, while you also did the cooking, so the interviewer wants your decisions, not just the outcome.
In one precise sentence, the best answer to this question is an ownership story with one impact statement and one lesson, told in a fixed order.
STAR is a four-part story shape, situation, task, action and result, that keeps an answer to events that happened rather than opinions. The steps below use it with a lesson added at the end.
Step 1: Choose one project you owned the outcome of
Choose one project where you owned the outcome. Ownership means you could have been blamed if it failed, not that you wrote every line.
Good candidates have three properties: a clear problem, a decision that was yours and a result you can describe with a number or a concrete change. Pick for the role you want. For an engineering manager (EM) role, a project that raised a team's delivery, quality or growth is a legitimate answer even if you wrote little code; a project where you only watched is not.
Input: your list of projects. Output: one project that passes the three tests. Say the situation and task in two sentences: what was broken and what you were asked to do. You now have the frame; the next step is the part interviewers listen for hardest.
Step 2: Say what you personally did, in I-sentences
Say what you personally decided and did, using "I" for your own actions and "we" only for shared ones. The interviewer cannot score your contribution from a story told in the plural.
Compare two sentences. "We moved to smaller releases" hides the owner. "I proposed splitting the release into small pieces, argued for it against a full rewrite and wrote the migration plan" names a decision, an alternative you rejected and a deliverable.
Give two or three such sentences. Include one decision where you chose between options and say why you chose. Input: the project. Output: a clear line between what you did and what others did. Credit the team once, briefly, and move on.
Step 3: Show a measured before-and-after result
Give a measured before-and-after result in one sentence. This is the impact statement, and it is what makes the story checkable.
Use a number you can defend. Delivery work has standard ones: the delivery metrics published at dora.dev include change lead time, the time from a change being committed to it running in production; as of October 2026, DevOps Research and Assessment (DORA) lists five delivery metrics. In the illustrative example below, change lead time fell from nine days to three days, and the share of releases rolled back fell from 20 percent to 8 percent.1 If you have no hard number, give a concrete before-and-after change, such as "on-call pages went from nightly to rare", and say it is an estimate.
Input: the project. Output: one sentence with a before and an after.
Step-by-step description
- Choose one project you owned.
- Say what you decided and did.
- Give a before and after number.
- Close with what you would change.
- Choose one project where you owned the outcome.
- Say what you personally decided and did.
- Give a measured before and after result.
- Close with what you learned and would change.
Step 4: Close with the lesson and what you would change
Close with what you learned and would change. This shows you review your own work, which separates a good answer from a strong one.
Pick one real regret, not a disguised boast. "I would involve the support team earlier, because we missed a billing edge case" is specific and cheap to admit. "I would have worked even harder" is not a lesson. End by connecting the lesson to the job you are interviewing for in a single clause.
Input: the finished story. Output: a closing sentence that is honest and short. Keep the four parts short enough to say at a calm speaking pace.
Weak and strong answers side by side (illustrative)
The example below is an invented composite, not a real person's account.
Weak: "We built a new release pipeline. It used containers and a lot of automation. It was a big project and the team did really well."
Strong: "Our releases were slow and risky, and I owned fixing that. I proposed splitting the release into small pieces against a full rewrite, because a rewrite would have stalled the team for months. I wrote the migration plan and ran the cutover. Change lead time went from nine days to three. I'd involve support earlier next time, because we missed a billing edge case."
Four phrases make the difference. "I proposed" names the owner. "Against a full rewrite" shows a rejected option. "Nine days to three" gives a checkable number. "I'd involve support earlier" gives a specific lesson. The weak answer has none of these, so the listener cannot tell what you did or what changed. The numbers are illustrative.1
Illustrative change lead time fell from 9 days to 3 days, so the strong answer lets the listener see the change without asking.
Text description of the diagram
- Illustrative change lead time fell from 9 days to 3 days.
- A before-and-after number lets the interviewer see the size of the change.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
What was the best thing you built?
I'm proudest of the release pipeline I rebuilt as tech lead of a team of six. Changes took nine days to reach production and one in five caused a rollback. I proposed splitting the release into independently deployable pieces, argued for it against a full rewrite, and wrote the migration plan. I also grew one engineer into the cutover owner, so the on-call rota moved off me. Change lead time dropped to three days and rollbacks to eight in a hundred, and the team kept both gains without me. I'd involve support earlier next time, because we missed a billing edge case. That is the approach I would bring to your team.
What makes it Staff-level: it states a decision against an alternative, makes a people decision as well as a technical one, gives a before and an after, and admits one specific miss. The numbers in the answer are illustrative.1
The rubric
A strong answer shows ownership, specifics and judgement. The table is advice on what separates answers, not any employer's scoring sheet.
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Ownership | "We built it." | "I decided and wrote the plan." | Owns risk and credits others by name |
| Choice of project | Whatever came to mind | A project that fits the role | Explains why it is the best one |
| Result | "It went well." | One before-and-after number | Number plus what it unlocked |
| Judgement | No alternatives | Mentions one rejected option | Explains the trade-off made |
| People and team impact | None | Names who you grew or delegated to | Built a team that kept the gain without you |
| Lesson | None | A generic lesson | One specific change for next time |
Three variants of this question
What is your proudest accomplishment?
The same story works. Lead with the ownership and the result, and add a sentence on why it mattered to you.
Tell me about a project you led from start to finish.
Keep the four steps, but spend more time on the plan and the order of work. Show how you handled one setback along the way.
What was the hardest thing you built?
Choose a project with a real obstacle. Make the obstacle and your decision around it the centre of Step 2, then give the result as usual.
Common mistakes
- "We built a great platform." (wrong) The interviewer cannot see your part. (right) "I proposed the design, and I wrote the migration plan."
- "It was a complicated system with many parts." (wrong) Complexity is not a result. (right) "Change lead time went from nine days to three, and I can walk you through how we measured it."
- "I can't think of anything that went wrong." (wrong) It signals low self-review. (right) "I would involve support earlier; we missed an edge case."
- Telling the story at great length. (wrong) You lose the listener before the result. (right) Keep to the four parts and let the interviewer ask for depth.
Follow-up questions
Should the best thing I built be technical if I am applying to be a manager?
Not necessarily. A project that improved a team's delivery, hiring or growth can be your best work. See how people management rounds judge this, and pair it with a view of your management philosophy.
What if I built it with a team?
Say so once, then separate your own decisions from theirs. Describing how you grew the engineers on the project is itself part of a strong answer.
What if the project failed or was cancelled?
You can still use it if the lesson is specific and you owned part of the outcome. State what failed, what you did and what you changed afterwards. Do not blame others.
How do I prove the result if I have no metrics?
Use a concrete before-and-after change and call it an estimate. A measure of team health, such as fewer escalations, can stand in for a metric.
What if the interviewer asks what went wrong along the way?
Have one delay or setback ready and show how you responded; the page on handling a delayed project covers this.
- Pick one project where you owned the outcome, not the biggest one.
- Use "I" for your decisions and "we" only for shared work.
- Give one before-and-after number, or an honest estimate.
- Close with one specific lesson and one thing you would change.
- Keep the answer short, in four parts.
Sources
- Amazon Leadership Principles — Amazon.jobs (vendor documentation, accessed 2026-10-26), 26 Oct 2026
- DORA software delivery metrics: change lead time and the five-metric model — dora.dev (accessed 2026-10-26), 26 Oct 2026
