What project are you most proud of?

In this article

1. Before you start
2. Why interviewers ask this
3. Project-pride answers from first principles
4. The Staff-level answer
5. The rubric
6. Three variants of this question
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This question usually comes up in the past-work conversation of the interview process and loop stages.

Why interviewers ask this

A vague answer to this question leaves the interviewer with nothing to probe, so the conversation turns into follow-ups you did not prepare for. The question gives the interviewer one real project to dig into, and the digging shows how you work.

The U.S. Office of Personnel Management (OPM) describes a structured interview as a method that measures job-related skills by asking about a candidate's behavior in past experiences, a hypothetical situation, or both. The page sits within OPM's assessment and selection section. "What project are you most proud of?" belongs to the first kind. Your past work is the evidence.

A weak answer describes a team's project in general terms and never says what the speaker did. A strong answer picks one project, says what you personally decided and built, gives a result with a number, and admits one thing you would change. Showing this well is one of the interview skills, such as structured storytelling, that carry over to every other behavioral question in the same loop.

Project-pride answers from first principles

Result

A result is the measured change that your work produced, stated with a before value, an after value and the way it was measured, so a listener can check the claim instead of taking your word for it.

In plain words

Think of a short trip report you give your manager after a work trip. You say where you went, why, what you did and what you found. The analogy breaks in one place. A trip report is written and nobody interrupts. In an interview the listener asks "why?" and "how do you know?" after every claim.

In one precise sentence, a strong answer picks one project, sets the scene and your role, states a measured result and closes with what you would change.

Four moves follow. Each one maps to a step in the diagram below. In situation, task, action, result (STAR) terms, Step 2 covers situation, task and action, Step 3 covers result, and Step 4 goes beyond STAR.

Step 1: Pick one project you can explain and prove

Choose the project where you can name your own decisions, state a result and explain it to a non-expert in a few sentences. Size is not the test. A small project you owned fully beats a large one where you were one of many hands.

Input: your list of past projects. Output: one project. Test each candidate with three questions. Can I say what I decided? Can I give a before and after? Can I explain it without jargon? A project that fails the second question is risky, because the follow-up "What was the impact?" will arrive. You now have your subject, and the next step sets it up in a few sentences.

Step 2: Set the scene and your own role in three sentences

Open with the situation and the task: what was wrong or needed, and what you were responsible for. Then say what you did, using "I" for your own decisions and "we" only for what the team did together. The interviewer cannot score your part if every verb is "we".

Input: the project. Output: three sentences covering context, your responsibility and your main action. For example: the old service was slow, I owned the fix, and I proposed and built a cache for the most common requests. Keep the background short. Details you cut can come back as answers to follow-ups, which is a better use of them. You now know where the story starts and who the actor is.

Step 3: State the result and how you measured it

State what changed, with a number and a baseline, and say how you measured it. A metric is a number that tracks one aspect of how something performs, such as response time, error rate or cost. A result is far easier to trust when the sentence carries the before value, the after value and the method.

Take an illustrative rebuild of a search-suggestion service. Median response time fell from 420 milliseconds to 160, a cut of 61.9 percent, and the servers needed fell from 24 to 15, a cut of 37.5 percent.¹ The method sentence is: "I replayed the same traffic before and after."

Text description of the diagram

• The illustrative median response time falls from 420 to 160 milliseconds.
• That is a cut of 61.9 percent.

If your project has no clean number, say what you observed instead and how you know: a deadline that was met, a manual task that stopped, a team that adopted the tool. State what you can honestly claim.

Step 4: Say what you would change, then stop

Close with one thing you would do differently and what you do now because of it. That shows you review your own work. Then stop talking and let the interviewer pick a follow-up.

Input: the finished story. Output: one honest lesson in one or two sentences. Choose a real lesson that did not sink the project, such as a missing alarm, a check you skipped or a decision you made too late. Do not invent a flaw to sound humble, and do not choose a lesson that makes the project look like a failure. The target length for the whole answer is 60 to 90 seconds, which at illustrative speaking rates of 130 to 150 words a minute is roughly 130 to 225 words.¹

1 · Pick2 · Scene and role3 · Result4 · ChangeReplay

Step-by-step description

1. Choose one project you can explain and prove.
2. Context in a few sentences, then your own action.
3. A number, a baseline and how you measured it.
4. One honest lesson, then stop.

• A strong answer picks one project, sets the scene and your role, states a measured result, and closes with what you would change.
• The measured result is the move the follow-up questions test.

What a weak answer sounds like

A weak answer to the proudest-project question names no personal action, no number and no lesson. Take this illustrative example: "We built a recommendation feature and it went really well. The team worked hard and the launch was a big success. I am proud because users liked it." It has 28 words,¹ and it shows all three gaps. Every follow-up now starts from zero: what did you do, what changed, how do you know?

The Staff-level answer

The answer above is illustrative and has 135 words, about 54 to 62 seconds at the speaking rates above.¹

What makes it Staff-level: it names a decision, its alternative and the trade-off accepted, it admits a failure, it separates "I" from "we", and it ends with a change that outlived the project. It does not claim a company asks this question; it is a model for any loop. For loops built around customer-facing work, the page on forward deployed and applied AI engineer rounds shows the round formats.

The rubric

A rubric is the list of things a listener looks for. A strong answer shows each row below; the cells are advice, not any company's real scoring.

Three variants of this question

Which project should I pick when several qualify?

Pick the one where your ownership and a checkable result are strongest. Run each candidate through the three tests of Step 1: can you say what you decided, give a before and after, and explain it without jargon? If two tie, choose the one closest to the work of the role you are interviewing for. The same choice applies when the question is phrased as a request, such as "Tell me about the project you're most proud of".

What is your proudest technical achievement, in two sentences?

Give the project, your action and the result in two sentences, then offer more. "I rebuilt a slow search service and cut median response time by about 62 percent, measured by replaying the same traffic. Happy to go into the design." The numbers are illustrative.

What if the project was a team effort or has no metric?

Say what the team did, then say your own piece in "I" sentences. Replace the number with a checkable observation: a deadline met, a manual step removed, a team that adopted your work. For a role that leads people, the page on system design for managers and the Meta engineering manager interview show how the same story shifts toward scope and decisions made through others.

Common mistakes

• "I always pick the biggest project I worked on." (wrong) Size is not the point, and a large project you barely shaped gives you nothing to defend. (right) "I picked the project where I owned the decisions."
• "We did this, then we did that." (wrong) The listener cannot tell what you did. (right) "I proposed the cache; the team reviewed it; I wrote the lookup layer."
• "It was a huge success." (wrong) There is no number, so the follow-up "What was the impact?" has nothing to hold. (right) "Median response time fell from 420 to 160 milliseconds, measured on replayed traffic."
• "I wouldn't change anything." (wrong) It signals that you did not review your own work. (right) "I would add the stale-results alarm first."
• Talking for several minutes. (wrong) Detail you cut can come back in a follow-up. (right) Stop after the lesson and let the interviewer choose.

Follow-up questions

Why is that the project you're most proud of?

Give one reason tied to something you did, not a feeling: it was slow and the fix was yours, or it taught you a practice you still use. A reason you can back with an example holds up under the next question.

What was the impact?

Restate the result in one sentence with the number and its baseline, then say who benefited, such as users, the team or the budget. Keep to what you can show.

How did you measure that impact?

Name the baseline, the tool or test and the period. In the sample answer: the same traffic replayed before and after the change. If you could not measure it exactly, say what you used instead and what it cannot show.

What was your own contribution, as opposed to the team's?

Name two or three concrete things only you did, such as a design decision, a piece of code or a persuasion you led. Credit teammates for theirs; it shows judgment.

What would you do differently?

Repeat the lesson from Step 4 and add what you do now because of it. If you are interviewing at an AI lab, see also how the Anthropic interview process works and OpenAI interview questions and process.

Sources

1. Structured Interviews — U.S. Office of Personnel Management (page read 2026-10-26; the page shows no publication date), 26 Oct 2026
2. Assessment and Selection — U.S. Office of Personnel Management (page read 2026-10-26; the page shows no publication date), 26 Oct 2026