How to read a developer's résumé when you are not technical

A developer's résumé is accidentally designed to mislead anyone who does not code. It arrives with a list of twenty technologies, a few company names, and sentences that read identically on the excellent candidate and the mediocre one. The natural reaction is to scan for the words from the job posting and discard the rest. That is precisely what produces the worst hires. This guide covers what to look at instead, with no programming knowledge required.

The technology list is the least informative part

Nearly every technical CV opens with a block of twenty or thirty names: languages, libraries, databases, tools. That block rarely lies, but it rarely says anything useful either, because it does not distinguish three years in production from one weekend on a tutorial. An honest candidate and an inflating one write the same list.

The real signal is in the body, not the list. If someone puts Kubernetes at the top, find where Kubernetes appears in an actual job description and what they did with it. If it only ever appears in the list, that is surface knowledge. Cross-checking every key technology against a concrete piece of experience removes more noise than anything else, and it does not require knowing what the technology does.

Six years of experience, or one year repeated six times

This is the distinction that decides the most money and the easiest one to spot once you know how. Walk the roles in chronological order and ask whether the scope of the work changes. A developer who is growing moves from touching one part to designing a system, from working alone to coordinating others, from being handed the solution to deciding on it. If the last three roles describe the same task with a different logo beside it, you are looking at one year of experience repeated three times.

Be careful about judging job changes by the standards of other sectors. In technology, two-to-three-year stints are normal and are not a red flag. What does deserve a question is a run of stints under a year, or constant lateral moves with no growth in responsibility.

The five signals that do count

• Concrete numbers. "Cut load time from eight seconds to under two" or "moved from one deploy a month to several a day" are claims someone could disprove, which is why people who write them usually lived them. Sentences without a figure mean nothing.
• Real product you can open. A published app, a public repository, a site that loads. Being able to see it yourself beats any description.
• Continuity. Having maintained something for years, not just launched it. Building is the easy part; living with what you built is what teaches.
• The reasoning behind a decision. A CV that says "we migrated to X because Y stopped holding up as we grew" shows judgement. One that only lists technologies does not.
• A public trail. Talks, articles, open source contributions, answers in communities. Not mandatory — there are excellent professionals with none of it — but when it exists, it is verifiable.

What people discard by mistake

Three very common rejection reasons throw away good candidates. The first is a missing technology from the posting: someone with five years in a comparable language picks yours up in weeks, so that filter selects on vocabulary rather than capability. The second is the university degree, a weak indicator in development, where a large share of strong profiles come from bootcamps or are self-taught. The third is an ugly CV. Many excellent developers write mediocre résumés because they almost never need one; the document's design tells you nothing about the quality of their work.

If you reject on a missing word, you are filtering on vocabulary, not capability.

Two questions that turn a CV into information

No résumé stands on its own. Two questions on the first call tell you more than re-reading it ten times. First: ask them to explain one of their projects without using tool names — what the problem was, what they decided, and what went wrong. Someone who built something tells it in plain language and volunteers the part that failed. Someone who was merely nearby retreats into acronyms and company names.

Second: what would they do if something broke on a Friday afternoon with customers waiting. The answer separates people who have been in real production from those who have only worked in test environments, and you do not need to be technical to hear the difference. Both questions underpin any technical screening process worth running.

And salary, for calibration

A CV reads differently depending on what you can pay. If your band sits below the dollar-denominated remote market, the profiles who reply to you are a different set, and it is worth knowing that before rejecting anyone as demanding. Ranges by country and seniority, with the gap between local and foreign employers, are in what a developer earns in LATAM.

If this is your job every day

Reading technical CVs is a learnable skill that almost nobody teaches. We are preparing a course that covers it in detail, alongside sourcing, interviewing without being technical, and closing the offer. It is not on sale yet, and everyone on the list goes in first at the launch price: join it here. If you would rather delegate the screening entirely, that is what we do in IT recruiting — tell us the profile and the first screened candidates arrive in about five business days.