Engineer Resume

Most resume advice was not written for people who ship software

You can tell within a paragraph. It talks about “leveraging synergies” and “results-driven professionals.” It suggests a skills bar chart. It has never had to explain, in one line, what you did during a six-month migration where the visible outcome was that nothing happened.

This site is about technical resumes specifically: software, data, platform, infrastructure. Written on the assumption that you know what a deployment is and that the person reading your resume probably does too.

What you’ll find here

• What actually belongs on the page. Which sections earn their space for an engineer, and which ones are habit.
• Bullets that say something. The difference between “worked on the payments service” and a line another engineer can evaluate — without inventing a percentage to do it.
• The stack list problem. Everyone has one. Most are too long, badly organised, and quietly overclaiming. Here’s how to fix all three.
• Side projects and open source. What they’re worth, when to include them, and what an empty GitHub profile does and doesn’t signal.
• Infrastructure and platform roles. How to describe work whose success condition is that nobody noticed anything.

Two things you won’t find. No invented metrics — if you can’t answer “how did you measure that?” from another engineer in an interview, the number shouldn’t be on the page, and a specific qualitative description beats a fabricated statistic anyway. And no absorbing your team’s work into the first person; write your actual scope, because reviewers ask.

Read the blog →

The person reading your resume is usually an engineer who has forty minutes and eleven candidates. Write for them.