A developer resume that gets past ATS and HR: structure and examples

You apply to roles that match your experience, and almost no invitations come back. You never get to the technical interview where you could show what you can do. In that situation the resume is the place to start: it is read differently from how you imagine.

A resume has two readers. The first is the applicant tracking system (ATS) and the job board's search: they split the text into fields and look for words from the posting. The second is a recruiter who opens the resume for half a minute and decides whether to call you. Both need the same thing: to find the role, the stack and what you did, fast. In the job postings from Telegram channels that we collect for our job market analytics (Russian market, since August 2026), the skills that appear most often in requirements are Python, SQL, PostgreSQL, Docker, Git and Kubernetes. If words like these are in the posting and in your experience but not in your resume, the first reader will not find you.

Structure

The order of sections that both the system and a person expect:

1. Header: name, target role, city or work format, contacts.
2. Summary: three or four lines about who you are.
3. Skills: a list of technologies grouped by meaning.
4. Experience: jobs from the most recent to the earliest.
5. Education, courses, languages.

Keep the layout plain: one column, standard section names, a text PDF and not an image. Tables, two columns, skill bars and icons are parsed poorly, and text ends up in the wrong fields. It is easy to check: select all text in the PDF, paste it into a plain text editor and see whether it reads in order.

Headline and summary

Write the role in the headline the way it is named in the postings you apply to. "Backend Developer (Go)" will be found. "Software Engineer, Category 2" copied from an HR record will not, though it is the same job.

The summary answers three questions: how many years of experience and in what, which stack, what you have been doing recently.

Backend developer with 5 years of experience, the last three in Go. I build high-load services in fintech: a payment gateway, anti-fraud, bank integrations. Stack: Go, PostgreSQL, Kafka, Kubernetes. Looking for a senior role with a say in architecture decisions.

There is no "responsible", "good communicator" or "fast learner" here. Everyone writes those, and recruiters skip them. Every sentence carries a fact someone can ask about. The same facts work for your spoken self-introduction, which has its own post.

How to describe experience

The most common mistake is listing duties instead of experience. "Development and maintenance of services" could be written about any developer at any company.

A scheme that works for each bullet: the task, what you did, the result. Start with a past-tense verb: designed, rewrote, sped up, introduced, cut. Name technologies inside the sentence, next to what you did with them. Put numbers where you have them: response time, data volume, number of users, release time. If there is no number, do not invent one: you will be asked about it in the interview.

Three to five bullets per job are enough. More detail for the last two jobs, a line or two for older ones.

If the project is under NDA, write about the scale and your role without client names or internal systems. How to do that is covered in the post on talking about a project under NDA.

Example: before and after

The same experience block. Before:

Backend Developer, Fintech Service LLC, 2023-2026

Development and maintenance of microservices. Work with databases. Participation in code review. Team collaboration. Bug fixing.

After:

Backend Developer (Go), Fintech Service LLC, 2023-2026

Payment gateway: 40 microservices, up to 3,000 requests per second.

• Rewrote the payment reconciliation service from cron scripts to Go and Kafka: reconciliation runs continuously instead of once a day, and discrepancies show up within five minutes.
• Found and removed N+1 queries in the transaction history service and added PostgreSQL indexes: p95 response time dropped from 1.2 s to 180 ms.
• Set up canary deployments in Kubernetes for my team: a rollback takes two minutes instead of half an hour.
• Introduced a code review checklist for a team of six, and reviews started closing within a day.

The second version shows what the system is, how big it is and what changed after your work. Go, Kafka, PostgreSQL and Kubernetes sit in the experience text and not only in the skills list, so search finds them and the recruiter believes them. The company and the numbers in the example are made up.

Keywords from the posting

Open the posting and write out the requirements: technologies, types of tasks, words from the team description. Then go through the list and mark what you have really done. Everything marked should be in the resume in the same words: if the posting says "PostgreSQL", do not write "relational databases". If it says "CI/CD", do not stop at "configured builds".

Two limits. Do not add technologies you have not worked with: the technical interview follows the resume. And do not hide a keyword list in white font or as a solid paragraph at the end: a human will see it.

Length

One or two pages. The recruiter reads the first and skims the second. If you end up with three, cut the old experience: a job from ten years ago fits in one line. Keep pet projects, courses and hobbies only if they add something to the role you are going for.

Common mistakes

• A headline that says "Programmer" with no stack or level.
• Duties instead of results.
• A list of forty technologies where nobody can tell what you know well and what you opened once.
• A different stack in the skills section and in the experience.
• Gaps in dates with no explanation. One line such as "career break, relocation" is enough.
• Photo, age, marital status. They are not needed for hiring in IT.
• Typos and inconsistent formatting: periods at the end of some bullets and not others.

Tailoring to a posting

You do not need to rewrite the resume for every application. Keep a main version and change three places in it: the role in the headline, the summary, and the order of bullets in the last two jobs, so that what matters to this posting is on top. If you are searching in two directions, say backend and data engineering, keep two resumes.

What to do next

Take one posting you want to land and check your resume against its list of requirements. Then upload the resume for a review in Sobes: it scores ATS readiness, content, completeness and role match from 0 to 100 and gives recommendations with ready-made edits. Without a subscription you get one review: the overall score and the three main problems.

Whether the edits worked will show in the share of invitations per application. How to calculate it is described in the post on the job search funnel.