Tell me about a project of your choice and its challenges
Asked at:
DoorDash
PayPal
Oracle
Atlassian
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This is an open-ended project showcase question, so interviewers are evaluating both the substance of the project and your judgment in choosing it. They want to see what level of complexity you naturally operate at, how you personally contributed, how you handled obstacles, and whether you can explain the work in a clear, structured way. For more senior candidates, the project itself is often less important than what it reveals about scope, leadership, and decision-making under uncertainty.
“Walk me through a project you've worked on and what made it challenging.”
“What's a project that best represents the kind of work you do? What were the hard parts?”
“Tell me about a significant project you were involved in and the biggest obstacles you had to handle.”
“Pick a project you're proud of and explain what made it difficult.”
“Can you describe a recent project you owned and the main challenges along the way?”
Key Insights
- You are being judged partly on project selection. If you choose something low-stakes, overly routine, or hard to attribute to your own work, you make the interviewer work harder to see your level.
- Don't just narrate what the team built. Make your personal role, key decisions, and the hardest tradeoffs unmistakably clear, especially if the project involved many people.
- Challenges are where the signal lives. A polished success story without real obstacles, changed assumptions, or hard decisions often sounds shallow rather than impressive.
What interviewers probe atlevel
Top Priority
Be precise about what you owned versus what you were taught or assigned.
Good examples
🟢I owned the service changes and test plan, and I proposed one adjustment to the original approach after noticing a data edge case.
🟢My mentor helped with the initial design, but I was responsible for the implementation, validation, and fixing issues found during rollout.
Bad examples
🔴We built a new onboarding flow, and we decided to change the database structure and improve the API responses.
🔴My lead designed most of it and gave me the tasks. I implemented everything they asked and we got it done.
Strong answers separate team effort from personal contribution and show agency; weak ones collapse everything into 'we' or describe passive execution.
Pick a project where your individual contribution is concrete and real, even if the overall scope was modest.
Good examples
🟢I picked a feature-sized project where I owned one important piece end to end, with guidance on design decisions but responsibility for implementation and rollout.
🟢I chose a project that was small in overall size but had a real technical challenge I had to work through myself, so it's easy to explain what I learned and delivered.
Bad examples
🔴I worked on migrating our whole platform to a new architecture. My part was fixing a few UI bugs and attending standups, but it was a huge project overall.
🔴I chose a small bug fix because it shipped quickly and users liked it, but there wasn't really much complexity beyond implementing the ticket.
Strong junior answers choose work with clear personal ownership and appropriate complexity; weak ones either hide behind team scale or pick something too trivial to show engineering judgment.
Valuable
Keep the story simple: what the project was, what you owned, what got hard, what you did, and what happened.
Good examples
🟢I quickly set the context, then focused most of my answer on the challenge I faced, how I solved it, and the result.
🟢I used plain language and made my role clear early, so the interviewer could follow the story without needing extra clarification.
Bad examples
🔴First I joined the team in June, then we had a planning meeting, and after that there were several tickets before I eventually worked on the feature itself.
🔴I spent most of the answer explaining background context and tools, so the project goal and my role only became clear near the end.
Strong answers make the listener's job easy; weak ones bury the signal in chronology or excess setup.
Show that the project changed how you work, not just that you completed it.
Good examples
🟢The project taught me to validate assumptions earlier, and I used that habit on later work by checking risky dependencies before implementation.
🟢I got feedback on my testing approach during the project, changed it, and since then I've used the same checklist on similar tasks.
Bad examples
🔴The project went well and I proved I could handle more work, so overall it was a success.
🔴After launch, we moved on to the next thing. I mainly took away that hard projects take persistence.
Strong answers show specific behavior change or durable impact; weak ones settle for generic success or vague lessons.
Example answers atlevel
Great answers
One project I like to talk about was adding a bulk upload feature for a small internal tool my team used. I owned the backend validation and the upload status page, with my mentor helping on the initial design. The hardest part was that the input files looked consistent in test data, but in real usage there were a lot of missing or malformed fields, so my first version failed too often. I reproduced a few real examples, added stricter validation and clearer error messages, and changed the processing flow so one bad row didn't fail the whole upload. We shipped it to a pilot group first, and support requests dropped because users could fix issues themselves. The biggest thing I learned was to validate assumptions with real data earlier, and I've used that on later tasks.
A project I enjoyed was simplifying our mobile web checkout flow and adding a lightweight progress indicator; I owned the front-end implementation and the integration tests while a designer handled the visuals and a backend engineer supported payment edge cases. The main challenge was that the third-party payment widget behaved inconsistently on slow connections, which made the page appear stuck and caused users to abandon their carts. I addressed it by reducing the number of visible steps, adding clear loading states and timeouts, wrapping the payment widget with a safe retry/fallback, and rolling the change out behind a feature flag so we could watch metrics. In the first month we saw a noticeable drop in cart abandonment, and I learned how small UX and reliability fixes directly affect business outcomes as well as the value of close coordination with design and backend teammates.
Poor answers
A project I worked on was part of our migration to a new platform, which was a really big effort for the company. I helped by taking the tickets assigned to me and implementing the front-end changes. The main challenge was just learning the codebase because there was a lot going on, but I picked it up and finished everything on time. The project launched successfully, so overall it showed I can contribute well on important work.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early February, 2026
Oracle
Senior
Late January, 2026
DoorDash
Staff
Project Deep Dive
Late November, 2025
Coursera
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.