Skip to content
C Codeloom
Career

Resume Tips for Software Engineers

A practical, opinionated guide to writing a software engineer's resume — impact bullets, tech stack lists, side projects, and the common mistakes that get resumes skipped in ten seconds.

·10 min read · By Yash Kesharwani
Beginner 10 min read

What you'll learn

  • Why a one-page resume still wins in most cases
  • How to write impact bullets that say something (verb + what + measurable result)
  • How to present your tech stack so recruiters and engineers both get value
  • Why side projects often beat coursework
  • What hiring managers actually read — and what they skip
  • The common mistakes that get a resume tossed in seconds

Prerequisites

  • No prior knowledge required — useful at any career stage

A resume is not a memoir. It is a sales document, read in about ten seconds by a tired human, scrolled through on a small monitor between meetings. The goal is not to list everything you have ever done. The goal is to make it impossible to skip you.

This post collects what works, what does not, and the patterns I have seen survive contact with thousands of resumes.

One page

For 95% of engineers — early career, mid-level, even most senior — one page is the right answer. Reasons:

  • Hiring managers skim. A second page often is not read.
  • A long resume signals that you cannot prioritise.
  • The discipline of cutting forces you to keep only the strongest bullets.

The exception is a research-heavy CV with publications, or a 15+ year career with a dense roster of senior roles. Even then, the first page must stand alone.

If you cannot fit your resume on one page, the answer is almost never “use a smaller font.” It is “cut weaker bullets.”

The five sections you need

A modern engineering resume rarely needs more than:

  1. Header — name, email, GitHub, LinkedIn, optional location
  2. Experience — reverse-chronological, 3–5 bullets per role
  3. Projects — 2–4 side projects with one to two lines each
  4. Education — degree, school, graduation year
  5. Skills / Stack — languages, frameworks, tools

That is it. No “objective.” No “summary” you wrote in 30 seconds. No photo. No quotes from previous managers.

The order can shift. Early-career candidates often put Projects above Experience because that is where their best work is. Mid-career candidates put Experience first. Either is fine.

Impact bullets: the formula

Every bullet under Experience or Projects should follow one shape:

Verb + what you did + measurable result

Weak:

Responsible for working on the payment system.

Better:

Refactored the payment system to use idempotency keys, eliminating
duplicate charges (~$30K/quarter in chargebacks).

Three things changed:

  • Strong verb. “Refactored” beats “responsible for.” Use “built,” “shipped,” “led,” “reduced,” “migrated,” “automated.”
  • Concrete what. “Idempotency keys” is specific. A reader who knows the domain immediately gets it.
  • Measurable result. A dollar figure, a percentage, a time saved, a request rate handled. Numbers anchor the bullet and signal that you think about outcomes.

More examples:

Built an internal dashboard in React + Postgres that replaced a
nightly spreadsheet, saving the ops team ~8 hours/week.

Reduced cold-start latency on the auth service from 1.2s to 180ms
by lazy-loading the JWT key cache.

Migrated 14 microservices from Node 16 to Node 20 with zero
downtime, owning the rollout plan and on-call rotation.

Led the team's adoption of Vitest, replacing Jest and cutting CI
test time from 9 minutes to 2.

You will not always have a clean number. When you do, use it. When you do not, describe the impact in human terms: who benefits, what they could do that they could not before.

Avoid “responsible for…”

This phrase is the most common resume tell. Every junior resume is full of it. It says nothing about what you actually did or whether you did it well.

Bad:

- Responsible for the front-end of the customer portal.
- Responsible for code reviews.
- Responsible for writing unit tests.

Better:

- Shipped 6 features for the customer portal in 4 months, including
  SSO and a self-serve refund flow used by 40% of customers.
- Reviewed ~200 pull requests/quarter; established a checklist that
  cut median review time from 2 days to 6 hours.
- Raised test coverage on the billing module from 30% to 85%,
  catching three production bugs in the next release.

Same job. Completely different reading.

Your tech stack: dense but honest

A Skills or Stack section should be:

  • Grouped. Languages, frameworks, databases, infra, tools. Skimmable.
  • Honest. If you list it, you can answer questions about it. Recruiters will pattern-match keywords; engineers will probe in interviews.
  • Current. Drop the things you used five years ago and have not touched since.

A reasonable shape:

Languages:    TypeScript, Python, Go
Frameworks:   React, Next.js, FastAPI, Astro
Databases:    Postgres, Redis, DynamoDB
Infra:        AWS (ECS, Lambda, S3), Terraform, Docker
Tools:        Git, GitHub Actions, Datadog, Linear

Avoid the “I once read a blog post about it” list. Three deep skills beat fifteen shallow ones.

For broader context on a few languages, see What Is Python?. For modern CSS skills worth listing, see What Is Tailwind?.

Side projects beat coursework

For early-career candidates, the Projects section often matters more than Education. A side project shows:

  • You can ship without being told to
  • You can pick a stack and own decisions
  • You care about something beyond grades

Coursework, by contrast, shows that you turned in assignments. Everyone applying did that.

A strong project entry has the same shape as a job bullet:

ShortLink — a self-hosted URL shortener (TypeScript, Hono, Postgres)
- Built a Hono API with rate limiting and per-link analytics.
- Deployed on Fly.io with weekly Postgres backups to S3.
- 1.2K stars on GitHub, 80+ self-hosted users.

Include a link. Link to a live demo if you have one. A linked, working project is worth more than three bullet points describing one.

Two real projects beat ten half-finished tutorials. If you have a graveyard of unfinished side projects, do not list them — pick one and polish it instead.

Education: short

For most candidates, the Education section is two lines:

BSc Computer Science, University of Somewhere — 2024
GPA: 3.8 (if strong; omit otherwise)

That is enough. Do not list every course. Hiring managers do not care that you took “Algorithms II” — they assume you did.

If you have a degree, your degree is in CS, and you graduated more than two years ago, education shrinks further or disappears below Projects.

What hiring managers actually read

From the perspective of someone scanning a stack of resumes:

  • Header for 1 second — what is your name, can I find your GitHub?
  • Most recent role for 4 seconds — what did you do last, was it relevant?
  • Tech stack for 2 seconds — keyword match?
  • Projects for 2 seconds — anything interesting?
  • Everything else only if the above hooked them

Optimise for those first ten seconds. The strongest bullet of your most recent role should be the first one a reader sees. Your tech stack should be easy to find without scrolling. Your Projects section should include at least one thing that makes someone stop and click a link.

Reflection prompt. Open your current resume. Read it for ten seconds, then look away. What do you remember? If the answer is “nothing specific,” your resume is doing nothing for you. Pick the one bullet you would want a reader to remember, and rewrite it until it is short, specific, and measurable. Then move it to the top of its section.

Format and design

You are not designing a magazine. The resume should be:

  • Plain. Single column, sans-serif font (Inter, Helvetica, Calibri), 10–11pt body.
  • Black on white. A single accent color is fine. More is noise.
  • PDF. Always PDF, never Word, never an image. Name it firstname-lastname-resume.pdf.
  • ATS-friendly. No tables, no text in images, no fancy multi-column layouts. The applicant tracking system will parse it wrong.

LaTeX templates (like Jake’s Resume) and plain-text generators both work well. Avoid Canva templates with two columns and giant icons — they look modern and parse terribly.

Common mistakes

The patterns that get resumes skipped fastest:

  • “Objective” section. “Seeking a challenging role that allows me to grow…” — every resume says this. Cut it. Use the space for one strong project bullet.
  • A photo. Cultural norms vary by country, but in the US, UK, and most of Asia, a photo signals inexperience and triggers bias-prevention rules at large companies. Skip it.
  • Listing every technology you have touched. A 40-line skills section reads as desperation. Trim aggressively.
  • Vague claims. “Strong communicator,” “team player,” “passionate about code.” Show, do not tell — write a bullet that demonstrates it.
  • Pronouns and full sentences. “I built a service that…” → “Built a service that…”. Resume bullets drop the subject.
  • Inconsistent tense. Past roles in past tense, current role in present tense. Pick a rule and stick to it.
  • Spelling and grammar mistakes. A single typo on a one-page resume is a credibility leak. Read it aloud. Have a friend read it.
  • Cute fonts. Comic Sans is a joke. So is Papyrus. So, increasingly, is anything not boring.
  • Outdated contact info. Triple-check the email and the GitHub link. A broken link on page one is fatal.

Tailoring per role

You do not need a unique resume per company. You do need to tweak the top.

When applying for a backend-heavy role, lead with backend bullets. When applying for a frontend role, lead with the React/Vue/Tailwind work. Reorder, do not rewrite. The whole exercise should take five minutes per application.

If you find yourself rewriting from scratch every time, your resume is trying to be too many things at once. Pick a primary specialisation and let the resume reflect it.

The cover letter question

Most engineering applications do not require a cover letter. When one is required:

  • Keep it to three short paragraphs
  • Open with why this company — not why any job
  • Pick one project or accomplishment to expand on
  • Close with a concrete next step

If a cover letter would be the same regardless of company, you do not need it. Skip and move on.

A final sanity check

Before sending, run through this list:

  1. Does it fit on one page?
  2. Is your GitHub link clickable and correct?
  3. Does every Experience bullet start with a verb?
  4. Does at least half of them include a number or concrete result?
  5. Would a skim of the top half tell a stranger what you do?
  6. Does the file open cleanly on a phone screen?
  7. Has someone other than you read it?

If yes to all seven, send it.

Recap

You now know:

  • One page is the right answer for almost everyone
  • Impact bullets follow verb + what + measurable result
  • “Responsible for…” is the most common resume tell — cut it
  • Stack lists should be grouped, honest, and current
  • Two finished side projects beat ten unfinished ones
  • Hiring managers spend ten seconds — optimise the top
  • Plain design and PDF format beat Canva templates every time

Next steps

Open your current resume. Pick the weakest bullet on it. Rewrite it using the verb + what + result formula. Repeat until every bullet earns its line.

Once your resume is solid, the next problem is the interview loop — system design, coding, behavioural. Those are different posts. For now, ship a resume you are proud to send.

Questions or feedback? Email codeloomdevv@gmail.com.