Last year I referred a backend colleague for an internal opening. His technical chops were solid — above average for his peer group — and he did well in the algorithm and system design interviews. Then HR screened him out before he even got to the first round. I grabbed his resume, and my first reaction was: that can't be right. Read it again more carefully, and there it was. His resume wasn't bad. It was just "unreadable to non-technical people, and uninteresting to technical ones."
Here's one example. He described an internal project like this:
Built a microservices architecture using Spring Cloud, refactored the legacy monolith to reduce business logic coupling. Data layer used MySQL + Redis + Elasticsearch. Async messaging handled by Kafka for decoupling.
Solid tech stack. But any interviewer reading that has exactly one question: You did all that — and then what? Did the system get faster after the refactor? Did users notice a difference? What did the business team say? None of that is there.
This is the signature mistake developers make on resumes: we're too comfortable describing our work in purely technical terms. We write code comments for other developers. We write resume bullet points like we're writing for our teammates. But the first person screening your resume is usually an HR recruiter, not an engineering manager. And even once you reach the technical interview, the interviewer isn't trying to count how many tech keywords you can list. They want to know what you actually solved with those tools.
Here are five of the most common developer resume problems, each with a before-and-after.
Case 1: A whole row of tech stack — and it's just a list of nouns
Background: Kai, three years of Java development. The most prominent spot on his resume had this:
Proficient in Java, Python, Go, Spring Boot, MyBatis, MySQL, Redis, Kafka, RabbitMQ, ES, Docker, K8s, Jenkins, Linux…
The longer this line gets, the less it's worth. When an interviewer sees a wall of tech keywords, they don't think you know everything. They think you've lumped "used it once" and "deep expertise" into the same bucket. Worse, they can't tell which direction you actually specialize in or where you can ship code on day one.
And every developer knows: one year of CRUD and one year of performance tuning on the same technology are two completely different skill levels. A flat tech stack list erases that distinction.
After:
Primary stack: Java / Spring Boot / MySQL (3 years, focused on high-concurrency server-side development)
Secondary: Redis, Kafka, Elasticsearch (independent technology selection and tuning experience)
DevOps: Docker, K8s (daily use, can write Dockerfiles and basic deployment scripts independently)
What's the difference? The original was a stew. This is three tiers. An interviewer can scan it in five seconds and see your core strength is Java backend — and that you're not just writing business logic, you've done middleware tuning. Tech you've only "touched" can stay off the resume entirely, or come up naturally in conversation. Here's the iron rule for developer resumes: every single technology you put on there, be ready to answer deep questions about it.
Case 2: Writing yourself as an executor, with zero signs of technical decision-making
Background: Xiao He, five years of backend experience across two companies. Every job entry on his resume looked like this:
Responsible for daily development and maintenance of core modules including user center, orders, and payments. Participated in requirements review and technical design. Collaborated with QA team on functional verification and release.
Can you tell the difference between his fifth year and his second year? Neither can anyone else. Any backend developer could write this paragraph. He's described himself as someone permanently stuck in the "take ticket → write code → deploy" loop.
But Xiao He's actual track record is nothing like that. At his first company, he led the initial database design for the user center module and proposed the sharding strategy. At his second, he drove the team's migration from SVN to Git and built their first CI/CD pipeline. Not a word of any of this made it onto his resume, because he thought, "Isn't this just… normal work?"
After:
Led the database design for the user center from scratch. Anticipated business growth rate and planned a sharding strategy upfront, supporting user growth from 500K to 6M+ over two years without significant query performance degradation.
Drove the team's migration from SVN to Git and built the team's first Jenkins-based CI/CD pipeline. Post-migration, code conflict rates dropped noticeably, and the feature release cycle shrank from biweekly to within a week.
That second bullet is especially important. It doesn't say "I know Jenkins." It says "I identified a team process problem, proposed a solution, and drove it to completion." That's the dividing line between a senior engineer and a mid-level one. When an interviewer reads a resume with five years of experience, this is the signal they're hunting for: can you spot problems and push solutions through, or do you just finish the tasks assigned to you?
Case 3: A row of GitHub links that say nothing
Background: Xiao Wang, two years of frontend experience. The "Personal Projects" section of his resume listed three GitHub links, each followed by a one-liner:
A NetEase Cloud Music clone built with React: link
A simple blog system: link
A Hackathon project: link
When an interviewer sees this, there's a 99% chance they won't click a single link. The reason is simple: they don't have time. You handed them three URLs without telling them what's worth seeing inside, so they treat it as empty space.
And honestly, these three projects differ massively in quality — the music player is something he worked on for two months and has 150+ stars; the blog system took three days; the Hackathon project was built with two backend teammates, and he handled the entire frontend plus some UI design. None of this is communicated. The three projects look like three equally lightweight homework assignments.
After:
React-based NetEase Cloud Music Player | Solo project | 150+ stars
Independently completed the full pipeline from UI design to frontend implementation. Core features include playback controls, synchronized lyrics scrolling, and playlist management. Built with React + Redux + Hooks, integrated with NeteaseCloudMusicApi for real data. Published on Juejin and featured on the homepage, with 300+ upvotes.Hackathon Project "XX" | 3-person team | 2nd place
Responsible for frontend architecture and all page development using Vue3 + TypeScript. Shipped from prototype to live demo in two days. The core highlight was a real-time collaborative editing feature implemented with WebSocket + CRDT.
After this rewrite, whether anyone clicks the GitHub links barely matters — the description alone gives the interviewer enough to judge the project's complexity, your role, and your technical depth. The link is just there for reference.
Case 4: Technical skills completely disconnected from business outcomes
Background: Lao Li, six years as an ML engineer, working on a recommendation system at an e-commerce company. His resume said:
Responsible for algorithm iteration on the recommendation system, including recall, ranking, and re-ranking module optimization. Used deep learning models to model user behavior, improving recommendation accuracy. Participated in building the A/B testing platform.
Any recommendation system engineer could write this paragraph. "Improved recommendation accuracy" — by how much? What's the definition of accuracy here? CTR? Conversion rate? GMV? After reading this, the interviewer has no idea what order of magnitude your optimization achieved.
But Lao Li's actual results are impressive: he pushed the homepage recommendation CTR from 7.2% to 9.8%, and maintained it while the user base nearly doubled. His multi-objective ranking model elegantly balanced add-to-cart rate against CTR. Not one word of this was on his resume, because he thought "those are business metrics, not my technical achievements."
This is the biggest blind spot. Technology only has commercial value when it lands in the business, and that commercial value is the only reason a company pays you a high salary. An ML engineer who says "I optimized the model" versus one who says "I improved CTR by 2.6 percentage points, running stably across tens of millions of users" — the market price difference is at least 30%.
After:
Responsible for full-pipeline algorithm iteration (recall → ranking → re-ranking) on the recommendation system. Led the upgrade of the multi-objective ranking model, balancing CTR (7.2% → 9.8%, +2.6pp) with add-to-cart rate, while maintaining recommendation service P99 latency ≤ 80ms during a period when DAU doubled to tens of millions.
Designed and drove the metrics framework for the A/B testing platform, shrinking the experiment analysis cycle from weekly to daily. Supported 200+ algorithm experiments annually.
Case 5: Project descriptions written like architecture docs
Background: Xiao Tang, four years of backend, working on an internal data platform. The project section of his resume read:
Project: Enterprise Data Platform
Tech stack: Spring Boot + Flink + ClickHouse + Kafka
Description: This project uses a microservices architecture, divided into data ingestion, compute, storage, and application layers. The ingestion layer supports MySQL Binlog, API data sources, and file uploads. The compute layer uses Flink for unified stream-batch processing. The storage layer uses ClickHouse for real-time OLAP analysis.
If you're an engineering manager reading this, your first thought is: "Is this your company's architecture doc?"
A resume is not a technical design document. The interviewer doesn't need to know how many layers your system has or what each layer is called. They need to know: what did you do in this project, why did you do it, and what did you achieve? Save the architecture diagram for the whiteboard during the interview. Writing out architectural layers on your resume is wasting prime real estate.
Xiao Tang actually did plenty worth writing about in this project: the Binlog ingestion pipeline he designed was 4x faster than the previous solution, and he single-handedly optimized ClickHouse materialized views to slash a core report's query time from 40 seconds to 3 seconds.
After:
Enterprise Data Platform | Core Developer
Redesigned the Binlog real-time ingestion pipeline, reducing data latency from 5s to under 1s and increasing throughput by 4x, supporting 300M+ rows of data sync per day.
Independently optimized ClickHouse materialized views, compressing query time for 3 core reports from 40s+ to under 3s. Business teams went from "waiting for the daily report" to "checking anytime."
After launch, data onboarding efficiency improved significantly — integrating a new business line's data source went from 3 days to under half a day.
Three sentences, each with a clear problem → solution arc. The interviewer reads the first one and knows this person can do performance optimization. The second one shows they don't just use off-the-shelf tools. The third proves their work impacted team efficiency.
Five Principles for Developer Resumes
1. Tier your tech stack — don't throw everything in one pot
Split your technical skills into three tiers: primary (what you make your living with), secondary (tech you've independently tuned), and familiar (you've used it but it's not deep). Keep your primary stack to no more than 3 items, secondary 3–5. Familiar can stay off the page. The interviewer only needs to know your sharpest tools.
2. Every technical decision should answer "why" and "what was the result"
Bad: Used Redis for caching.
Good: Introduced a Redis caching layer, reducing product detail page API response time from 680ms to 45ms.
It's not "what technology did you use." It's "what pain point drove you to use this technology, and what changed as a result." Tech is the means. Solving the problem is the value.
3. There's no technical work that can't be quantified — you just haven't found the right angle
If you genuinely can't find a percentage, reframe:
- How much traffic did your system handle? (peak QPS)
- How many people did your code impact? (users or business lines covered)
- How many people use what you built every day? (daily call volume / active users)
- How much faster or cheaper is it compared to before? (latency change, cost change)
A backend developer saying "the API I built handles 8 million calls a day and hasn't had an incident in six months" — that's enough.
4. GitHub projects need descriptions, not just links
Minimum three lines per project: what you built, what tech you used, and what feedback or impact it got. If you've done open source contributions, don't just write "submitted PRs to project X." Specify what bug you fixed, roughly how much code was involved, and whether the PR got merged.
5. Your work experience should signal your role on the team
- Under 2 years: it's okay to be an executor, but show what modules you independently delivered.
- 3–5 years: there should be signs you owned technical decisions, not just received assignments.
- 5+ years: it must be visible that you influenced the team or business direction — through technical infrastructure, process improvements, or mentoring.
After You Write: A Five-Point Developer Self-Check
- Scan your tech stack section. Can someone identify your core specialization in 5 seconds?
- How many of your work experience bullets follow the "what you did → what result it produced" structure?
- Next to every GitHub link, did you write out the project's highlights and your specific role?
- Can you find at least 3 concrete numbers anywhere on your resume? (QPS, user count, latency, efficiency gain — any number counts.)
- If you were an HR person with zero technical background, could you roughly explain what this person does after reading their resume?
Honestly, the biggest obstacle for developers writing resumes isn't writing ability. It's the belief that "if my tech is strong enough, the resume doesn't matter." But reality is simple: no matter how good your skills are, if you can't get past the resume screen, you never get the chance to prove them. Spending one afternoon reworking your resume against the principles above has a better return on investment than grinding ten more LeetCode problems.
If you've revised it and you're still not sure about the result — it's genuinely hard to self-edit; your own blind spots are real — upload your resume to DeepResume for a diagnostic. The system checks three dimensions: technical keyword coverage, metric quantification, and clarity of expression. It'll tell you exactly where you can go stronger.