How to Write a Good Resume

Course Content

How to Write a Good Resume

15 sections · 30 lessons

Skills, education and projects sections

The experience section proves what you did. The sections below it — skills, education, projects — support that proof, and each one is easy to pad into something that weakens the page.

This lesson takes them in turn. For each, the question is the same: what is this section for, when does it help, and when does it start competing with better material?

A skills section that survives scrutiny

The skills section is the most-padded part of most resumes and the easiest to make worse than useless.

The rule that governs the listKeep• Anything you could be interviewed on• Languages you have shipped with• Tools that appear in your bulletsRemove• Things you read a tutorial about• HTML, Git, and Microsoft Office• Rating bars and years-of-use claims
Every skill listed is a question you have agreed to answer, so the list is a promise, not an inventory.

What it is for

Two things:

  1. Search. Recruiters filter on technology names, so the technologies you want to be found for need to appear.
  2. Fast confirmation. A hiring manager glances down to check you have the stack.

It is not for demonstrating breadth. Breadth belongs on your LinkedIn profile, where being found is the whole point and nobody will quiz you on it.

The rule that governs everything else

This one rule solves most skills-section problems. It removes the language you used in one university module. It removes the framework you read a tutorial about. What remains is defensible.

How to structure it

Group into three or four labelled categories, ordered by relevance to the role you want:

Text
Languages      Go, Python, TypeScript, SQLInfrastructure AWS (ECS, RDS, S3), Terraform, Docker, KubernetesData           PostgreSQL, Redis, Kafka, ClickHousePractices      Distributed tracing, incident response, CI/CD

Four lines. Scannable. Every item defensible.

What to remove

RemoveWhy
Proficiency bars or star ratingsMeaningless — your 4/5 and mine are not comparable. They also break parsers
"Microsoft Office", "Git", "Windows"Assumed. Listing them suggests you were short of material
Languages used once, years agoThey invite questions you will answer badly
Soft skills in a skills listCommunication, teamwork, leadership — unverifiable; prove these in your bullets
A single 40-item listNobody reads it, and it makes the real skills unfindable

Skills also belong in your bullets

The skills section confirms; the bullets prove. A technology named inside an achievement carries far more weight than the same word in a list. Compare the list entry:

Skills: Kafka

with the same technology inside a bullet:

• Cut order-processing lag from 6 minutes to under 10 seconds by moving fulfilment events onto Kafka with partition keys by warehouse.

Do both. The list gets you found; the bullet gets you believed.

Education, and when it moves down

Education is straightforward, with one common mistake and one genuinely hard case.

When education moves below experienceKeep it near the top• Still studying or just graduated• No full-time engineering role yet• Degree is the strongest credentialMove it down• Two or more years of experience• Work now outranks the coursework• Drop GPA and coursework with it
Education is prime page-one space that stops paying rent the moment you have shipped real work.

Placement

SituationWhere education goesWhat to include
Student or new gradNear the top, after contactDegree, institution, graduation date, relevant coursework, GPA if strong
0–2 years experienceAfter experience and projectsDegree, institution, year
3+ yearsNear the bottomDegree, institution, year — one or two lines
10+ yearsBottom, one lineDegree, institution. Year optional

The common mistake, as the lesson on section order noted: leaving education at the top years after it stopped being your strongest evidence.

What to include, and for how long

Coursework: only as a student or new grad, and only courses relevant to the role. Distributed Systems, Compilers, Machine Learning is useful. Introduction to Programming is not.

GPA: include it if it is strong and you graduated recently. Drop it after about two years of work, or immediately if it is not strong. Nobody will ask why it is absent.

Honours and awards: include meaningful ones — a competitive scholarship, a first-class degree, a placement in a well-known competition. Drop them as your work history grows.

The hard cases

No degree. Include the section anyway, with whatever is true: a bootcamp, relevant certifications, or significant self-directed study. Do not draw attention to the absence with an explanatory note. Most technology employers care far more about the last two years of your work, and an omitted degree row is unremarkable.

Degree in an unrelated field. Include it plainly. A physics or economics degree is not a liability, and trying to obscure it looks worse than the fact. If the transition needs framing, that is what the summary is for.

Degree in progress. State the expected completion date: BSc Computer Science, University of Pune — expected June 2027.

Projects, open source, and publications

These sections can be your strongest asset or obvious filler, and the difference is specific.

When a projects section helpsIt helps• You have little paid experience• The project is deployed and used• It shows a skill your jobs did notIt is filler• Tutorial clones with no users• Course assignments everyone built• Repos last touched three years ago
A project entry is written like a job entry: what it does, who uses it, what you built, at what scale.

When a projects section helps

  • Students and new graduates. Often your only evidence of building software. It should be substantial and placed high.
  • Career switchers. How you demonstrate current ability when your job history does not.
  • Anyone whose side project is more impressive than their day job. A tool with real users beats a bullet about an internal service nobody has heard of.

When it does not

Once you have three or more years of relevant professional experience, a projects section usually competes with better material. A tutorial-grade project alongside real production work makes the real work look smaller.

How to write a project entry

Same structure as a job: what it is, what you built, what happened as a result.

Weak:

Recipe App — A full-stack recipe application built with React, Node.js, and MongoDB. Users can create, edit, and delete recipes.

That describes a tutorial. Now:

Strong:

Pantry — Recipe app that suggests meals from ingredients you already have. ~2,400 monthly users. Built the ingredient-matching search in Postgres using trigram similarity after full-text search returned poor matches on misspelt ingredients. React, Node, Postgres. github.com/priyanair/pantry

The second names a real problem, a decision made in response to a failure, and evidence someone uses it.

If you have no users, that is fine — lead with the hard technical decision instead. The point is to show engineering judgement, not popularity.

Open source

Include contributions when they are substantial and verifiable. Name the project, describe what you contributed, and link the pull request or the profile:

Contributor, Apache Airflow — Fixed a scheduler deadlock affecting DAGs with more than 500 tasks (PR #34112). Three merged PRs in the scheduler module.

One merged pull request that fixed something real beats "contributed to open source". Vagueness here is read as nothing.

Publications, patents, and talks

Include when relevant to the role. Format them consistently and keep them short:

Talk: "Reducing p99 latency in a multi-tenant scheduler" — GopherCon India 2026

Patent: US 11,xxx,xxx — Method for distributed rate limiting (co-inventor)

For research-heavy roles, these can be the strongest section on your resume. For most product engineering roles they are a modest positive, and one line each is sufficient.