Skip the Portfolio Screenshots, Ask This Instead
10 questions that reveal whether a developer can actually deliver. What to ask before signing.
A bad developer hire at $100 to $200 per hour adds up fast. Worse is the rework when you discover, eight weeks in, that the person can’t communicate, can’t meet deadlines, or can’t adapt when the product pivots.
According to Toptal’s survey of technology leaders, more than 60% say poor technical hires are a significant drag on project timelines. The solution is not hiring faster. It’s hiring with a clear process.
The gap between a polished pitch and actual capability is wider than most founders realize. Here are the ten questions that cut through it.
Before You Look at a Portfolio
Do you actually need to see live URLs?
A portfolio of screenshots proves almost nothing. Screenshots are static images. They could be lifted from anywhere. What you need is working software you can open and interact with.
Ask for three to five URLs. Open them yourself. Try clicking around. Note whether the UI feels polished or rough. Check whether the product actually solves a problem or just looks like it does on a demo screen.
The critical follow-up: ask which parts of each project the developer owned versus what a team built. Most developers overstate their contribution on shared work. The answer “I built the checkout flow and the admin reporting panel” is a stronger signal than “I was part of the team that built the whole platform.”
Jason Fried of Basecamp put it plainly: “The best engineers I’ve ever worked with can explain their past work at three levels of depth. What it does, why it was built that way, and what they’d do differently now.”
Can you speak to their actual clients?
Past client references are the most underused hiring tool. Most hiring managers ask for references and never call them. Call them.
When you do, ask one specific question: “Did this developer flag problems early, or did you find out about issues when they were already expensive to fix?”
That question separates developers who protect their reputation by communicating hard truths from those who stay quiet and hope problems fix themselves. According to the Project Management Institute, poor communication causes project failure in one in three software projects. A developer who communicates well is worth more than one who codes faster.
Understanding What You’re Actually Hiring
What’s their actual specialty?
There are generalists and specialists. Both have a place, but you need to know which one you’re hiring.
A generalist is valuable for early-stage builds where you’re still figuring out what the product needs to be. A specialist is what you need when you have a specific technical problem. Real-time data processing. Payment gateway integration. HIPAA-compliant storage. You need someone who’s solved it before.
The failure mode is hiring a generalist for a specialist problem and paying for their education. Ask directly: “Have you built this specific thing before? What was the outcome?” Listen for whether they can describe a concrete past example or whether they’re saying “I can learn it.”
What do they know about your platform choice?
Mobile development is not one choice. iOS and Android native development require separate codebases and separate expertise. Cross-platform frameworks like React Native and Flutter share code but carry trade-offs on device-specific features and complex animations.
The right answer depends on your product, your users, and your maintenance budget. What matters is whether the developer can articulate those trade-offs clearly and without trying to sell you on one solution. A developer who says “React Native is always the right choice” is not being straight with you.
Ask: “What’s a case where you’d recommend native over cross-platform?” A developer who can answer that with a specific example understands your project’s actual constraints, not just their preference.
How They Actually Work
Do they have a system for deadlines?
This is not a question about work ethic. It’s a question about process.
Strong developers have a system. They break work into defined chunks. They track progress against milestones. They flag blockers the same day they appear. They don’t disappear for two weeks and resurface with a partially built feature.
Get RaftLabs’s stories in your inbox
Join Medium for free to get updates from this writer.
Ask about their last project. How many milestones were hit on time? What caused the ones that weren’t? How did they communicate the delay? Specifics separate real process from a polished answer.
How do they debug?
Every developer hits a wall. The question is what they do there.
Good developers describe the debugging process with detail: what they ruled out, who they asked, what they eventually found. They’re not embarrassed by the struggle. They’re methodical about it. Developers who say “I always figure it out” are either lying or haven’t worked on systems complex enough to break in non-obvious ways. That’s a risk on any project with real technical complexity.
Ask them to walk through a specific bug they couldn’t fix for more than 24 hours. Listen for the process.
How do they respond to failure?
This question is a character screen more than a technical one.
Ask them to describe a project that failed. Strong developers name a specific failure, explain the root cause honestly, and describe what changed in their process afterward. “We underestimated the complexity of the data migration and it pushed the launch by three weeks. I now always scope data migration separately and do a dry run before go-live.” That’s a developer who learns.
Vague answers like “we had some challenges as a team” signal a lack of ownership. In software, someone is always responsible for a decision that led to a failure. A developer who can’t name their own role in a past failure will struggle to own problems in your project.
Before You Start Building
What’s their approach to testing?
Testing is where corners get cut when deadlines tighten.
Ask directly: “What’s your test coverage approach for a new feature?” and “When do you decide a feature is ready to ship?”
Strong developers can describe their testing process at each layer. Unit tests for business logic. Integration tests for connected systems. Manual testing for user flows. They can tell you the difference between a smoke test and regression test. They have an opinion on what “done” means before a feature goes to production.
Developers who say “testing slows me down” will ship bugs to your users and expect you to find them.
How will you stay in sync?
Communication structure is not a soft concern. It’s a delivery mechanism.
Ask for specifics: What does a typical status update look like? How often? Where? What happens if a blocker appears at 4pm on a Friday? Is there a shared project management tool where you can see task progress without asking?
A professional developer answers these questions before you ship. They have a default communication structure, not because you asked, but because they’ve seen what happens when they don’t.
Frederick Brooks said it best in The Mythical Man-Month: “Transparency is not just a communication style. It’s a delivery practice. Teams that share bad news early fix it cheaply. Teams that hide it fix it expensively.”
If the answer is “I’ll update you when there’s something to show,” that’s a red flag. No news in software development is usually bad news.
What happens after launch?
Production bugs are inevitable. The question is whether you have a developer on the line when they appear.
Your contract should specify response time for production bugs, what counts as a bug versus a new feature request, pricing for ongoing maintenance, and how they handle compatibility issues when a major iOS or Android update ships.
Developers who won’t discuss post-launch terms are telling you something. Either they don’t plan to be available, or they’ve had enough post-launch disputes that they’re avoiding the topic. Both are problems you want to uncover before you sign. Post-development support terms belong in the contract before work starts. Retroactive support agreements are always more expensive and more contentious.
The Process Matters More Than You Think
Hiring a developer is the first step in building your product. It can go wrong quickly. The difference between a successful hire and a costly mistake is whether you knew what to look for before you started.
The questions above are not about finding the smartest person in the room. They’re about finding the person whose experience, communication, and process actually match your project’s needs. Someone you can work with for 12 weeks without surprises.
If you’re evaluating whether to hire in-house, contract freelancers, or partner with a development team, we’ve written guides on the trade-offs between each model that can help you decide which approach fits your timeline and budget.
Originally published at https://www.raftlabs.com/blog/10-essential-tips-for-hiring-a-software-developer
