The real red flags when hiring a developer
Start by removing the false ones, because they do the most damage. Short tenures, gaps in employment, no computer science degree and an empty public profile are all screened on routinely and predict very little. They are easy to spot, which is the entire reason they are used. The signals that genuinely matter take a conversation to find, and there are fewer of them than the internet suggests.
Which red flags are not red flags?
Short tenures first. Two-year stints have been ordinary in this industry for a long time, and in the years when contract work and start-up failures were common they say more about the employers than the candidate. A pattern of leaving before three months is worth asking about; a pattern of leaving after two years is just a career.
Employment gaps are similarly weak. Illness, caring responsibilities, redundancy and deliberate breaks all produce identical looking gaps, and none of them predicts performance. Ask what they did and listen for whether they can talk about it plainly, which is the only part that carries information.
Then the two most expensive filters: no degree and no public code. Many strong developers came through other routes, and public code selects for spare time and a tolerant employer rather than for skill. Screening on either removes capable people in bulk and leaves you with a narrower field that looks like the last field.
What on a CV is actually worth noticing?
Six things, and each of them is a question rather than a verdict. The usual mistake is to treat the signal as the conclusion, when in every case a single question resolves it in either direction.
| What you see | Usual reading | Better reading | The question to ask |
|---|---|---|---|
| Under three months, repeatedly | Difficult to work with | Possibly contract work, possibly a real pattern | What was the arrangement, and who ended each one? |
| Every technology ever listed | Well rounded | Nothing has been used in depth | Which three would you be happy to be tested on? |
| Only we, never I | Team player | Contribution is unclear | Which part did you personally write? |
| Titles rising very fast | High performer | Small companies with free titles | How many engineers were there when you were lead? |
| Same role for eight years | Loyal, or stagnant | Depends entirely on what changed around them | What was different about the job in year seven? |
| No production ownership anywhere | Overlooked | Genuinely important for a small team | How did you find out when something broke? |
Which interview behaviours actually predict problems?
Blaming previous colleagues, consistently. One difficult former employer is a fact of working life; a pattern where every previous team was incompetent and every previous manager unreasonable describes how this role will be discussed in a year. Listen for whether the candidate ever describes their own contribution to a bad situation.
Refusing to say I do not know is the second, and it is more common than blaming. A candidate who invents a plausible answer under mild pressure will do the same thing in a design discussion, and the cost of a confident wrong answer inside a small team is high because nobody is positioned to check it.
The third is an inability to describe anything they built in enough detail to be questioned. Vagueness is occasionally nerves, so probe twice before concluding, but a candidate who cannot get specific about their own work after two invitations either did not do it or did not understand it.
How do you tell what someone actually did?
Ask about the parts nobody boasts about. What was the hardest bug in that project, how did you find it, and what was the actual cause. People who did the work answer this immediately and in detail, because debugging memories are specific and slightly unpleasant, which makes them stick.
Follow with what they would do differently. Genuine ownership produces regret with a reason attached, and the reason is usually technical and small. Borrowed experience produces general improvements such as better communication or more testing, which anybody could say about any project.
The last probe is the awkward one: who else worked on it and what did they do. Candidates describing their own work name colleagues and divide the credit without prompting, because they remember the arrangement. Candidates describing somebody else's work stay at the level of the project.
Which of your own habits create false flags?
Screening on stack familiarity. Rejecting a strong developer because their last five years were in a different language filters on recency rather than ability, and the transfer cost for a capable engineer is weeks. This is the most common way companies reject people they would have been glad to hire.
Reading fluency as competence. In any process involving candidates working in a second language, confidence and vocabulary get scored as technical strength, and the correlation is weak. Written exercises and code reading reduce this considerably, which is a practical argument for including them.
Interviewing without agreed criteria. Unstructured impressions mostly measure similarity to the interviewer, and they are recorded as culture judgements afterwards. Writing down two or three specific things that would change your mind, before the session, is the cheapest correction available and takes five minutes.
What do you do when you see a real flag?
Ask about it directly, once, and give the candidate a genuine chance to answer. Most flags are ambiguous on paper and resolve in one question, and the candidates worth hiring answer an awkward question well rather than being offended by it.
If the answer does not resolve it, ask for a reference who can speak to that specific point rather than a general reference. A named question to a former colleague is a short conversation and it is the only part of reference checking that produces information.
And be willing to reject on one thing. A candidate who was excellent in every session and blamed everyone in their previous job has told you something reliable, and hiring in the hope that it does not repeat is a decision people regret in writing afterwards.
Common questions
- Are short tenures a red flag for developers?
- Rarely. Two-year stints have been ordinary in this industry for a long time and often reflect contract work, acquisitions or companies that closed. What is worth asking about is a repeated pattern of leaving before three months, and even then the question is what the arrangement was and who ended it. A pattern of leaving after two years is simply a career.
- Should you reject a developer with no degree or no public code?
- No, and both filters are expensive. Many capable developers arrived through other routes, and public repositories select for spare time and a tolerant employer rather than for skill, so screening on them removes good candidates in bulk. Neither is easier to justify once you notice that they mainly reproduce the field you already have.
- What interview behaviour genuinely predicts a bad hire?
- Consistently blaming previous colleagues, where every past team was incompetent and no account includes the candidate's own contribution to the situation. Refusing to say I do not know is the second, because someone who invents a plausible answer under mild pressure will do it in a design discussion, and inside a small team nobody is positioned to check it.
- How do you tell whether a candidate actually did the work they describe?
- Ask about the hardest bug in the project, how they found it and what the cause turned out to be. People who did the work answer immediately and in detail because debugging memories are specific and unpleasant. Then ask what they would do differently: genuine ownership produces small technical regrets with reasons, while borrowed experience produces general improvements such as better communication.
- What interviewer habits cause good candidates to be rejected?
- Screening on stack familiarity, which filters on recency rather than ability when the transfer cost for a capable engineer is weeks. Reading language fluency as technical competence, which is a weak correlation and is reduced by written exercises and code reading. And interviewing without agreed criteria, since unstructured impressions largely measure similarity to the interviewer and are recorded afterwards as culture judgements.
