Software Engineer
An engineering résumé is usually read twice by two different people who want different things. A recruiter matches the stack in the posting and spends well under a minute doing it. An engineer then reads it looking for the size and difficulty of the systems you have worked on. A page tuned for only one of them fails the other, and most pages are tuned for the recruiter.
The stack list gets you read, and then stops helping
Keyword matching at the first screen is real, and pretending otherwise costs interviews. If the posting says Kotlin and Postgres and you have shipped both, those words need to appear. That is the entire job of the skills section.
It is also the whole of its value. Once an engineer is reading, a list of eighteen technologies actively hurts: it invites the assumption that most of them were touched once, and it makes the two you are genuinely strong in impossible to find. Separate what you would be comfortable being interviewed on from what you have used, or cut the second group.
Version numbers, years-per-language tables, and self-assessed proficiency bars all read as padding to the person who will interview you. None of them survive contact with a technical question.
Describe the system, not the ticket
“Developed new features using React and Node.js” is on thousands of résumés and conveys nothing about difficulty. The information an engineer wants is scale and constraint: how much traffic, how much data, how many services, what could not go down, and who else depended on you.
“Owned the payments service — 400 requests per second at peak, idempotent retries across three providers — and cut failed-charge retries from 11% to 3%” tells a reader what kind of engineer you are in one line. It also gives them the interview question they were going to ask anyway, which works in your favour.
Incidents belong here too. Something you broke and fixed, or an outage you diagnosed, is memorable in a way that feature work is not, and it demonstrates the operational sense that separates mid from senior far more reliably than a job title does.
Seniority is shown by blast radius
Titles are noise across companies — a senior engineer at a twelve-person startup and at a bank are not the same claim, and everyone reading knows it. What travels is the radius of your decisions: how many other people had to live with them, and for how long.
Design documents that were adopted, a migration other teams had to follow, an interface a dozen services call, a review culture you changed. These read as seniority in any organisation. “Mentored junior developers” does not, because it appears on every résumé from mid-level upward and is never elaborated.
If you have been the person others ask before making a change in a particular area, that is the sentence to write, and it should be specific about the area.
Where these résumés usually get cut
The most damaging pattern is a page of responsibilities that could describe any developer at any company: participated in code reviews, worked in an Agile environment, collaborated with cross-functional teams. All true, all shared with every other applicant, and collectively a full page of nothing.
The second is the personal-projects section carrying more weight than the professional one, in a résumé that has professional experience. Tutorial-shaped projects invite comparison with your paid work and lose. Keep one if it is genuinely unusual, and only if you would enjoy being questioned on it.
The third is silence about why you left, when the dates make it loud. Short stints and gaps are ordinary and become a problem only when the page appears to be avoiding them. A four-word clause — “contract ended”, “team dissolved”, “returned to study” — removes the question entirely.
Terms that appear in almost every posting.
- Named languages and frameworks
- A literal filter at the first screen. Include what is true and what the posting names; do not pad past that.
- System design
- Traffic, data volume, failure modes. Adjectives like scalable are not evidence.
- Cloud and infrastructure
- Whether you operated it or consumed it. These are different jobs and interviewers ask.
- Testing and CI
- What you changed about how the team ships, not that tests existed.
- On-call / production ownership
- One incident you diagnosed says more about seniority than any title.
Add a term only when your own experience supports it. ApplySpan flags requirements you cannot evidence rather than writing them in for you.
Questions
How long should a software engineer resume be?+
One page up to roughly eight years, two after that. The constraint is not a rule so much as an observation: the first screen is short, and a second page is only reached when the first one earned it.
Do I need a GitHub link or portfolio?+
Only if it holds something you would happily be questioned on. An abandoned profile of forks and tutorials is worse than no link, because a reviewer will judge the weakest thing they find there.
Should I list technologies I have only used briefly?+
Not in the same group as your strengths. An interviewer picks from your list, and there is no upside to a question about something you touched once two years ago.