How to evaluate a developer without labels

The problem with label-based evaluation

When you are hiring a developer, the first thing most people look at is the title. Senior? Great, send them through. Junior? Maybe later. This shortcut feels efficient, but it is actually costing you the best candidates.

Labels compress a complex set of skills, experiences, and capabilities into a single word. A "senior developer" at a 5-person startup has a completely different skill set than a "senior developer" at a bank. One has built entire systems from scratch. The other has deep expertise in maintaining large-scale enterprise applications. Both are valuable. Neither is captured by the word "senior."

Here is a practical framework for evaluating developers based on what they can actually do, not what their title says they should be able to do.

The four dimensions that actually matter

After hundreds of placements and years of watching what predicts success on the job, I have narrowed it down to four dimensions. These apply whether someone has 2 years of experience or 20.

• Technical depth. How deeply does this person understand their primary technology stack? Can they explain not just the "how" but the "why"? Do they know the tradeoffs of the tools they use?
• Scope of impact. What is the largest system or project they have been responsible for? This is not about years. It is about the complexity and scale of problems they have solved.
• Communication and collaboration. Can they explain technical decisions to non-technical stakeholders? Do they contribute to team discussions? Can they disagree constructively?
• Learning velocity. How quickly do they pick up new technologies and concepts? What have they learned in the last six months? This matters more than what they already know.

Questions that reveal real capability

Forget "how many years of React experience do you have?" Here are questions that actually tell you something useful:

• "Walk me through the most complex technical problem you solved recently." Listen for how they break down the problem, what tradeoffs they considered, and whether they can explain it clearly. The specificity of their answer tells you more than any label.
• "Tell me about a technical decision you made that turned out to be wrong." This tests self-awareness and growth mindset. Strong developers can articulate their mistakes without getting defensive. They can explain what they learned and what they would do differently.
• "If you joined our team tomorrow, what would you want to understand in the first two weeks?" This reveals how they approach new environments. Do they ask about architecture? Team dynamics? Deployment processes? Business context? The best developers are curious about all of it.
• "Show me something you built that you are proud of." This could be a side project, an open source contribution, or a feature at a previous job. What matters is not the technology. It is how they talk about the work. Enthusiasm and depth of understanding are hard to fake.

Red flags that labels hide

A "senior" title can mask some serious problems. Watch for these:

• Cannot explain decisions. If someone has 10 years of experience but cannot articulate why they chose one approach over another, the experience may be shallow. Ten years of repeating the same year is not senior.
• Resists learning new things. Technology changes constantly. A developer who has stopped learning is a developer who is falling behind, regardless of their title.
• Only talks about individual contributions. Software is a team sport. If every story is "I built this" with no mention of collaboration, that is a warning sign.
• Defaults to complexity. Experienced developers should be making things simpler, not more complicated. If someone always reaches for the most sophisticated solution, they may be optimizing for their own enjoyment rather than the project's needs.

Green flags that labels miss

Some of the strongest developers I have placed had titles that undersold them. Look for these signals:

• Asks great questions. During the interview, are they just answering, or are they also asking about your architecture, your team, your challenges? Genuine curiosity is a predictor of success.
• Has opinions but holds them loosely. The best developers have strong technical perspectives but can change their mind when presented with new information. This balance is rare and valuable.
• Can zoom in and out. They can discuss a specific algorithm and then step back to talk about system-level architecture. This ability to operate at multiple levels of abstraction is one of the clearest signals of capability.
• Has built things outside of work. Side projects, open source contributions, blog posts, conference talks. These are not requirements, but they signal someone who is genuinely passionate about their craft.

Putting it into practice

Next time you receive a candidate profile, try this: cover the title and years of experience. Read the skills, the project descriptions, the technologies used. Form your initial impression based on what this person has actually done. Then uncover the label and see if it changes your assessment.

If it does, ask yourself why. Is the label adding real information, or is it just triggering assumptions? In most cases, it is the latter. The proof is in the work, not in the title. That is what "proof over paper" means at InitLabs, and it is available to any company willing to look past the labels.