How to check a developer can work in someone else's code

The challenge with code inheritance is this: the cheapest developer isn't always the one who should inherit your system. A coder might excel at building fresh projects but struggle the moment they must understand someone else's architecture, naming conventions, database structure and half-finished decisions. The stakes are high—a misreading of legacy code can cascade into silent data corruption or system failures weeks later. You need checks that separate developers who can *actually* work in your codebase from those who'll treat it as a puzzle they're solving for the first time every time.

Request a structured code audit before engagement

Before you hire, ask the candidate to spend a few hours reviewing a representative sample of your code. Not their portfolio—your actual code. Pay them a small fee for this (a few hundred rand), and use their report as your first real verification. A developer competent in maintenance will identify the language and framework version, flag obvious vulnerabilities or debt, note the testing strategy, and ask intelligent follow-up questions about why certain choices were made. They'll also be honest about what they don't know. Someone who skims the code and sends back generic observations hasn't engaged seriously. Their audit should be specific enough that you recognise your own system in their findings.

Verify hands-on experience with your tech stack

Don't rely on "I know Python" or "I've worked with Laravel." Instead, ask for the names of three projects where they debugged or extended code written by someone else—not greenfield builds. Phone at least two of those references directly. Ask them: Did this developer understand your existing code quickly? Did they introduce bugs in unrelated parts of the system when fixing one thing? Did they document their changes? How were they to work with when your original coder wasn't around to explain things? These questions reveal whether the developer's claimed experience is real or polished.

Also ask the candidate to explain a specific bug they fixed in someone else's code—how they diagnosed it, what assumptions nearly trapped them, and what they learned. A genuine answer will feel earned, not rehearsed.

Check their approach to documentation and communication

Developers who work in inherited code must be ruthless about writing things down. Ask them to show you examples of:

• Change logs or commit messages from previous projects (clear enough that you could follow their changes months later)
• Brief technical notes or readmes they've written (not exhaustive, but enough for the next person)
• Evidence they've asked clarifying questions in writing before diving in (Slack threads, email, issue trackers)

If they have none of these, they likely treat code as a black box they solve but don't explain. That's fine for one-off fixes, but dangerous for ongoing maintenance. Also ask how they'd keep you informed of what they're changing and why—weekly summaries, pull request comments, or something else. The best sign is when they suggest a communication method without being prompted.

Run a small paid trial on a real, low-risk bug

Before handing over anything critical, pay them to fix an actual (not dummy) bug in your system. Choose something non-catastrophic—a report that calculates wrong, a user permission that's too loose, or a performance leak you've tolerated. Watch their process: Do they ask for more context? Do they check whether the bug exists in other parts of the code too? Do they run tests after fixing? Do they offer to refactor nearby debt while they're there, or do they resist scope creep? Do they push back on your instructions if they think you're about to create a bigger problem?

After they deliver, ask them to walk you through what they found and why they fixed it that way. Can they articulate the trade-offs? Did they uncover anything else while they were in there? This trial is your best window into whether they actually understand legacy code or just move through it mechanically.

Once you've verified these points—through a structured audit, real reference conversations, evidence of clear communication, and a working trial—you have confidence that they'll inherit your system thoughtfully. When you're ready to hire, you can find verified developers on Strove and use these same checks to separate those who truly work *in* code from those who only write their own.