The software engineering resume has a specific problem that other professional resumes do not: it is read by two completely different audiences with completely different needs. The recruiter reads it for keywords, job titles, and company names. The engineering manager or tech lead reads it for technical credibility — and they can tell the difference between a resume that describes real technical work and one that uses the right vocabulary without the substance behind it. Writing a resume that works for both audiences requires understanding what each one is actually looking at.
There is one specific thing that separates software engineering resumes that get callbacks from those that do not, and it is not the template, the formatting, or even the company names. It is the specificity of the technical claims. A resume that says "built scalable microservices" means nothing. A resume that says "designed and implemented an event-driven notification service in Go that handles 40,000 messages per second with sub-10ms p99 latency, replacing a polling-based system that was generating 60% of our database load" tells a technical reviewer something real — and cannot have been written without actually doing it.
This guide is about producing that kind of specificity consistently across your resume, and about the structural decisions that make the specificity readable rather than buried.
The recruiter and the technical reviewer want different things from your resume. Understanding this difference is what allows you to write a resume that satisfies both.
Recruiters are typically evaluating five things in a first scan: job titles (do they match what we are hiring for?), company names (are they recognizable or credible?), tenure (are there red flags about job-hopping or gaps?), education (does it meet the formal requirement if there is one?), and the technical skills list (do the keywords match what we're looking for?). This scan takes 15 to 30 seconds. If none of these things raise concerns, the resume moves to the technical reviewer. If any of them raise concerns, it often stops there.
The recruiter is typically not in a position to evaluate whether your technical claims are credible — they are matching patterns, not assessing engineering judgment. This is why keyword presence in the skills section matters for getting past this stage, and why the format decisions that make the job titles and companies visible quickly matter.
The engineering manager, tech lead, or senior engineer reviewing your resume is looking for something fundamentally different: evidence that you are actually a capable engineer, not just someone with the right vocabulary. They are reading your experience bullets with specific questions. What did this person actually build? What were the constraints they were working within?
What decisions did they make that required engineering judgment? What scale of problem were they working on? Is this experience at a level of complexity that makes them likely to succeed in this role?
Technical reviewers cannot fully assess these questions from a resume alone — that is what the technical interview is for. But they can get a signal from the specificity of the resume. A bullet that names the specific technology, describes the specific problem, and characterizes the specific outcome tells a technical reviewer something. A bullet that uses general engineering language without specifics tells them that either the candidate cannot articulate their technical work, or the work was not technical enough to articulate specifically.
Either signal is concerning.
The software engineering community has been debating the one-page resume question for decades. The honest answer: one page is appropriate for engineers with under 8 years of experience. Two pages is acceptable for engineers with 8+ years who have genuinely different roles and projects to describe. More than two pages is almost never necessary and is almost always evidence of poor editing rather than genuinely important additional information.
The reason one page works for most engineers is not that longer resumes are penalized — it is that one page forces the editing discipline that produces a better resume. A two-page resume that could have been one page is almost always worse than the one-page version it would have been with tighter editing. The content that gets removed in editing to fit one page is almost always the least important content. What remains is the resume the reader actually wanted.
The cases where two pages are justified: a principal or staff engineer with five or more substantive roles, each with different technical scope; a PhD with significant research output plus industry experience; a career that spans genuinely different technical domains where both are relevant to current targets. The test: does each additional section add information that changes the case for interviewing you, or does it add information that is merely true? Only the former justifies the length.
In order of what to cut first: oldest experience (more than 10 years ago unless directly relevant), skills that are ubiquitous (Git, Agile, "proficiency in Google Docs" — these are baseline assumptions, not differentiators), education details beyond the degree and institution for anyone with more than 2 years of experience (coursework, GPA, clubs), verbose bullets where the same information can be conveyed in fewer words, and the professional summary if it merely restates what the experience section already shows. Do not cut: any role in the last 7 years, any project that demonstrates specific technical depth, and any certification that is genuinely relevant to target roles.
The skills section is the most ATS-critical part of a software engineering resume and simultaneously the most commonly done wrong. The failure modes are specific and worth naming.
"Python, JavaScript, React, PostgreSQL, AWS, Docker, Git, Kubernetes, TensorFlow, Redis, Node.js, TypeScript, MongoDB, GraphQL, Terraform" — this is the contents of a toolkit, not a skills section. A technical reviewer reading this cannot immediately identify what kind of engineer you are, what your primary stack is, or what distinguishes your skills from someone with a similar-looking list. The same skills organized by category tell a different story: "Languages: Python, TypeScript, JavaScript | Frameworks: React, FastAPI, Node.js | Databases: PostgreSQL, MongoDB, Redis | Infrastructure: AWS (Lambda, ECS, RDS), Docker, Kubernetes, Terraform | Tools: Git, GitHub Actions, Datadog"
The organized version immediately communicates: primary language is Python and TypeScript, front-end uses React, cloud is AWS with specific services named, and there is genuine infrastructure experience. The alphabetical version communicates: this person has used many technologies.
A skills section that lists Go, Rust, Haskell, and Erlang alongside Python and JavaScript without any qualification will either impress or concern a technical reviewer depending on the role. If the role requires Go and the reviewer asks Go-specific questions in the interview, the answer needs to match the claimed competency. A skills section where everything appears as equally capable will produce interview questions at the level of the most prominent items on the list. This is fine if your proficiency is actually even.
It creates problems if you listed things you touched briefly alongside things you work with daily.
One way to handle this without adding a proficiency-rating system (which reviewers are skeptical of): list primary skills first within each category, and list peripheral skills toward the end or in a separate "familiar with" line. "Languages: Python (primary), TypeScript, Go | Familiar with: Rust, Haskell" is honest and more useful to both you and the reviewer than a flat list where Rust appears between Python and TypeScript.
A recruiter searching for "Kafka" will not find "distributed messaging system." A recruiter searching for "Kubernetes" will not find "container orchestration." Use the actual names of the technologies, not descriptions of their category. This is the ATS optimization that requires the least effort and has the most impact — use exact, proper-cased names of technologies rather than their generic descriptions.
| Engineering type | Primary categories | Key terms to include |
|---|---|---|
| Backend / API | Languages, Frameworks, Databases, Cloud, Infrastructure | Specific languages, framework names (FastAPI, Django, Spring Boot, NestJS), database specifics (PostgreSQL not just "SQL"), specific AWS/GCP services used |
| Frontend / Full-stack | Languages, Frameworks, State management, Build tools, Testing | React/Vue/Angular (specific version context helps), state management (Redux, Zustand, Pinia), build tools (webpack, Vite, Next.js), testing (Jest, Cypress, Playwright) |
| Data Engineering | Languages, Orchestration, Processing, Cloud, Warehouses | Python, SQL, Airflow, dbt, Spark/PySpark, specific cloud data services (BigQuery, Redshift, Snowflake), specific ingestion tools |
| ML / AI Engineering | Languages, ML Frameworks, MLOps, Data tools, Cloud | Python, PyTorch or TensorFlow (both), Hugging Face, MLflow, Kubeflow, SageMaker, specific model types worked with (LLMs, computer vision, etc.) |
| Platform / Infrastructure | Languages, IaC, Orchestration, CI/CD, Cloud | Go or Python, Terraform, Kubernetes, Helm, GitHub Actions/Jenkins/CircleCI, specific cloud provider depth |
The experience section is where the resume either works or fails for the technical reviewer. The recruiter has already passed the resume through; now a technical person is evaluating whether the claimed experience is real and relevant. The bullets are the evidence.
A strong software engineering experience bullet has three elements in order: what you did (technically specific action), the technical context that makes the action non-trivial (constraints, scale, architecture decisions), and the outcome (measurable or observable result). Every element is important; the middle element is the one most commonly omitted.
The middle element — technical context — is what distinguishes "built an API" from real engineering work. The constraints and design decisions you navigated are the evidence of engineering judgment. What made the problem interesting or hard? What alternative approaches did you consider and reject?
What tradeoff did you make and why? These questions, answered in two clauses of a bullet, are what make a technical reviewer think "this person actually understands what they built."
Entry 1 — the "did a thing" bullet:
Before: "Developed REST APIs using Python and FastAPI for the product backend."
After: "Designed and implemented a document processing API in FastAPI that serves 200 concurrent users — chose async endpoints over the team's existing synchronous Flask pattern because the workload was I/O-bound (PDF parsing, external service calls), reducing average response time from 4.2s to 340ms under load while eliminating the timeout errors that had been generating 3-4 customer escalations per week."
The after version gives a technical reviewer five specific things to probe in an interview and shows genuine understanding of async vs sync tradeoffs.
Entry 2 — the vague scale claim:
Before: "Optimized database queries to improve application performance."
After: "Identified and resolved a series of N+1 query problems in our ORM layer that were causing 40% of our API's database load — added eager loading for 8 common access patterns, added a covering index on the most expensive query (which had no index on the composite key it was filtering by), and introduced query result caching for reference data that was being fetched identically on every request; p95 response time on the affected endpoints dropped from 1.8s to 120ms."
The after version shows understanding of what N+1 queries are, how to address them at multiple levels, and what the actual impact was.
Entry 3 — the team accomplishment masquerading as individual:
Before: "Led migration of monolithic application to microservices architecture."
After: "Architected and led the extraction of the order management domain from a 400k-LOC monolith into an independent service — designed the event-driven integration pattern that allowed incremental extraction without a big-bang rewrite, defined the API contracts, managed the data migration strategy, and coordinated the cutover with zero downtime; the extracted service now handles 12,000 orders/day independently and has enabled 3 other teams to build integrations that were impossible when the logic was embedded in the monolith."
The after version shows architectural thinking, the specific pattern chosen (event-driven incremental extraction), and the business impact of the technical work.
Software engineering resumes are full of performance metrics, and most of them are either fabricated, context-free, or both. "Improved API response time by 40%" tells a technical reviewer almost nothing without knowing: what the starting point was, what the endpoint was, what was measured (p50? p95? p99?), under what load conditions, and whether the improvement was achieved through a genuine architectural change or by adding more hardware.
Better metrics than raw percentage improvements: absolute numbers with context ("p99 latency from 2.1s to 180ms under 100 concurrent requests"), volume metrics that characterize scale ("processes 500K events per day"), reliability metrics ("achieved 99.97% uptime over 18 months after implementing circuit breakers"), business impact metrics that connect engineering work to something an executive cares about ("eliminated the weekend on-call escalations that were averaging 2 per month"), and cost metrics ("reduced monthly infrastructure spend from X to Y by optimizing our container resource requests after profiling actual memory usage").
The specific numbers matter less than the fact that you have them. A candidate who cannot characterize the scale or impact of their work raises questions about whether they understand what they built, or whether they cared about the outcome beyond the technical implementation. Both raise concerns.
For software engineers with fewer than three years of professional experience, the projects section is often the most important technical evidence on the resume. For engineers with five or more years of substantive work experience, a projects section is optional — include it only if the projects demonstrate something meaningfully different from what the work experience already covers.
A project worth including on a software engineering resume has at least one of these properties: it demonstrates a specific technical capability at a level of depth that exceeds what your work experience shows, it solves a genuine problem rather than reproducing a tutorial, it is publicly visible (GitHub repo with real code and a README that explains the project), and there is a design decision you made that required judgment and can be explained specifically.
The projects not worth including: tutorial reproductions with tutorial code, homework assignments whose description would be "followed the assignment prompt," anything described as "a weather app" or "a to-do list" without a specific technical angle that makes it more than the most basic version of those things, and any project where the GitHub link shows very few commits with no documentation.
The project entry should answer: what problem did you solve, what technical choices did you make and why, what did it produce or do, and where can they see it. This should fit in two to three focused lines — not a paragraph of background, not a list of technologies that includes everything you ever touched while building it.
Weak: "Recipe app — A web application built with React and Node.js that allows users to search, save, and share recipes. Used MongoDB for storage."
Strong: "RecipeSearch — Full-text search engine for recipes using Elasticsearch, built to solve the problem that ingredient-based search at major recipe sites treats ingredients as tags rather than indexing amounts and techniques. Implemented custom analyzers for culinary vocabulary (e.g., "dice" and "diced" as equivalent, unit normalization), achieving sub-100ms search over 50K indexed recipes. React frontend, Node.js API, Elasticsearch — [GitHub link]"
The strong version names the specific technical problem (ingredient-based search that understands amounts and techniques), the specific technical solution (custom analyzers in Elasticsearch), and a specific outcome (sub-100ms on 50K records). It also explains why this is more interesting than a recipe app using a standard search implementation.
A merged pull request to a meaningful open source project is worth one line on a software engineering resume. Not a documentation fix or a typo correction — a code contribution that was reviewed by maintainers and accepted. The value is the external validation: someone who did not know you reviewed your code and found it acceptable for inclusion. That is a qualitatively different signal than code in your own repositories where you are the only reviewer.
If you have open source contributions, list them concisely: the project name, the nature of the contribution in a phrase, and the link. "Contributed Redis-backed session middleware to [project] — merged PR #1234" is sufficient.
One of the more common resume situations in software engineering: a candidate with four years of total experience applying for a senior role, or a candidate with seven years applying for roles that typically go to people with five years. The experience level implied by your years of employment and the level you are prepared to operate at are not always the same thing, and the resume is often where this mismatch needs to be addressed.
If your work has involved genuinely senior-level scope — you have owned significant systems, made architecture decisions, mentored others, and driven projects from ambiguity to completion — your resume should demonstrate that scope specifically. Job titles are not always the right signal; a company that was six months old when you joined may have given you a "software engineer" title for work that would be "senior engineer" or "staff engineer" work at a larger company. Make the scope visible through the bullets, not through inflating the title.
The resume evidence that signals senior-level readiness despite moderate YoE: bullets that describe systems design decisions rather than implementation only, explicit mentions of technical mentorship or leading other engineers, evidence of ownership of problems rather than tasks, and scale indicators that are consistent with senior-level responsibility.
Seven years of experience in software engineering can mean very different things. Seven years of increasingly complex, progressively scoped work with demonstrated growth in responsibility reads as senior or above. Seven years of doing similar work at similar scope, moving between companies roughly every 18 months, does not read as senior regardless of the YoE number. Technical reviewers look at the trajectory — is each role demonstrably more complex and more responsible than the last? — as much as the total number of years.
If your trajectory is not obvious from your titles, make it visible through the bullets: show the progression from smaller scope to larger scope, from implementation to design, from individual contributor to technical lead on specific work. The progression should be legible even if the titles are all "Software Engineer."
A resume optimized for a FAANG interview process is not the same document as a resume optimized for a Series B startup. The same engineer should write different versions for different targets — not because the underlying experience changes, but because the emphasis, vocabulary, and evidence that is most persuasive differs by context.
Large tech companies with rigorous interview processes are reading for evidence that you can operate at scale. The specific signals they look for: metrics that characterize the scale of systems you have worked on (users, requests per second, data volume), evidence of systems thinking rather than purely feature implementation, mention of impact on significant business metrics, and technical depth on the specific areas their interview process will probe. Resume screening at FAANG companies is often handled by recruiting coordinators before reaching engineers, so ATS-friendliness and matching the vocabulary of the job description matter more than at smaller companies where engineers review resumes directly.
Early-stage companies are looking for a specific combination: technical competence and versatility. The resume signals that work here: breadth of technical skills (full-stack experience is more valued than at specialized large-company teams), evidence of shipping things — products or features that are live and used — rather than operating on very large existing systems, comfort with ambiguity (projects that you owned end-to-end rather than contributing to a well-defined component of a well-defined system), and founding or significant early-employee experience at previous companies if you have it.
Remote-first companies are implicitly evaluating your ability to work effectively without in-person collaboration. The resume evidence that addresses this: clear, specific technical writing (your bullets demonstrate that you can communicate technical work in writing), independent project ownership, asynchronous communication tools mentioned in the skills section (Slack is table stakes; specific technical documentation tools, async video tools, or written technical specifications are stronger signals), and any experience with distributed teams or time zones.
For software engineers, the GitHub profile is to the resume what a portfolio is to a designer. Technical reviewers who are interested in a candidate will often look at the GitHub before making a decision to advance. What they find there either confirms or undermines the resume claims.
Recent commit activity: the contribution graph shows some regular activity in the last 3–6 months. Not every day — that is neither expected nor realistic for someone employed full-time — but enough to show that you are actively writing code outside of work. A completely empty contribution graph for the last year while claiming active software development experience raises questions.
Readable code in the pinned repositories: code that is organized, reasonably commented, and shows some attention to quality. You do not need to be writing production-quality code in all your personal projects, but code that shows no variable naming conventions, no organization, and no documentation beyond "this is my project" is an ambiguous signal.
READMEs that explain the project: a README is a technical communication artifact, and a good one signals that you can write about technical work clearly. Explain what the project is, why you built it, how to run it, and what the interesting technical parts are. This takes an hour and affects how every engineer who looks at your GitHub profile evaluates the project.
Many forked repositories with no commits. Repositories named "practice-problems" containing solutions to LeetCode or HackerRank problems with no other context. Projects whose last commit was the initial commit with all the tutorial starter code. A bio that has no information.
None of these are dealbreakers, but they are negative signals that accumulate into an impression of a candidate who has not thought carefully about professional presentation.
The Notepad test is the most reliable quick check for ATS compatibility: copy and paste your resume into a plain text editor and read what appears. If the output is garbled, out of order, or missing content, an ATS will have the same problem parsing it. The specific formatting decisions that fail the Notepad test most often: tables, text boxes, columns (ATS systems often read columns left-to-right across both columns rather than top-to-bottom within each column), headers and footers that contain contact information (many ATS systems do not parse Word document headers), and SVG or image elements that contain text.
The safest format for ATS compatibility: a single-column layout in a clean font (Calibri, Helvetica, Arial, Garamond all parse well), contact information in the document body not in a header, all dates in a consistent format (Month Year — Month Year or just Year — Year for older roles), and submitted as a PDF generated from a text document rather than scanned. The PDF preserves your formatting for human readers while retaining the underlying text that ATS systems parse.
Resume builders (Canva, Novoresume, and similar) often produce visually polished output that fails ATS parsing because of the underlying format choices — columns, text boxes, images with text, unusual PDF encoding. If you use a visual builder, run your output through an ATS simulator before submitting it to employers who use automated screening. The Rolerise Resume Optimizer checks keyword matching against job descriptions; a separate Notepad test checks format compatibility.