You have the same background you had the week before the layoff. What changed is the market reading it. A software engineer resume after a layoff has to do something your old one never had to do: account for time you were not employed, and prove your hands are still on a keyboard.
Most of what circulates about this is generic career-gap advice or motivation. Neither tells you where the layoff line goes, or what a reviewer does with your GitHub link.
What actually changed in engineering hiring
Three things about the pipeline are worth knowing before you touch the file, because they decide which advice applies at which stage.
- The first read is fast, and it is a person. A recruiter narrows a long queue with the search tools inside the applicant tracking system, then scans for title, years, and stack match. The software stores and sorts. A human still decides.
- Tech layoffs since 2023 have made gaps and short tenures ordinary in that queue. What is not ordinary is an end date with no reason attached and a timeline nobody can follow.
- Currency evidence gets read later. Commit history, tagged releases, named framework versions: the hiring manager and the engineer who interviews you will look at those. A recruiter on a volume screen almost never will.
So the resume has two jobs, aimed at two different readers. Translate impact for the fast pass. Prove currency for the technical one.
The layoff line on your resume: where and whether to say it
Short version. If there is a visible gap and a company event caused it, write one line. If the gap is a couple of months and the dates speak for themselves, skip it and answer the question in the screen.
Put it as a short sub bullet under the affected role, or as the last line of your summary if the layoff is the top-of-page story.
Two phrasings, written the way a person talks:
- Laid off when the company cut the whole platform team.
- Position eliminated when leadership shut down the product line I worked on.
Neutral, no blame, nothing about severance or how it felt. Read yours out loud. If it sounds like a press release, cut words until it sounds like a status update.
Two things that line will not do for you. It will not carry the conversation: a recruiter is going to ask why you left in the first call, and a calm, consistent verbal answer matters more than the wording on paper. And if you have been through more than one round in this stretch, per-role one-liners will not stop anyone from connecting the dots. Name the pattern once, in the summary or the cover note. Two rounds of company-wide cuts reads as market conditions. Two separate explanations read as something else.
How long you have been out changes the tone, not the content. Under six months, one line is enough. Past a year, expect the follow-up question in every screen, and have a two sentence version ready that ends with what you have been building since.
Keeping a stack current on paper during a gap
Reviewers want proof you kept your tools sharp. That proof can be light. It has to be real, and it has to be dated.
What counts as a currency signal:
- Named versions in a project line or a README. A bare framework name tells a reviewer nothing about whether you touched it last year or five years ago.
- Fresh code with receipts. Merged pull requests, tags, issue links, a live demo, a package release.
- Production markers. Tests, CI, a health check endpoint, some monitoring, a runbook in the repo.
- Problems that look like real work. Latency, reliability, cost, privacy, developer experience.
What reads as padding: tutorial repos with no README and no users, a bullet claiming you stayed current with nothing attached, a certificate with no code behind it. If a course was worth taking, ship something from it and write that up as the project.
On the page, a Projects section with entries that look like small roles does the work. Stack, shipped artifact, outcome in plain language. Link the repo only if you would be happy opening it in an interview.
A worked example of an entry that reads as production evidence:
Incident Dashboard, solo project during job search Built and deployed a small production grade dashboard in React and FastAPI, containerized and shipped to a managed VM with basic observability. Evidence: tagged releases, unit and integration tests, health check endpoint, and a README with ops notes and a runbook.
How many entries you need tracks how long you have been out. One solid project covers a short gap. Past a year, two or three smaller shipped things dated a few months apart do more than one big build finished the week before you started applying, because the timeline is part of what gets read.
So pick one project and get three words onto its top line: shipped, tested, monitored. If you cannot say all three honestly, shrink the scope until you can.
Side projects and open source: what counts as evidence
Side projects and open source only count if they look like work someone would pay for. Be clear-eyed about who reads them, too. The recruiter clearing a screening queue will not open your repo. This section is for the hiring manager, and for the part of an interview where you walk through something you built.
What a side project needs to look like production work:
- It solves a pain you actually had. Migration scripts, small CLIs, dashboards.
- It has a release. Even when you are the only user, cut the release and write the note.
- A stranger can run it from the README. Commands, prerequisites, a short runbook.
What makes an open source contribution count:
- Merged pull requests tied to issues. One sentence on the problem, one on the fix.
- Releases you cut or helped cut. Say what changed and why anyone cared.
- Docs or tests that unblocked other people. The unblock is the point, and the line count is not.
Placement. If your last paid role ended recently, keep Experience first and put Projects after Skills. If the gap is the top story and the projects are strong, move Projects above Experience and keep the section tight. Both kinds go in one Projects section either way, cut to the two or three entries you would want to be asked about.
Seniority framing when applying sideways or down
Plenty of engineers in this cycle are applying a level below the last title they held. The worry is looking overqualified, or looking like you will leave the moment the market turns. Framing helps with some of that, and it is worth knowing up front where it stops helping.
Calibrate the bullets to the scope of the target job. If the last two years were mostly strategy and reviewing other people's designs, pull the delivery and craft work forward. Trade size bragging for complexity, because a nasty latency problem you fixed says more to a hiring manager filling a mid-level backend role than the headcount you used to carry. Cut the bullet count while you are in there. The sharpest outcomes stay, the rest is interview material.
Keep the titles you actually held. Do not restate a senior role as staff to match a posting, and do not go the other way either. Retitling here means a functional headline that names your lane, something like Backend Software Engineer, at or below the level you genuinely reached. Level words you never held tend to surface again at reference or background check, and a recruiter reads that as inflation.
A summary you can adapt: Software engineer focused on backend services and reliability. Primary stack includes Go, Python, and Postgres. Known for calm incident response and pragmatic shipping.
Then there is the part no resume solves. A recruiter's first screen will ask what you are looking for, and a senior number attached to a mid-level requisition ends the conversation no matter how the bullets read. Decide your real floor before you apply down, and say it plainly and early rather than finding the mismatch in round three.
Tailoring for screening without keyword stuffing
The goal is coverage inside context you actually owned, not a pile of terms.
- Mirror the exact skill names from the posting when they are true for you, inside bullets tied to outcomes.
- Keep Skills short and grouped: backend, frontend, cloud, data. A laundry list dilutes everything in it.
- If the posting names a domain, use the domain term once, in a bullet where it belongs.
HiringCoachAI can take some of the mechanical work off you. The resume builder targets a posting using language from your own history, and the job application tracker keeps a high-volume search from turning into forty browser tabs.
Assembly order
- Header. Name, city and state, email, GitHub or portfolio, LinkedIn.
- Summary. One or two lines: target role, core stack, one thing you are known for.
- Skills. Grouped, not dumped.
- Projects. Two or three entries with evidence.
- Experience. Your last few roles, impact bullets.
- Education and certifications. Only if they earn the space.
If you want help getting this onto paper faster, create a free HiringCoachAI account and run it through the resume builder. It will not write your layoff line for you, and it should not.