Tech resumes: mistakes that turn recruiters away

The recruiter spends ten seconds on your resume

I've sat on the other side of more than one technical screen, and the uncomfortable truth is this: on the first pass, nobody reads your resume. They glance. In about ten seconds they decide whether to spend another minute or move on to the next PDF in the pile. Most tech resumes die in exactly those ten seconds, not because the person is bad, but because the document tells the wrong story. You listed everything you've ever touched and forgot to say what you actually fixed.

This piece is about the mistakes that turn recruiters away before the interview, and what to put in their place. I'll treat the resume for what it is: a filter optimized to be discarded fast. In parallel, it pays to strengthen your public presence, because a good repository usually speaks louder than any bullet point — I wrote about that in how to document projects on GitHub.

The wall of buzzwords impresses no one

The most common mistake is treating the resume as a list of keywords to slip past the ATS. The result is a wall: React, Vue, Angular, Node, Python, Go, Rust, Docker, Kubernetes, AWS, GCP, Terraform, Kafka, Redis, GraphQL. When I see thirty stacked technologies, I don't think "what a well-rounded person." I think "this person touched everything for a week and is good at none of it."

List what you'd actually use in an interview without breaking a sweat. If you put Kubernetes on the resume, I'll ask about liveness probes, about how you debugged a pod stuck in CrashLoopBackOff. If the answer is "oh, I ran the deploy once following a tutorial," you just burned credibility for the rest of the document. Fewer technologies with real depth beat the infinite list.

"Responsible for" says nothing

This is the one that hurts most. The experience section becomes a list of responsibilities:

- Responsible for developing REST APIs
- Responsible for maintaining the legacy system
- Responsible for the team's code reviews

That describes the job, not you. Anyone in that role was "responsible" for the same things. What sets you apart is impact, and impact is measured with a number and an action. Rewrite each line as action verb + what changed + metric:

- Cut checkout API p95 latency from 800ms to 180ms by moving N+1 queries to batch loading
- Reduced CI build time from 14min to 4min with layer caching and parallelized tests
- Killed 60% of nightly pager alerts by fixing retries without backoff in the queue consumer

Not everything has a pretty metric, and that's fine. But "responsible for" is never the best version of the sentence. Swap it for "built," "migrated," "reduced," "automated." The verb carries the action; the number carries the proof.

Three pages, a generic objective, and no links

A few classics that kill a resume instantly:

• Three pages or more. Unless you're a senior with fifteen years of road behind you, a resume is one page. Two at the limit. Nobody reads the third, and the fact that a third exists already signals you can't prioritize.
• Generic objective. "Seeking a challenging opportunity at an innovative company to grow professionally." It takes up space and says nothing. Cut it. If you want a summary at the top, make it one concrete line: "Backend dev focused on distributed systems, Go and Postgres, with a track record of cutting infra cost."
• No links. No GitHub, no portfolio, no LinkedIn. For a technical role, the link to your code is worth more than half the bullets. Its absence makes me suspect there's nothing to show.
• A PDF that turns into character soup in the ATS. Dual-column layouts, icons instead of text, exotic fonts. The ATS parser scrambles all of it. Keep it simple, single column, real text.

Tailor the resume to the role

Sending the same PDF to forty openings is efficient for you and terrible for results. Every posting describes what matters: read the description and reorder. If the role is data-heavy, your ETL pipeline project moves to the top; that mobile app you built in 2019 drops or disappears. I'm not telling you to lie — I'm telling you to surface what's relevant to that specific person.

It costs five minutes per application and visibly changes your response rate. A resume that looks made for the role signals that you read the description and care. A generic resume signals you're spraying in every direction.

What actually opens doors

I'll say what you may not want to hear: past a certain point, the resume matters less than your public presence. A well-written README, a project that runs when I clone it, a GitHub profile with real commits — that beats a polished two-page resume easily. The resume opens the door; your code decides whether you walk in.

That's why I invest more in a lean, honest portfolio than in stretching the experience list. Two or three projects you can explain line by line are worth more than ten dead repositories. And a README that explains the problem, the technical decision, and the trade-off shows exactly the kind of reasoning you want in a tech hire.

Frequently asked questions

Should I put a summary at the top of my resume?

You can, as long as it's concrete. One line that says what you do, with which tools, and what sets you apart. Avoid empty motivational phrases. If the summary could sit on anyone else's resume, it's doing nothing for you.

How many technologies should I list?

List only what you can defend comfortably in an interview. There's no magic number, but if the list goes past fifteen items, there's probably filler in there. Real depth in a few technologies inspires more confidence than a showcase of logos.

Is a one-page resume worth it?

For most people, yes. One page forces prioritization and respects the reader's time. Seniors with a long history can go to two, but it rarely justifies going beyond that. The third page is almost always a sign of missing focus.

Do personal projects count without professional experience?

They count, a lot, when they're well documented and actually run. A project that solves a concrete problem, with a clear README and clean code, covers much of the absence of formal experience. It's the most direct way to prove you can build something end to end.

Before you send the next resume

The resume isn't your biography, it's an ad with ten seconds of attention. Cut the buzzwords, swap "responsible for" for achievements with metrics, keep it to one page, tailor it to each role, and make the link to your code highly visible. And invest in what actually decides the hire: an honest portfolio and a README that shows how you think. The document opens the door, but it's your public work that gets you in.