Tell me about one project you are proud of and how you would do it differently if you could redo it
Asked at:
Oracle
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to learn both what kind of work you gravitate toward and how you think about your own execution after the fact. The "proud of" part reveals your standards, scope, and ownership; the "what would you do differently" part tests reflection, learning, and whether you can critique something successful without becoming defensive or fake-humble. Strong answers make it clear why the project mattered, what you specifically drove, and what you learned that changed how you operate.
“Walk me through a project you feel especially good about, and what you learned from it that you'd apply next time.”
“What’s a piece of work you’re most proud of? If you had a chance to do it over, what would you change?”
“Tell me about a project that went well and why it stands out to you. What would you approach differently today?”
“Pick one project that best represents your work. What made it successful, and what would you improve on a second pass?”
Key Insights
- You do not need to pick a flawless project. In fact, a project with some scar tissue is often better because it lets you show pride and honest reflection at the same time.
- The redo portion is not asking for self-criticism theater. The best answers name a real tradeoff or blind spot, explain why it happened, and show how that lesson would change your approach now.
- Your choice of project is itself signal. Pick something with scope appropriate to your level and be precise about your personal contribution rather than hiding inside "we."
What interviewers probe atlevel
Top Priority
Your redo should be a real lesson from execution, not a fake weakness like 'I cared too much' or a vague wish for more time.
Good examples
🟢If I did it again, I would get feedback from users before building the second half of the interface. We made assumptions that were reasonable, but a short check-in earlier would have saved rework.
🟢I would spend more time defining edge cases up front. I focused on the happy path first, and that meant we found a few avoidable issues late in testing.
Bad examples
🔴If I could redo it, I’d probably just start earlier so everything would be even smoother.
🔴I think the main thing I’d change is being even more detail-oriented, because the project actually went pretty well overall.
Weak answers avoid naming a real mistake or tradeoff; strong answers identify a concrete execution lesson and explain why it mattered.
At junior level, interviewers mainly want to see meaningful ownership within a small project, not a grand story borrowed from the team.
Good examples
🟢I’m proud of building an internal dashboard for support because I owned one clear slice end to end, from clarifying what agents needed to shipping the first version and fixing the first round of issues.
🟢I worked on improving test reliability for a service my team owned. It wasn’t huge, but I took a messy recurring problem, narrowed it down, made the changes, and reduced noise for the team.
Bad examples
🔴I’m most proud of helping with our platform migration; I mostly fixed a few tickets and attended the meetings, but it was a big company project so I learned a lot.
🔴My proudest project was rewriting our deployment system. I mostly followed the design my mentor made and implemented one component, but it was critical to the business.
Weak answers borrow significance from the surrounding project; strong answers show level-appropriate ownership of a concrete problem the candidate actually drove.
Valuable
It is not enough to say what you would change; show that the lesson actually influenced how you work now.
Good examples
🟢After that project, I started writing down assumptions and reviewing them with a teammate before I build the second half of a feature, and it’s helped me catch gaps earlier.
🟢That experience taught me to test with one real user or partner before polishing the full flow, and I’ve used that approach on later tasks with better results.
Bad examples
🔴Since then I’ve just tried to be more careful on projects in general.
🔴I learned that planning matters, so now I make sure to think things through.
Weak answers describe a feeling; strong answers describe a repeatable behavior change tied to later evidence.
Example answers atlevel
Great answers
One project I’m proud of was building an internal tool that let our support team look up order status without asking engineers for help. I was the primary engineer on it, with my mentor helping me review the design, and I owned the API, the basic interface, and the launch fixes after we released it. I’m proud of it because it solved a real day-to-day problem and people started using it almost immediately. If I could redo it, I would talk to two or three support agents earlier before finishing the whole interface, because we ended up changing the layout after they showed us how they actually searched for issues. That taught me to validate assumptions sooner, and on later tasks I started doing short check-ins with the people who would use what I was building.
One project I’m proud of was improving the accessibility of the online donation form for a small non‑profit where I did frontend work. I was the sole developer on the changes and worked with the program manager and a couple of volunteer testers to understand common pain points. I implemented semantic HTML, ARIA attributes, better keyboard focus handling, clearer error announcements for screen readers, and improved color contrast. After we rolled it out we saw a noticeable increase in completed donations from users who use assistive technology and we got direct thanks from a few donors. If I could do it again I’d bring in two or three people who use screen readers for usability testing much earlier and add simple automated accessibility checks to our CI so regressions would be caught sooner. That taught me how valuable early user feedback and lightweight automation are, even on small features.
Poor answers
A project I’m proud of was our company’s migration to a new service architecture. It was a very important initiative and I helped with several parts of it, mostly by picking up tickets and making the requested changes. It went well because I stayed busy and got my work done quickly. If I could redo it, I’d probably just start a little earlier and be even more detail-oriented, but overall I was happy with how it turned out.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late December, 2025
Oracle
Senior
Early December, 2025
Oracle
Mid-level
Early November, 2025
Oracle
Principal
Tell me about one project you are proud of. If you were to redo this project, how would you do it differently?
Hello Interview Premium
Your account is free and you can post anonymously if you choose.