Hiring a developer who can't deliver costs more than their salary. It costs momentum, opportunity, and often the morale of your existing team. The challenge for non-technical founders is that the warning signs aren't always obvious. Technical competence is hard to evaluate when you don't write code yourself.

But many red flags have nothing to do with code. They're visible in conversations, references, and how candidates approach problems. You don't need to be technical to spot them.

Red Flag #1: Vague Portfolio with No Specifics

When a developer describes past work in generalities, something is off.

Warning signs:

• "I worked on a large e-commerce platform" (What specifically did you build?)
• "I was part of the team that built the mobile app" (What was your contribution?)
• "I helped improve performance" (By how much? What did you change?)

What good looks like:

• "I built the checkout flow, which reduced cart abandonment by 15%"
• "I designed the API architecture and implemented user authentication"
• "I optimized database queries that reduced page load time from 4 seconds to 800ms"

Specificity indicates real ownership. Vagueness often means minimal contribution or inflated claims.

Question to ask: "Walk me through a feature you built from start to finish. What decisions did you make? What challenges did you face?"

If they can't provide detailed answers, they either didn't do the work or don't understand it well enough to explain.

Red Flag #2: Unable to Explain Technical Decisions Simply

Strong engineers can explain complex concepts to non-technical people. They do it regularly with product managers, designers, and stakeholders.

Warning signs:

• Excessive jargon when simpler language would work
• Impatience when asked clarifying questions
• "It's technical, you wouldn't understand"
• Explanations that leave you more confused than before

What good looks like:

• Uses analogies and examples
• Checks for understanding
• Adjusts explanation based on your questions
• Happy to explain until it clicks

Why this matters: If they can't explain their thinking to you now, they won't be able to collaborate effectively later. You'll be making decisions without understanding the tradeoffs.

Question to ask: "Can you explain [something from their portfolio] to me like I've never written code?"

The best candidates enjoy this challenge. Poor candidates get frustrated.

Red Flag #3: No Questions About Your Business

A developer who doesn't ask about your business, users, or goals is a developer who builds features, not products.

Warning signs:

• Only asks about technology stack
• No curiosity about who uses the product
• Doesn't inquire about business model or metrics
• Focuses entirely on what they'll build, not why

What good looks like:

• Asks about your users and their problems
• Wants to understand success metrics
• Curious about business model
• Questions existing technical decisions

Why this matters: You need developers who understand that code serves users and business goals. Without business context, they'll make technically elegant decisions that don't serve your actual needs.

Question to observe: Watch what questions they ask in return. The questions reveal their mental model of the work.

Red Flag #4: Overconfidence in Estimates

"That's easy, I could do that in a week."

Any experienced developer knows that estimates are notoriously difficult. Software is uncertain. Requirements are incomplete. Surprises are inevitable.

Warning signs:

• Instant estimates without asking clarifying questions
• "That's simple" about requirements they just heard
• No acknowledgment of uncertainty
• History of blown deadlines (check references)

What good looks like:

• Asks clarifying questions before estimating
• Expresses estimates as ranges
• Identifies assumptions and risks
• Acknowledges when they need more information

Why this matters: Overconfident estimators consistently underdeliver. They either rush to make deadlines (producing buggy code) or miss deadlines repeatedly (destroying trust and momentum).

Question to ask: "What would make this take longer than expected?"

The best candidates can immediately list risks. Overconfident candidates look confused by the question.

Red Flag #5: Blames Others for Past Failures

Every developer has worked on failed projects. How they talk about those failures reveals their character.

Warning signs:

• Previous failures were always someone else's fault
• "The product manager gave bad requirements"
• "The other developers were incompetent"
• "Management didn't understand what was needed"
• No ownership of any part of the failure

What good looks like:

• Reflects on what they could have done differently
• Identifies systemic issues without only blaming individuals
• Shows learning from the experience
• Takes partial ownership where appropriate

Why this matters: Blame-focused developers create toxic environments. They don't learn from failures. When things go wrong on your project (and things always go wrong), they'll blame you, your team, or your requirements rather than solving the problem.

Question to ask: "Tell me about a project that didn't go well. What happened?"

Listen for ownership vs. blame.

Red Flag #6: Can't Discuss Tradeoffs

Every technical decision involves tradeoffs. There is no perfect choice, only choices with different consequences.

Warning signs:

• "This is the right way to do it" (absolute certainty)
• Can't articulate downsides of their preferred approach
• Dismissive of alternative approaches
• "That's how it's done" without explaining why

What good looks like:

• Explains pros and cons of different approaches
• Acknowledges when tradeoffs depend on context
• Can argue for multiple approaches depending on constraints
• Updates opinion based on new information

Why this matters: Developers who think in absolutes make poor decisions in real-world situations where constraints vary. They'll choose the "right" technical solution that's wrong for your specific context.

Question to ask: "You mentioned using [technology/approach]. What's the downside? When would a different choice be better?"

Strong candidates engage thoughtfully. Rigid candidates get defensive.

Red Flag #7: Poor Communication Patterns

Communication issues visible in the hiring process will be worse once they start working.

Warning signs:

• Takes days to respond to emails
• Misses or is late to interviews without notice
• Vague or confusing written communication
• Doesn't follow up or confirm details
• Interrupts frequently in conversation

What good looks like:

• Responsive and timely communication
• Clear written and verbal expression
• Confirms understanding
• Follows through on commitments

Why this matters: You'll be working with this person daily. Communication friction compounds. Small issues in hiring become large issues in collaboration.

Observation: The hiring process is their best behavior. If communication is poor now, it will be worse later.

Red Flag #8: Gaps in Fundamental Knowledge

Trendy frameworks come and go. Fundamentals persist. Developers who know the latest framework but not underlying principles struggle with novel problems.

Warning signs:

• Can't explain how their tools work under the hood
• Copies code without understanding it
• Struggles with questions about basic concepts
• Only comfortable with one technology
• Can't reason from first principles

What good looks like:

• Understands why, not just how
• Can learn new tools quickly because they understand fundamentals
• Explains concepts at multiple levels of abstraction
• Comfortable reasoning through unfamiliar problems

Why this matters: Your needs will evolve. Technologies will change. Developers with strong fundamentals adapt. Those who only know current tools become obsolete.

Question to ask: "How does [something they use] actually work?"

The depth of their answer reveals the depth of their knowledge.

Red Flag #9: No Evidence of Continuous Learning

Software development changes constantly. Developers who don't learn become less valuable over time.

Warning signs:

• Same skills as five years ago
• No side projects, courses, or learning activities
• Unaware of recent developments in their field
• Hasn't read a technical book or article recently
• No curiosity about how things could be better

What good looks like:

• Learning activities outside of work
• Awareness of industry trends
• Has opinions about new technologies (even if skeptical)
• Can discuss what they're currently learning
• Curious about your product and domain

Why this matters: The field moves fast. Someone who isn't learning is falling behind. And curiosity is one of the best predictors of engineering success.

Question to ask: "What's something you've learned recently?"

The answer reveals both their learning habits and their interests.

Red Flag #10: References Don't Align

References are your reality check. Use them.

Warning signs:

• No professional references
• References are friends, not colleagues
• References can't speak to their work specifically
• Hesitation or vague answers from references
• Stories don't match what the candidate told you

What good looks like:

• Multiple professional references
• References speak specifically about their work
• Consistent story with what candidate described
• Former colleagues enthusiastic to work with them again
• References proactively volunteer positive information

Questions for references:

• "Would you hire them again?"
• "What was their biggest contribution?"
• "How did they handle challenges?"
• "What would they need to work on?"

The "would you hire them again" question cuts through everything. Watch for hesitation.

Beyond Red Flags: What to Look For

Avoiding bad hires is necessary but not sufficient. What does a good hire actually look like?

Technical Competence:

• Can break down problems systematically
• Writes code that others can understand
• Has opinions informed by experience
• Knows what they don't know

Collaboration Skills:

• Communicates clearly
• Asks good questions
• Handles feedback gracefully
• Works well with non-technical people

Character:

• Takes ownership
• Follows through on commitments
• Stays calm under pressure
• Learns from mistakes

Fit:

• Interested in your specific product
• Values what you value (speed, quality, innovation, stability)
• Comfortable with your stage (startup chaos vs. established process)
• Excited about the role

The Hiring Process Itself

How you hire affects what you find.

Talk to them, don't just test them. Technical assessments matter, but conversations reveal things tests don't. How they think, communicate, and collaborate.

Check references seriously. Don't skip this. References catch what interviews miss.

Involve your team. Multiple perspectives reduce blind spots. If possible, have them work with existing team members briefly.

Pay attention to your gut. If something feels off but you can't articulate why, investigate further. Your instinct is pattern-matching on signals you're not consciously processing.

The Cost of Getting It Wrong

A bad hire costs:

• 3-6 months before problems become undeniable
• Damage to team morale and culture
• Missed deadlines and technical debt
• The opportunity cost of what you could have built
• The cost of starting the search again

It's worth investing time upfront to get this right.

At Topcode, we handle this process for you. Our developers are pre-vetted for technical competence, communication skills, and collaborative fit. When you hire developers through us, you skip the red flags and get proven professionals ready to contribute from day one.

Because hiring the wrong developer is expensive. Getting it right is everything.