What project are you most proud of?
Asked at:
Meta
DoorDash
Collectors
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.
“Tell me about a project you’re especially proud of.”
“What’s a piece of work you feel had the most meaningful impact?”
“If you could pick one project that best represents your strengths, what would it be?”
“Walk me through the project that stands out most from your recent work.”
“What’s one project from your past that you’d want this interview panel to understand?”
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
Your story becomes much stronger if you can explain the real challenge, not just say the project was hard because it was new to you.
Good examples
🟢The hardest part was that the failures were intermittent, so I had to narrow down whether the issue was in our service or in how requests were retried. I ran a few targeted checks before changing anything.
🟢What made it difficult was balancing a quick fix with not breaking an active release. I had to understand the edge cases first instead of just patching the first bug I saw.
Bad examples
🔴It was challenging because I had never used that framework before, so I had to learn a lot as I went.
🔴The main difficulty was that there were a lot of tasks to do and we were pretty busy.
Weak answers define difficulty as personal effort or unfamiliarity; strong answers identify a real problem constraint and show reasoning through it.
Be precise about what you owned versus what you were guided on; interviewers reward clarity and honesty more than inflated claims.
Good examples
🟢My lead defined the broader direction, and I owned the validation and implementation for the form flow changes. I also caught an edge case in testing and proposed the fix we shipped.
🟢This was a team project, but my specific responsibility was the background job and the deployment checklist. I took that part from initial investigation through launch support.
Bad examples
🔴I led the whole project to improve onboarding, and then later it becomes clear my manager chose the approach, broke down the tasks, and handled the rollout.
🔴We rebuilt the dashboard and it went great. I mostly talk about what the team did, so it's hard to tell what decisions or deliverables were actually mine.
Weak answers either inflate ownership or blur it completely; strong answers cleanly separate team context from individual responsibility.
At junior level, the project does not need to be huge, but it should show real contribution to a meaningful problem rather than a classroom-style task with no consequences.
Good examples
🟢I'm most proud of a customer-facing onboarding fix I worked on during my first year. My part was scoped to one service, but it removed a failure path that had been causing support tickets every week.
🟢A project I'm proud of was improving test reliability for a feature our team was shipping. It was not a company-wide effort, but it affected an active release and reduced delays for the team.
Bad examples
🔴The project I'm most proud of was refactoring some helper functions because I like clean code. It made the file easier to read, and my lead said it looked better.
🔴I built a small internal script on my own time that renamed files faster. It wasn't used much, but it was fun and showed I can code independently.
Weak answers pick work that is personally enjoyable but low-consequence; strong answers choose bounded work with real users, team reliance, or visible business impact.
Valuable
Staff-level judgment often means setting tradeoff frameworks others can use consistently, not just making one good technical call yourself.
Good examples
🟢Rather than debating isolated design choices, I defined the principles we would optimize for so engineers could make aligned decisions without me in every thread.
🟢The key judgment call was narrowing the problem. We could not optimize every dimension at once, so I made the tradeoff explicit and kept the team focused on the highest-value path.
Bad examples
🔴I made the final call on the architecture because there were too many opinions and someone needed to decide.
🔴I picked the option that would age best technically, even though it required substantial extra coordination.
Weak answers centralize judgment in one decider; strong answers turn judgment into a shared framework that scales.
Junior candidates can earn extra signal by showing collaboration and initiative that made the team's work easier, even if they were not leading the project.
Good examples
🟢I wrote up the debugging steps I used so the next person wouldn't have to rediscover them, and the team started using that note during future releases.
🟢I asked for feedback from a more experienced engineer, then shared what I learned with another new teammate who was working in the same area.
Bad examples
🔴I mostly focused on my tasks and tried not to slow anyone down. Once my part worked, I considered the project basically done.
🔴I handled my assigned piece well, and beyond that there wasn't really any reason for me to get involved in how the team worked.
Weak answers stop at individual task completion; strong answers show early signs of helping the team beyond the minimum.
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.
Early July, 2026
Hex
Mid-level
Late June, 2026
Spotify
Mid-level
Late May, 2026
Meta
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.