Hiring a developer is one of the most consequential decisions a startup founder makes, and most founders make it by looking at the wrong things.
Not because they are careless, but because the signals that are easiest to see, the GitHub profile, the list of technologies, the years of experience, are not the signals that actually predict whether a developer will do well on your specific product, in your specific context, with the constraints you are actually working under.
The signals that matter are harder to find in a portfolio and easier to find in a conversation. This post is about what those signals are, how to look for them, and what red flags to watch for when they are absent. It is written for founders who are not technical enough to evaluate code directly but need to make a confident hiring decision anyway.
The goal is not to teach you to think like a developer. It is to teach you to ask the questions that reveal whether a developer thinks like someone who can build your product.
The signals that predict a great developer hire are not in the portfolio. They are in the conversation. The portfolio gets you to the conversation. The conversation is the actual evaluation.
WHAT MOST FOUNDERS GET WRONG
The most common hiring mistake is optimising for technical breadth over product judgment. A developer who knows twelve frameworks is less valuable to an early-stage startup than a developer who deeply understands how to translate a product idea into something users can actually use.
The second most common mistake is treating the portfolio as the evaluation rather than the starting point. A polished portfolio tells you that a developer can build things and present them well. It does not tell you how they make decisions when the requirements are unclear, how they communicate when something goes wrong, or whether they understand your users well enough to make the hundreds of small decisions that building a product requires.
The third mistake is hiring for past experience in your specific technology stack rather than for the thinking patterns that transfer across stacks. A developer who has never used your particular framework but thinks clearly about systems, users, and constraints will outperform a developer who knows the framework but does not think beyond it.
THE SIGNALS THAT ACTUALLY MATTER
They ask about the problem before asking about the solution
The first question a strong developer asks when you describe your product is not what technology you want to use or what features you need built. It is what problem you are solving and for whom.
This distinction reveals something fundamental about how a developer thinks. A developer who jumps immediately to implementation is a technician. A developer who wants to understand the problem first is a product thinker. The technician will build what you specify. The product thinker will tell you when what you specified will not solve the problem you described, before you have spent money building it.
In a first conversation, pay attention to the ratio of questions about your users to questions about your technical requirements. A developer who asks more about your users than your stack is showing you how they will think throughout the entire engagement.
They can explain their decisions, not just their work
When you look at a project in a developer portfolio and ask why they made a particular decision, a strong developer can give you a clear, reasoned answer. Not a defensive one, not a technical one full of jargon, but a clear account of what problem the decision was solving and what the alternatives were.
This matters because the decisions a developer makes on your product will rarely be explained to you unless you ask. The quality of those explanations when you do ask reveals whether the decisions were deliberate or accidental, whether the developer has the self-awareness to know why they did what they did, and whether they can communicate clearly with someone who is not technical.
A developer who says "I used this approach because it was the most maintainable given the expected growth of the feature" is telling you something different from a developer who says "I used this because it is what I know." Both answers might lead to working code. Only one of them tells you what to expect when the next decision has to be made.
Ask why, not what. The what is in the portfolio. The why is what you are actually hiring.
They talk about failure as readily as success
Every developer has built something that did not work the way they intended, made a decision they later regretted, or underestimated the complexity of a problem. How a developer talks about those experiences tells you more about their professional character than anything in their portfolio.
A developer who can describe a past mistake specifically, explain what they learned from it, and describe what they would do differently, is a developer who processes experience into growth. That capacity is what makes someone better over time rather than just more experienced at the same level.
A developer who cannot name a significant mistake, or who frames all past failures as someone else's fault, or whose portfolio contains only successes with no account of difficulty, is showing you that they either lack self-awareness or lack honesty. Neither is a quality you want managing decisions on your product.
They push back on your requirements
This one surprises founders. Surely you want a developer who does what you ask?
You do. But you also want a developer who tells you when what you are asking for will not achieve what you are trying to accomplish. The ability to push back respectfully, to say "I can build that, but have you considered that it might create this problem for your users?" is the difference between a developer who executes and a developer who partners.
A developer who agrees with everything you say in an initial conversation is either very junior, or telling you what you want to hear, or not thinking critically about your product. The first is fine if you account for it. The second two are expensive to discover after the contract starts.
The push back you want is specific and constructive. Not "that is a bad idea" but "if we build it that way, here is what I think will happen, and here is an alternative that might serve your users better." That kind of pushback is a sign of engagement, not difficulty.
They think about what happens after launch
A developer who only thinks about building the feature and not about maintaining it, extending it, and eventually replacing it is thinking about a fraction of the cost you are actually incurring.
In a conversation, ask about a project they have maintained over time rather than just built. Ask what changed after the initial launch and how they handled it. Ask what they would build differently if they were starting it again today. These questions reveal whether a developer thinks about the full lifecycle of what they build or only the exciting part at the beginning.
Startups frequently make the mistake of hiring for speed and paying for it in maintenance costs, rewrite costs, and the compounding technical debt that accumulates when nobody thought past the launch date. A developer who talks about long-term maintainability without being prompted is telling you they have thought about this before.
THE RED FLAGS THAT ARE EASY TO MISS
They cannot estimate with confidence
Every project involves estimation. A developer who cannot give you a reasoned estimate, even a rough one with explicit uncertainty, is either too junior to have developed that skill or unwilling to commit to accountability. Neither is comfortable in an engagement where your timeline and budget are real constraints.
The estimate you want is not a promise. It is a reasoned best guess with explicit assumptions: "Based on what you have described, I think this is a four to six week project, assuming the design is settled before development starts and the API integration does not surface unexpected complexity." That kind of estimate tells you the developer has thought about the work, understands what could go wrong, and is being honest about uncertainty rather than telling you what you want to hear.
Their portfolio has no explanation of decisions
A portfolio full of finished products with no account of why decisions were made is a portfolio designed to impress rather than inform. It tells you the developer can build things that look good. It tells you nothing about how they think.
The portfolios that should give you confidence are the ones that include case studies: honest accounts of the problem, the approach, the decisions that were made and why, and what was learned. A developer who writes about their work that way is a developer who reflects on what they build, which is the quality that produces improvement over time.
They focus on technology rather than outcomes
Pay attention to how a developer describes their own work. A developer who leads with outcomes, "I built a system that reduced checkout drop-off by making the payment flow work across three providers" is thinking about impact. A developer who leads with technology, "I built a Next.js application with a .NET backend using Entity Framework Core" is thinking about their own skills.
Both are describing the same work. Only one of them is describing it in a way that reveals they understand what the work was actually for.
WHAT TO ASK IN THE FIRST CONVERSATION
These are not trick questions. They are genuine questions that reveal genuine things.
Tell me about a project that did not go the way you planned. What happened and what did you do?
When you look at your most recent project, what would you build differently if you started today?
If I described my product to you and you thought my approach was wrong, what would you do?
How do you decide what to build first when everything feels urgent?
What does a successful engagement look like to you at the end of three months?
None of these questions require technical knowledge to evaluate. What you are listening for is clarity of thinking, honesty about difficulty, evidence of product thinking, and the kind of professional self-awareness that predicts reliable behaviour over time.
A developer who answers these questions well and whose portfolio reflects the kind of thinking described in this post is a developer worth engaging seriously. The technology they know is secondary to how they think about using it.
THE HIRING DECISION THAT ACTUALLY MATTERS
The most important question you are answering when you hire a developer is not: can this person build what I need? Assume yes. The more important question is: will I trust this person with the decisions I cannot make myself?
Because that is what you are actually doing when you hire a developer. You are delegating hundreds of decisions you will never see, made under constraints you will not always be aware of, with consequences that will shape your product for months or years. The technical skill executes those decisions. The judgment, communication, and product thinking determine whether they are the right decisions.
Hire for judgment first. The technical skill is easier to verify and easier to find. The judgment is rarer and harder to see, which is exactly why most founders miss it.
CLOSING THOUGHT
The developer who is right for your startup is not the one with the most impressive portfolio or the longest technology list. It is the one who asks the best questions about your users before asking about your stack, who can account honestly for their past decisions including the ones that did not work, and who thinks about your product rather than just your specification. Those qualities are findable in a first conversation if you know what to look for. Now you do.
If you are currently looking for a full-stack developer who leads with product thinking, handles design and engineering end to end, and communicates the way this post describes, tell me about what you are building.