What is the favorite project you have worked on, and what made it your favorite?
answer
- name the project and your seat
- why it was actually hard
- the part you kept choosing
- what it turned into
- the specific why it stuck
basics
~20 sTests whether your enthusiasm is specific enough to be real. Pick a project you owned a real slice of, spend the airtime on the part you kept choosing to work on, and close with the thing you would look for again.
how to answer
5 beats- name the project and your seat on itTwo sentences: what it was and what you personally owned. Say the boundary of your slice up front so the interviewer never has to work out which parts were yours. Keep setup plus problem to roughly fifteen to twenty percent of your airtime.
- the constraint that made it hardState what made it genuinely difficult — an ambiguity, a compatibility rule, a performance budget. A project with no named difficulty reads as a tour of a codebase rather than a story.
- the part you kept coming back toSpeak in I and name the specific stretch of work you found yourself choosing over other things — the problem you took home in your head. One or two concrete decisions are enough; this is about what held your attention, not a walkthrough. Roughly forty percent of your airtime.
- what it turned intoSay what shipped and who it ended up helping, in two or three sentences. A number is welcome but it is not the point here — an outcome you can describe warmly beats one you can only quantify.
- why this one is your favoriteFinish with one specific sentence about the work itself, not the praise or the launch, and give this a full quarter of your airtime rather than a closing line. Name the thing you would look for again, which is the part the interviewer maps onto this role.
your answer
5 story prompts- Choose a project you owned a real slice of, not one you only watched.
- Prefer something from the last two years so the technical details are still sharp.
- Name what was genuinely hard about it in one sentence, before any outcome.
- Decide the one-sentence why now, and make it about the work itself.
- This can be your proudest-work story re-angled toward what made it enjoyable.
draft and rehearse your own answer in a learn session
go deeper
This probes motivation and depth of ownership at once. The interviewer learns what kind of work you seek out when you have a choice, and whether you can describe technical work vividly enough to prove you were close to it. A strong answer sounds like memory rather than summary, and names a value the interviewer can check against the role.
My favorite is still a small one. An open-source docs theme I use generated its colours at runtime through a style-in-JavaScript layer, and I volunteered to port it to build-time CSS custom properties. I owned the port itself; a maintainer reviewed and owned the release. The hard part was that people had themed the site in ways the maintainers had never intended — overriding generated class names in their own stylesheets. A straight rewrite would have silently broken those sites. So I started by grepping every public fork I could find for overrides and grouped what I saw into four patterns. Three of them mapped cleanly onto custom properties, so I named the properties to match what people were already overriding rather than what was tidy. The fourth pattern I could not preserve, so I wrote it up in the release notes with a two-line replacement snippet. I also considered shipping a compatibility shim that kept emitting the old class names, and rejected it because it would have kept the runtime script on the critical path, which was the whole point of the change. The theme's landing route went from six render-blocking stylesheet requests to two, and no fork reported a broken theme after release. It is my favorite because it was the first time I had to think about people I could not talk to. The code was ordinary; deciding what would quietly break was the interesting part.
The seat is drawn honestly and small, which is exactly right at this level, and the rejected compatibility shim shows a real decision rather than a task list. The closing why is about the work, not praise. Dropping the four override patterns would leave a generic refactor story.
Mine is a documentation-site migration I led in an open-source project I help maintain — moving twenty-three pages off a hand-rolled build onto a modern static framework. I owned the plan, the risky routes and the contributor communication. The difficulty was not the framework; it was that the site was the project's front door, and half the pages had been written by people who had since drifted away. Breaking a URL would have broken years of inbound links. I started by pulling the top routes from the analytics the project already published and froze that list as a redirect contract we had to satisfy before merging. Then I migrated in three tranches rather than one branch, smallest and least-linked pages first, so the build differences surfaced while the stakes were low. The tranche approach cost about two extra weeks of parallel maintenance, and I said so out loud when I proposed it, because the alternative was a single cut-over nobody could review honestly. The one thing I insisted on keeping was the old search index format, so search never went dark mid-migration. Across the site the average render-blocking requests per route dropped from twelve to three, and every URL in the frozen contract still resolved after cut-over. It is my favorite because the interesting decisions were about sequencing and blast radius rather than code, and I found I liked that more than I expected to.
Ownership is stated plainly and the hard part is sequencing, which is the mid-level signal here. Naming the two-week cost of the tranche plan out loud, and the deliberate choice to freeze the search index, are what make it sound remembered. Without the redirect contract this would be a routine upgrade story.
A course project, a side project or one substantial ticket is fine. Be exact about which parts were yours, describe the hardest bug at mechanism level, and never inflate your slice — interviewers probe the boundary and honest small scope survives the probe.
Choose something you owned end to end: a feature, a component, a migration slice. The interesting content is your decisions and the alternatives you rejected, plus how you handled review and other people's dependencies on your work.
Pick a project where the hard part was ambiguity, sequencing or blast radius rather than raw code. Say what you deliberately did not build, and what you left behind that kept working after you moved on.
The strongest choice is a project whose value outlived it — a mechanism, standard or path other teams reused. Say how you picked it over the alternatives competing for the same engineering time, and be honest about what it cost.
saying these in an interview costs you the question
- Picking the most prestigious project rather than one you can describe in detail
- Narrating the team's work in we, with no I anywhere
- Describing the product rather than the engineering inside it
- A long setup and a ten-second result with no outcome named
- Answering why it was your favorite with it was just a really cool project
- Choosing something so old the technical details have gone fuzzy
- What would you do differently if you started that project again?Name one real thing, technical or process, and explain what would change as a result. Avoid the fake regret of I would have started sooner. Choosing an alternative you actively considered and rejected at the time is the strongest form, because it shows the decision was deliberate rather than accidental.
- Which parts of it were yours and which belonged to other people?Draw the line explicitly and generously. Say what you decided and built, then credit the parts you did not do without diminishing them. Interviewers ask this to test whether the I in your story was accurate, so an honest, smaller-than-implied slice is much safer than an evasive answer.
- What was the hardest technical decision on it?Give the decision, the two options you were weighing, the constraint that broke the tie, and how it turned out. One decision described properly beats three listed. If the decision proved wrong later, say so and what you learned — that answer usually scores higher than a clean one.
- Why did that one stick with you more than the others?Answer about the work, not the outcome or the praise. Autonomy, a feedback loop you could see, users you talked to, a problem that matched how you think — any of these are credible. Vague answers here undo an otherwise strong story, so decide your one sentence before the interview.