The First Engineering Resume
A first engineering resume has a real problem underneath it: you are asked to demonstrate engineering ability using material that was mostly produced under instruction. Coursework had a specification. The bootcamp capstone had a template. The tutorial had a finish line.
The material is still usable. What changes it from filler into evidence is describing the parts where you made a decision — because a decision is the only thing on a page like this that a reviewing engineer can evaluate.
Order the page around where the evidence is
Default order for someone with no professional engineering experience:
Contact → Projects → Education (with relevant coursework) → Experience (any work at all) → Skills
Projects go first because they are your strongest material and everybody involved knows it. Nobody is confused or offended by this; the convention exists precisely for your situation. The general ordering argument is in what belongs on an engineering resume, and this is its early-career case.
One page. Not because of a rule about page counts, but because a page is genuinely enough for this material and a second page will be padding, which reads worse than brevity.
Projects: two done properly beats six listed
The characteristic first-resume mistake is a list of every project ever attempted, each described in one line naming its framework. That produces a page where nothing is examined and nothing is memorable.
Two projects, four lines each, is better. For each one, get these in:
What it does, and for whom. A sentence a non-specialist could follow.
One decision you made and why. This is the whole game. Not “used PostgreSQL” — why PostgreSQL rather than the alternative you considered, or how you modelled the thing that was awkward to model.
One thing that was harder than expected, and how you dealt with it. The most valuable sentence available to you. It is also the one nobody else writes.
The state it’s in. Working and deployed, working locally, or unfinished with a named next step. Honesty here is free and its absence is noticed.
Weak: Recipe App — Full-stack recipe application. Technologies: React, Node.js, Express, MongoDB, Tailwind CSS.
Better: Recipe App — Stores recipes and generates a shopping list from a week’s selections. The interesting part was ingredient matching: “2 large onions” and “one onion, diced” have to combine, so I ended up parsing quantity and unit separately and normalising units before summing, with a manual override for the cases the parser gets wrong. Deployed and used by three people, one of whom is not me.
The second one contains a real problem with a real solution and an honest limitation. It’s a small project and it reads like engineering.
Coursework, and what’s worth naming
Most coursework is invisible to a reviewer, but some of it is genuinely informative about what you can do.
Worth naming: operating systems, compilers, distributed systems, databases, networks, computer architecture, and anything with a substantial implementation component. These predict specific capability. So does a project you built inside one — a toy filesystem, a small interpreter, a database that does one transaction correctly.
Not worth naming: introductory programming sequences, mathematics unless the role is quantitative, and any list of course titles longer than one line. “Relevant coursework” as a five-line block is space that a project description would have used better.
A thesis or capstone with a real technical component is worth two lines, described the same way as a project — problem, decision, difficulty.
Bootcamp graduates: two specific notes
Name it as what it is. List the bootcamp by name as a bootcamp. Attempts to make it look like a degree fail, they fail in a way that makes the reader suspicious of everything else, and they’re unnecessary. Plenty of good engineers came through one.
Change the capstone, or accept that it reads as coursework. A cohort’s projects are frequently recognisable to anyone who has reviewed a few of them, and a reviewer who identifies the template stops reading it as your work. The cheapest fix is to keep building it after the course ends: add a feature nobody assigned, handle a case the template ignores, deploy it and fix what breaks in production. Now the interesting half of the description is yours.
Non-engineering work experience is not a liability
If you have worked — retail, hospitality, support, warehouse, teaching, the army — put it on the page as one line per role. It accounts for your time, it shows you have held a job, and none of it hurts you.
What doesn’t work is straining to make it sound technical. “Leveraged data-driven insights to optimise customer throughput” about a coffee shop is worse than “Barista, Blue Door Coffee — two years, part-time while studying.” The plain version is credible and takes one line.
The exception is genuine overlap, which is worth a sentence: a support role where you wrote SQL to investigate customer issues, an operations job where you automated a spreadsheet process, a teaching job where you built the tooling. That’s real and it belongs.
Internships, and how to write a short one
An internship is professional experience and should be written like it, with the same discipline as any other role — see writing engineering bullets that say something.
The pressure with a short internship is to inflate it. Resist: an intern who describes one contained piece of work accurately reads much better than one claiming to have owned a system.
Illustration: Added pagination to an internal admin API that had been returning entire tables — including the cursor design, the index it needed, and the migration to add it. Reviewed and shipped to production.
Small, complete, obviously true, and it demonstrates that you worked inside an existing codebase to someone else’s standard, which is the thing an internship uniquely evidences.
The skills list, when the list is most of what you have
It goes near the top for a first resume, because it genuinely is part of the evidence. It still shouldn’t be forty items.
Group it, and be honest about level. The single most useful thing you can do is separate what you have built something substantial with from what you have only touched:
Comfortable Python, SQL, Git, PostgreSQL, Flask Used on projects React, TypeScript, Docker Learning Go, Kubernetes
That third line is not a weakness. It tells a reviewer exactly where the boundary is, which is what they were trying to work out, and it protects you from an interview that opens on the item you listed optimistically. The longer argument against a padded list is in the tech stack list problem.
What to cut
- Skill percentage bars and star ratings.
- “Passionate about technology” and every variant.
- Every tutorial-following project with nothing added.
- A GitHub link to an empty profile — see what a link to your code actually proves.
- Secondary-school results, once you have a degree or a bootcamp on the page.
- Hobbies, unless one of them is genuinely interesting to talk about.
The highest-return hour
If you have one hour to improve a first engineering resume, don’t spend it on the wording. Spend it on the README and deployment of your best project, then rewrite that project’s four lines to include the decision and the difficulty.
The reason is that a first resume is competing against many others with identical shapes and near-identical stacks. The distinguishing feature is never the technology list; it’s the one project described by someone who clearly understood what they were building.