Two people read your engineering resume and want opposite things. How to structure skills, write bullets that survive scrutiny, and use projects well.
Your engineering resume gets read twice, by people with different jobs.
The recruiter reads it first, usually for under a minute, and is checking whether you match the requisition: the stack, the years, the level, the location. They are not evaluating your architecture decisions, and they may not know what Kubernetes does.
The hiring engineer reads it second, more slowly, and is asking a different question — has this person shipped something difficult, and can they explain what made it difficult?
Most engineering resumes are written for one of those readers and fail the other. Keyword-stuffed ones clear the first screen and then look hollow to the engineer. Beautifully written narrative ones never reach the engineer because the recruiter could not find "Kafka" on the page.
The document has to do both, and fortunately they do not conflict.
The skills section: for the first reader
This is the recruiter's section. It should be near the top, scannable in five seconds, and specific.
Group it. An eighteen-item comma-separated run is a wall; three labelled clusters can be read at a glance.
Languages Go, TypeScript, Python, SQL
Infrastructure AWS (ECS, RDS, Lambda, SQS), Terraform, Docker, GitHub Actions
Data Postgres, Redis, Kafka, dbt, Snowflake
Practice Distributed tracing, load testing, incident response, code review
Three rules:
Name specific technologies, not categories. "Cloud technologies" matches no search. "AWS (ECS, RDS, Lambda)" matches three.
Include the sub-services. Recruiters filter on "Lambda" and "Terraform", not "AWS". Naming the specific services you have used is what makes you findable, and it is also more honest — "AWS" covers two hundred products.
Do not list what you cannot defend. Everything here is an invitation to be asked. If you touched Kafka once in 2022, either put it under a clearly-labelled "Familiar" grouping or leave it out. An engineer who asks about consumer-group rebalancing and gets a blank look has learned something about the rest of your resume too.
Skip proficiency bars. Nobody has ever drawn themselves at two stars, they carry no information, and rendered as graphics they contain no extractable text.
The bullets: for the second reader
This is where engineering resumes are won and lost, and the failure is consistent — describing the technology instead of the problem.
"Developed and maintained microservices using Node.js, Docker and Kubernetes in an Agile environment."
"Traced a memory leak that had forced weekly restarts for eight months — a connection pool that was never released on timeout. The fix took average API response from 420ms to 95ms and ended the on-call pages."
What an engineer is looking for in a bullet:
- A problem that was actually hard, and some signal of why
- What you decided, particularly where there was a trade-off
- What changed, in numbers where they exist
- Scale, because 400 requests per second and 400,000 are different jobs
The trade-off is the part most resumes omit and engineers most want. "Chose to shard by tenant rather than by time, accepting more complex rebalancing to keep single-tenant queries fast" tells a reviewer more about your judgment than any list of technologies.
Cut CI from 22 minutes to 6 by splitting the test suite and caching layers properly; the change removed the informal habit of skipping tests on 'small' PRs.
Migrated 14 services from EC2 to ECS over four months with no customer-facing downtime, right-sizing during the move to cut monthly spend by roughly 30%.
Both name a number. Neither is a list of tools.
Projects and GitHub
Whether to include personal projects depends entirely on where you are.
Under about three years of experience, projects are essential — they are the closest thing you have to evidence of shipping. Write them like jobs: name, timeframe, one line of context, two bullets with outcomes.
Mid-level and beyond, projects are optional and often should come out. Production work at scale carries more weight, and a side project competing for space with real systems work sends the wrong signal. The exception is when the project demonstrates something your job cannot — you work on internal tools but want to move to distributed systems, so you built something distributed.
On linking GitHub: only if what is there helps. A profile consisting of forked tutorials and three empty repositories actively damages your case, because a reviewer will click and form an impression.
If you do link, link a specific repository rather than the profile, and make sure it has a README that explains what the thing is, why it exists, and how to run it. Reviewers spend about ninety seconds there. A good README is worth more than a thousand additional lines of code.
Getting past the experience filter
The posting says three to five years. You have eighteen months. Two things genuinely help.
Match on evidence rather than duration. If the requirement is production experience with a specific technology and you have shipped something real with it, say so in the summary where it will be seen before the dates are. Years are a proxy for capability; direct evidence beats a proxy.
Show the scale you have worked at. Junior candidates routinely under-describe scope. If your service handles meaningful traffic, or your team owns something with real consequences, that belongs on the page — "the service that fails if this breaks" is a sentence worth writing.
What does not work is padding the skills section with everything you have read about. Reviewers screen for it, and the interview will surface it in the first fifteen minutes.
Format specifics
One page under about eight years, two beyond. Engineers skim aggressively; a third page lowers the odds your good material is found.
One column. Two-column layouts get extracted in file order rather than visual order, which can separate your job titles from their bullets entirely.
No skill graphics, no icons, no headshot.
Include the link that is actually worth clicking — a repository, a live deployment, a technical blog post. One is enough. Three links, none of which reward the click, is worse than one that does.
Text-based PDF, and check it: open the export, select all, paste into a plain text editor. If your stack names and job titles come through in the right order, the recruiter's system will index them correctly. Our guide on how ATS actually works covers what that pipeline is doing.
The review pass
Read each bullet and ask whether an engineer could form a question from it. "Developed microservices using Node.js" produces no question. "Sharded by tenant rather than by time" produces several — and questions are what get you into an interview where you can answer them.
Then check the reverse: is there anything on the page you would rather not be asked about? Fix that before you send it, not in the room.
Land more interviews with ATS-optimized resume tools
Build Your Engineering ResumeFrequently Asked Questions
How should engineers structure the skills section?
Grouped by category — languages, infrastructure, data, tooling — with specific named technologies rather than umbrella terms. Put it near the top regardless of seniority, because recruiters screening for a stack read it before anything else.
Should I include personal side projects?
Yes if you have under about three years of professional experience, or if the project demonstrates something your day job does not. Beyond mid-level, shipped production work carries more weight and projects can come out.
Do I need to link my GitHub?
Only if what is there supports your case. A profile of empty tutorial repositories is worse than no link. Link a specific repository with a real README rather than the profile itself.
How long should an engineering resume be?
One page under about eight years, two beyond. Engineers reviewing resumes skim aggressively, and a third page reduces the chance the good material is found.
CraftMyDocs Editorial Team
Resume & Career Experts
The CraftMyDocs editorial team writes practical, tested guidance on resumes, cover letters, ATS, and job searching — drawing on recruiter feedback and the data behind thousands of resumes built on the platform.