Short answer: a senior engineer with several short jobs is not automatically a red flag. Layoffs, acquisitions, and startups that ran out of money have filled many good resumes with one-year stints. What matters is the pattern behind the dates: why each role ended, whether they finished meaningful work anywhere, and whether they have ever stayed long enough to live with their own decisions. Ask about each move directly, verify with references, and weigh the answers against what your company actually needs.
Founders often send me a resume and ask the same question: "Four jobs in five years. Should I even interview this person?" Usually the answer is yes, with the right questions ready.
Why short tenures are more common now
Several things have pushed engineering tenures down over the past few years.
- Large tech layoffs affected many strong engineers who did nothing wrong.
- Many startups shut down or were acquired, and roles ended with them.
- Some engineers move deliberately to get raises that internal promotions do not match.
- Contract and fixed-term work has become more common, and some resumes list each contract as a separate job.
So the dates alone mean less than they used to. A resume with four roles might be four layoffs, four contracts, or four times someone left when things got hard. You need to know which.
The patterns that should worry you
No long stint anywhere
One or two short roles in a long career are normal. A senior engineer with ten years of experience and nothing longer than about a year is different. Engineering judgment grows from maintaining systems after they ship. Someone who always leaves before year two may never have dealt with the consequences of their own architecture, the migration that went wrong, or the shortcut that became a support burden. For a first senior hire, that experience is a big part of what you are paying for.
Every exit is someone else's fault
Listen to how they explain each move. "The company ran out of money," "my whole team was cut," and "I was hired for a project that got cancelled" are normal. If every story blames a bad manager, bad colleagues, or bad leadership, with no reflection at all, notice it.
Leaving at the hard part
Some engineers leave right after the exciting build phase, just before the product needs maintenance, scaling, or cleanup. Ask what state the system was in when they left. If the answer is always "just launched," dig further.
Stories that do not match references
This is the strongest signal. If they say a role ended in a layoff and a former manager describes something else, that matters more than the dates themselves.
The patterns that are usually fine
- Short roles at companies that clearly shut down, were acquired, or had public layoffs.
- Early-career moves, especially in the first few years.
- Contract roles that were always meant to be short.
- One or two quick exits from a bad fit, followed by longer stays.
- Moves that each came with clearly bigger scope, where they can explain what they learned and why they left.
A good engineer who has been through three shutdowns may actually be a strong fit for a startup. They know what failure looks like, and they may be good at shipping under pressure.
How to interview for it
Do not avoid the topic, and do not make it an interrogation. Walk through the resume in order and ask the same questions for each role:
- Why did you join?
- What did you build or own there?
- What state was it in when you left?
- Why did you leave, and whose decision was it?
- What would you do differently?
Answers that are specific, consistent, and include their own mistakes are good signs. For more on reading answers when you cannot judge the technical detail yourself, see interviewing a senior engineer when you cannot read code.
Then ask the forward-looking question plainly: "What would make you want to stay here for three years?" You are not asking for a promise. You are checking whether what they want matches what you can offer.
Verify with references
Reference calls are where tenure questions get answered. Ask former managers:
- Why did this person's role end?
- What did they leave behind, and was it in good shape?
- Would you hire them again, and for what kind of role?
The last question is the most useful. "Yes, for a build phase, not for long-term ownership" tells you a lot. The reference check questions post covers how to get honest answers from people who want to be polite.
Match the risk to the role
Think about what you actually need. If you are hiring your first senior engineer to own the product for the next few years, tenure risk matters more, because losing them after twelve months means losing most of your technical knowledge. The post on key-person codebase risk explains why.
If you need someone for a defined build over six to twelve months, a strong engineer who prefers short, focused engagements may be exactly right, and a contract arrangement may suit both sides better than a full-time offer.
You can also reduce the risk whatever you decide: require documentation as part of the job, keep all accounts company-owned, and use standard vesting so the incentive to stay grows over time. A short paid trial helps too, because you see real work before a long commitment.
If you want an experienced second opinion on a specific candidate, you can book a call.
FAQ
How many short jobs is too many for a senior engineer?
There is no fixed number. Several one-year roles with no longer stay anywhere in a ten-year career deserves careful questions. A few short roles explained by layoffs or shutdowns usually does not.
Should I ask candidates directly why they left each job?
Yes, respectfully and in the same way for every candidate. Clear, consistent answers that include their own part are a good sign.
Are layoffs a red flag on an engineering resume?
No. Layoffs have affected many strong engineers. Confirm the circumstances through references and focus on what the person built and learned.
Can I reduce the risk of a short tenure after hiring?
Yes. Standard vesting, company-owned accounts, written documentation, and shared knowledge of the codebase all make a departure less damaging, whoever you hire.