10 essential tips for hiring a software developer

Hiring a software developer is one of the most consequential decisions a growing business makes -- and one of the most commonly botched. A bad hire at $100-$200 per hour adds up fast. More costly is the rework when you discover, eight weeks in, that the person can't communicate, can't meet deadlines, or can't adapt when requirements shift.

According to a survey by Toptal, more than 60% of technology leaders report that poor technical hires are a significant drag on project delivery timelines. The fix is not hiring faster -- it's hiring with a clear process.

Here are ten questions and signals that cut through a polished pitch and tell you what you actually need to know.

1. Can I see your portfolio -- with live URLs?

A portfolio of screenshots proves nothing. Screenshots can be lifted from anywhere. What you want is live, working software you can open and use yourself.

Ask for three to five URLs. Visit them. Try to break them. Note whether the UI is polished or rough. Check whether the product actually solves a problem or just looks like it does on a demo screen.

The non-obvious check: ask which parts of each project the developer owned versus what a team built. Most developers overstate their contribution on shared work. A specific answer ("I built the checkout flow and the admin reporting panel") is a better signal than "I was part of the team that built the whole platform."

"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." -- Jason Fried, Co-founder, Basecamp, in Rework (2010)

2. How many clients have you shipped for -- and can I speak to them?

Past client references are the most underused hiring tool. Most businesses 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 one 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 is the primary cause of project failure in one in three software projects. A developer who communicates well is worth more than one who codes fast.

3. What's your area of technical specialty?

There are generalists and specialists. Both have a place -- but you need to know which 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 defined technical problem (real-time data processing, payment gateway integration, HIPAA-compliant storage) and you need someone who's solved it before.

The failure mode is hiring a generalist for a specialist problem. Ask directly: "Have you built this specific thing before? What was the outcome?" If the answer is "I can learn it," that may be true -- but you're paying for their education.

4. Which mobile platforms do you build for -- and what are the trade-offs?

Not all platforms are equal. iOS and Android native development require separate codebases and separate expertise. Cross-platform frameworks like React Native and Flutter share code across platforms 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 you're listening for is whether the developer can articulate those trade-offs clearly and without a sales pitch. 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 question with a specific example understands the actual constraints of your project.

5. How do you manage deadlines -- specifically when something unexpected comes up?

This is not a question about work ethic. This is a question about process.

Strong developers have a system: they break work into defined chunks, track progress against milestones, and flag blockers the same day they appear. They don't disappear for two weeks and resurface with a partially built feature.

Ask for 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.

6. Walk me through a bug you couldn't fix for more than 24 hours.

Every developer hits a wall. The question is what they do there.

Good developers describe the debugging process: what they ruled out, who they asked, what they eventually found. They're not embarrassed by the struggle -- they're methodical about it. They treat debugging as a diagnostic process, not a mystery.

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 second category is a risk on any project with real technical complexity.

7. Tell me about a project that failed. What caused it?

This question is a character screen more than a technical one.

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 ("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.

8. How do you approach 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.

9. How will we communicate during the build?

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. 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.

"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." -- Frederick Brooks, The Mythical Man-Month (1975, Addison-Wesley)

10. Do you offer post-development support -- and what does the contract say?

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.

Hiring a developer is the first step in building your product, and it can go wrong quickly. Know what you want before you start. Know which questions will tell you whether the candidate's experience matches what you actually need.

At RaftLabs, we provide software development services for startups and businesses that need a team that adjusts quickly to changing requirements. If you're evaluating whether to hire in-house or partner with a firm, we're happy to walk you through the trade-offs.