The Software Engineer Resume Template That Survives Six Seconds

It's four o'clock on a Friday. The req has been open for eleven days, there are 180 applications in the folder, and the hiring manager — who also has a sprint review on Monday and a production incident from Tuesday still open in another tab — has an hour before they leave.

They are not going to read your resume. Nobody is going to read your resume. What is going to happen is that someone scrolls a list, opens yours, spends about six seconds in the top third of page one, and makes one of two decisions: maybe or next. Everything you write below that fold is only ever read by someone who has already decided you might be worth it.

That's not cynicism. It's the constraint. And once you accept it, building a software engineer's resume gets a lot simpler — because you stop trying to be comprehensive and start trying to be legible.

What happens in the six seconds?

They're answering three questions, in this order, and they're doing it almost pre-verbally:

1. 1What kind of engineer is this? Backend, frontend, infra, ML, mobile. If they can't tell, you're already in trouble — a generalist reads as unplaceable, not versatile.
2. 2How senior? Not your title — your scope. Did you own a system, a feature, or a ticket?
3. 3Is there anything here I couldn't get from the other 179? One number. One specific system. One thing only you did.

Notice what isn't on that list. Not your font. Not your two-column layout. Not the little skill bars showing you at 80% Python. Those things don't get you rejected — they just don't do anything, while costing you the space and the parseability that would.

So what's the template?

Boring. Deliberately, aggressively boring. Single column, standard headings, real text, one page. Every deviation from this is a risk you're taking for no upside — and the parser that reads you first has never once been impressed by a sidebar.

How do you write the bullets?

This is the whole game, and it's where almost every engineering resume dies. Look at the difference:

• Responsible for backend services and API development.
• Worked on migrating our infrastructure to Kubernetes.
• Helped improve system performance and reliability.

• Migrated 40 services to Kubernetes, taking deploy time from 25 min to 4
  and removing the weekly release freeze.
• Reduced p99 API latency 6x by adding a read-through cache and killing an
  N+1 in the orders path.

Same person. Same job. The first version tells you what the org chart said they were assigned. The second tells you what was different because they were there — and that is the only thing a hiring manager is actually reading for.

The formula that forces it — popularised as a Google recruiting guideline — is accomplished [X], as measured by [Y], by doing [Z]. It works not because it's magic but because you cannot finish the sentence without naming an outcome, a measurement and a method. Which happens to be exactly the three things you'll be asked about in the interview anyway. A bullet written this way is a pre-answered interview question.

Where does the tech stack actually belong?

Both places, doing different jobs.

The practical rule: every technology you'd be sad not to be asked about should appear inside a bullet at least once. The skills list is there so the database search finds you. The bullets are there so the human keeps reading.

Do side projects count?

Yes — under one condition. A project counts when someone other than you has used it. Stars, downloads, a company running it, teammates depending on it, users. "Open-source double-entry accounting library, 900+ stars, used in production by three companies" is a real credential.

A project does not count when it's a tutorial you followed. A to-do app, a weather dashboard, a clone of an existing product with no users — a hiring manager has seen four hundred of these and they read as "has completed a course", which they already assumed. If you're early-career and that's all you have, one of them, described in terms of a real technical decision you made and defended, beats three of them listed as titles.

A GitHub link with nothing on it is worse than no GitHub link. They will click it, and the click will cost you.

What should you cut?

• The objective statement. "Seeking a challenging role where I can leverage my skills." Everyone is. Replace it with a summary that says what you do and how well.
• Every soft-skill adjective. "Team player", "detail-oriented", "passionate". Nobody has ever searched an ATS for team player, and nobody has ever believed one.
• Coursework, if you're more than two years out. It was relevant once.
• Any technology you'd panic about being asked to whiteboard. Every term on your resume is an implicit offer to discuss it for five minutes.
• The second page, if you're under ten years in. It isn't extra room; it's a page nobody reaches.