27 Questions to Ask a Developer Before Hiring (and the Answers to Listen For)

The best questions to ask a developer before hiring are about who writes the code, how you'll see progress, what the price covers and who owns the result. Programming languages matter less than most people think. Below are 27 questions you can use on a first call, each with what a good answer sounds like and the red flag to listen for.

I'm a freelance developer based in Denmark, so these are questions I get asked myself. Read the list with that in mind, and feel free to use it on me. I've also included the questions that matter when your developer works from another country, which is routine when you hire within Europe.

The short answer: five questions for a 20-minute call

Ask these on a video call rather than sending them as a questionnaire. How a developer answers tells you as much as the answer itself: does it get specific, or does it drift into generalities?

The questions work for freelancers and agencies alike, and the answers will also help you decide whether a freelancer or an agency fits your project. If you're just getting started, read my complete guide to hiring a developer first and come back when you have two or three candidates.

Experience and fit

1. Who will actually write the code?

At an agency, the salesperson, the project manager and the developer can be three different people. Some freelancers subcontract parts of the work too. Neither is wrong in itself, but you need to know.

Good answer: The name of the person or people writing the code, and an offer to meet them. If subcontractors are involved, you hear about it without having to ask twice. My own answer is short: it's me, and I'm also the one you talk to.

Red flag: "Our team," and you never meet anyone but the salesperson.

2. What have you built that's similar to my project, and what was your role?

Good answer: A specific project, ideally one you can see or try, and an honest account of what the developer did and what others handled.

Red flag: Polished screenshots with no explanation, or a role that gets vaguer the more you ask.

3. What was the hardest part of that project?

This question separates people who have done the work from people who have read about it.

Good answer: A concrete problem, such as a third-party API that didn't behave as documented, and what they would do differently today.

Red flag: "It all went pretty smoothly." Projects almost never do.

4. Which tech stack would you use, and why does it fit my project?

Most developers have a preferred toolkit. That's how people get good. What you're listening for is the reasoning.

Good answer: The choice is tied to your situation: maintenance, hosting and how easy it will be to find another developer later. Mainstream frameworks like Laravel, React and Next.js make you less dependent on one person. I work with exactly those, so weigh my opinion accordingly.

Red flag: A homegrown framework only they understand, or jargon that doesn't get explained when you ask.

5. What would you advise me not to build?

Good answer: A suggestion to cut something from the first version, or to use an existing service for part of it. That shows they're thinking about your business and your budget.

Red flag: Yes to everything. A developer who never says no on the first call rarely speaks up when the budget is about to run away.

6. Can I speak to two past clients?

Good answer: Yes, with names and contact details within a few days. To make that call worth your time, use these questions for a developer's references.

Red flag: Only testimonials on their website, or an NDA as the reason for every single project.

Process and communication

7. What do the first two weeks look like?

Good answer: A concrete plan: a kickoff call, access to the systems involved, agreement on the first tasks and something you can see and click through soon after.

Red flag: "We'll just get started." No plan for the start usually means no plan for the rest.

8. How often will I see working software?

Good answer: Ongoing access to a staging environment (a private test version of your site or app) and a short demo every week or two.

Red flag: You see the result at handover. That's when misunderstandings are most expensive to fix.

9. What hours do you work, and how much overlap will we have?

This matters more than people expect when you hire across borders.

Good answer: Specific working hours, a fixed window of overlap with your team and a response time you can hold them to. I'm on Central European Time, so my working day lines up with UK and EU business hours, and I reply within one business day.

Red flag: "I'm always available." That doesn't last, and it usually means nothing has been agreed.

10. How many clients are you working with right now?

Good answer: An honest number and an explanation of how their time is split, for example fixed days each week for your project.

Red flag: A dodge. You risk getting whatever hours are left once the other clients are happy.

11. What do you need from me?

Good answer: A list: one person who can make decisions, content and copy, access to existing systems and answers to questions within an agreed number of days.

Red flag: "Nothing, I'll handle it all." Then they'll be guessing how your business works.

12. How do you handle changes mid-project?

Every project changes. What matters is whether there's a set way to deal with it.

Good answer: The change is described, priced and approved in writing before anyone works on it.

Red flag: "We'll figure it out." That tends to end in a surprise invoice or an argument about what was agreed.

13. What do you do when something takes longer than planned?

Good answer: They tell you as soon as they know, with options: cut something, move a deadline or increase the budget.

Red flag: It has never happened to them. Either they've done very few projects, or they aren't telling you the whole story.

Cost, estimates and contract

14. Fixed price or hourly, and why for this project?

Good answer: A reason. A fixed price suits a well-defined piece of work, while hourly or day-rate billing suits ongoing development where the details shift. Many developers combine the two: a fixed price for a defined phase, then hourly.

Red flag: A fixed price on a large project after a 30-minute chat and no follow-up questions. Either there's a big buffer baked in, or every deviation becomes an extra invoice.

15. What isn't included in the price?

Good answer: A specific list: hosting, licenses, payment provider and other third-party services, copy and images, plus maintenance after launch.

Red flag: "Everything's included." It never is.

16. How confident are you in this estimate?

Good answer: A range rather than a single number, and an explanation of where the uncertainty sits. For larger projects, a suggestion to start with a short, paid discovery phase that turns the estimate into something you can budget against. That's how I work myself: larger builds start with a fixed-price discovery phase.

Red flag: An exact figure, down to the euro, for a project that has only been described loosely.

17. Which currency do you invoice in, and how is VAT handled?

This is the question people forget when the developer is in another country.

Good answer: A clear answer on currency (often EUR within Europe), payment terms and VAT. For B2B services between two EU countries, the supplier usually doesn't charge VAT, and the customer pays it under the reverse-charge procedure. Check the details for your company with your accountant.

Red flag: Vague answers about invoicing, or a request for the full amount up front.

18. What happens if we stop halfway, and which law governs the contract?

Good answer: You pay for completed work and get the code, documentation and access straight away. There's a reasonable notice period, and the contract states which country's law applies. My freelance developer contract checklist covers what else it should include.

Red flag: No written contract, or code held back until the entire project is paid for.

19. Do you carry professional indemnity insurance?

Not every small job needs it, but if the software is business-critical or handles payments, it's a fair question.

Good answer: They know what cover they have and what it includes, and they can send proof.

Red flag: They've never thought about it, or they get irritated that you asked.

Code, quality and ownership

20. Who owns the code, and where does it live?

Good answer: You own it, and it lives in your own repository (the archive that holds the code and its history, for example on GitHub) from day one. The developer has access, but you hold the keys. That's how I work, and it should be in the contract too.

Red flag: The code sits in the developer's personal account and will be "transferred when the project is done."

21. How do you test that it works?

Good answer: Automated tests for the critical parts, such as login and payments, and a staging environment where changes are checked before they go live. The level of testing should match the budget, and they can explain why.

Red flag: "I click through it myself," for a system your business depends on.

22. How do you document things so someone else can take over?

Good answer: A setup guide, a short record of the key decisions and every login and access level in one place.

Red flag: "The code documents itself." Clean code helps, but it won't tell anyone why things are the way they are or where the server lives.

23. How do you handle security and personal data?

Good answer: Specific answers about updates, access control, backups and where data is hosted (ideally in the EU if your users are). If the developer processes personal data on your behalf, GDPR requires a written contract between you as controller and them as processor, usually called a data processing agreement (DPA).

Red flag: "The hosting company takes care of that."

24. Do you use AI coding tools, and how do you check the output?

Good answer: Openness about which tools they use, a human review of all code before it ships and a clear rule that your confidential data doesn't go into those tools without your agreement.

Red flag: They can't explain the code they deliver. AI tools are fine, but whoever hands over the code still has to stand behind it.

After launch

25. What happens in the first month after launch?

Good answer: An agreed period for fixing bugs, monitoring of errors and downtime, and a plan for the first round of adjustments.

Red flag: "Then it's done." The first month with real users almost always turns up something to fix.

26. What will hosting and maintenance cost per year?

Good answer: A rough range and what it covers: hosting, security updates, monitoring and small fixes. Ideally as a fixed monthly agreement, so you don't need a new quote every time.

Red flag: "It just runs." Frameworks and the packages your code depends on need regular updates, or security holes appear.

27. What does a handover look like if I want to move to someone else?

Good answer: A calm answer covering access, documentation and a call with the new developer. If you're already in that situation, here's how to switch developers mid-project without losing your work.

Red flag: They get defensive. A good developer sets things up so you can leave whenever you want.

Next steps: turning answers into a decision

All 27 questions in one call is too many. Here's how to use the list in practice:

1. Pick the 10-15 questions that matter most for your project, starting with the five in the table above. If your developer is in another country, add questions 9, 17 and 18.
2. Ask two or three candidates the same questions, and write the answers down right after each call.
3. Get the important answers in writing: price, exclusions, code ownership, notice period and governing law.
4. Call the references before you sign.

The answers that should make you walk away are collected in 15 red flags when hiring a developer.

The answers might also tell you not to hire someone like me. If you need a full-time developer for years, hire one. If design, copy and development all have to happen at once, an agency is often the better fit. To see what kind of work I take on and how I approach it, have a look at my services as a freelance developer in Europe.

Frequently asked questions

How many developers should I interview before choosing?+

Two or three is usually enough. With fewer, you have nothing to compare against, and with more it gets hard to remember who said what. For a small job, such as a single integration or a handful of fixes, one thorough call and a reference check can be enough, so the hiring process doesn't take longer than the work itself.

Should I send these questions before the call?+

Send a short project description instead of the full list. The questions work best live, because you can hear whether the answers are specific or rehearsed. A one or two page brief does make the call more useful, though: the developer can prepare questions about your project, and the questions they ask tell you something about their experience too.

What if I don't understand the technical answers?+

Ask the developer to explain it again in plain language. A good developer can explain stack choices, testing and security without jargon, and that's a good sign in itself. On a larger project, paying an independent developer for a couple of hours to review the proposals is cheap compared to choosing the wrong person.

Does it matter where in Europe the developer is based?+

Less than you might think for the code itself, but location affects time zone overlap, how invoicing and VAT work, and which country's law governs the contract. Language can matter too if the developer writes user-facing text. Agree on the first three in writing before you start, and distance rarely becomes a problem.