A technical resume is read twice: once by a recruiter who does not know what a message queue is, and once by an engineer who does. The first read decides whether the second happens. So the skills are grouped so a recruiter can match them to the posting, the bullets carry a result a recruiter can picture, and the stack sits inside each bullet where the engineer will find it. A project has a link only if the link is worth opening. Impact is a number, and the number is about the system, the users or the team, not the code.
Key points
- Group the stack under plain labels: Languages, Infrastructure, Data, Tools. Two to six items each.
- Every bullet has a result the recruiter can read and a stack detail the engineer can read.
- Projects as roles: what it does, who uses it, the stack, one number.
- A code link only when the repository is clean and current. A dead link is worse than none.
- Impact is measured on the system or the users. Lines of code is not a number.
The two readers
| Reader | Reads for | What they skip |
|---|---|---|
| The recruiter | The posting's terms, the level, the years, a result they can picture | Everything after the first missing term |
| The engineer | The stack in context, the scale, the hard part, what you owned | Buzzwords, lists of technologies with no context |
A resume written only for the engineer never reaches the engineer. A resume written only for the recruiter gets the interview and loses it in the first ten minutes. Each bullet has to carry both.
The recruiter reads the result. The engineer reads the parenthesis.
The skills section
Grouped, labelled in plain words, in the posting's order. For a backend engineer:
Languages: Go, Python, SQL. Infrastructure: Kubernetes, Terraform, AWS. Data: Postgres, Kafka, Redis. Tools: Git, GitHub Actions, Grafana.
Two to six items under each label. Nothing you cannot be interviewed on. No proficiency labels, no years per item, no version numbers. The guide on skills has the parser rules, and the main one is the posting's exact spelling.
A list of forty technologies is read by the recruiter as none and by the engineer as padding. Twelve to twenty, grouped, is a list both readers finish.
Bullets with two layers
The formula is verb, scope, result, with the stack in a clause the recruiter can skip.
Rebuilt the settlement pipeline for twelve payment partners (Go, Kafka, Postgres), handling twelve times the volume at the same infrastructure cost.
The recruiter reads: rebuilt a pipeline, twelve partners, twelve times the volume, same cost. The engineer reads: Go and Kafka and Postgres, and a throughput problem solved without scaling the bill. Both got what they came for from one line.
More examples of the shape:
- Cut p95 API latency from 900 to 120 milliseconds by moving session lookups from Postgres to Redis, for a service handling 40,000 requests a minute.
- Led the migration of 60 services from a hand-managed cluster to Kubernetes with Terraform, cutting deploy time from forty minutes to four.
- Designed the event schema (Avro, Kafka) that three teams now publish to, replacing four point-to-point integrations.
Projects
A project is a role: title, where it lives, dates, bullets. The first bullet says what it does and who uses it. The second names the stack and the hard part. The third has a number.
Maintainer, openqueue (open source), 2023 to present
- A lightweight job queue for Go services, used in production by at least six companies that have filed issues.
- Exactly-once delivery over Postgres without an external broker, the part most users adopt it for.
- 1,400 stars, 31 contributors, releases monthly.
Six projects is five too many. The one or two that have users, a hard part, and a number go on. The rest live on the code profile, linked once.
Links
One link to a code profile and one to a portfolio or a blog, if they are current. A profile whose last commit was two years ago says the opposite of what you want. A repository with no readme and a failing build says you ship like that.
Before the link goes on, open it as the engineer will: readme first, then the most recent commit, then the tests. If any of the three embarrasses you, fix it or drop the link.
Impact that counts
Impact is about the system, the users or the team. Latency, throughput, cost, uptime, deploy time, incidents, the number of teams on the thing you built, the number of services migrated. Those are numbers an engineer trusts and a recruiter can picture.
Lines of code, commits, pull requests reviewed and "contributed to" are not impact. They describe activity. Every engineer has them, and none of them tells the reader what changed.
If the work had no number, the result is a change in words: "replacing four point-to-point integrations", "the part most users adopt it for", "the first service on the new cluster".
Questions
Does the parser handle code terms?
Yes, as plain strings. "Go" is a problem for some search tools because it is a common word, so write "Go (Golang)" once in the skills list. "C++" and "C#" parse fine as text.
How many years do I list per technology?
None. The role dates say how long you have been working, and the interview says how well.
Do I list the technologies I used at each job?
Inside the bullets, as the parenthesis, where they were used. A "technologies used" line under each role is a second skills list, and it is read as one.
What about certifications?
Cloud and security certifications matter in operations roles and go in education with the year. Most software roles do not read them. The project does more.
Is a one-page technical resume enough for ten years?
Two pages, with the last two roles in depth and the rest at a line each, and the skills section on page one. The guide on length has the rule.