Tech stack on a resume: skills section, per job, or in the bullets?

Name the important technologies inside your experience bullets, and keep one short, grouped skills section for the full list. Add a separate "Tech:" line under each job only when your roles used clearly different stacks or were short contracts. Then a reader can see what you used, when you used it, and what you built with it.

This post shows the three patterns on the same job, explains when each one works, and ends with skills sections for frontend, backend, DevOps and iOS engineers.

The three ways to show your tech stack

Here is one backend role written three ways. The work and the stack are the same in each version. Only the place where the technologies appear changes.

Pattern 1: skills section only. The bullets describe the work, and every technology lives in a list elsewhere on the page.

Tallis Payments, London
Backend Engineer | Apr 2021 – Present
- Built the payouts service that sends settlement files to partner banks every night
- Moved fraud checks out of the checkout request path into an asynchronous worker

Skills: Go, PostgreSQL, Kafka, Redis, AWS (ECS, SQS), Terraform

Pattern 2: a trailing "Tech:" line per role. The bullets stay the same, and a single line lists what the role used.

Tallis Payments, London
Backend Engineer | Apr 2021 – Present
- Built the payouts service that sends settlement files to partner banks every night
- Moved fraud checks out of the checkout request path into an asynchronous worker
Tech: Go, PostgreSQL, Kafka, Redis, AWS (ECS, SQS), Terraform

Pattern 3: technologies named inside the bullets. Each technology appears next to the thing it was used for.

Tallis Payments, London
Backend Engineer | Apr 2021 – Present
- Built the payouts service in Go and PostgreSQL that sends settlement files to partner banks every night
- Moved fraud checks out of the checkout request path into an asynchronous Kafka consumer, with Redis caching the risk scores

Pattern 1 is the weakest on its own. The reader knows you have used Kafka, but not where, when or for what. Pattern 2 answers "where" and "when". Pattern 3 also answers "for what", and that is the question an interviewer will ask.

Which pattern should you use?

Use pattern 3 as the default. A technology inside a bullet is attached to a piece of work, so it is evidence. The same word in a list is only a claim. Keep a skills section as well, because some readers look for one specific tool and want to find it without reading every bullet.

Do not force every technology into a bullet. Name the tools that matter to the result, usually one or two per bullet. "Built the payouts service in Go" reads naturally. "Built the payouts service in Go with PostgreSQL, Redis, Docker, Terraform and GitHub Actions" turns the bullet into a list. The senior frontend engineer resume example does this well: its current role names React and TypeScript in the migration bullet and leaves the testing tools to the skills section.

Add a "Tech:" line under each role in two situations:

• You have many short roles or contracts. Contracts often last six to twelve months, and each one can use a different stack. A reader matching you to a role can scan one line per contract instead of searching the bullets.
• Your stack changed between jobs. If you moved from PHP to Go, a per-role line makes it obvious which experience is current.

A contractor's history with Tech lines looks like this:

Halden Digital (via Brookline Recruitment), Leeds
Contract Frontend Developer | Jan 2024 – Sep 2024
- Rebuilt the quote journey for a car insurance brand as a Next.js app with server-side rendering
Tech: Next.js, TypeScript, TanStack Query, Playwright

Orlen Bank, London
Contract Frontend Developer | Mar 2023 – Dec 2023
- Moved the online banking dashboard from AngularJS to Angular 15, one route at a time
Tech: Angular, RxJS, NgRx, Jest

Put the line after the bullets, start it with a plain label such as "Tech:" or "Stack:", and keep it to one line of normal text. Use it under every role or under none, so the page reads consistently. The bullets can still name the main tool, as these do.

Show which stack is current and which is five years old

Recency is the part a skills section cannot show. "Java" in a skills list could mean you write it every day or that you last used it in 2018. A reader who needs Java this year will want to know which.

Some recruiters search their candidate database for a technology name, and the result shows them your resume. Then they read your experience to see where that word appears. If the word appears only in the skills section, or only under a job from 2017, they have to guess or ask.

Here is an older role written so that its age is clear:

Corvel Insurance, Manchester
Software Engineer | Jun 2017 – Mar 2021
- Maintained the policy administration system in PHP and Symfony and added integration tests for its claims API
- Wrote the first Go service at the company, a document generator that replaced a nightly PHP batch job

A reader can see that PHP was the main language from 2017 to 2021, and that Go started there and continued at Tallis Payments. In an interview, that gives you a clear story about why you moved from one language to the other.

When an old technology is still in your skills section, put it last in its group, or move it out. Your skills list should look like your next job, not your first one.

How many technologies is too many?

List only what you could discuss for twenty minutes in an interview. Anything on the page is a fair question. A list of thirty tools tells the reader that you have used many tools, and leaves them to guess which ones you know well.

A practical limit is four or five groups with three to eight items each. Cut these first:

• Tools every engineer uses. Git, VS Code, Jira, Slack, npm. They rarely affect a decision, and they take space from tools that do.
• Methodologies and soft skills. Agile, Scrum, "problem solving" and "teamwork" are not technologies. If they matter, show them in a bullet about how you worked.
• One-time experiments. A framework you tried in a weekend tutorial does not belong next to the one you used for three years.
• Duplicates and vague categories. "JavaScript, JS, ES6" is one item. "Cloud" alone says little; "AWS (ECS, Lambda, RDS)" says what you used.

Before and after for a full stack engineer:

Before:
Skills: JavaScript, TypeScript, React, Redux, Vue, Angular, Node.js, Express, NestJS, Python, Django, Java, PostgreSQL, MySQL, MongoDB, Firebase, AWS, GCP, Docker, Kubernetes, Git, GitHub, Jira, VS Code, Agile, Scrum, HTML, CSS, REST, Teamwork

After:
Frontend: React, TypeScript, Redux, Tailwind CSS
Backend: Node.js, NestJS, PostgreSQL, Redis
Testing: Jest, React Testing Library, Playwright
Infrastructure: AWS (ECS, RDS, S3), Docker, GitHub Actions

The second list describes one engineer with one main stack. A reader can match it to a job description in a few seconds, and every item is something the engineer can explain in an interview.

Why you should skip skill bars and self-ratings

Skill bars, stars, dots and percentages ("React 90%") cause three problems.

First, they mean nothing to the reader. Your 4 out of 5 in Python has no reference point, and the reader cannot compare it to anyone else's. Second, they are graphics. Text extraction reads words, and a bar drawn next to "Python" becomes either nothing or noise. Third, a number like "Kubernetes 85%" invites a question you cannot answer well.

Order shows strength better than a rating. Put your strongest tools first in each group. If you need to mark a weaker skill, use a plain word, and let your experience bullets show the rest:

Before:
Python ●●●●○ | Go ●●●○○ | Rust ●○○○○

After:
Languages: Python, Go, Rust (basic)

Skills section layouts for frontend, backend, DevOps and iOS

Group by what the reader is hiring for. The groups should match how engineers in your area talk about their own stack.

Frontend. Lead with the framework and language, then state management, styling, testing and build tools. Accessibility and performance tooling belong here if you have done real work on them.

Frontend: React, TypeScript, Next.js, Redux Toolkit
Styling: CSS Modules, Tailwind CSS, Storybook
Testing: Jest, React Testing Library, Playwright
Performance and accessibility: Lighthouse, Web Vitals, axe

Backend. Lead with the language and runtime, then data stores, messaging, infrastructure and testing. Some engineers keep their main database with the language, as our mid-level backend engineer resume example does:

Backend: Node.js, Express.js, TypeScript, PostgreSQL, Sequelize
Cloud & DevOps: Docker, AWS EC2 & Lambda, GitHub Actions, Terraform
Data & Messaging: RabbitMQ, Redis, REST APIs, GraphQL
Testing & Quality: Jest, Supertest, Postman, ESLint

DevOps and cloud. Name the specific cloud services, not only the provider. "AWS" says little. "AWS (EKS, IAM, VPC)" tells the reader which parts of AWS you have worked with. Our senior DevOps engineer example also names tools inside its bullets, which shows pattern 3 on a real role:

CloudVista Solutions, Bangalore, India
Senior DevOps Engineer | 2020 – Present
- Automated CI/CD pipelines (Jenkins, ArgoCD) reducing release cycle from 2 days to 4 hours
- Implemented multi-region disaster recovery on AWS EKS, improving platform reliability to 99.99%

Cloud & Containerization: Kubernetes (EKS, GKE, AKS), Docker, AWS (EC2, S3, IAM, VPC, RDS), Terraform, Helm

Resume example

Senior DevOps Engineer Resume Example

Tools named inside the bullets, with specific cloud services in the skills section.

View the full example

iOS. Separate the language and UI frameworks from architecture patterns and tooling. Mobile readers want to know whether you work in UIKit, SwiftUI or both, and which architecture you are used to. This is the full skills section from our senior iOS engineer example:

Languages & Frameworks: Swift, Objective-C, SwiftUI, UIKit, Combine, RxSwift
App Architecture: MVVM, VIPER, Clean Architecture, Modularization
Performance & Tooling: Instruments, Xcode Profiler, Crashlytics, Firebase, Fastlane
Testing: XCTest, Quick/Nimble, Snapshot Testing, CI/CD

Resume example

Senior iOS Engineer Resume Example

A skills section grouped the way iOS engineers describe their own stack.

View the full example

If space is tight, trim the skills section before you cut experience. Our post on how long a software engineer resume should be covers what else to remove.