Tell me about a time you inherited a legacy codebase or project with little documentation. How did you get up to speed?

How to answer this behavioral interview question: a complete STAR example, the mistakes interviewers watch for, and the follow-ups you should expect.

A strong STAR example answer

When I joined a payments team, I inherited a five-year-old invoicing service whose original authors had all left. There was no documentation, the test coverage was under 15 percent, and my first assignment was to add multi-currency support — a change that touched the pricing engine nobody fully understood.

I resisted the temptation to start coding immediately. For the first two weeks I treated the codebase like an archaeological dig: I read commit history to reconstruct why decisions were made, traced requests in production logs to map real usage, and paired with support engineers who knew the system's quirks from customer tickets. I wrote down everything in a living document as I went.

Before changing the pricing engine, I wrote 40 characterization tests that pinned down its existing behavior, so I would know instantly if my changes altered anything unintended. That safety net caught two regressions during development that would have reached production otherwise.

Multi-currency shipped after nine weeks with zero pricing incidents. The documentation I wrote became the onboarding guide for three later hires, and test coverage on the service reached 60 percent within a year. The characterization tests still run in CI today, catching the occasional regression before anyone notices.

How to structure your own answer

• Situation: Describe the system you inherited and why it was in poor shape.
• Task: State what you were expected to deliver on top of it.
• Action: Detail your strategy for understanding the system safely before changing it.
• Result: Give the result, including how you left the project better than you found it.

Common mistakes to avoid

• Diving into code changes immediately without a strategy for understanding the system first.
• Badmouthing the previous developers — it reads as immaturity, not expertise.
• Omitting how you verified you understood the system correctly before modifying it.
• Ignoring the cleanup angle — strong answers show you left things better for the next person.

Follow-up questions to prepare for

Interviewers use follow-ups to verify your story is real. If you use this question in a real interview, expect probes like:

• What are characterization tests, and when would you skip them?
• How did you decide what to document versus leave alone?
• What was the riskiest change you made, and how did you de-risk it?

Related behavioral questions

Keep drilling with these, or browse the complete question bank.