The Tech Stack List Problem

The skills section is the part of an engineering resume that everyone writes last, in five minutes, by listing everything they can remember touching. The result is usually something like this:

Java, Python, JavaScript, TypeScript, C++, Go, Ruby, PHP, SQL, NoSQL, HTML, CSS, React, Angular, Vue, Node.js, Express, Django, Flask, Spring, Docker, Kubernetes, AWS, Azure, GCP, Jenkins, Git, GitHub, GitLab, Jira, Agile, Scrum, REST, GraphQL, gRPC, MongoDB, PostgreSQL, MySQL, Redis, Elasticsearch, Kafka, RabbitMQ, Terraform, Ansible, Linux, Bash, CI/CD, Microservices, TDD, OOP, Machine Learning

Forty-eight items. Let’s talk about what that actually communicates.

What a long list signals

That you can’t prioritise. The reviewer’s job is to figure out what you’re good at. A list of everything defers that work back to them, and they won’t do it.

That some of this isn’t true. Not deliberately — but “I used Angular for one sprint in 2019” and “I have shipped and maintained Angular applications” are both in that list and indistinguishable. The reader knows this, so they discount the whole list.

That you might get asked about the weakest item. This is the practical risk. An interviewer scanning for something to open with will sometimes pick a term at random. If it’s the one you listed out of optimism, the interview starts with you backing away from your own resume.

That you don’t know what’s a skill. Git is not a skill; it’s a baseline. Neither is “Agile,” “OOP,” or “REST.” Listing them suggests you don’t have enough real ones to fill the space.

The defensibility filter

Go through your list and keep only what passes this: if an interviewer said “tell me about a time you used this and something went wrong,” could you talk for five minutes?

That’s a deliberately low bar — five minutes, one story. But it eliminates the tutorial-level entries immediately, because a thing you followed a guide through has no war story attached.

Everything that fails the filter falls into three groups:

• Delete. You touched it once, it isn’t relevant, it’s gone. Nobody is checking whether you left something out.
• Demote into a bullet. If you used it on one project and that project is on your resume, mention it in the bullet where it belongs, with its context: “prototyped the ingest in Rust before we settled on Go.” Now the level of your experience is obvious and accurate.
• Move to a “familiar with” line, if you really want it on the page. One short line at the end: Also familiar with: Rust, Elixir, Kotlin. This is honest signalling — it says “I’ve been in here, don’t quiz me hard,” and reviewers read it exactly that way.

Most people cut a forty-item list to about eighteen and the resume gets stronger.

Group by category, always

An unsorted list forces the reader to scan for what they care about. A grouped one lets them jump straight there.

Languages Go, Python, TypeScript, SQL Data stores PostgreSQL, Redis, ClickHouse Streaming Kafka, Debezium Infrastructure AWS (ECS, RDS, S3, Lambda), Terraform, Docker Observability Prometheus, Grafana, OpenTelemetry

Five lines. A backend hiring manager checking for Kafka experience finds it in two seconds. The categories themselves also tell a story: this person works on data-heavy backend systems and cares about observability. The unsorted version buries that.

Pick categories that match your actual specialism. A frontend engineer’s grouping should not be the one above — it’d be Languages / Frameworks / Styling / Build & tooling / Testing.

Be specific about clouds

AWS on its own means anywhere from “I’ve deployed to EC2 once” to “I’ve operated a multi-account organisation.” Name the services:

AWS (ECS, RDS, S3, Lambda, EventBridge, IAM)

That’s far more informative and it’s self-limiting in a good way — you’ll only list the services you actually know, which is precisely the point. IAM in particular is worth naming if you know it, because a lot of people list AWS and cannot write a policy.

Same logic for anything else with enormous surface area. Kubernetes could mean you write YAML or that you’ve operated a cluster. If it’s the latter, say something: Kubernetes (operated self-managed clusters, wrote custom controllers).

Don’t list all three clouds

AWS, Azure, GCP reads as one of two things: you’re a consultant who genuinely has moved between them, or you’ve written the names of three clouds. Absent evidence in your work history for more than one, list the one you know and drop the others. You can mention exposure to a second in the “familiar with” line if it matters.

The same applies to listing four JavaScript frameworks, three CI systems, and both MongoDB and PostgreSQL with no indication of which you’d actually reach for.

Kill the proficiency ratings

Star ratings, percentage circles, progress bars, “Expert / Advanced / Intermediate” tags.

Nobody knows what 80% Python is. There’s no shared scale, so the number carries no information — it’s pure self-assessment presented as measurement. Worse, the confident people rate themselves high and the ones who actually know the language rate themselves lower, so if the ratings mean anything at all, they’re inverted.

They also eat a large amount of vertical space, and when your resume is rendered as plain text — which happens more often than you’d think — the bars vanish and leave a column of orphaned labels.

If you want to convey depth, do it with context: put the languages you’re strongest in first, and let the work history show where you’ve used them for years.

Where the list should live

For an experienced engineer: after the work experience. The reviewer reads what you did, then checks the list to confirm the shape of it. Putting a skills list first asks them to evaluate a set of nouns with no context.

For a new graduate or a career changer into engineering: near the top, because the list is a substantial part of the evidence and there’s less work history to lead with.

Either way it should be four to six lines. If it’s a paragraph, it’s too long.

The last check

Read your final list and ask: does this describe a person, or a job board?

A good skills section has a shape. Someone should be able to look at it and say “this is a backend engineer who works on data pipelines” or “this is a frontend specialist with real accessibility experience.” If yours could belong to anyone in the industry, cut it in half and see if a shape appears.