How to Answer "What Project Are You Most Proud Of?" (With Sample Answers)

This is the friendliest question in the interview and it's routinely wasted. You're being handed the chance to choose the evidence you'll be judged on, and most candidates pick the project with the biggest headline number rather than the one that best demonstrates the skills this job needs.

Choose deliberately. It's also the question most likely to generate ten minutes of follow-up, so pick something you can go deep on.

What the interviewer is actually testing

• What you consider good work. Your definition of "proud" is diagnostic. Pride in shipping fast, in craft, in a team outcome, in a hard call — each says something different.
• Whether you can size your own contribution honestly. This is the big one. "We" throughout an answer makes it impossible to tell what you did; "I" throughout makes you sound like you took credit for a team's work.
• Depth. A project you truly led survives five layers of follow-up. One you were adjacent to does not, and interviewers find the floor quickly.
• Whether the skills transfer. They're mapping your project onto their problems.

Choosing the project

Score your candidates on four things:

1. Relevance. Does it use the skills in the job description? A smaller relevant project beats a larger irrelevant one every time.
2. Your role was substantial. You made decisions, not just tickets.
3. It had a real outcome you can name. Numbers if you have them; a clear before-and-after if you don't.
4. It had a genuine difficulty. Projects that went smoothly make boring answers. The interesting part is always the obstacle.

Recency helps but isn't decisive. A stronger project from three years ago beats a mediocre one from last month — just be ready for "what have you done more recently?"

A structure that works

1. One sentence of context. What the project was and why it existed. Resist the urge to explain your entire company.
2. Your specific role. Say the team size and what was yours. Do this early — it frames everything after it.
3. The hard part. The decision, constraint or obstacle. This is the substance.
4. What you did about it.
5. The outcome, and why you're proud. The "why" is the part candidates skip and interviewers remember.

Sample answers

Sample 1 — software engineer

"We had a nightly batch job that reconciled payments, and it had grown to the point where it ran for eleven hours and regularly failed, which meant finance started their day without numbers maybe twice a week.

I was one of three engineers on it and I owned the redesign. The obvious answer was to make the batch faster, and I spent a week proving to myself that wouldn't hold — the data volume was growing about 8% a month, so we'd have been back in the same place within a year.

So I argued for switching it to incremental processing instead, which was the harder sell because it was a bigger change and a rewrite is a scary word. What made the argument land was building a small prototype over two days against real data rather than making the case on a slide.

The job went from eleven hours to about twenty minutes and stopped failing. Finance got their numbers before they arrived rather than after lunch.

The reason it's the one I'm proud of isn't the speed — it's that I nearly took the easy option. I'd already started on the optimisation before I stopped and checked the growth rate."

Sample 2 — marketing

"We were spending most of a fairly small budget on paid acquisition, and the CAC had been climbing for three quarters. I was the second marketing hire and I owned the channel mix.

The uncomfortable part was that the paid programme was the thing I'd been hired to run, and the honest conclusion was that it was structurally getting worse. I built the case with cohort data rather than opinion — LTV by channel over eighteen months — and it showed that our organic and referral cohorts retained about twice as long.

I proposed moving 40% of the budget to content and a referral programme over two quarters, with an explicit kill criterion so it wasn't an act of faith.

Blended CAC came down by about a third and referral became our second-largest channel within a year.

I'm proud of it mainly because arguing to shrink your own programme is not a natural instinct, and I nearly didn't."

Sample 3 — early career

"It's a small one, but it's mine. Our support team was answering the same billing question constantly — something like a fifth of all tickets — and everyone treated it as background noise.

I was three months in. Nobody asked me to do this. I read a couple of hundred of those tickets and worked out that almost all of them came from one line on the invoice that people misread as a double charge.

I wrote it up with examples and took it to the product manager, who I'd never spoken to. He changed the wording in a sprint.

That ticket category dropped by about 80%.

I'm proud of it because the total work was two days of reading and a one-page doc, and it had been costing the team hours every week for a year. It taught me that most of the value in support is in the patterns, not the individual tickets."

Sample 4 — team lead

"A migration off a legacy system that two previous attempts had failed to finish. I led it, with five engineers, over about seven months.

The reason it had failed twice was that both attempts tried to move everything at once and got beaten by the long tail of edge cases. My call was to migrate the top four use cases — about 80% of the traffic — and then explicitly decide in public whether the remaining tail was worth doing.

That was contentious internally because it meant running both systems for a while, which everyone hates. I had to make the case that a partial migration that finished was worth more than a complete one that didn't.

We finished the 80% in four months. We then killed two of the tail use cases entirely rather than migrating them, because once we looked properly they had eleven users between them.

I'm proud of the scoping decision rather than the delivery. The engineering wasn't the hard part — the hard part was getting people to agree to do less."

Common mistakes

• Saying "we" for ten minutes. The interviewer cannot score a team. Say what was yours.
• Choosing a project with no obstacle. Smooth projects make forgettable answers.
• Over-explaining the setup. If you're three minutes in and haven't reached your contribution, you've lost them.
• Picking something you can't go deep on. Follow-ups will expose it, and that's much worse than having picked a smaller project.
• Numbers you can't source. If you say 40%, expect "how was that measured?"
• Never saying why you're proud. Without it you've described a project, not answered the question.
• Only having student projects when you have professional experience available.

Follow-up questions to expect

Assume the interview stays here for a while. Prepare for:

• "What would you do differently?" — Have a real answer. "Nothing" is the wrong one.
• "What was the hardest technical decision and what were the alternatives?" — Be able to name the option you rejected and why.
• "What did other people on the team do?" — Generosity here reads well, and evasiveness reads badly.
• "What went wrong?" — Something did. Say what.
• "How did you measure success?" — Know where your numbers came from.