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 from a real project, including the part of it that still needs work.

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"
  it mattered to real people               it mattered to nobody outside the team
  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: a feature I built the backend for at Sidecar Health, which let members compare doctors before booking a visit. Read the STAR labels as the structure underneath, not as something you say out loud.

Situation. I worked at Sidecar Health, a health insurance company whose mission is to bring down the cost of care. It works differently from a traditional insurer: instead of the doctor's office billing the insurance company, members pay at the visit with a Sidecar-issued Visa card, then upload a photo of the receipt. The provider is paid on the spot and there is no claim to chase. Paying that way typically costs about 40% less than the traditional billing route.

Because members were paying for their care directly, they started asking for what you would want before any purchase: what does this doctor charge for this service compared with the others nearby, and how good are they? For years, that pricing simply was not public. Then federal price transparency rules required providers to publish their prices. We already had the data, and members were asking for it.

Task. Give members a way to compare the providers near them on price and on ratings and reviews from other members who had actually been seen there, before they booked. Demand was there now, so we gave ourselves about a month.

Action. We were a team of three: I owned the backend, with one front-end developer and one QA engineer. The hardest problem was search. Our data lived in MySQL 5.7, and its full-text search was not fast enough for members looking up providers. I took the initiative to learn Elasticsearch, built a proof of concept, and demoed what it could do to the team, so we could decide on what it actually did rather than on my say-so. Once we agreed, I moved the searchable data into Elasticsearch. That was a project in itself, but it cleared the performance problem.

Result. We shipped it in about a month of long hours, with search fast enough to use. Members could choose a care provider the way they would choose a new TV: compare the options, read what other people thought, and make an educated decision.

Learning. What I am proudest of is who it was for. A lot of people need care and assume they cannot afford it. Once prices and reviews are visible, they can see that there are good, affordable options near them. That is the kind of work I want to keep doing: making a complicated system understandable for the people who depend on it.

Spoken at a normal pace that is about two minutes, which is about right for a first telling, and leaves room for the follow-ups.

Why that answer works

It is proud of an outcome, not a technology. MySQL and Elasticsearch appear only where they explain a decision. The achievement is that people who might have skipped care could see affordable options. That tells the interviewer what this engineer values in a single sentence.

It explains an unfamiliar business in thirty seconds. Most interviewers have never heard of paying an insurer's members up front with a card. One concrete walk-through — see the doctor, pay with the card, upload the receipt — makes the rest of the story make sense, and the 40% figure tells the listener why the company exists.

It has a reason for “why now”. The price transparency rules are the turning point: the data existed, the law changed, and members were asking. A project with a trigger is easier to follow than one that simply happened, and it shows the engineer understood the business context, not just the ticket.

The scope is exact. “A team of three; I owned the backend” tells the interviewer precisely what to credit, and makes everything after it believable. Saying “we” for the team and “I” for your part is the whole trick.

There is a real decision, made the right way. Keep fighting MySQL, or move search to a tool built for it? The answer does not just say Elasticsearch was better. It shows a proof of concept and a demo, so the team decided on evidence. That one sentence is also an ownership story and a learning-fast story, which is why this project carries three columns in the story bank. And it names the cost: moving the data “was a project in itself”.

The learning bridges to motivation. “Making a complicated system understandable for the people who depend on it” is also a ready answer to “what kind of work do you want to do next?” One sentence of the proudest-project answer can be reused, honestly, in the motivation questions at the end of the round.

What would still make it stronger

One gap remains, and it is the most common one: the result has no number. “Search fast enough to use” and the TV comparison show what the feature did, not how much it mattered. Any honest figure would be stronger: search response time before and after Elasticsearch, how many members used the feature in its first month, a metric the business watched. If there truly is no number, use a concrete moment instead, such as a member's message about finding care they could afford.

What not to do is invent one. A made-up metric falls apart on the second follow-up question. Go back to your notes, old pull requests or a former teammate, and use what actually happened.

The follow-ups to prepare

The first telling is the start of the conversation, not the end. These are the follow-ups this answer invites. Prepare a true answer to each before the interview:

“Why not tune MySQL, or upgrade it?” — Expect it from any backend interviewer. Know what you tried in MySQL first, and what the proof of concept showed that made the case.
“How did you keep Elasticsearch in sync with MySQL?” — Moving searchable data into a second store creates a consistency problem. Have the real answer: how changes reached the index, and what happened if that failed.
“What was hard about learning it?” — The proof of concept is a learning story too. One concrete thing that surprised you is worth more than a list of features.
“How did you stop fake or unfair reviews?” — Any review feature invites this. Showing only reviews from members who had a recorded visit is the kind of design point worth knowing cold.
“How did you know it worked?” — How you measured search speed, and what members did with the feature.
“What would you do differently?” — With a month of long hours, there is usually something that was cut or rushed. Saying so honestly scores well.

Adapting it to your own project

Your project will not be a healthcare feature, but the skeleton transfers to almost anything:

SITUATION  what the company/product does, in one concrete example
           ("pay at the visit with the card, upload the receipt")
           and the ONE fact that makes it matter ("about 40% less")
WHY NOW    the trigger: a law, a customer ask, an outage, a deadline
TASK       the goal, for whom, and the constraint ("about a month")
ACTION     YOUR part, told in "I"
           the hardest problem, the options, and the one you chose
           how you made sure it was right before it shipped
RESULT     what changed for the users, with a number if you have one
LEARNING   what you are actually proud of, in one sentence

The most common gap when people fill this in is the action. 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.
Explain the business in one concrete example, then say why now.
Say “we” for the team and “I” for your part; the action is the longest part: your piece, the hard problem, the choice.
Give the result a number if an honest one exists; never invent one.
Show a decision made on evidence: a proof of concept beats an opinion.
Prepare the follow-ups, especially “why not tune MySQL?” and “what would you do differently?”.

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