Eighteen months ago your strongest engineer left for a bigger company. Now they have messaged you: the new job is not what they hoped, and they would like to come back. You remember how much they got done. You also remember the week they handed in notice and how much it hurt.
Short answer: a former engineer who left on good terms is often the safest senior hire you can make, because the biggest unknowns in hiring are already answered. But "safe" depends on why they left, what has changed on both sides, and whether you would hire them today if you had never met them. Interview them properly, ask the uncomfortable question about why they left, and price the offer on today's role, not the old one.
Why rehires are popular right now
You are not alone in getting this message. ADP Research reported that returning employees made up about 35 percent of new hires in March 2025, the highest share it had recorded since it started tracking in 2018. After several years of tech layoffs and job-hopping, plenty of people discovered the grass was not greener, and plenty of companies discovered that a known person beats a cold search.
For an early-stage company the appeal is obvious. Hiring a senior engineer from scratch usually takes two to four months. A rehire can be a two-week conversation. And the person already knows your codebase, your customers, and where the bodies are buried.
What a rehire tells you that a new candidate cannot
The hardest things to learn about a senior engineer in an interview loop are the things you already know about this one:
- How they behave under real pressure. You have seen them during an outage, a missed deadline, a hard customer.
- How they work with you specifically. Not founders in general. You.
- Whether they finish things. Interviews test how people talk about work. You watched them do it.
- How they leave. Did they hand over cleanly, document their systems, and stay reachable? That is one of the best predictors of how they will behave next time something goes wrong.
That last point matters more than founders expect. If their exit was clean, it is strong evidence of character. If it was messy, with undocumented systems and a two-week notice dropped mid-launch, take that seriously no matter how good the work was before. Our post on what to do when your only engineer resigns covers what a good exit should look like.
The question you must ask: why did you leave?
Founders often skip this because it feels awkward or because they assume they already know. Ask anyway, and listen for whether the reason has actually gone away.
Common reasons, and what each means for a return:
They wanted more money or a bigger title. Fair, and often fixable now if you have raised since. Check the gap is real and you can close it without breaking your pay structure for everyone else.
They wanted to learn at a larger company. Often a good sign. They come back with exposure to scale, process, and tooling. Probe whether they now expect that process here.
They were burned out. Ask what caused it. If it was your on-call setup, your pace, or one specific person, and none of that has changed, they will burn out again.
They disagreed with a decision you made. This is the one to dig into. If they left because of how you run engineering and you still run it that way, a rehire just restarts the clock.
They left because of you. Sometimes the honest answer is a working-relationship problem with a founder. That can be fixed, but only if both of you name it.
The risks founders underestimate
You are hiring a memory. Your company has changed. You may have three more engineers, a different stack, a new cofounder. The person you remember may not fit the team you have now, and the team may not want them. Ask the engineers who were hired after they left.
The team watches what you reward. If your current engineers see a leaver come back with a 30 percent raise and a better title, some of them will draw the conclusion that leaving is the way to get promoted. Be deliberate about how the offer compares to people who stayed.
Old access and old habits. They will know shortcuts and systems that no longer exist or were deliberately changed. Treat onboarding as real onboarding, not a password reset. A one-week walk-through of what changed avoids a lot of "that's not how we did it."
Equity resets. Any vested equity from their first stint is theirs. Unvested shares were forfeited when they left. A new grant, with a new vesting schedule, is normal. Do not try to restart the old one. Get your lawyer to paper it cleanly, because a messy cap table entry is the kind of thing that comes up in technical and legal diligence later.
How to run the rehire process
Keep it shorter than a normal loop, but not zero.
- A frank conversation first. Why they left, what they learned, what they want now, and what would make them leave again.
- One interview with someone who has not worked with them. Ideally your current most senior engineer. This tests fit with the team you have, not the team you had.
- A focused reference from the place they are leaving. You already know how they worked with you. The question is what changed in the last eighteen months.
- A clear role description. Write down what they will own. Do not assume they will slot back into their old area, which someone else may now run.
- An offer based on the role today. Use your current pay bands. Our post on what to pay your first engineer covers how to set them if you do not have bands yet.
When the answer should be no
Say no, kindly, if any of these are true:
- The reason they left still exists and you are not willing to change it.
- Your current team has real concerns that you cannot resolve.
- You would not hire this person if they were a stranger with the same CV and interview.
- They need the job more than you need them, and both of you know it.
That last one is subtle. A rehire out of loyalty, or to rescue someone, tends to end in a second, more painful exit.
FAQ
Should a rehired engineer get their old title back?
Only if the role today matches it. If the team has grown and someone else now leads their old area, a lateral title is fair. Explain why upfront.
Is it awkward for the engineers who stayed?
Sometimes. Tell the team before the offer goes out, explain the role, and make sure the returning engineer is not leapfrogging someone who earned the same step by staying.
Do rehires leave again?
Some do. The ones who leave twice usually left the first time for a reason that never got fixed. That is why the "why did you leave" conversation matters so much.
Should we skip the interview entirely?
No. Keep it short, but always include one person who has not worked with them. It is the cheapest protection you have.
If you are weighing a rehire against an outside search and want a neutral view on the trade-off, book a call. Plenty of early teams use a few hours of senior judgment for exactly this kind of decision; our pricing shows how that works.