Master Resume: How to Build and Keep One (Developer Guide)

A master resume is the complete, private record of your career: every role, every project, every metric, every tool, in one file no employer sees. You tailor from it; you never send it. Developers need one more than most, because a software career throws off more detail than any two-page resume (CV) can hold, and the detail you cut today is the detail next month’s posting asks for.

This guide covers what a master resume is, why you should keep one, how to build it section by section, how to keep it current, and how tailored versions come out of it. For the tailoring step itself, read how to tailor your resume to a job description; this post stops where that one begins.

What a master resume is

Think of it as a database, with a resume as a query result. The master holds the full table: four, six or ten pages of roles, bullets, projects, talks, certifications and skills, with dates and numbers for each. A tailored resume is a one- or two-page view of that table, filtered for one posting.

Three properties follow from that.

Private. Nobody reads the master but you. That changes what belongs in it. The bullet about the migration that failed and what you learned belongs in the master, because an interviewer may ask, even though it will never make a tailored version.

Complete. The master errs on the side of too much. Six to ten bullets per role, where a tailored resume keeps three. Side projects that went nowhere. The internal tool that only your old team knows about.

Stable. You add to it and you never cut from it. A tailored resume is disposable; the master is the thing you maintain.

It differs from the academic CV, which is also long and complete but goes to employers in that form. A master resume is a working document, and formatting can wait.

Why developers should keep a master resume

Your memory degrades faster than your career changes. Two years after a project, you remember that you “worked on the billing service”. You do not remember that you cut the p99 from 800 ms to 120 ms, that it ran on Go with a Postgres backend, or that you wrote the runbook. The numbers go first. A master resume captures them while you still have the dashboard open.

Career tracks diverge. A backend engineer who has also done data work has two plausible next jobs. The bullets that sell a platform role (on-call, Kubernetes, cost cuts) are not the bullets that sell a data role (pipelines, warehouse modelling, dbt). One master holds both sets; a tailored version picks one.

Every project counts somewhere. The open-source contribution, the hackathon, the Terraform module you wrote for your own homelab: none of these fit a resume aimed at a frontend role, and any of them might be the thing a different posting asks for. If they are not written down, you will not think of them when they matter.

Every metric needs a source. A number on a resume has to survive an interview question. The master is where you record, beside “cut build time by 60%”, what you measured, from what to what, and how. When a tailored version carries the number, you can defend it.

Tailoring becomes selection. With a master, tailoring takes minutes: pick the bullets that match, reword them in the posting’s terms, cut the rest. Without one, tailoring means reconstructing your past from memory each time, and that is where resumes drift from the truth.

Consistency across surfaces. Your LinkedIn profile, your tailored resumes and your interview answers should agree on dates, titles and numbers. One source of truth makes that automatic.

How to build a master resume, section by section

Open a plain Markdown file. Formatting, templates and page limits are for the tailored version. The master wants structure and completeness.

Header

Name, email, phone, city, and links: GitHub, LinkedIn, a personal site if you have one. Record the exact form you want these to appear in so tailored versions do not differ (one with “+91”, one without).

Summaries, one per career track

Write a three-line summary for each kind of role you might apply to. A backend summary, a platform summary, a data summary. Each names the two or three strengths that track cares about. When you tailor, you start from the closest one and adjust.

Experience

For each role: employer, title, location, dates with months, and the stack you used there. Then bullets, six to ten per role, each one an action with a result. Record more than you would ever show:

• What you built, with the tool named.
• What changed because of it, with a number where you have one.
• The scale: users, requests per second, data volume, team size.
• Anything you owned: on-call, a service, a migration, hiring.
• Collaboration that a posting might ask about: cross-team work, mentoring, working with product.

Under each bullet that carries a number, add a short note on where the number came from. “Grafana dashboard, March 2025, p99 before and after the cache.” You will never show the note; you will be glad of it in the interview.

Projects

Side projects, open-source work, hackathon entries, internal tools. For each: name, link, dates, your role, the stack, and two or three bullets on what you did and what came of it. Stars, downloads or users if you have them. A project with no outcome still goes in, with a line on what you learned.

Skills, grouped and dated

Group them: languages, frameworks, infrastructure, data, practices. Beside each, note the year you last used it in anger. A skills list in a tailored resume should hold only what you could be interviewed on today; the “last used” column tells you which ones those are.

Education and certifications

Degrees with institution, dates and anything relevant (thesis topic, a course that maps to your work). Certifications with the issuing body and expiry.

Talks, writing, community

Conference talks, meetup talks, blog posts that got traction, podcasts, mentoring programmes. Most tailored resumes drop these; some postings reward them.

A changelog

At the bottom, a dated list of what you added and when. It makes the next update easier, and it shows you at a glance when you last touched the file.

Master resume template (fictional example)

The skeleton below shows the shape. The person, companies and numbers are invented.

Example (fictional): Arjun Mehta, backend engineer, Bengaluru

# Arjun Mehta
Bengaluru, IN · arjun.mehta@example.com · +91 98xxx xxxxx
github.com/arjunm-example · linkedin.com/in/arjunm-example

## Summaries
### Backend / platform
Backend engineer with 6 years on payment and ledger systems in Go and
Python. Owned services at 4k rps; cut infra cost 30% at Finlo.
### Data engineering
Engineer with 3 years building batch and streaming pipelines (Airflow,
Kafka, BigQuery) on top of 6 years of backend work.

## Experience

### Finlo Payments · Senior Software Engineer
Bengaluru · Apr 2023 to present · Go, PostgreSQL, Kafka, Kubernetes, GCP
- Owned the ledger service (4k rps peak, 11 downstream consumers).
- Cut p99 write latency from 410 ms to 95 ms by batching ledger
  inserts and adding a write-ahead queue.
  > Source: Grafana ledger-latency dashboard, Jun 2024, 7-day window.
- Reduced GCP spend for the payments namespace by 30% (USD 18k/month
  to 12.6k) by right-sizing node pools and moving batch jobs to spot.
  > Source: GCP billing export, Q3 2024 vs Q1 2024.
- Led the migration of 6 services from Cloud Run to GKE over 4 months.
- On-call rotation for payments (1 week in 5); wrote the incident
  runbook used by 12 engineers.
- Mentored 2 junior engineers; both shipped their first production
  service within a quarter.
- Replaced a hand-rolled retry layer with a Kafka dead-letter pattern;
  duplicate payouts dropped to zero over the following 6 months.
- (Not for most resumes) Ran a Rust rewrite spike for the ledger that
  we did not ship; wrote the decision doc.

### Brightcart · Software Engineer
Pune · Jul 2019 to Mar 2023 · Python, Django, MySQL, Redis, AWS
- Built the order-tracking API (Django REST) serving 200k daily orders.
- Moved product search from MySQL LIKE queries to Elasticsearch;
  median search time fell from 1.2 s to 90 ms.
  > Source: Datadog APM, Nov 2021.
- Built the first Airflow pipelines for the data team (12 DAGs,
  nightly loads into Redshift).
- Wrote the Terraform for the staging environment (previously
  hand-configured).
- Interviewed 40+ candidates for backend roles over 2 years.

## Projects
### kafka-replay (open source) · 2024 to present
CLI to replay Kafka topics into a local cluster for debugging. Go.
310 GitHub stars, used by 3 teams at Finlo.
### homelab-terraform · 2022
Terraform modules for a Proxmox homelab. Unfinished; learned the
Proxmox API and Terraform providers.

## Skills (last used)
- Languages: Go (2025), Python (2025), SQL (2025), Rust (2024, spike),
  TypeScript (2022)
- Infrastructure: Kubernetes (2025), Terraform (2025), GCP (2025),
  AWS (2023), Docker (2025)
- Data: Kafka (2025), PostgreSQL (2025), Airflow (2023), Redshift
  (2023), Elasticsearch (2022), BigQuery (2024)
- Practices: on-call, incident runbooks, design docs, mentoring

## Education
B.E. Computer Engineering, Pune University, 2015 to 2019

## Talks and writing
- "Ledger write paths at 4k rps", Bengaluru Go meetup, Sep 2024
- Blog: "Dead-letter queues without the drama", 2024 (12k views)

## Changelog
- 2025-09: added kafka-replay star count, Q3 cost numbers
- 2025-03: added mentoring bullet, Rust spike note
- 2024-11: file created from 2023 resume + Brightcart notes

Note what the file has that no tailored resume would: source lines under numbers, a “not for most resumes” bullet, an unfinished project, a last-used year on every skill, and two summaries. Those are the master’s job.

How to keep it updated

A master resume dies when updates become a chore, so make them small and tie them to events you already notice.

Update when you ship. When a project lands or a metric moves, add the bullet that week. The numbers are on the dashboard now; in a year they will not be.

Keep it in version control. A Markdown file in a private Git repository gives you history for free. You can see what you added when, and diff the master against any tailored version you built from it.

Review quarterly. Fifteen minutes, four times a year: read the current role’s bullets, add what happened, update the last-used years. Put it in the calendar.

Record the source with the number. The habit of writing “Source: …” under each metric takes ten seconds and saves you from the interview question you cannot answer.

Keep a brag document alongside it. Julia Evans’s brag document idea, a running list of what you did at work, feeds the master. The brag document is raw; the master is curated.

If your master has thin entries, a role with two bullets and no numbers, Resume Matcher has an enrichment step for that: it spots weak entries, asks you up to six questions about them, and writes two to four new bullets from your answers, without adding details you did not give.

Career tracks: when one master is not enough

Most developers manage with one master and several summaries. Some do not. If your backend history and your data history have different skills lists, different project selections and different summaries, two masters are cleaner than one file with a tangle of annotations.

Resume Matcher is built around this. You can keep up to five master resumes, one per career track, with one marked as the default. The tailor page preselects the default; you switch when a posting calls for a different track. Each master is a full resume in its own right, built from an uploaded PDF or Word file or from the Resume Wizard’s questions, and each one can carry custom sections if you need a block the standard layout lacks.

How tailored versions come from the master

Tailoring is selection plus wording. For a posting, you pull the bullets that match its requirements, reword them in its terms, pick the summary for that track, trim the skills list to what the posting cares about and what you used in the last few years, and cut the rest to fit one or two pages. The master does not change. The tailoring guide walks through each of those steps with a worked example.

In Resume Matcher, each tailored resume is a separate document that points back to the master it came from. The model proposes targeted edits to your summary, bullets and skills; code checks each one, locks your name, employers, titles, dates and degrees, and reverts any number that was not in the master. You review a before-and-after diff and confirm or regenerate. The master stays as you wrote it, so the next posting starts from the same complete source. Saved tailored versions remain editable and export as PDF from any of seven templates.

Keep the master. Everything else is a view of it.

If this helped

If the skeleton saved you a rebuild from memory, a star on Resume Matcher on GitHub helps other job seekers find it. You can follow me, Saurabh Rai, on GitHub, X and LinkedIn.