What project are you most proud of?
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see how you define meaningful work and whether your sense of pride aligns with impact, ownership, and judgment at your level. Because you get to choose the example, the story itself is a signal: seasoned interviewers notice what scope you select, what role you actually played, and whether you can explain why the work mattered beyond being technically interesting.
Key Insights
- You are being evaluated not just on the project, but on your taste in choosing it. Pick a story whose scope and complexity match your level, and be explicit about why it mattered.
- Pride without outcomes is weak signal. Explain what was hard, what you personally drove, and what changed because of the work.
- Many candidates over-focus on the build and under-explain the decisions. Show how you handled ambiguity, tradeoffs, and follow-through, not just what was implemented.
What interviewers probe atlevel
Top Priority
You do not need perfect metrics, but you should explain what improved and who benefited from the work.
Good examples
🟢I'm proud of it because after we shipped, support tickets on that flow dropped noticeably and the team stopped having to manually fix those cases every week.
🟢What made it meaningful was that it removed a frustrating issue for users and also reduced repeated debugging for our team during releases.
Bad examples
🔴I'm proud of it because it was a lot of work and people seemed happy with it.
🔴The project turned out well, and we shipped it on time, which showed it was successful.
Weak answers center effort or completion; strong answers explain the value created for users, the team, or the business.
Valuable
Example answers atlevel
Great answers
The project I’m most proud of was a fix to our account setup flow in my first year. New users were sometimes getting stuck after email verification, and support had a manual workaround, but no one had isolated the bug yet. My lead helped me narrow the scope, and I owned the investigation, the code change in one service, and the testing plan for the edge cases I found. What made me proud of it was that it wasn’t just a bug fix for me to learn from — after we shipped it, support tickets on that issue dropped and the team stopped revisiting the same problem every release. I also documented the failure pattern and test cases so another new engineer could use them later. It felt like the first time I took a real problem from unclear symptoms to a result that mattered.
The project I’m most proud of was adding keyboard navigation and screen-reader support to our app’s date-picker component. As a junior frontend engineer I worked closely with a designer and our QA lead, and my mentor reviewed the implementation while I wrote the code, unit tests, and a small demo page that showed the accessibility behaviors. Previously, customers who relied on assistive technology had to use a workaround; after we shipped it, support tickets about the date picker dropped and one customer emailed to say the app finally worked for their whole team. I also wrote a short checklist other engineers could follow when building accessible components. That work mattered to me because it made the product usable for people who’d been excluded and taught me how small, focused changes can have a real human impact.
Poor answers
The project I’m most proud of was cleaning up a utility module that had a lot of old code in it. I refactored it to be much easier to read and broke some of the functions into smaller pieces. It didn’t really change the product, but the code looked a lot better afterward and I enjoy that kind of work. My manager was happy that I took initiative and handled it on my own.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid August, 2026
Mid August, 2026
Late July, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.