Interview Questions to Ask a Developer Before Hiring (2026 Guide)

Interviewing a developer when you cannot judge their code feels like guessing. It does not have to be. This guide is for non-technical founders and managers about to interview a freelance or remote developer. It gives you 15 questions grouped by what they reveal, what a good answer sounds like, the red flags, and how to confirm that the person on the call is the person who will do the work.

What you are actually trying to learn

You are not checking whether they know every framework. You are answering three questions:

• Can they build it? Have they shipped something comparable, and can they explain how?
• Will they communicate? Will you know where the project stands without chasing?
• Will they tell you bad news early? Every project hits problems. The developers worth hiring raise them while there is still time to act.

The questions below are built around those three, plus the practical terms you need agreed before day one.

15 questions, with good answers and red flags

Can they build it?

1. "Walk me through something you built that is similar to this. What was your part?" Good: specific screens, decisions and problems, with a clear line between their work and the team's. Red flag: only "we", and the detail runs out when you ask a follow-up.
2. "Looking at my project, what would you build first, and what would you leave out?" Good: they ask questions back and suggest a smaller first version. Red flag: they agree to everything and quote a price before asking anything.
3. "Which tools would you use for this, and why?" Good: reasons tied to your situation, such as budget, speed or how easy it will be to hire the next developer. Red flag: "it is the best" with no reason, or a choice only they seem to know.
4. "Tell me about the hardest bug you fixed recently. How did you find it?" Good: a step-by-step story. Red flag: a vague answer, or blaming someone else.
5. "How do you check your work before you tell me it is done?" Good: testing as they go, automated tests where they help, a test site you can use. Red flag: "I just make sure it works."

Will they communicate?

1. "What would a weekly update from you look like?" Good: done, next, blocked, and anything they need from you. Red flag: "I'll let you know when it's finished."
2. "If something I ask for is unclear, what do you do?" Good: they ask, then write back what they understood before building. Red flag: they guess and fix it later.
3. "Which hours are you online, and how fast do you usually reply?" Good: specific hours and an honest reply time. Red flag: "always available", which nobody is.
4. "Explain one technical decision from a past project as if I were a customer." Good: plain words, and they check you followed. Red flag: jargon, or impatience when you ask again.

Will they tell you bad news early?

1. "Tell me about a project that ran late. When did you tell the client?" Good: they flagged it as soon as they saw it, with a revised plan. Red flag: they have never been late, or they told the client on the deadline.
2. "What would make you tell me this project will cost more than I expect?" Good: named risks, such as unclear requirements or third-party services. Red flag: no risks at all.
3. "What kind of work do you turn down?" Good: a clear answer about their limits. Red flag: they take on everything.
4. "If you find a bug in your own work after I have paid, what happens?" Good: they fix their own mistakes within an agreed period. Red flag: every fix is billable from day one.

Working terms

1. "Where will the code live, and when do I get access?" Good: in your repository, or shared with you, from early on. Red flag: you see nothing until the end.
2. "How would you split this into milestones and payments?" Good: small, testable stages with a payment each. Red flag: most of the money upfront.

You are not testing whether they know everything. You are testing whether they will tell you when they do not.

Judging technical depth without being technical

You can get a long way without reading code.

• Ask about past work, then go two levels down. "Why did you do it that way?" then "What would you change now?" People who did the work have answers. People repeating a portfolio do not.
• Run a paid trial. A small, real task of a few days tells you more than any interview. Our guide to paid trial projects covers how to set one up.
• Get a second opinion. Pay an experienced developer for an hour or two to review the trial code or join the final call. It is cheap compared with a bad hire.

Check the person on the call does the work

Proxy interviews and AI-scripted answers are a real problem in remote hiring. Keep cameras on. Ask follow-ups that are not in any script, such as "what broke first on that project?" Ask them to share their screen and open a project they built. Make sure the person on the trial is the person you interviewed, and that the name on the contract matches the person you pay. On DevDey, look for the DevDey Verified badge, which means the person passed an interview and an identity check. For more, read our guide on vetting remote developers and spotting interview fraud.

Find developers to interview

You can browse developer profiles on DevDey without an account, or post a job for free and let MAAVIS rank profiles against it. Message candidates in the app, then pay whoever you hire directly. DevDey takes no commission. If this is your first technical hire, read hiring your first developer as a non-technical founder.