Blog
-
Resumes for Security Engineers
Security work is confidential and its wins are absences. How to describe findings, fixes, and controls so a technical reviewer can judge them.
-
The Mobile Engineering Resume
Mobile engineers have a shipped app anyone can download and a codebase nobody can see. How to write bullets that use the first and survive the second.
-
Test and Quality Work That Reads as Engineering
Improved test coverage is one of the emptiest bullets available. What to write instead about suites, flakes, and the failures your tests caught.
-
The Questions a Technical Reviewer Is Trying to Answer
An engineer reading your resume is answering a short list of questions. Knowing which ones tells you where the page is failing them.
-
Name the Problem, Not Just the Tool
Bullets that list technologies read as a stack inventory in the wrong place. How much tool-naming a sentence can carry, and what to do with the rest.
-
Resumes for Infrastructure and Platform Roles
How to describe work whose success condition is that nothing happened — reliability, migrations, on-call, and platforms with internal users.
-
Side Projects, Open Source, and What Counts
When a projects section helps, when it competes with your real experience, and what an empty GitHub profile actually signals to a reviewer.
-
The Tech Stack List Problem
Every engineer's skills section is too long, badly grouped, and quietly overclaiming. A method for cutting it down to what you can defend.
-
What Belongs on an Engineering Resume
Which sections earn their space on a technical resume, which are habit, and how to order them so a reviewing engineer finds what they need fast.
-
Writing Engineering Bullets That Say Something
How to describe technical work so another engineer can evaluate it — without inventing the performance percentage everyone else is inventing.
-
Scope, Not Years: The Seniority Signal in a Resume
Seniority on a technical resume is read from the size of what you owned, not from time served. What scope consists of, and how to show it honestly.
-
The Staff-Level Resume Problem
Past senior, most of your impact runs through other people. How to put influence work on a resume without it reading as management.
-
When the Numbers Belong to Another Team
You built it, but product owns the dashboard and finance owns the cost. What to cite when the measurement of your work isn't yours to see.
-
What an Engineering Job Posting Tells You About the Team
A technical posting leaks information about the codebase, the on-call load, and the team's real problem. How to read it before you decide to apply.
-
When the Work Was Keeping a Legacy System Alive
Maintenance and upgrade work reads as an accident of where you worked unless you write it as engineering. How to make the constraints visible.
-
When Nobody Reviewed Your Code
If your whole career has been unsupervised engineering, reviewers worry about calibration, not ability. Three signals that answer the worry honestly.
-
Moving From a Big Company to a Startup, and Back
Company size changes what your bullets are evidence of. What a small team reads as a risk in a big-company resume, and the reverse.
-
The Bullet About an Incident
An outage you diagnosed is strong resume material. How to write one incident as evidence of reasoning without turning it into a hero story.
-
A Selected-Work Block for the System You Know Best
One system described in five lines, with its constraints and trade-offs, does more for a senior application than fifteen scattered bullets.
-
Design Documents, RFCs, and What They Show
Written artefacts are the physical output of senior engineering work. How to cite a design doc or postmortem on a resume without attaching one.
-
What a Link to Your Code Actually Proves
A repository link is an invitation to be judged on evidence. What a reviewer can verify from it, what they can't, and when not to include it.
-
The First Engineering Resume
With no professional experience, your evidence is projects and coursework. How to write them so an engineer reads them as engineering.
-
Unfalsifiable Claims on an Engineering Resume
Scalable, robust, clean, best practices. A claim a reader cannot imagine being false carries no information. How to convert each one into a fact.
-
The Context Line Above Your Bullets
One line per role naming the company, the team, and the stack lets every bullet underneath it be about work instead of environment.
-
Resumes for Data Engineers
Data work is judged on correctness and freshness, not features. How to describe pipelines, backfills, and data quality so an engineer can evaluate them.
-
Resumes for Machine Learning Engineers
A model metric with no system around it is the weakest line on an ML resume. What to write about training, serving, and the loop between them.
-
The Frontend Engineering Resume
Frontend work is the most visible engineering there is and the easiest to under-describe. What to write instead of a list of frameworks.
-
A Specialism the Reader Wasn't Looking For
Embedded, compilers, geospatial, protocols, simulation. How to write a niche technical specialism so a generalist reviewer can evaluate it.
-
The Project That Got Cancelled
Work that never shipped is still engineering. How to put a cancelled project, an abandoned rewrite, or a deprecated system on a resume.
-
A Personal Site That Earns the Link
Most engineers' personal sites restate the resume. The version that helps publishes the reasoning behind work nobody else can see.