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.
What it is for
Two things:
- Search. Recruiters filter on technology names, so the technologies you want to be found for need to appear.
- 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:
Languages Go, Python, TypeScript, SQLInfrastructure AWS (ECS, RDS, S3), Terraform, Docker, KubernetesData PostgreSQL, Redis, Kafka, ClickHousePractices Distributed tracing, incident response, CI/CDFour lines. Scannable. Every item defensible.
What to remove
| Remove | Why |
|---|---|
| Proficiency bars or star ratings | Meaningless — 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 ago | They invite questions you will answer badly |
| Soft skills in a skills list | Communication, teamwork, leadership — unverifiable; prove these in your bullets |
| A single 40-item list | Nobody 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.
Placement
| Situation | Where education goes | What to include |
|---|---|---|
| Student or new grad | Near the top, after contact | Degree, institution, graduation date, relevant coursework, GPA if strong |
| 0–2 years experience | After experience and projects | Degree, institution, year |
| 3+ years | Near the bottom | Degree, institution, year — one or two lines |
| 10+ years | Bottom, one line | Degree, 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 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.