Tell Me About a Project You Are Proud Of

“Tell me about a project you are proud of” opens more behavioral rounds than any other question, often as the very first one. It sounds like a friendly warm-up, and it is treated as one, which is why so many answers to it are weak: a tour of the features, a list of technologies, and a closing “so yeah, it went well”.

It is not a warm-up. It is the interviewer's best chance to see what you consider good work, which tells them more about how you will work for them than almost anything else you say. This post covers what they are listening for, how to choose the project, and a complete worked answer with the follow-ups that come next.

What the interviewer is listening for

Three things, mostly in this order:

What you value. Do you call a project good because it used interesting technology, because it shipped on time, because users loved it, because it was hard? There is no wrong answer, but there is a revealing one, and the best answers are proud of an outcome rather than a tool.
Your scope. How much of it was yours. Did you build a component someone else designed, or did you see the problem, decide the approach and carry it to the end? Be accurate; both are fine at the right level.
Your judgement. The hard part of the project and how you handled it. A project with no hard part is a project you were not proud of; you were just finished with it.

Choosing the project

Pick the one where you can tell the strongest story, which is not always the biggest or most famous project. A good choice has:

GOOD CHOICE                              WEAK CHOICE
  you drove a meaningful part of it        you were one of forty contributors
  a real risk or hard constraint           everything went to plan
  a decision you can defend                the architecture was handed to you
  a result you can measure                 "people seemed to like it"
  recent enough to remember the detail     five years ago, details fuzzy
  explainable to a non-specialist          only makes sense with your codebase open

If the interviewer is from a different domain, the last row matters most. You are going to explain the stakes in thirty seconds, so the project's difficulty has to be something a smart outsider can grasp: money, risk, users, time.

The worked answer

Here is a real answer, told the way it should sound in the room: the project that moved this site off WordPress. Read the STAR labels as the structure underneath, not as something you say out loud.

Situation. I run lovemesomecoding.com, a programming tutorial site. It had been on WordPress on shared hosting for years: 512 posts, about $25 a month, and its value was in search: Google had indexed those 512 pages at their existing URLs.

Task. I wanted to move it to a static site on AWS — cheaper, faster, and something I fully controlled — without losing any of that search traffic. In practice that meant one hard requirement: every URL Google knew about had to keep working, exactly as it was.

Action. The first thing I did was measure what I actually had, using WordPress's own API: 512 posts, 56 pages, 336 images, and 568 URLs in total that the old site served. Then I hit the real design problem. I wanted posts stored as JSON and pulled in by the site, but if the browser fetched the content at runtime, Google would index an empty page. So I chose to pre-render every page at build time and rebuild the site whenever a post is published: publishing takes a few minutes instead of being instant, but the search engine sees exactly what it saw before.

The migration found a nasty bug early. Some tutorials have raw HTML — script tags, buttons — inside their code samples. The HTML parser I was using treated those as real elements and silently deleted them, and the character count barely changed, so a size check would have passed. I changed the pipeline to pull every code block out before any parsing, and then compared all 5,152 code blocks byte for byte against the originals rather than trusting lengths.

Before switching the domain over, I wrote a script that replayed all 568 old URLs against the new site. When it passed, I switched DNS with a sixty-second TTL and kept the old host paid for thirty days as a rollback.

Result. All 568 URLs answered on the new site with zero 404s — 532 directly and 36 through redirects to the right page. Hosting went from about $25 a month to roughly $0.60. And the build now refuses to deploy if any URL Google has indexed stops resolving, so that requirement is enforced by the build from now on, not by me remembering it.

Learning. The thing I'm proudest of isn't the new stack, it's that I treated the old URLs as the actual product. The most valuable check was the boring one: replaying every URL before I touched DNS.

Spoken at a normal pace that is a little over two minutes, which is about right for a first telling.

Why that answer works

It is proud of an outcome, not a technology. The answer never says “I used Next.js and Lambda” as if that were the achievement. The achievement is that the search traffic survived and the bill dropped. Technologies appear only where they explain a decision.

The situation is four sentences. Just enough to establish the stakes: the site, the cost, and the fact that its value lived in its URLs. Everything after that is action.

There is a real decision with a stated cost. Pre-rendering versus fetching at runtime, chosen for a reason, with the downside named: publishing takes minutes instead of being instant. Naming the cost of your own choice is one of the strongest signals of judgement you can give, because it shows you saw the alternatives.

There is a problem, found and handled. The code-sample bug is what makes the story believable. It is specific, slightly embarrassing, and the fix shows a principle — compare the actual content, not a proxy for it — that the interviewer can imagine you applying on their team.

The result has numbers, and a mechanism. 568 URLs, zero 404s, $25 down to $0.60. Then the last line of the result goes one step further: the requirement is now enforced by the build. That turns a one-off success into a lasting change, which is what ownership looks like.

The follow-ups, and how to answer them

The first telling is the start of the conversation, not the end. These are the follow-ups this answer invites, with the true answers:

“What would you do differently?” — Commit hygiene. Early on I pushed commits to GitHub that included node_modules and about 72 MB of migration output that should never have been tracked. I fixed it going forward, but the files are still in the repository's history. A .gitignore written before the first commit would have prevented it. (That one is a full story of its own, in the failure post.)
“Why not just keep the WordPress URLs with redirects?” — Redirects keep a page reachable, but they move where Google thinks the page lives. Keeping the exact URLs meant there was nothing for search to re-learn. Some slugs were wrong — Java 25 content lived under /java-8/ — and I kept them anyway and fixed only the display names.
“How did you know traffic survived?” — The URL replay proved every page answered. Search Console coverage needs weeks to confirm, which is why the old host stayed up for thirty days as a rollback.
“Did you do it alone?” — Answer honestly. In this case: it is a solo project, and I used a coding assistant for much of the implementation. My part was the decisions, the requirements, and the verification — deciding that the URLs were the thing to protect, choosing the rendering approach, and insisting on the checks before cutover.

That last follow-up deserves a moment, because it is increasingly common. If you used an AI assistant, say so plainly and describe what you did. Interviewers are not looking for people who typed every line; they are looking for people who made the right calls and can prove the result was correct. Claiming generated work as hand-written is the kind of embellishment the follow-ups are designed to uncover.

Adapting it when your project is different

Your project will not be a website migration, but the skeleton transfers to almost anything:

SITUATION  what it was, and the ONE fact that made it matter
           ("its value was in 512 indexed URLs")
TASK       the goal, and the hard constraint
           ("move it without losing any of them")
ACTION     how you found out what you really had (measure first)
           the key decision, its alternative, and its cost
           the problem you hit, and the principle behind the fix
           how you de-risked the moment of no return
RESULT     the numbers, plus what keeps it true from now on
LEARNING   what you are actually proud of, in one sentence

The most common gap when people fill this in is the key decision. If you cannot name a moment where you chose between two real options, either the project is the wrong one for this question, or you have not yet thought about why you did what you did. Both are worth discovering at your desk rather than in the interview.

What to take from this

The question measures what you value; be proud of an outcome, not a tool.
Choose the project with the strongest story: your scope, a real risk, a defensible decision, a measurable result.
Name the cost of your own decision. It is the clearest signal of judgement in the whole answer.
Prepare the follow-ups, especially “what would you do differently?” and “did you do it alone?”.
Be exact about what was yours, including the parts an assistant wrote.

Next: tell me about a time you failed — and two bugs that actually shipped.