cvharbor editorial

How to write a software engineer resume that gets read

Most software engineer resumes list what the job involved. The ones that get interviews list what changed because the engineer was there — and say it in language a non-engineer reading quickly can still follow.

A hiring manager or recruiter spends well under a minute on a first pass. In that time they are looking for evidence you have done, at some scale, the kind of work the role needs — not a description of your day-to-day. The single biggest lever on a software engineer resume is rewriting responsibility statements as outcome statements.

Responsibility versus impact

"Responsible for the checkout service" tells the reader what you were near. It does not tell them what you did to it, or whether it worked. The fix is not longer sentences — it is naming the change and, where you actually have the number, its size.

The good version works because the number came from somewhere the engineer could actually check: a support ticket queue. If you cannot point to where a number came from, do not invent one. A specific, honest qualitative claim — "cut failed-payment tickets sharply enough that support stopped escalating them" — beats a number nobody can defend in an interview.

Listing a tech stack without it reading as a keyword dump

A wall of technologies with no context tells a reader you have touched them, not that you can use them well. The stack list still matters, because recruiters do search by technology, but it works best paired with where each one was actually load-bearing.

• Group by category rather than one flat list: languages, frameworks, infrastructure, data. A reader scanning for "Kubernetes" finds it faster under "Infrastructure" than buried between a language and a testing library.
• List what you'd be comfortable being interviewed on. A technology you used once, briefly, two jobs ago and could not now explain in depth is a liability if it gets asked about.
• Put the stack that matters most for the role you want near the top of that section — the reader's eye goes there first, and role-specific ordering costs nothing.
• Skip tools everyone assumes: don't list "Git" or "command line" as if they were differentiators.

The stronger signal, though, sits in the experience bullets themselves. "Built the ingestion pipeline in Go, moving it off a Python service that could not keep up with peak load" tells a reader far more about your relationship with Go than the word appearing in a list.

Generic bullet points, and what replaces them

A specific bullet almost always survives contact with the interview; a generic one gets you a follow-up question you cannot answer well because there was nothing behind it. The tell is a bullet that would be equally true at a different company, on a different team, doing different work.

If you are stuck rewriting a bullet, ask what would have been different if you had not done that piece of work. If the honest answer is "nothing much," it probably belongs lower in the list or not at all.

GitHub, portfolios, and side projects

A GitHub link is worth including when the profile itself is worth a look: real commit history, projects that run, code you would not be embarrassed to have someone read. A link to an account with three forked tutorial repos and no original commits does more harm than leaving it off, because a curious reader will click.

• Pin two or three repositories that best represent your work, not everything you have ever pushed.
• A short README that says what the project does and why you built it turns a code dump into something a non-expert can also evaluate.
• A side project that solves a real problem you had is a stronger signal than a from-a-tutorial clone, even if the tutorial one is more polished.
• If your best work is proprietary and cannot be shown, say so plainly in a project description rather than leaving a confusing gap.

Junior candidates without much paid experience get the most lift from this section, because it is often the only place they can show unsupervised work. Senior candidates get less lift from it — by that point, the job history is doing the talking, and a portfolio is a nice-to-have rather than load-bearing.

Our builder is set up for this: it separates the tech-stack field from the experience bullets so you are not tempted to bury your stack in prose, and it will not let a bullet through with no outcome in it. Build your resume

What the interview format tells you about what to emphasize

Software engineering hiring runs through a small number of well-known formats, and knowing which one a company favors changes what is worth emphasizing on the resume that gets you there.

Take-home projects

Companies that lean on take-homes are usually trying to see how you structure a small, real problem without an interviewer in the room. A resume heavy on side projects and personal repositories tends to land well here, because it already demonstrates the kind of self-directed, finished work a take-home is trying to test for.

System design interviews

System design rounds test how you reason about scale, trade-offs and failure modes, usually for mid-level and senior roles. A resume aimed at this format benefits from bullets that show you have actually made those trade-offs before: why a queue instead of a direct call, why a cache was added and what happened when it was not there.

Live coding and algorithm interviews

This format tests raw problem-solving under time pressure and correlates least with what your resume says. It is still worth knowing that a company favoring this format is not weighting your project history as heavily, so do not over-invest resume space trying to win a round the resume itself cannot influence.

None of this means writing three versions of your resume. It means knowing, if you have a choice of what to lead with, which format the company you are applying to is more likely to run — often visible from the job posting or from what past candidates have reported.

Before you send it

• Does every bullet name a change, not just a duty?
• Where you have a real number, is it one you could defend if asked how it was measured?
• Is the tech stack grouped and ordered for the specific role, not just dumped in alphabetical order?
• If you link GitHub, would the pinned repositories survive someone actually opening them?
• Does at least one bullet per role answer "what would have been different if I had not done this"?