What to ask a full stack developer before you hire one
Marketplace hiring guides are written to get you to a hire fast: an average hourly rate, a 48 hour turnaround, a checklist of frameworks. Speed of placement is what they optimise, not whether the project survives its first year. The skills a full stack developer actually needs, the questions that show whether someone can own a system from architecture to handover, and what a good answer sounds like.
Six months after the hire, the product works. Customers use it. Then the developer takes a full-time job, and the person you hire next spends their first week trying to deploy it. There is no README, the production database is on the old developer's personal cloud account, the payment webhook has been failing silently since August, and nobody can say which of the four environment files is the real one. Nothing about the original hire was wrong on paper. The developer was skilled, fast and pleasant to work with. You just never asked the questions that would have shown whether they could own the thing, as well as build it.
Search for how to hire a full stack developer and the results are marketplace guides, quoting average rates around $73 an hour and hires inside 24 to 48 hours. That is what a marketplace is built for: placement, quickly. It is a good model for some work, and I will come back to which. But a guide written to shorten the time to hire has no reason to ask what happens a year later, and a year later is where most of the cost of a bad hire lives.
What full stack actually has to cover
Most job posts and marketplace profiles describe full stack as a frontend framework plus a backend framework. That is the part that is easiest to evaluate and least likely to sink the project. The skills that matter are the layers between and around them:
| Layer | What owning it means | What it looks like when nobody did |
|---|---|---|
| Interface | Components, state, accessibility, performance on a slow phone | Rarely the problem. Usually the best-built part |
| API and business logic | Validation, clear boundaries, consistent errors | Logic duplicated between the browser and the server, disagreeing |
| Data model | Tables that match the business, migrations, constraints | A schema nobody can change without breaking a report |
| Authorisation | Who can see and change what, checked on the server | Buttons hidden in the UI, endpoints open to anyone who asks |
| Background work | Queues, retries, idempotency, failure alerts | Emails sent twice, payments recorded never |
| Deployment | Repeatable deploys, environments, rollback | One person who knows how to release, from their laptop |
| Monitoring | Errors, logs and alerts someone actually reads | Customers report outages before you know about them |
| Security | Secrets, dependencies, input handling, backups | Keys in the repository, backups never restored |
| Handover | Documentation, owned accounts, a codebase someone else can run | The next developer starts by reverse-engineering the last one |
You do not need a developer who is expert in every row. You need one who knows every row exists, has made decisions in each, and can tell you which ones they would want help with.
The questions, and what a good answer sounds like
The useful questions are about consequences, not tools. Anyone can list frameworks. What separates people is what they did when something went wrong, and whether they planned for it before it did.
Architecture
- Walk me through the data model of something you built. What would you change? A good answer names a real regret and what it cost: a column that should have been a table, a status that should have been a history. A developer who regrets nothing either has not maintained anything for long or has not looked.
- Where does authorisation live in your last project? You want a specific place: a policy layer, a scoped query, a middleware with a test. We hide it in the UI or a long pause is the answer that leads to a data breach. The plumbing AI gets wrong shows what this looks like in a real codebase.
- What happens when a background job fails halfway through? Listen for retries, idempotency, and how they would find out. If the honest answer is that it would fail silently, you have learned something important for the price of one question.
Delivery
- Tell me about an estimate you got wrong. Everyone has one. A good answer explains what they missed and what they do differently now. An answer of I am always on time is a warning, not a reassurance.
- What would you cut from my scope? This is the most revealing question on the list. A developer who can own a product will push back, because they have seen which features eat the budget. One who agrees to everything is optimising for winning the job, and you will pay for it in month three. What a SaaS MVP actually costs shows what a reasonable cut looks like.
- How will I know where the project is each week? You want something concrete: a deployed staging site, a short written update, a board you can see. Not a promise to check in.
Production
- How did you deploy the last thing you built, and how do you roll it back? Good answers describe a pipeline and a rollback they have actually used. A manual upload from their machine is fine for a prototype and a risk for anything with paying users.
- How would you know it broke at three in the morning? Error tracking, alerts, a health check, and who receives them. The client would tell me means the customers will tell the client first.
- When did you last restore a backup? Not take one: restore one. Most developers have never done it, and the ones who have will tell you what surprised them.
Handover
- If you disappeared tomorrow, what would the next developer find? Listen for a README that gets someone running locally, documented environment variables, decisions written down, and tests that describe behaviour. This is the question the opening story needed.
- Whose accounts will everything live on? The right answer is yours: your repository, your cloud account, your domain, your payment and email providers, with the developer invited as a user. Anything else makes the developer a dependency however good the code is.
- How do you use AI coding tools, and how do you review what they write? Almost everyone uses them now, and that is fine. What matters is the review: tests that the agent cannot edit, small changes, and someone who reads the code that touches money and permissions. Harness engineering covers what that looks like done properly.
A paid trial beats a whiteboard
Interviews test how someone talks about work. A short paid trial tests the work. Give them one to three days on a task shaped like your project, in a repository you own, and pay for it properly. Then judge more than whether the feature works:
- 1The questions they asked before starting. A good developer finds the ambiguity in your brief on the first day, not the last.
- 2How the work is split. Small commits with clear messages, or one large change at the end.
- 3The pull request description. Does it say what changed, why, how to test it and what was left out?
- 4The tests. Not how many, but whether they would fail if the feature broke.
- 5What they did not finish, and how they told you. Everyone runs out of time on a trial. How they report it is how they will report it on the real project.
Red flags worth walking away from
- Wants production credentials before there is a contract, or wants to host the project on their own accounts.
- Quotes a fixed price without asking what the product does, who uses it or what it connects to.
- Cannot show anything they built that is still running, or anything they handed over to someone else.
- Agrees with every feature and every deadline in the first call.
- Talks about frameworks with enthusiasm and about testing, deployment and monitoring not at all.
When the marketplace is the right call
None of this means marketplaces are wrong. For a bug fix, a landing page change, a well-specified integration or a few days of extra hands on a codebase someone else owns, fast placement is exactly what you want and the vetting above is more than the job needs. The questions matter when the person you hire will make decisions you will live with: the data model, the permissions, the deployment, and what happens when they leave.
What to prepare before you ask
The questions work better when the developer has something real to respond to. Before the first call, write down what you are building, where it is now, a rough budget range, the deadline and what drives it, the existing stack and who else is involved. A good developer will use that to ask better questions back, and you will learn as much from their questions as from their answers.
Hire for what happens after the first version ships. Building the first version is the part almost everyone can do.
If you are hiring for a product that someone has to own, from architecture through launch to a clean handover, ask me the questions above. I will answer them with real projects, and you can see what I have built and still support on the work page. Check availability and book a call.
Questions people ask
What skills does a full stack developer need?
Beyond a frontend framework and a backend language, a full stack developer who can own a product needs data modelling, authorisation, background jobs and failure handling, deployment and rollback, monitoring, basic security, and the ability to hand the system over. The framework is the easiest part to learn. The other layers are where projects built by capable feature developers usually fail in their first year.
What questions should I ask before hiring a full stack developer?
Ask them to walk through the data model of something they built and what they would change, where authorisation lives in their last project, what happens when a background job fails halfway, how they deploy and roll back, how they would know production broke at night, what they would cut from your scope, and what the next developer would find if they left tomorrow.
Should I hire a developer from a freelance marketplace?
For small, well-defined work, such as a bug fix, a landing page change or an integration with a clear specification, a marketplace is often the better tool because it is fast and the risk is small. For a product someone has to own for months, the speed of placement matters much less than whether the person can design, deploy, monitor and hand over the whole system.
How do I test a developer before hiring them?
Pay for a short trial of one to three days on a task shaped like your real work, in a repository you own. Judge the questions they ask before starting, how the work is split into commits, the pull request description, the tests, and how they report what they did not finish. Those show how the next six months will go far better than a whiteboard exercise.
Building something like this?
I design and ship these systems for clients: retrieval over private data, agents that complete real tasks, and the Laravel platforms underneath them.