Tell me about a project you are most proud of.
answer
- one project, thirty seconds of context
- your seat, said in first person
- two decisions and rejected alternatives
- result with a number
- what you would change now
basics
~20 sTests ownership and whether you can make technical work legible fast. Pick one project, set context in about thirty seconds, say what you personally decided and why, land a measured result, and leave room for drill-down.
how to answer
5 beats- context and stakes, in about thirty secondsSay what the system was, who depended on it, and what was going wrong or missing. Keep context and role together to roughly fifteen to twenty percent of your airtime — the commonest structural failure here is a long setup and a ten-second result.
- the seat you were in and what you ownedState your role in the first person and be specific about the surface: this module, this decision, this conversation. If it was collaborative, name the collaboration and then name your slice inside it.
- the two or three decisions you made, and what you rejectedThis is the bulk of the answer, around sixty percent. For each decision give the option you turned down and the criterion that settled it. Decisions with visible alternatives are what separate a walkthrough from a status report.
- the result, measured or honestly estimatedGive a before and an after with a number, and say how you know. If you never measured it, say so and offer the estimate you would defend, with the reasoning. Do not round the number to make it sound bigger.
- what you would do differently, offered before it is askedClose with one structural change — sequencing, verification, who you involved — and what it would have bought. Volunteering the cost you accepted reads as seniority; waiting to be cornered into it does not.
your answer
5 story prompts- Pick one project you personally shaped, recent enough that you still remember the layer below yours.
- Write your result line first: one number, before and after, or a defensible estimate.
- List every decision on that project that had a real alternative you rejected.
- Mark each sentence 'I' or 'we' and rewrite the ones that hide your contribution.
- Prepare a second project in case the interviewer asks for something other than that one.
draft and rehearse your own answer in a learn session
go deeper
This is an ownership and communication probe. The interviewer wants to know whether you drove real technical decisions or stood near someone who did, and whether you can make an unfamiliar system legible to a stranger in two minutes. Because every claim becomes drill-down material, the answer also measures calibration and honesty about your own contribution.
The project I am proudest of is a contribution I made to an open-source node metrics agent that a lot of self-hosted clusters run as a daemon. I picked it up because our own agent pods were burning more CPU than some of the workloads we were trying to observe. My first plan was to rewrite the collector loop, and a maintainer pushed back on the issue — correctly. It was too big for a first contribution and it would have broken every custom exporter people had built on the current interfaces. So I cut it down to one thing: the agent re-read and re-parsed the entire cgroup tree on every sampling interval, including for containers that had not changed since the previous pass. I added change detection keyed on directory modification time and re-parsed only what had moved. Two calls I had to defend in review. I kept the cache purely in memory instead of persisting it, because a restart is cheap and I would rather be correct after a restart than fast on the first sample. And I made the new path the default with an opt-out, which one maintainer questioned; my argument was that the default was the path that needed fixing, and I backed it with a benchmark on a thirty-eight node test cluster. After it merged, the agent's own share of node CPU fell from about 6.4 percent to 2.1, and CPU headroom on that test fleet went from 11 percent to just over 15. If I did it again I would write the benchmark before the patch. I spent most of the review cycle proving a number I should have had on day one.
Junior-appropriate scope — one contribution — that still reads as ownership because the speaker names a rejected plan, two defended decisions and a measured result. The volunteered lesson at the end is structural rather than self-deprecating. It would downlevel instantly if the decisions were dropped and only the fix described.
I would pick the sampling-pipeline rework I owned in an open-source infrastructure agent I help maintain. Operators running dense clusters kept filing the same complaint from different angles: on nodes with a few thousand containers, the agent crowded out the workloads and their scrapes timed out. I ran the intake myself — read the last couple of dozen issues, reproduced three of them locally, and found they were one problem. Every metric family was serialized independently, so identical label sets were rebuilt thousands of times per scrape. The clean answer was a pipeline rewrite with a shared interning layer, and I wrote that proposal. Then I halved it, because a rewrite invalidates every third-party exporter built against the current interfaces, and we cannot migrate a community we do not employ. What shipped was interning behind the existing interface plus a lazily built label index, with the old path retained as a fallback an operator could switch back to. I pushed for that fallback against two maintainers who wanted a clean cut. My argument was that we cannot roll a release back on behalf of people who vendor us, and the price was a couple of hundred lines of soon-to-be-dead code for one cycle. On the reference cluster we benchmark against, scrape p99 dropped from 4.3 seconds to 1.2, and CPU headroom across those nodes moved from 18 percent to 29 — which is the number the operators were actually asking about. What I would change: I announced the fallback in the release notes and nowhere else, so three people found it by reading source instead.
Middle-level signal comes from end-to-end ownership of a feature and the mechanics of persuasion: intake, a proposal deliberately cut in half, and a design argument won against two peers with a stated cost. The result names both the user-visible metric and the one operators care about. Vaguer attribution would drop this to junior.
Scope is one task or one contribution, and that is fine. Show that you understood why the work mattered and that you made at least one real judgment call — a design choice, a shortcut you refused — rather than only executing a ticket someone else specified.
Own a feature or component end to end. The interviewer is listening for the mechanics of collaboration: how you scoped it, whom you had to convince, what review feedback changed your design, and what you shipped versus what you deliberately cut.
Scope is a system in production with a team around it. Name the risk you carried, the decision that could plausibly have gone wrong, and the thing you put in place afterwards so that class of problem does not come back.
Expect the project to be judged as strategy: why this work rather than the next-best use of the same engineers. Show the mechanism you left behind — a standard, a review forum, a migration path — that outlives the project itself.
saying these in an interview costs you the question
- Narrating the whole team's work in 'we' with no personal contribution anywhere
- Four minutes of architecture background before saying what you actually did
- Claiming a decision you cannot defend once the follow-ups get specific
- Ending with no outcome, or an outcome with no number and no honest estimate
- Choosing a project so old or so peripheral that you no longer remember the details
- Presenting the design as flawless, with no tradeoff and nothing you would change
- You said 'we' a few times there — what did you personally do?Do not get defensive or over-correct into claiming the whole thing. Answer with the specific surface you owned: the code you wrote, the decision you made, the person you convinced. Naming a teammate's contribution alongside yours reads as confident, not diminishing, as long as your own line is unambiguous.
- Why that approach and not the more obvious alternative?Show that the alternative was actually considered, not discovered in the interview. Give the criterion you decided on — risk, reversibility, migration cost, who had to maintain it — and be willing to say the alternative was defensible too. 'I did not think of it at the time' is an acceptable answer if it is true.
- What would you do differently if you started it again?Have this ready before it is asked; it is the most predictable probe on this question. Pick something structural — sequencing, verification, who you looped in — not a self-deprecating throwaway. Say what you would change and what it would have bought you.
- How did you know it actually worked?Describe the verification, not the hope: the benchmark, the soak, the dashboard you watched, the users who stopped complaining. If you never measured it, say so plainly and give the estimate you would defend, with the reasoning behind the estimate.
## The prompt family This one arrives in several wordings: - 'tell me about a project you are proud of', - 'walk me through something you have built recently', - 'pick a project from your resume and tell me about it', - 'what is the most interesting thing you have worked on'. Treat them as one preparation. The only real variable is the adjective: - *proudest* invites impact and ownership, - *recent* constrains you to something you still remember in detail, - *interesting* buys you room to pick the technically unusual one. Prepare **one project deeply enough** that it survives all three framings, and a second in reserve in case the interviewer says 'something other than that'. ## Why it opens a deep-dive round This question is rarely scored on its own. It is the seed for the next fifteen to forty minutes: whatever you claim becomes the drill-down material. That has a strategic consequence most candidates miss — the best project to pick is not your most impressive one, it is **the most impressive one whose floor you can still stand on**. A project where you understand the layer below the one you worked on will always interview better than a larger project where the second follow-up hits the edge of your knowledge. ## Weak versus strong shape - The **weak version** is a documentary: the company, the org chart, the history of the system, the team, and then, forty seconds from the end, a vague result. - The **strong version** front-loads. One or two sentences of context — enough for the stakes to land — then straight to what you were handed and what you decided. A useful airtime split is roughly: - fifteen to twenty percent context and role, - sixty percent decisions and actions, - and twenty to twenty-five percent result plus reflection. If you record yourself once, the setup is almost always the part that has doubled. ## Attribution 'We' is the single most common downgrade signal in this answer, and it is usually humility rather than dishonesty — which is exactly why it costs people offers. The fix is not to strip every 'we'; collaborative work described entirely in 'I' reads worse. The fix is that **every claim of a decision, a diagnosis or a tradeoff should have a named subject**. 'We decided to shard by cgroup path' tells the interviewer nothing about you; 'the team wanted a coordinator, I argued for deterministic assignment and wrote the proposal' tells them everything. ## Evidence types Rank them: 1. a measured before-and-after is best, 2. a defensible estimate with its reasoning is a close second, 3. a qualitative outcome with a named beneficiary is third, 4. and 'it went well' is not evidence. Non-round numbers land as remembered rather than manufactured. If the number is not yours — a team result, a company metric — say whose it is and what your slice of it was; interviewers rarely punish honest scoping and reliably punish inflation they can smell. ## Tradeoffs and regret Volunteering a cost is **a seniority signal, not a confession**. Every real project has a thing you gave up: coverage, generality, performance, someone else's timeline. Say the cost out loud, then say why you took it. Pair it with one thing you would do differently, delivered as a decision rather than an apology. Candidates who present a spotless project invite the interviewer to go looking for the flaw, and then it is found in cross-examination rather than offered. ## How the bar moves The question is asked identically at every level and scored completely differently. - **Early on**, the interviewer wants evidence that you make judgments rather than only take instruction. - In the **middle**, they want a feature you carried through disagreement and review. - **Senior**, they want production risk and what you changed structurally afterwards. - **Principal**, they want to know why this project and not another one, and what mechanism survives it.