How technical should a technical resume get?

It depends entirely on who reads it. For an engineering manager, name versions and protocols and assume the reader knows what they imply. For a recruiter, a protocol list is a filter that quietly removes you. The version that survives both readers is a plain-language summary over a precise skills section, so the same page serves a first screen and a first conversation.

Can I put unpaid projects on a technical resume?

Yes, and they often carry more weight than another job title, because they are inspectable. Describe the problem, what you built, and one fact somebody else could check, with a link to the repository if there is one. Do not present a weekend project in the language of a shipped system.

Should I include a home lab?

Only if you can talk about it for ten minutes without overselling it. It is genuine evidence of hands-on time and it is also the easiest line on the page to be challenged on, so state it as what it is: where you learned the routing and VLAN work listed above. One honest line, not a photograph and not an inventory.

Fictional person, employer, and product, written as a worked example. Do not reuse the numbers.

Resume example

Technical

Tobias Wren, six years in industrial monitoring support, applying to a pre-sales solutions role. Technical resumes are usually read twice: once by a recruiter who knows the job title, and once by an engineer who knows whether you are telling the truth. This one is built to survive both passes.

6 years, hands-on Support to pre-sales Mixed reader Target: solutions engineer, industrial software

Tobias Wren

Solutions Engineer

Portland, OR tobias.wren@example.com +1 503 555 0176 tobiaswren.example

Summary

Solutions engineer with six years in industrial monitoring, moving from the support desk to the pre-sales side. I take a customer's failed install and turn it into a configuration, a timeline, and a number they can sign off. Equally comfortable on a site with a ladder and in a room with an executive, and I write the documentation neither of them wants to write.

Experience

Ardent Systems

Feb 2022 – Present

Portland, OR

Technical Support Engineer II

Own second- and third-line support for 400 industrial customers running the Ardent gateway fleet, on a coverage rota I rewrote to a median first response under four hours.
Turned the twelve most common repeat faults into a diagnostics script, taking the top cause from 60 tickets a quarter to 11.
Built and now run the vendor's certified training course; 40 customer engineers have completed it.
Wrote the deployment guide for the current gateway revision, and the migration notes three customers followed without opening a support ticket.
Join roughly nine pre-sales calls a quarter, translating a customer's process into a configuration and a quote.

Kestrel Networks

Aug 2019 – Jan 2022

Portland, OR

Network Support Technician

Second-line support for 22 school-district networks across 60 sites, including the escalation path for two firewall replacements.
Replaced a district monitoring spreadsheet of manual checks with scheduled synthetic checks, which surfaced the failing links those checks had been missing for a year.
Carried the summer firewall cutover with no after-hours pages, using a rollback plan written before the first change window.

Projects

fleet-uptime-cli

2023 – Present

Node · open source

Command-line tool that polls a fleet and prints one line per site, built to stop me running the same four commands by hand at the start of every shift. 140 stars on a public repository.
Handles the partially-offline gateway case the vendor's own tool does not, which is the reason people use it.

Home lab

2021 – Present

Self-directed, evenings and weekends

Six machines and a rack of second-hand switches, which I break on purpose. This is where the routing, VLAN, and TLS work in the skills section was actually learned.

Skills

Platforms Ardent Gateway, Linux (systemd, journald), Windows Server, Docker

Networking TCP/IP, VLANs, routing, DNS, TLS, MQTT, Modbus TCP, Wireshark

Languages and automation Python, Bash, Node, SQL, Ansible, Prometheus, Grafana

Practice Root-cause analysis, incident timelines, customer-facing troubleshooting, technical writing, pre-sales scoping

Certifications

Certified Systems Administrator

2023

Institute of Technical Operations · renewed 2025

Certified Network Associate

2020

Northwind Technical Institute

Education

Oregon State University

2015 – 2019

B.S. Computer Engineering

Why this works

Eight decisions, each visible in the document on the left.

The summary is a sentence your reader can repeat. "I take a customer's failed install and turn it into a configuration, a timeline, and a number they can sign off" is a line a hiring manager can say to their boss in the corridor. "Passionate systems engineer with a knack for complex problems" is not a sentence anyone can repeat.
Scale is stated, because a technical reader cannot infer it. 400 customers, 22 networks, 60 sites, 40 engineers trained. "Managed a large customer base" tells an engineer nothing they can use, and the number next to it tells them everything.
Products are named the way the vendor names them. Ardent Gateway, Modbus TCP, journald. Keyword filters and recruiter searches are literal, and "monitoring solutions" is not a product anyone searches for.
The bullets are about faults, not features. Sixty tickets a quarter down to eleven is a technical claim with a method behind it. "Improved system performance" is unfalsifiable, and anyone who has done the work reads it as noise.
It acknowledges that there are two readers. The rota line is uptime language for an engineer; the pre-sales line is scoping language for a commercial reader. Both earn their place, because the reader of your resume is not only the person who forwards it to you.
Projects stay in. Technical hiring managers read them, and they are the part of the page that proves the skills block is not aspirational. Each one names the constraint — four commands by hand, a case the vendor tool misses — rather than listing a stack.
Confidentiality is handled with altitude, not a disclaimer. "A vendor gateway fleet", "a district firewall replacement" say the scale without naming a customer. Nobody needs the customer name; everybody needs to know whether it was three sites or three hundred.
Credentials carry their renewal date. A certification that lapsed is a liability rather than an asset, so the year the reviewer sees is the year it is next due. Where a credential has no renewal, the issue date is the fact that matters.

Adapting it

Reorder for the reader, not for the chronology of the field. Support, infrastructure, and pre-sales weight the same three years very differently, and the summary is the only part of the page you should rewrite per application without touching anything else.
Moving from support into development means rewriting verbs, not adding experience. "Resolved" becomes "built", "documented" becomes "designed" — but only where that is true. A resume that claims to have shipped something you only supported is found out in the first technical screen.
Delete any tool you would be uncomfortable being asked to pair on. On a technical resume a tool listing is a claim of interview readiness, and the pairing session is where the claim gets tested. A shorter, honest list beats a longer one you have to defend.

If the same work has to survive a two-column layout as well as a parser, the writing guides set out when that is safe, and how ATS read resumes covers what the parsers actually do.

Questions this situation raises

How technical should a technical resume get? It depends entirely on who reads it. For an engineering manager, name versions and protocols and assume the reader knows what they imply. For a recruiter, a protocol list is a filter that quietly removes you. The version that survives both readers is a plain-language summary over a precise skills section, so the same page serves a first screen and a first conversation.
Can I put unpaid projects on a technical resume? Yes, and they often carry more weight than another job title, because they are inspectable. Describe the problem, what you built, and one fact somebody else could check, with a link to the repository if there is one. Do not present a weekend project in the language of a shipped system.
Should I include a home lab? Only if you can talk about it for ten minutes without overselling it. It is genuine evidence of hands-on time and it is also the easiest line on the page to be challenged on, so state it as what it is: where you learned the routing and VLAN work listed above. One honest line, not a photograph and not an inventory.

Start from this example

The builder opens with this resume already loaded. Nothing is uploaded and no account is involved — replace the contact details first, then work down the page.

Start from this example

Building the import link.

Facts about this example
Level	Mid-career technical, 6 years hands-on
Sections used	Summary, experience, projects, skills, certifications, education
Assumed reader	Two — an engineer and a recruiter in the same loop
Number style	Fault counts, customer counts, sites — not percentages
Design	Slate accent, 10.5pt, uppercase headings, 0.5in margins