Your legacy system needs help. You're interviewing developers. They all sound confident: "Yes, I can handle .NET systems." "I've worked with databases before." "I'm sure I can figure it out."

But legacy system work is different from building new applications. It requires specific skills, experience with old technologies, comfort with undocumented code, and realistic assessment abilities. Most developers fail at this—not because they're incompetent, but because legacy work demands different expertise.

Here are 5 critical questions to ask during interviews. The answers will reveal whether you're talking to someone who can actually fix your system—or someone who will waste your money and make things worse.

Question 1: 'Tell me about the last undocumented legacy system you worked on. What was your process for understanding it?'

Why This Question Matters

Legacy work starts with understanding code you didn't write, with no documentation, possibly in unfamiliar patterns. How a developer approaches this reveals their actual capability.

Good Answers Include:

• Specific systematic approach: "I start by reading the database schema to understand data model, then trace key workflows from entry points, mapping dependencies as I go..."
• Concrete examples: "On a recent project, I spent the first week just reading code without changing anything, documenting what I learned..."
• Tools and techniques: "I use code analysis tools to identify dependencies, database profiling to understand performance, and I document findings in a wiki..."
• Time estimates: "Understanding typically takes 2-4 weeks depending on complexity before I'm confident making changes..."
• Patience acknowledgment: "The hardest part is resisting the urge to start 'fixing' before you understand what you're dealing with..."

Red Flag Answers:

• "I just jump in and start coding, you learn as you go." (Recipe for disaster)
• "I haven't really worked on legacy systems, but I'm a fast learner." (Honest but disqualifying)
• "I usually rewrite old code as I encounter it." (Will break things)
• "Documentation isn't that important, good code is self-explanatory." (Naive view)
• Vague answers without specific examples or process

Question 2: 'Have you worked with [specific technology in your stack]? What versions? What was challenging about it?'

Why This Question Matters

Legacy systems often use older technology versions with different patterns than modern development. Experience with the specific stack matters enormously.

What to Ask About Your Stack:

• If you're on .NET Framework 4.5: "Have you worked with .NET Framework—not just .NET Core/5+? What's different about Framework development?"
• If you use SQL Server: "What versions of SQL Server have you worked with? Have you dealt with performance issues in large transactional databases?"
• If you have VB.NET: "Have you worked with VB.NET or just C#? Can you read and modify VB code comfortably?"
• If you have WinForms/WebForms: "Have you maintained WinForms/WebForms applications, or only modern web frameworks?"

Good Answers Include:

• Specific version numbers and awareness of differences between versions
• Recognition of challenges: "Framework 4.5 doesn't have async/await the same way Core does..."
• Multiple projects using that technology
• Awareness of migration paths: "I've helped clients upgrade from Framework to Core..."
• Practical experience: "The biggest challenge with older SQL Server is missing features like..."
• Comfort with 'outdated' tech: "Yes, I still work with WebForms regularly..."

Red Flag Answers:

• "I've worked with .NET" (without clarifying Framework vs. Core—they don't know the difference)
• "That's pretty old technology, why haven't you upgraded?" (Judgmental, not helpful)
• "I mainly work with modern stacks but I can learn old ones." (Will be slow and expensive)
• "All .NET is basically the same." (Fundamentally wrong)
• Can't articulate specific challenges or differences between versions

Question 3: 'Can you describe a time when you had to choose between fixing an existing system versus recommending a rewrite? How did you make that decision?'

Why This Question Matters

This reveals the developer's judgment and whether they push rewrites for their benefit or genuinely assess what's best for the business.

Good Answers Include:

• Structured decision framework: "I assess code quality, architectural soundness, technology viability, and cost of fixing vs. replacing..."
• Business focus: "I presented both options with realistic costs and timelines, letting the business decide based on their situation..."
• Examples of both outcomes: "I've recommended fixes when systems were salvageable and rewrites when they weren't..."
• Cost awareness: "Rewrites are expensive and risky, so I only recommend them when fixing would cost nearly as much..."
• Honesty about limitations: "Sometimes I recommend consulting a specialist before deciding because I'm not sure..."

Red Flag Answers:

• "I always recommend rewrites, old code is impossible to maintain." (Blanket approach)
• "Rewrites are faster than fixing old systems." (Usually false)
• "I haven't really faced that situation." (Lack of experience)
• Can't articulate decision criteria
• Only gives rewrite examples (suggests bias toward lucrative rebuild projects)
• Dismisses fixing as "throwing good money after bad" without analysis

Question 4: 'How do you estimate work on legacy systems where you don't know what you'll find?'

Why This Question Matters

Legacy work has unknown complexity. How developers handle estimation reveals their realism and risk management approach.

Good Answers Include:

• Phased approach: "I start with time-boxed assessment phase to understand the system, then estimate specific work based on findings..."
• Range estimates: "I give ranges rather than fixed numbers—best case, likely case, worst case—because surprises always emerge..."
• Discovery clauses: "I include discovery contingency in estimates, typically 20-30% buffer for unknowns..."
• Incremental commits: "I prefer working in sprints with re-assessment between phases rather than fixed-price total projects..."
• Communication protocol: "If I discover issues that significantly impact timeline or cost, I communicate immediately rather than absorbing overruns..."
• Reference past projects: "Similar systems typically took X weeks, so I estimate Y weeks accounting for..."
• Honest about uncertainty: "Until I spend time in the codebase, estimates are rough guesses. Let's start with assessment phase..."

Red Flag Answers:

• Specific confident estimates without seeing the code ("I can fix that in 2 weeks")
• "I'll give you a fixed price for everything." (Will either pad heavily or lose money and do poor work)
• "I won't know until I start, so let's just begin and see." (No planning)
• Very low estimates that seem too good to be true (they are)
• "I'm fast, I can do it quicker than other developers." (Overconfidence)
• No discussion of risk or uncertainty

Legacy work estimates should acknowledge uncertainty while providing structured approach to managing it. Developers who promise exact timelines without assessment are either naive or dishonest.

Question 5: 'What happens if you can't fix the problem, or if your fix causes new issues? What's your policy on rework?'

Why This Question Matters

This reveals integrity and how they handle failures. Legacy work sometimes goes wrong—you want someone who stands behind their work.

Good Answers Include:

• Clear warranty policy: "I warranty my work for 30-90 days. If my changes cause issues, I fix them at no charge..."
• Testing process: "I test thoroughly before deploying. If issues emerge, I have rollback procedures..."
• Honest assessment: "If I discover I can't solve the problem, I'll tell you early rather than wasting your money..."
• Collaboration mindset: "If I'm stuck, I might consult specialists or recommend bringing in additional expertise..."
• Documentation of changes: "I document what I changed so if problems occur, we can identify the cause quickly..."
• Communication commitment: "I keep you informed of progress and obstacles rather than going silent when things get difficult..."

Red Flag Answers:

• "That won't happen, I'm very careful." (Everyone makes mistakes)
• "You pay for my time regardless of outcome." (No accountability)
• "Any rework is additional cost." (You pay twice for the same work)
• "I can definitely fix anything." (Overconfident, will overpromise)
• Vague or defensive answers about responsibility
• No mention of testing, documentation, or quality assurance

Bonus Question: 'Can you provide references from clients with legacy systems similar to mine?'

This should be easy for experienced legacy specialists. They should have:

• 2-3 contactable references
• Ideally references from similar industries or systems
• Willingness to provide references without hesitation
• Examples of successfully completed legacy projects

If they can't provide references or seem reluctant, that's concerning. Everyone starts somewhere, but if you need experienced help, references verify their claims.

What to Do with the Answers

After interviews, assess each candidate:

Green Flags (Hire with Confidence):

• Systematic approach to understanding undocumented code
• Direct experience with your specific technology stack
• Balanced judgment on fix vs. rewrite decisions
• Realistic estimation acknowledging uncertainty
• Clear policies on warranties and accountability
• Verifiable references from similar projects

Yellow Flags (Hire with Caution):

• Some relevant experience but not in your exact stack
• Good approach but limited legacy project history
• Reasonable answers but no references available
• Junior developer with senior supervision available

Yellow flags don't disqualify automatically—but expect longer timelines, more supervision needed, and possibly higher ultimate cost due to learning curve.

Red Flags (Don't Hire):

• No systematic approach to legacy work
• Never worked with your technology stack
• Always recommends rewrites
• Overconfident estimates without seeing code
• No accountability for their work
• Can't provide any relevant references

Red flags indicate high probability of wasted money and worsened problems. Keep looking.

Beyond Technical Skills: Cultural Fit

Technical capability matters, but so does working relationship. Also assess:

• Communication style: Can they explain technical issues in business terms you understand?
• Availability alignment: Do their hours match when you need support?
• Long-term thinking: Do they see this as one-off fix or ongoing partnership?
• Business understanding: Do they ask about your business needs, not just technical specs?
• Realistic expectations: Do they set reasonable expectations or overpromise?
• Professional demeanor: Responsive, organized, prepared for interview?

You might work with this person for years. Technical skills get you shortlisted, but working relationship determines long-term success.

The Bottom Line

Hiring the wrong developer for legacy system work is expensive—both in money wasted and problems created. The 5 questions above quickly separate capable specialists from those who will fail:

• Process for understanding undocumented systems
• Experience with your specific technology stack
• Judgment on fix vs. rewrite decisions
• Realistic estimation approach
• Accountability and warranty policies

Pay attention to not just what they say, but how they say it. Vague answers, overconfidence, lack of specific examples, and unwillingness to acknowledge difficulty all indicate inexperience.

Finding truly capable legacy system specialists takes time—they're rarer than modern framework developers. But hiring the right person the first time saves far more than hiring quickly and wrong.