If you're reading this, you probably have a piece of software that used to work fine and now doesn't. You're about to hire someone to fix it — either the original developer isn't around, or they are but you've lost trust, or you just need more hands.
Hiring the right developer at this stage is high stakes. The wrong hire in a broken codebase doesn't just slow you down — they can make the wreckage worse in ways you won't notice for six months. And if you've read the earlier post on refactor vs rewrite, you already know that the temptation to rewrite everything comes disproportionately from people who benefit financially from doing it.
The questions below are the ones I'd want a founder to ask me. Not to make it easier for me — to make it harder to get away with a bad answer.
They're grouped into four categories: how they think, whether they've actually looked at your code, whether their incentives align with yours, and the character stuff you only find out by asking directly.
Group 1: How they think (methodology)
1. "What would you do in the first two weeks, before writing any new code?"
The right answer sounds boring: read the code, run it locally, understand what customers actually do with it, find the three most fragile spots, write down what surprised them. Anyone whose first-two-weeks plan is "start refactoring" or "start rebuilding X in framework Y" is telling you they've already decided what to do before looking at your situation. Run.
2. "Walk me through the last time you inherited a messy codebase. What did you actually do?"
You want a specific story, with specific decisions and specific tradeoffs. Not a philosophy. If they can't give you a real example, they've never done this — they've only built greenfield projects, which is a very different skill. Fixing an existing product is closer to surgery than to construction.
3. "How do you decide whether to fix a bug in place vs refactor the code around it?"
The honest answer involves reading the same file three times over three weeks and only refactoring once the shape of the change becomes obvious. Watch out for anyone who says "I always refactor as I go" — that's how one-line bug fixes turn into 40-file pull requests that never get reviewed properly.
Group 2: Have they actually looked at YOUR code?
The next three questions require them to have spent an hour on your specific project. Any serious developer will do this for free before quoting you. Anyone who won't is either too busy for your work or doesn't care enough to earn it.
4. "Which three files or modules in our codebase concern you most, and why?"
If they've looked, they'll have opinions. Real ones, with reasoning. If they can only say "the code is messy" or "it needs modernization," they haven't opened the repo. Vague criticism is a tell.
5. "What's one thing the previous developer did well?"
This is a trick question, and the answer tells you almost everything. Developers who badmouth their predecessors are usually preparing you to badmouth them next. Someone senior will find something to respect — a clever workaround, a smart tradeoff under time pressure, a boring-but-solid choice. If everything the previous person did is "wrong," you're hiring someone with more ego than judgment.
6. "Which parts of the codebase do you think you'd need to touch to deliver [the specific outcome you want], and which would you leave alone?"
You want to hear them separate "must change" from "can safely leave." If everything must change, either they haven't done the analysis or they're pitching you a rewrite disguised as a fix. If they can't identify anything that must change, they haven't understood your outcome.
Group 3: Incentives and accountability
7. "How do you handle it when you underestimate a piece of work by 2x?"
The honest answer is: it happens regularly, and the response should be to flag it to you the day it becomes clear, propose two or three options (cut scope, extend timeline, accept the overrun), and let you decide. Anyone who claims they don't underestimate is either lying or hasn't done enough work to have been humbled by it.
8. "Are you willing to write down what 'done' means before you start each piece of work, in words a non-developer can understand?"
This is the single strongest predictor I know of a good working relationship on a stalled project. If they'll do this, disputes become impossible — either the criteria are met or they aren't. If they won't, every deliverable becomes a subjective conversation about whether it's "good enough" and you'll always lose those conversations because you're not the technical one.
9. "How do you feel about being on the hook for a bug that shipped six months after you did the work?"
The right answer is: fine, up to a reasonable line, and the line should be discussed upfront. Someone who wants zero long-tail responsibility for their own code will not build defensively enough. Someone who accepts unlimited long-tail responsibility for it is either lying or desperate. You want a professional adult who accepts warranty on their work and has a defined scope for it.
Group 4: The honest hard stuff
10. "What kind of work do you refuse to do, and why?"
This is the question that separates senior from mid-level. A senior developer has strong opinions about what's a bad idea and will decline to do it, even for money. A mid-level developer will do whatever you ask, then blame the outcome on the request. You want the person who'll push back — and you want to hear their pushback in the interview, not on your third invoice.
11. "If you had to leave this project in three months, what would you need to hand over so someone else could pick it up?"
The answer reveals whether they think in terms of "my code" or "the project's code." You want someone whose default mode is documenting, naming things clearly, writing tests that explain intent, and generally leaving a trail. That kind of person is roughly twice as productive over a year, because they don't spend half their time re-explaining decisions they made and forgot.
12. "Under what circumstances would you tell me not to hire you?"
If they can't think of any, they'll take work they shouldn't. The right answer includes specifics — "if the deadline is fixed and the scope is fixed and neither can move, I'm the wrong hire," or "if you already know what the solution looks like and you just want someone to build it, you want a contractor not a consultant." Someone who sells themselves for every situation is a red flag disguised as enthusiasm.
The bonus question — the answer that's an instant no
Ask them: "If we hired you and after two weeks you thought the whole thing needed a rewrite, what would you do?"
Instant-no answer: "I'd start planning the rewrite and give you a proposal."
Correct answer, in some form: "I'd write down exactly why I think that, walk you through the reasoning, present the three or four alternatives, tell you which one I'd pick and why, and let you make the call — because it's your company, not mine."
The instant-no isn't about whether a rewrite is ever the right choice. It's about who's making the call. A developer who unilaterally decides to rewrite your product is either arrogant or has a financial incentive you can't see. Neither ends well.
A concrete example
I audited a codebase last year for a small business owner who'd inherited a system built by a contractor who'd since disappeared. Two other developers had already told her the code was "unfixable" and quoted her rewrites in the $60k–$120k range.
I spent an afternoon reading it before quoting anything. The code was ugly — messy naming, no tests, three different ways of doing the same thing in different files. But it wasn't broken. The architecture was fine. The database schema was actually thoughtful. The three specific problems she was hitting were all in one module (checkout), and the rest of the app was doing its job.
The honest answer was: two weeks of focused work on the checkout module, plus some safety-net tests, would fix everything she was actually complaining about. Total cost: about a tenth of the smallest rewrite quote. That's what shipped. The old app is still running today.
The reason the other two developers recommended rewrites wasn't malice. It was that rewriting greenfield is easier and more fun than reading someone else's messy code and figuring out what to keep. Their comfort was their incentive. The questions above are designed to expose that gap before you're paying to close it.
What to do this week
If you're about to hire someone to fix your app:
- Pick your top three candidates.
- Send them the twelve questions above via email, with a simple ask: reply in writing (short is fine), and be willing to spend an hour on a call walking through the answers.
- Do not pay them for this. If they won't invest an hour to earn your work, they won't invest the ten hours it takes to properly understand your code before starting.
- After the calls, before you decide: reread the refactor vs rewrite framework with each candidate's answers in mind. It becomes much clearer which of them is pattern-matching your situation vs which is selling you a rewrite that pays their bill.
If you're not sure what you're actually hiring for yet — because you don't have a clear scope written down — the free MVP planner will produce a realistic version of what your product should be. Not a fix plan, but a baseline. Founders who bring a clear scope to interviews get much better answers than founders who bring a vague problem.
The right developer for a stalled codebase is not the one who's most excited about your project. It's the one who's most honest about what they don't know yet, and most willing to be measured against what they promise. These twelve questions are how you find them.
---
If you'd like a second opinion on your specific situation — either on the codebase itself or on the developers you're interviewing — that's what an independent code audit is for. Reach out via the contact page with a paragraph about what's going on and I'll tell you honestly what I'd do in your position.