Why engineers keep their CV in a repo
A résumé is a document you rewrite for every application and then lose track of. Kept as Markdown in a repo, it behaves like the rest of your work: you can diff what changed between the version that got a callback and the one that did not, branch a variant for a backend role and another for platform, and never again wonder which file is current. Export to PDF when you apply.
What engineering hiring managers read first
Most engineering résumés are screened in under a minute, and the reader is usually looking for three things in this order: scope, evidence, and depth.
Scope means the size of the thing you owned. “Built the notification service” says more than “worked on backend features,” and “owned it from design through on-call” says more again.
Evidence means numbers attached to systems, not adjectives. Requests per second, data volume, latency before and after, users affected, build times cut. An engineer who writes “reduced p99 latency from 840ms to 120ms by replacing the N+1 query pattern in the checkout path” has communicated more competence in one line than a paragraph of “passionate about performance.”
Depth means one or two technologies you clearly know well, rather than twenty you have touched. Interviewers pick a topic from your résumé and dig; a list you cannot defend is worse than a short one you can.
Stack terms engineering screens match on
Engineering roles are usually filtered on concrete stack terms, so write the ones that are actually true of your work, spelled the way the job posting spells them:
- Languages: the two or three you would take an interview in, not every language you have compiled
- Frameworks and runtimes: React, Node.js, Django, Spring, Rails, .NET — whatever you genuinely ship in
- Data: PostgreSQL, MySQL, Redis, Kafka, Elasticsearch, and the modelling work you did with them
- Infrastructure: AWS, GCP or Azure, Docker, Kubernetes, Terraform, CI/CD
- Practice: code review, testing, system design, on-call, incident response, mentoring
Write “CI/CD” if the posting does, and spell out an acronym once if it is ambiguous. Keyword-stuffing a skills block does not help; the same terms appearing inside real accomplishment bullets does.
What sinks otherwise strong engineering résumés
The exhaustive technology list. A skills section with forty entries reads as either padding or inexperience. It also guarantees an interviewer picks the one you know least.
“Responsible for.” It describes a job description, not a person. You were responsible for the service; what did you do to it, and what changed as a result?
Team credit written as personal credit. Senior reviewers notice immediately when a résumé claims an outcome that obviously took a team. “Led the three-engineer effort that…” is stronger than an implied solo heroic, because it is believable.
No numbers anywhere. If nothing on the page is measured, the reader has no way to calibrate your level, and will assume the lower one.
Burying the interesting work. The most impressive thing you have built should not be the fourth bullet of the second role. Lead with it.
A note on side projects and open source
Personal projects earn their place when they show something the day job cannot — a language you want to be hired in, a system design decision you made alone, real users. A tutorial to-do app does not. If you contribute to open source, name the project and the nature of the contribution; a bare GitHub URL asks the reader to do research they will not do.
Frequently Asked Questions
Is this software engineer resume template free? +
Yes. Edit it in your browser and export to PDF, DOCX, or HTML with no account, no watermark, and no usage limit.
Is a Markdown resume ATS-friendly? +
When exported to PDF, the résumé uses standard headings, plain text, and no complex tables or columns — which is exactly what applicant tracking systems parse best. Keep section titles conventional (Experience, Skills, Education) for the best results.
Can I keep my resume in version control? +
That's one of the main reasons engineers draft résumés in Markdown. The source is plain text, so you can track it in Git, diff changes, and keep tailored versions on separate branches.