Most people hiring a developer for the first time ask about availability, price, and whether they've done something similar before. Those are fine questions, but they don't tell you much about whether working with this person will go well.

The questions that matter reveal how someone thinks, how they communicate, and how they handle the situations that make or break a project. Here's what to ask.

About their process

"Walk me through how you handle a project from kickoff to launch."

A developer with experience has a process. They know what information they need upfront, how they handle feedback cycles, how they manage scope, and what they do when requirements change. A developer without a clear answer to this question is likely learning on your project.

You're not looking for a specific methodology — you're looking for evidence that they've done this enough times to have learned what works.

"What typically causes projects to go over budget or timeline, and how do you handle it?"

This question has a few good answers: unclear requirements, scope creep, delayed content from the client, unforeseen technical complexity. A developer who gives you a thoughtful answer is being honest about the real dynamics of projects. One who says "that doesn't usually happen to me" is either inexperienced or not being straight with you.

About their technical approach

"What technology would you use for this project, and why?"

You don't need to evaluate the technical answer — you need to evaluate whether they give one. A developer who recommends a specific approach and can explain why it fits your situation is thinking about your project. One who defaults to "whatever you want" or names their preferred stack regardless of your needs is not.

If they recommend something that sounds surprising, ask them to explain the tradeoff. The explanation matters more than the recommendation.

"What would you not do yourself on this project?"

Good developers know the edges of their expertise. If your project needs specific skills — database performance at scale, mobile app development, email deliverability work — someone who doesn't specialize in those areas should say so. "I can do the core build, but for the payment integration you'd want someone who does that regularly" is the honest answer. "I can handle everything" is the one to be suspicious of.

About the working relationship

"What do you need from me to keep things on track?"

The answer should include: timely feedback, consolidated reviews, content provided before design begins, access to existing accounts and assets, and a point of contact who can make decisions. If they don't know what they need from you, they haven't thought through where projects get delayed.

"How do you handle it when requirements change mid-project?"

The right answer involves a defined process: scope changes are documented, priced, and approved before work begins. A developer who says "it depends" or "we just figure it out" is someone whose projects expand in cost and timeline without clear communication about why.

"What does your communication look like during a project?"

Frequency, channel, what they'll initiate versus what you'll need to ask for. You want to know: will I be chasing updates, or will I hear from you? There's no single right answer to this — what matters is that the answer is explicit and matches your working style.

About past work

"Tell me about a project that went sideways and how you handled it."

Every experienced developer has a project that didn't go well. What matters is whether they can talk about it honestly — what went wrong, what they'd do differently, what they learned. A developer who can't name a difficult project is either not being honest or hasn't done enough work to have faced real complexity.

The meta-question

How to hire a developer without getting burned ultimately comes down to finding someone who has done this before, can think clearly about your specific situation, and will communicate honestly when something isn't going to plan.

The questions above are designed to surface that. They're not a test — they're a conversation. Good answers come in different forms. What you're looking for is someone who engages with the questions seriously, thinks before answering, and gives you the impression that they care about your project going well.

That combination is rarer than it should be. When you find it, it's worth paying for.

Once you've narrowed the field, revisiting the freelance vs. agency vs. in-house comparison can help you think through the right engagement structure — not just who to hire, but how to hire them.