Chapter 13: Your Stack on Your Resume
Your resume says “5 years of React.” The hiring manager reads “can only do React.” You meant one thing. They heard another. And the gap between those two readings is costing you jobs.
Let’s talk about the most consequential document in your professional life and how your relationship with your stack has probably distorted it.
Your resume — or your LinkedIn profile, or your portfolio site, or whatever artifact you use to represent yourself to potential employers — is a story. It’s a compressed narrative of who you are professionally, what you’ve done, and what you’re capable of doing next. And like all stories, it has a frame. The frame determines what gets emphasized, what gets omitted, and what impression the reader walks away with.
For most developers, the frame is the stack. The resume leads with technologies. The skills section is a list of languages and frameworks. The experience section describes what was built and in what language. The entire document is organized around tools, not capabilities.
This seems natural. It seems like what employers want. And to some extent, it is — many hiring processes are keyword-driven, and the keywords are technologies. But this framing comes with a cost that’s worth understanding.
The Keyword Trap
Modern hiring, especially at the initial screening stage, is often a keyword-matching exercise. A recruiter or an automated system scans your resume for specific technology terms and checks them against the job description. If the terms match, you advance. If they don’t, you’re filtered out.
This reality has created a generation of resumes that are, essentially, keyword documents. Developers front-load their most marketable technologies. They list every framework they’ve ever touched. They turn their professional narrative into a technology inventory, because the inventory is what gets through the filter.
The problem is that optimizing for keyword filters means optimizing for a process that values the wrong things. The keyword filter selects for technology match, not for capability. It selects for “has used React” not “can build great user interfaces.” It selects for “has used Kubernetes” not “can design reliable infrastructure.” It selects for the tool, not the builder.
And once you’ve been selected by a keyword filter, you arrive at the interview pre-categorized. The interviewer looks at your resume and sees “React developer.” Not “developer who has, among other things, used React.” The categorization is already done, and expanding beyond it in the interview is an uphill battle.
What Hiring Managers Actually Want
Here’s what a good hiring manager — the kind you want to work for — actually wants to know about you. It’s not just your tool list.
They want to know what you’ve built and why it mattered. Not “built a React frontend,” but “built the customer-facing dashboard that reduced support tickets by 40%.” The technology is relevant context, not the main event. The main event is the impact.
They want to know how you think about problems. Can you take an ambiguous requirement and turn it into a technical approach? Can you evaluate trade-offs? Can you make decisions under uncertainty? These abilities are stack-independent, and they’re what separate mid-level developers from senior ones.
They want to know how you work with other humans. Can you communicate technical concepts to non-technical stakeholders? Can you mentor junior developers? Can you give and receive code review gracefully? Can you disagree productively?
They want to know whether you can learn. If the job uses a technology you haven’t used, can you pick it up? The best signal for this is evidence that you’ve done it before — that you’ve worked across technologies and thrived in new environments.
None of these things are captured by a skills section that says “React, TypeScript, Node.js, PostgreSQL, Docker, Kubernetes, AWS.”
Reframing the Resume
So what does a resume look like when it’s framed around capability rather than stack?
It still mentions technologies — you’re not going to leave them out entirely, because the keyword filter exists and you need to get through it. But the technologies appear as supporting details, not as the headline.
Instead of:
Senior React Developer — Built and maintained React-based web applications using TypeScript, Redux, and GraphQL.
Try:
Senior Software Engineer — Led the redesign of the customer portal, improving page load times by 60% and increasing user engagement by 25%. Built with React and TypeScript; designed the GraphQL API layer that served three client applications.
The second version contains the same keywords. But the story it tells is fundamentally different. It says: “I solve problems and deliver results, and here are the tools I used to do it.” Not: “I am a React developer who does React things.”
The difference is subtle but hiring managers notice it. The first version says “hire me for my stack.” The second says “hire me for my thinking, and here’s proof that I can execute.”
The Skills Section Problem
The skills section of a resume is where stack identity gets most concentrated. It’s usually a long list of technologies, ordered by some combination of proficiency and marketability. And it’s almost always doing you a disservice.
Here’s why: a flat list of technologies tells the reader nothing about how you relate to those technologies. “Python” on your skills list could mean “I’ve written production Python services for five years” or “I did a Codecademy course once.” “Kubernetes” could mean “I’ve designed and operated multi-cluster deployments” or “I’ve run kubectl a few times.” The list compresses wildly different levels of experience into identical-looking entries.
A better approach is to provide context. Group your skills by what you’ve done with them:
Core tools (daily use in production): Python, PostgreSQL, Docker, AWS
Proficient (shipped projects, comfortable leading): Go, TypeScript, React, Terraform
Working knowledge (can contribute immediately): Rust, Kotlin, GraphQL
Exploring (actively learning): Elixir, WebAssembly
This tells a much richer story. It says you have depth but also breadth. It’s honest about your levels. And it frames each technology as something you use, not something you are.
The LinkedIn Headline Dilemma
Nowhere is the stack-identity problem more visible than in LinkedIn headlines. “Senior React Developer.” “Python Engineer.” “Full-Stack JavaScript Developer.” These headlines are optimized for recruiter search, and they work for that purpose. But they also cement the identity. They tell every visitor to your profile: this person is their stack.
Consider alternatives that lead with capability:
“Software Engineer — Building Reliable Data Systems”
“Product-Focused Developer — Web Applications & APIs”
“Engineering Lead — Infrastructure & Developer Experience”
These headlines are still searchable, still professional, still clear about what you do. But they leave room for growth. They don’t lock you into a specific technology. And they signal something that the best employers value: this person thinks about outcomes, not just tools.
Job Hunting Beyond Your Stack
The most practical application of everything in this chapter: when you’re looking for a job, don’t limit yourself to postings that match your exact stack.
This is terrifying advice. Every instinct tells you to apply for the jobs that match your keyword list, because those are the safe bets. And yes, you should apply for those. But also apply for the jobs that match your capabilities, even if the technology stack is different.
A job posting that says “we use Go” when you’ve mostly used Python is not a job you can’t do. It’s a job where you’d need to learn Go, and if you’ve read this far in this book, you know that learning Go is very achievable for an experienced developer. The question isn’t “do I know Go?” The question is “am I capable of learning Go quickly enough to be productive?” And if you have a track record of learning new technologies — if your resume demonstrates adaptability — the answer is almost certainly yes.
The jobs that require a stack you don’t know are also, often, the most interesting jobs. Because they’re selecting for a different kind of developer — one who’s curious, adaptable, and not boxed in by their current tools. Those teams tend to be better places to work.
Writing Yourself Into the Future
Your resume is not just a record of your past. It’s a proposal for your future. Every choice about what to emphasize and what to downplay is a statement about where you want to go.
If you organize your resume around a stack, you’re proposing a future in that stack. You’re saying: give me more of the same. And that might be what you want.
But if you organize your resume around capabilities — around problem-solving, around impact, around the ability to learn and adapt — you’re proposing a future that’s open. You’re saying: I can go wherever the interesting problems are. And that opens up a much bigger world.
The stack goes on the resume. Of course it does. But it goes in the supporting role, not the lead. The lead is you.
Next: Chapter 14 - Talking About Technology Without Becoming It