A technical resume proves you can build, run or analyze things with specific tools. Put a skills section grouped by category near the top, describe every role and project with the technology you used and the result it produced, and link work a reviewer can open: a GitHub profile, a portfolio or a live product. List only skills you could answer interview questions about.
Key takeaways
- Group skills by category (languages, frameworks, data, cloud, tools) and put the ones the posting asks for first on each line.
- Every skill you list should reappear in a bullet or project that shows what you did with it.
- Write bullets as what you built, with what, at what scale, and what changed: speed, cost, reliability, time saved or users served.
- Relevant projects count as evidence. Give each one a title, the stack, a date, a link and one or two outcome bullets.
- Link GitHub or a portfolio only after you have cleaned up what a visitor sees first.
- Skip skill bars, self-ratings and tools you touched once.
01
What makes a resume technical?
A technical resume is an ordinary resume with three additions: a skills section that names tools precisely, bullets that say which technology did the work, and links to things you have built. It is the usual format for software, data, IT, security, QA, DevOps, hardware and lab roles.
It has two readers: a recruiter checking that the posting’s tools appear on the page, and an engineer or hiring manager reading for depth. That is why the stack belongs in the skills section and again inside the bullets.
Section order depends on where your strongest evidence is.
| Your situation | Section order that usually works |
|---|---|
| Student or new graduate | Header, education, skills, projects, experience |
| Two or more years in technical roles | Header, skills, experience, selected projects, education |
| Career changer or bootcamp graduate | Header, summary, skills, projects, experience, education |
For the basics of each section, start with how to write a resume.
02
How to organize the skills section by category
One long comma-separated list makes a reader hunt. Four to six labeled lines let them find the tool they care about at a glance. Choose categories that fit your field, and order each line by how well you know the tool and how much the posting cares about it.
SKILLS Languages: Go, Python, TypeScript, SQL Frameworks: gRPC, FastAPI, React Data: PostgreSQL, Redis, Kafka Cloud and infrastructure: AWS (ECS, S3, RDS), Docker, Terraform Practices: CI/CD with GitHub Actions, code review, on-call rotation
SKILLS Analysis: SQL (window functions, CTEs), Python (pandas, NumPy), Excel Visualization: Tableau, Looker Studio, matplotlib Statistics: A/B testing, regression, cohort analysis Data tools: BigQuery, dbt, Airflow
SKILLS Systems: Windows 11, macOS, Ubuntu Server Identity and devices: Microsoft Entra ID, Intune, Jamf Networking: TCP/IP, DNS, DHCP, VPN, VLANs Scripting: PowerShell, Bash
Three rules keep it honest:
- Use the posting’s exact names. If the posting says “PostgreSQL,” write that, not “relational databases.” The guide to resume keywords covers how to find the terms that matter.
- Leave soft skills out of this section. “Communication” and “leadership” mean little as list items. UC Berkeley’s School of Information tells its students not to list people skills there because they are “a bit meaningless without more context.” Show them in bullets instead.
- Separate what you know from what you have tried. To mention a tool you have used lightly, add a last line labeled “Familiar with.” Do not mix it in with your strongest skills.
For choosing which skills to list, see skills to put on a resume.
03
How to write bullets that show measurable impact
A technical bullet answers four questions in one line: what you built or changed, with what, at what scale, and what happened as a result.
[Action verb] + [what you built or changed] + [tools used] + [scale] + [result]
The figures in these examples are invented to show the shape. Yours must be real.
| Instead of | Write |
|---|---|
| Responsible for backend services | Rebuilt the order-status API in Go with Redis caching, cutting median response time from 900 ms to 140 ms across about 2 million requests a day |
| Worked on data pipelines | Moved 14 nightly SQL jobs to dbt and Airflow, which ended manual reruns and had reports ready by 6 a.m. instead of noon |
| Did testing for the mobile app | Wrote 220 Playwright end-to-end tests for checkout and login, catching 31 regressions before release over two quarters |
| Helped users with IT issues | Resolved about 45 tickets a week for a 300-person office and wrote 12 self-service guides that cut password-reset tickets by a third |
MIT’s career office puts the principle plainly: experience descriptions should not read like job descriptions, and you should quantify where you can.
If you have no business metric, measure the engineering: response time, build or deploy time, test coverage, error rate, uptime, data volume, tickets closed, hours of manual work removed, or the number of users and teams served. An honest estimate marked “about” is fine. A number you cannot explain in an interview is not. More patterns are in the guide to resume bullet points.
04
How to list projects on a technical resume
Projects belong on the page when they show a skill your jobs do not, which makes them most useful for students, career changers and anyone moving to a new stack. Class projects, competitions, personal builds and open-source contributions all qualify. Give each one a title, the tools, a date and a link, then one or two bullets on what it does and what you solved.
Transit Delay Tracker | Python, FastAPI, PostgreSQL, Docker | 2026 github.com/[username]/transit-delay-tracker - Built an API and dashboard that collects live arrival data for 40 bus routes every 30 seconds and shows delay patterns by hour - Cut database storage by 60% by batching writes and partitioning tables by day
Warehouse Picking Optimizer | Java, Spring Boot, React | Capstone, team of 4 | Spring 2026 - Wrote the route-planning service, which shortened simulated picker walking distance by 18% against the baseline - Set up the test suite and CI pipeline the team used for all 140 merges
Contributor, [project name] | Rust | 2025 - 2026 - Fixed a memory leak in the connection pool and added a regression test (merged, pull request #[number])
On team projects, write what you did, not what the team did. Put projects above experience if they are your best evidence and below it if your jobs already make the case.
05
Which links to include: GitHub and a portfolio
Put links in the header, written out as plain text so they survive printing and resume parsing.
Priya Raman Austin, TX | 512-555-0142 | priya.raman@email.com github.com/priyaraman | priyaraman.dev | linkedin.com/in/priyaraman
Before you add a GitHub link, set up what a visitor sees first:
- Pin your best work. GitHub lets you pin up to six repositories and gists to your profile. Choose the ones closest to the jobs you want.
- Give each pinned repository a README. GitHub’s documentation says a README typically covers what the project does, why it is useful and how to get started.
- Consider a profile README. GitHub shows one on your profile when you create a public repository named after your username with a
README.mdfile in it. Two or three lines about what you build are enough. - Open the link in a private browser window. Confirm that nothing you meant to show is private and nothing you meant to hide is public.
A portfolio does the same job where the output is visual; see the guide to building a portfolio website. If your GitHub profile is empty or holds only copies of tutorials, leave the link off.
06
How to format and tailor a technical resume
Keep it to one page early in your career and two when you have the experience to fill them. Use a single column, standard section headings and a text-based PDF, as described in the guide to an ATS-friendly resume. Spell out an acronym the first time unless the posting uses the acronym itself, and replace internal project names with a description of what the thing did.
Then tailor. For each posting, reorder the skills lines so the required tools come first, swap in the project that fits best and adjust two or three bullets. Do not add a skill because the posting wants it. Everything on the page is fair game in an interview.
FAQ
Frequently asked questions
How long should a technical resume be?
One page if you are a student or early in your career, two if you have enough relevant experience to fill them. MIT’s career office advises sticking to one page unless you have extensive experience or an advanced degree. Cut older and unrelated work before you shrink the font.
Should I put GitHub on my resume?
Yes, if the profile shows work related to the job and the pinned repositories have clear READMEs. A reviewer who clicks will judge what they find. An empty profile, or one that holds only forked tutorials, is better left off.
Where does the skills section go on a technical resume?
Near the top, directly under the header or a short summary, so the tools a recruiter is checking for are visible at once. Students usually place it after education. Wherever it sits, repeat the important tools inside your experience and project bullets.
Should I rate my skills as beginner, intermediate or advanced?
No. Ratings have no shared meaning, and bars or stars are graphics that carry no searchable text. Order each line from strongest to weakest instead, and move anything you have only tried to a “Familiar with” line.
Can projects replace work experience on a technical resume?
They can stand in for it when you have little or none. A project with real users, a measurable result and a public link shows the same things a job bullet does. Label them as projects, not jobs, and say what your part was on any team effort.
Sources
- UC Berkeley School of Information: Resume Basics: grouping technical skills, what a project entry includes, one-column PDF layout, and keeping people skills off the skills list.
- MIT Career Advising & Professional Development: Resumes: accomplishments over job descriptions, quantifying, class and personal projects, and one-page length.
- GitHub Docs: Pinning items to your profile: pinning up to six repositories and gists.
- GitHub Docs: About the repository README file: what a README typically includes.
- GitHub Docs: Managing your profile README: the conditions for a profile README to appear.
Published by Jobbie and last updated on October 6, 2026. This guide is general information for job seekers, not legal, tax or financial advice. Spotted something wrong? Tell us.