Telling whether a software developer is good is genuinely hard, especially if you are not deeply technical yourself, and the signals people instinctively trust are the unreliable ones. A polished resume can be padded. Confidence is not competence, some of the most confident people are the least skilled, and some of the best are quietly unassuming. What actually predicts whether someone is good is their real work, whether they have shipped things to real users, and how they reason about actual problems, not how impressive they sound in a conversation. Look at the reliable signals, and discount the ones that fool everyone.
Key Takeaways
- Resumes and confidence are unreliable signals of whether a developer is good.
- The reliable signals: their actual work, real shipped experience, and their reasoning.
- Has shipped to real users beats has built impressive-sounding things.
- How they reason about real problems reveals more than how they present.
The Signals That Mislead
The two things people most instinctively trust, resumes and confidence, are exactly the ones that fool them. A resume lists impressive companies and technologies without telling you what the person actually did or how well, and it can be quietly inflated. Confidence is worse, because we read it as competence, and yet confidence and skill are barely correlated: plenty of highly confident developers are mediocre, and plenty of genuinely excellent ones are understated. If you judge a developer by how assured they sound, you will regularly pick the wrong one. So consciously set aside the resume shine and the confident delivery, and look at signals that are harder to fake.
The Signals That Predict
Three things reliably indicate a good developer. First, their actual work: real code they have written, which a technical evaluator can assess directly, tells you far more than any description of it (the five-stage vetting process). Second, shipped experience: whether they have actually delivered things to real users, because shipping involves the hard, unglamorous finishing work that talkers skip, and a track record of shipped software is strong evidence. Third, reasoning: how they think through a real problem, weigh tradeoffs, and reason about their own past decisions, which reveals depth that presentation cannot (interview questions for a senior software engineer). These are harder to assess than reading a resume, and they are what actually tell you.
| Misleading signal | Reliable signal |
|---|---|
| Impressive resume | Their actual code and work |
| Confident delivery | Track record of shipped software |
| Buzzword fluency | Reasoning about real problems |
| Big company names | What they personally did and shipped |
A Concrete Version
You are evaluating a developer who interviews very well, confident, polished, name-drops impressive companies. That tells you little. What tells you something is looking at real work they have done and having someone technical assess it, checking whether they have genuinely shipped products to real users rather than only worked on things that never launched, and probing how they reason through an actual problem and reflect on a past decision. A developer who looks ordinary in conversation but has a real trail of shipped work and reasons clearly about tradeoffs is very likely good; a dazzling talker with nothing shipped and shallow reasoning very likely is not. The reliable signals pointed the opposite way from the first impression.
The Honest Counterpoint
The reliable signals are harder to read, and for a non-technical founder some of them, assessing actual code, judging technical reasoning, are difficult to evaluate alone, which is the honest limitation here. The answer is not to fall back on resumes and confidence but to get help judging the signals that matter: a technical advisor or a partner who vets rigorously can assess the code and reasoning you cannot (how to de-risk hiring a nearshore developer). It is also true that no single signal is definitive, a good developer might have a thin shipping record early in their career, so weigh the signals together rather than treating any one as decisive. Use the reliable signals, and get help reading the technical ones.
The Bottom Line
Telling if a software developer is good means trusting the reliable signals and discounting the seductive ones. Resumes can be padded and confidence is barely correlated with skill, so set them aside and look at real work, whether they have actually shipped to real users, and how they reason about genuine problems. Those signals are harder to read, and for the technical ones a non-technical founder should get help from an advisor or a rigorous vetting partner. Judge the work and the reasoning, not the resume and the confidence, and you will pick good developers far more often.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
