Resumes by level: new graduate to staff engineer

The rules in Sections 4 to 7 apply to everyone, but the problem a resume has to solve changes as a career goes on. A new graduate has too little material. A senior engineer has plenty, described at too small a scale. The fix at each stage is different, and sometimes it is the opposite of the fix at the stage before.

This lesson walks up the individual-contributor ladder: student and new graduate, bootcamp graduate and self-taught engineer, mid-level engineer, and senior or staff engineer. For each, it names what the reader is worried about, the structure that answers it, and the rewrite that makes the difference. Read your own stage closely and skim the others; the stage above yours tells you what to start collecting now.

Student and new graduate

You have the least material and the most competition. Both problems have the same fix: depth over breadth.

The core problem

A recruiter comparing forty new-grad resumes sees the same page forty times — same degree, similar coursework, the same three or four course projects. Nothing distinguishes them.

The instinct is to add more: more technologies, more projects, more societies. This makes it worse, because it makes your page more like everyone else's, not less.

The structure

ContactEducation          ← degree, institution, graduation date, relevant coursework, GPA if strongProjects           ← the section that does the workExperience         ← internships, part-time technical work, teaching assistantshipsSkills

Make one project carry the page

One substantial project described in depth beats four described shallowly.

Shallow:

Chat Application — Real-time chat app built with React, Node.js, and Socket.io. Supports multiple rooms and user authentication.

Deep:

Chat Application — Real-time chat supporting 200+ concurrent connections in load testing. Messages initially arrived out of order under load; traced it to independent socket writes racing, and fixed it with per-room sequence numbers and client-side reordering. React, Node, Socket.io, Redis. github.com/…

Same project. The second shows a problem encountered, diagnosed, and solved — which is exactly what the job is.

Internships and non-software work

Internships go in Experience and get the full treatment from Section 5 (Resume Structure) — context line, impact-first bullets. Three months is enough to have changed something.

Non-technical work — retail, hospitality, tutoring — is worth one compressed line if it shows sustained responsibility. Do not give it bullets. It is context, not evidence.

Teaching assistant and lab demonstrator roles are worth more than people think: they show communication and technical depth together.

What to drop

School results (once you have a degree), unrelated societies, "references available on request", and any project that is a followed tutorial.

Bootcamp graduate and self-taught

A bootcamp graduate or self-taught engineer has a different problem from a new graduate. Your challenge is credibility, and you address it with evidence rather than explanation.

What the reader is worried about

Be clear-eyed about it: the reader's unstated concern is whether your knowledge is shallow — whether you can build inside a framework's happy path but not debug outside it.

Your resume's job is to answer that concern with evidence. Not to argue about it.

Do not apologise, do not over-explain

Career-changing bootcamp graduate eager to break into tech and prove myself in my first developer role.

This foregrounds the doubt and offers nothing against it. Replace it with facts:

Backend developer. Built and operate Ledgerline, a double-entry bookkeeping API with 40 active users, running on AWS since Feb 2026. Previously six years in accounting operations.

That prior career is an asset here, not something to hide — an accountant building a bookkeeping API knows the domain better than most engineers ever will.

Where the credibility comes from

In rough order of how much they help:

1. A deployed thing with real users. Even ten users. It means you have handled deploys, errors, and someone else's expectations.
2. A hard technical problem you can describe. One deep debugging story is worth more than five projects.
3. Open-source contributions to a real project. Verifiable, and it shows you can read unfamiliar code.
4. Freelance or contract work. Real clients, real constraints.
5. The bootcamp itself. Genuine, and the weakest signal because everyone in your cohort has it.

The structure

ContactSummary            ← 2–3 lines: what you build now, and the prior career as domain contextProjects           ← 2 substantial, deployed if possibleExperience         ← prior career, compressed, keeping anything transferableEducation / TrainingSkills

Use the previous career

Do not bury it. Six years in logistics makes you a strong candidate for a logistics technology company. Compress it to two or three lines and keep whatever is genuinely transferable — stakeholder management, domain knowledge, working to deadlines.

Mid-level individual contributor

Two to six years in. The most competitive band, and the one where the generic-resume problem is worst.

Why this band is hardest

At this level almost everyone has the same shape: a couple of roles, real production experience, a familiar stack. Your competition is not weak, and the differences are not in the facts — they are in how the facts are written.

The differentiator is ownership. Everyone at this level shipped features. Fewer can show they owned outcomes.

The upgrade

Notice what is happening: each right-hand entry names something you decided, not something you executed.

The structure

ContactExperience         ← the whole document, essentiallySkillsEducation          ← one or two lines

No summary unless one of the four cases in Summary or objective applies. No projects section unless your side project genuinely outshines your job.

Depth allocation

Weight strongly toward the present:

• Current role: 4–6 bullets, plus a context line
• Previous role: 2–3 bullets
• The one before: 1–2 bullets, or a single line
• Anything older: title, company, dates only

A common mid-level mistake is equal treatment across three roles. Your first job matters far less than what you did last year.

The transferability problem

If you have spent four years on one internal system, you may struggle to show relevance elsewhere. The fix is to describe the shape of the problem rather than the product.

Built features for the Meridian internal reporting platform.

Built the query layer for an internal analytics platform serving 40+ teams: cut p95 dashboard load from 9 s to 1.4 s by pre-aggregating the twelve most-used metrics.

The second is legible to someone who has never heard of Meridian.

Senior and staff engineer

At the top of the IC ladder, the failure mode is the opposite of the junior one: not too little material, but material described at too small a scale.

The under-selling problem

Senior engineers often write resumes that read as mid-level, because they describe the code they wrote rather than the decisions they made and the reach those decisions had.

Built the new notification service using Go and Kafka.

An engineer of any level could have written that bullet. Now:

Designed and led the notification platform now used by 6 product teams for all customer messaging; replaced 3 divergent in-house implementations. Set the delivery guarantees and the on-call model, and ran the migration over two quarters.

The technical work is the same. The second describes reach and direction.

What senior and staff resumes must show

1. Cross-team impact. Work whose effect extended past your own team.
2. Technical direction. Choices that shaped what others built afterwards.
3. Influence without authority. Getting people to agree, not just getting code merged.
4. Business connection. Why the architecture decision mattered commercially.
5. Multiplication. Mentoring, standards, tooling, or review culture that made others more effective.

Language that carries level

Use the second column only where it is true. Inflated verbs on modest work are transparent and read worse than accurate ones.

Length and structure

Two pages are appropriate past about ten years. The second page is for earlier roles, not for more detail on recent ones.

ContactExperience         ← recent roles in depth, older roles compressedSkills             ← selective; you no longer need to list everythingEducation          ← one line

Optional additions if genuinely substantial: patents, talks, open-source maintainership.

Skills sections at senior level

Get shorter, not longer. A staff engineer listing thirty technologies looks less senior than one listing twelve, because seniority implies judgement about what matters.