Course Content
How to Write a Good Resume
15 sections · 30 lessons
Job descriptions and structured screening rubrics
This section is written for the other side of the table. Read it even if you are not hiring — understanding the rubric is the fastest way to write for it, and the section ends with Reading the rubric backwards, which makes that explicit.
Screening starts before any resume arrives. The job description decides who applies and what they write, and the rubric decides how what they wrote is scored. This lesson covers both, in the order a hiring manager should build them.
Writing a job description that yields good resumes
Vague requirements produce unusable pools
The most common job description defect is a wish-list: fifteen requirements, no ordering, no distinction between essential and desirable.
5+ years experience. Strong knowledge of Java, Python, Go, or Rust. Experience with AWS, GCP, or Azure. Familiarity with Kubernetes, Docker, Terraform. Understanding of microservices, event-driven architecture, and distributed systems. Excellent communication skills. Bachelor's degree in Computer Science or equivalent.
Two failure modes follow, and they pull in opposite directions:
- Strong candidates self-select out. Research on job applications has consistently found that some groups — women in particular — are markedly less likely to apply unless they meet nearly all listed criteria. A fifteen-item list filters out people who would have been excellent.
- Weak candidates apply anyway, because the list is so broad that almost anyone matches something.
You get a larger pool and a worse one.
What a usable job description contains
Three to five genuine requirements, ordered. Not everything you would like. What someone must have on day one.
A separate "nice to have" section, explicitly labelled, so candidates know which is which.
A description of the actual work. Not "you will work on exciting challenges" — what system, what team, what problems.
You will own our event ingestion pipeline: about 2 billion events a day from 40 customer integrations, currently on Kafka and ClickHouse. The main problem this year is schema evolution — we break downstream consumers roughly once a month and we need that to stop.
A candidate reading that can tell whether they are a fit, and their resume will be tailored against something real.
The level, stated. "Senior" means different things at different companies. State the expected scope: "you will own a service end to end and set technical direction within one team."
The compensation band. Increasingly required by law in several jurisdictions, and it prevents both sides wasting time.
A structured screening rubric
Once the resumes come in, the job description's requirements become the criteria you score against. Unstructured screening produces inconsistent outcomes and is difficult to defend. A rubric is cheap to build and fixes most of it.
Build the rubric before opening any resume
Order matters. Criteria defined after you have seen candidates get shaped by the candidates you happened to see first.
Define three to five criteria, each with an explicit evidence standard.
An example rubric
| Criterion | Evidence standard | 1 | 2 | 3 |
|---|---|---|---|---|
| Backend depth | Owned a production service | No production ownership | Contributed to a service | Owned one end to end incl. on-call |
| Distributed systems | Worked on a system with real distribution problems | Single-service work only | Consumed a queue or cache | Designed for partition, ordering, or consistency |
| Scale | Systems of comparable scale | Unstated | Moderate, stated | Comparable or larger, stated with numbers |
| Ownership | Decisions made, not tasks completed | Tasks only | Some technical choices | Set direction others followed |
Each score has a written descriptor, so two screeners mean the same thing by "2".
Scoring rules
Score independently, then discuss. If two people screen the same resume, they should score before comparing. Discussing first produces convergence on whoever spoke first rather than on the evidence.
Record the evidence, not the impression. "Score 3 — 'owned routing service, 12M requests/day, on-call rotation of 6'" is reviewable. "Score 3 — seems strong" is not.
Decide the bar in advance. What total advances? What is an automatic decline regardless of total? Decide before you start, not after you have seen a candidate you like.