Full Stack Developer Interview Questions and Scorecard
Full stack developer interview questions for employers hiring without an HR department: 6 sets, good-answer notes, a work sample brief, and a scorecard.
Full Stack Developer Interview Questions and Scorecard
Six question sets for employers running the interview themselves: end-to-end feature ownership, front end, back end and data, security and deployment, a paid work sample brief, and a scorecard with a balance check. Download as DOCX.
The hardest part of hiring a full stack developer is not writing the questions. It is knowing whether the answers were any good. Most owners making this hire have never written code, and almost every question list online is written for the candidate rehearsing answers, not for the employer trying to decide.
At FirstHR, we build for small businesses that hire without an HR department, where the founder runs the interview alone and the developer they pick will probably be the only engineer in the company. This page is written from that side of the table. Every question comes with the reason it is worth asking and what a strong answer contains.
You get six downloadable sets: end-to-end feature ownership, front end depth, back end and data, security and deployment, a paid work sample brief, and a scorecard with a red flag checklist. Pair them with the full stack developer job description you posted, and browse the rest of the hiring templates when you need the surrounding paperwork.
TL;DR
Interview a full stack developer on four things: whether they can narrate one feature end to end across database, server, and browser; depth in each half separately; security, deployment, and tested backups if they will be your only engineer; and judgment on buy versus build, prioritization, and handover. Score both halves apart and compare them. A large gap means you found a specialist, not a full stack developer.
What a Full Stack Developer Actually Owns
A full stack developer owns the entire path a request takes: the interface the customer touches in the browser, the server code and API behind it, the database underneath that, and usually the deployment that puts all three online. The title is a claim about breadth, not about seniority.
That breadth is why small businesses hire the role. Splitting the work between a front end developer and a back end developer only pays off once there is enough work to keep both busy. Below that line, one person who can carry a feature from the table to the screen ships more than two who each wait on the other.
It also means the interview has to cover more ground than a specialist interview, without turning into a trivia contest across five technologies. The sets on this page solve that by testing the seams: the places where the halves meet, where a candidate who only really knows one of them will show it.
Telling a Real Full Stack Developer From a Specialist
The fastest test is a single question: ask the candidate to walk you through one feature they built end to end, from the database table to the button the customer clicks. A real full stack developer tells a story with all three layers in it. A specialist tells a detailed story about one layer and goes quiet or vague about the rest.
Listen for the grammar as much as the content. Strong candidates say I designed the table, I wrote the endpoint, I built the form. Candidates who worked next to the other half tend to slip into passive voice at exactly the moment they leave their own territory: the API was provided, the database was already set up. That shift is the tell, and you do not need to understand the technology to hear it.
The distinction is commercial, not semantic. Many candidates who call themselves full stack are strong in the browser and adequate on the server, because that is the more common path into the work. Hiring one of them for a role that holds payments or customer records means you have bought half the coverage you thought you were buying.
What the role must cover
Front end specialist
Full stack developer
Builds the interface the customer uses
Designs database tables and queries
Builds and versions an API
Deploys and rolls back a release
Can be the only engineer in the company
Score the two halves separately and compare them, which is what the balance check in the downloadable scorecard is for. If one score is a 4 or 5 and the other is a 1 or 2, hire the person for what they actually are and plan for the missing half.
Which Question Sets Should You Use?
Use the end-to-end set with every candidate, then add the sets that match your risk. If the developer will be your only engineer, the security and deployment set is not optional. If you are hiring into an existing team, weight the half where the team is thinnest.
End-to-End Feature
Use with everyone
The set that separates a real full stack developer from a specialist: one feature narrated from the database table to the button the customer clicks.
Front End Depth
The browser half
Framework judgment, mobile performance, browser versus server validation, accessibility, and state. Judgment over pixel taste.
Back End and Data
Where mistakes cost money
Data modeling, APIs, background jobs, third-party failure, live migrations, and never charging a customer twice.
Security and Reliability
Your only engineer
Secrets handling, deploys and rollback, monitoring, tested backups, and what they would fix first in your setup.
Work Sample and Ownership
Beats a whiteboard
A paid three-to-five-hour brief every finalist gets, plus buy-versus-build, prioritization, documentation, and handover questions.
Scorecard and Red Flags
Score, do not guess
Eight scoring areas, a front-end-versus-back-end balance check, and a ten-item red flag checklist. The asset most question lists skip.
Match the Sets to Your Actual Risk
Your only engineer, owning everything: End-to-End plus Back End plus Security, then the Work Sample. Joining an existing team: End-to-End plus whichever half the team is short on. A customer-facing product with payments or personal data: weight Back End and Security heavily and treat a weak answer there as disqualifying. Short on time: run End-to-End as a 30 minute screen, then send the Work Sample to whoever survives. Use the Scorecard with all of them.
6 Free Question Sets to Download
Download all six as one Word document or copy the sets individually. Each set lists the questions, the reason each one is worth asking, what a strong answer contains, what a weak one sounds like, and space for notes. Ask the same core questions of every candidate.
Download All 6 Full Stack Developer Question Sets
End-to-end, front end, back end and data, security and deployment, a paid work sample brief, and a scorecard with red flags. All in one DOCX.
Set 1: End-to-End Feature Questions
The set to use with everyone. One feature narrated from the database table to the button the customer clicks, plus debugging method and what happened the last time something broke in production.
End-to-End Feature Questions
FULL STACK DEVELOPER INTERVIEW: END-TO-END FEATURE OWNERSHIP
Candidate: __
Interviewer: __
Date: __
Use this set with every candidate. It is the one that separates a real full
stack developer from a specialist who has touched the other half once.
QUESTIONS TO ASK
1. Walk me through one feature you built end to end, from the database table
to the button the customer clicks.
Why ask it: a full stack hire is paid for the whole path, not one layer.
The story either has a database, a server, and a browser in it, or it does
not, and you will hear the gap immediately.
2. A page is loading slowly. How do you find out whether the problem is the
browser, the server, or the database?
Why ask it: this is the single most common real production question, and
it forces the candidate to reason across all three layers at once.
3. How do you decide what runs in the browser and what has to run on the
server?
Why ask it: the boundary is where security and performance mistakes live.
Anyone who owns both sides should have a clear rule for drawing it.
4. You change an API. How do you keep the front end from breaking?
Why ask it: solo full stack developers break their own contracts more than
they break anyone else’s. Listen for versioning, staged rollout, or tests.
5. A customer reports a bug you cannot reproduce. Walk me through your first
hour.
Why ask it: debugging method matters more than trivia for a small team.
6. Tell me about something you shipped that broke in production. What did you
do in the first ten minutes, and what changed afterward?
Why ask it: the follow-up answer tells you whether they build habits or
just apologize.
7. What is the last thing you built where you owned both halves alone, with
nobody reviewing your code?
Why ask it: this is exactly the job at a small business.
WHAT A STRONG ANSWER SOUNDS LIKE
A strong candidate narrates the whole path without prompting: what the data
looked like, what the server did with it, what the browser rendered, and where
it went wrong. They name the tool they used to measure, not just the layer they
guessed at. On the outage question they describe a sequence (stop the bleeding,
find the cause, add a guard) and they can say what is different now.
A weak answer stays on one layer and hand-waves the rest ("the back end guy
handled the database"). Another weak pattern: every story is a greenfield
build, and nothing was ever maintained, inherited, or fixed under pressure.
NOTES
[Capture the layers actually covered, tools named, and red flags here.]
Set 2: Front End Questions for a Full Stack Hire
The browser half at the depth a full stack hire needs: framework judgment, mobile performance, why validation happens twice, accessibility, and state. Judgment matters more here than visual taste.
Front End Questions for a Full Stack Hire
FULL STACK DEVELOPER INTERVIEW: FRONT END DEPTH
Candidate: __
Interviewer: __
Date: __
Use this set to check the browser half at the depth a full stack hire needs.
You are not hiring a design specialist, so judge judgment, not pixel taste.
QUESTIONS TO ASK
1. Which front end framework do you reach for, and when would you not use one
at all?
Why ask it: a candidate who always reaches for the heaviest option will
build you something expensive to maintain.
2. How do you make a page fast on a phone with a weak connection?
Why ask it: most small business traffic is mobile, and this question has
concrete right answers (image sizing, bundle size, caching, fewer requests).
3. A form validates in the browser and again on the server. Why do both?
Why ask it: the correct answer is that browser validation is convenience
and server validation is security. Getting this wrong is a real risk signal.
4. How do you handle accessibility, and what do you check before you ship?
Why ask it: accessibility affects who can use your product and shows
whether the candidate thinks past their own screen.
5. How do you manage state that several parts of a page need at once?
Why ask it: it is the most common source of front end bugs.
6. Show me something you built and tell me what you would change about it now.
Why ask it: self-criticism is the cheapest proxy for growth there is.
7. How do you test the front end, and what do you deliberately not test?
Why ask it: a candidate with no testing opinion has not maintained anything
long enough to feel the pain.
WHAT A STRONG ANSWER SOUNDS LIKE
Strong candidates make tradeoffs out loud: they pick a framework for a reason
and can name a case where plain HTML and a little JavaScript would be better.
On performance they name what they measured. On the validation question they
say plainly that anything sent from a browser can be forged, so the server has
to check it again.
A weak answer treats the framework as the skill, cannot explain why the server
must re-validate, and has never looked at a page on a real phone.
NOTES
[Capture frameworks named, performance method, and validation reasoning.]
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
The server half, where a mistake actually costs money: data modeling, APIs, background jobs, third-party failure, changing a live database, and never charging a customer twice.
Back End, API, and Database Questions
FULL STACK DEVELOPER INTERVIEW: BACK END, API, AND DATABASE
Candidate: __
Interviewer: __
Date: __
Use this set to check the server half. For most small businesses this is where
a mistake actually costs money, so weight it heavily.
QUESTIONS TO ASK
1. Design the tables for [orders and customers] in our business. What would you
index, and why?
Why ask it: data modeling is the decision that is hardest to reverse later.
2. When would you choose a relational database, and when something else?
Why ask it: a candidate who has only one answer has only used one tool.
3. Walk me through building an API that another system will consume.
Why ask it: small businesses live on integrations, so this comes up fast.
4. We need to send five thousand emails when a job finishes. How do you do that
without freezing the page?
Why ask it: background work is the standard growing-pain problem, and the
answer (a queue, a scheduled worker) is concrete.
5. A payment provider or third-party service goes down for an hour. What
happens to our application?
Why ask it: it tests whether they design for failure or assume sunshine.
6. How do you change a live database that already holds real customer data?
Why ask it: migrations on production are where solo developers cause
irreversible damage. Look for backups, reversibility, and staged rollout.
7. How do you make sure a customer never gets charged twice?
Why ask it: any candidate who has handled money knows the word for this.
WHAT A STRONG ANSWER SOUNDS LIKE
Strong candidates ask you clarifying questions before designing the tables,
because the right model depends on your business. They index for the queries
they expect and can say what an index costs. They design for failure: retries,
timeouts, a queue, a way to replay work. On the live migration question they
talk about taking a backup first, making the change reversible, and shipping it
in steps rather than one big switch.
A weak answer designs a schema without asking a single question, treats every
third-party service as always available, and describes changing a production
database as routine and unremarkable.
NOTES
[Capture schema reasoning, failure handling, and migration discipline.]
Set 4: Security, Deployment, and Reliability Questions
Use this whenever the developer will be your only engineer. Secrets handling, deploys and rollback, monitoring, tested backups, and what they would fix first in your current setup.
Security, Deployment, and Reliability Questions
FULL STACK DEVELOPER INTERVIEW: SECURITY, DEPLOYMENT, RELIABILITY
Candidate: __
Interviewer: __
Date: __
Use this set whenever the developer will be your only engineer. Nobody else is
going to catch these mistakes for you.
QUESTIONS TO ASK
1. You inherit an application you did not write. What are the first security
problems you look for?
Why ask it: it reveals a real checklist or the absence of one.
2. Where do passwords and API keys live in your projects?
Why ask it: the wrong answer here is disqualifying and easy to spot. Keys
do not belong in the source code repository.
3. How do you deploy, and how do you roll back when a release is bad?
Why ask it: a developer with no rollback story will eventually leave your
site broken while they debug.
4. How do you find out something is broken before a customer tells you?
Why ask it: monitoring is the difference between an hour of downtime and a
day of it.
5. What do you back up, and when did you last restore from a backup to check
it worked?
Why ask it: untested backups are the most common false comfort in small
business systems.
6. We hold customer data we are legally required to protect. How does that
change how you build?
Why ask it: it tests whether they think about access, retention, and logs.
7. What would you fix first in our current setup if we hired you tomorrow?
Why ask it: the answer shows how they prioritize risk against features.
WHAT A STRONG ANSWER SOUNDS LIKE
Strong candidates treat secrets as configuration, never as code. They have a
deploy process they can describe in order, and a rollback that takes minutes
rather than an afternoon. They mention monitoring or alerting by name and can
tell you about a time an alert saved them. On backups they distinguish between
having a backup and having tested a restore, which very few candidates do.
A weak answer treats security as something added later, keeps keys in the
repository "because it is a small project," and has never rolled a release
back.
NOTES
[Capture secrets handling, deploy and rollback story, monitoring, backups.]
Set 5: Work Sample Brief and Solo-Ownership Questions
A paid three-to-five-hour brief you can send to every finalist, plus the questions that matter when nobody technical reviews the work: buy versus build, prioritization, documentation, and handover.
Work Sample Brief and Solo-Ownership Questions
FULL STACK DEVELOPER INTERVIEW: WORK SAMPLE AND SOLO OWNERSHIP
Candidate: __
Interviewer: __
Date: __
PART 1: THE PAID WORK SAMPLE BRIEF
Scope it to three to five hours, pay for the time, and give every finalist the
same brief. A small, real, self-contained task beats a whiteboard puzzle for a
role like this.
Brief template:
Task: Build [a small feature that touches data, server, and screen], for
example a page that lists [records], lets a user add one, and validates the
input on both sides.
Constraints: Use whatever stack you are strongest in. Three to five hours.
Deliverable: A repository we can run, plus a short README explaining your
decisions and what you would do with another day.
What we score: whether it runs, data model, input validation, error
handling, readability, and the quality of the README.
The README is the part most employers forget to ask for, and it is the part
that predicts whether you will be able to work with this person.
PART 2: QUESTIONS TO ASK (SOLO OWNERSHIP)
1. When do you recommend buying or using an existing service instead of
writing code?
Why ask it: a developer who builds everything from scratch will burn your
budget. Look for a real example where they chose not to build.
2. I hand you ten things and one week. How do you decide the order?
Why ask it: with no engineering manager, prioritization is your problem
unless the developer is good at it.
3. How would you document what you build so the next person can pick it up?
Why ask it: your bus factor is one. Documentation is the only mitigation.
4. What do you do when I ask for something you think is a bad idea?
Why ask it: you need someone who pushes back clearly and then commits.
5. How do you explain a technical tradeoff to someone who does not code?
Why ask it: this is most of the job when the owner is the only stakeholder.
6. If you left in three months, what would the handover look like?
Why ask it: candidates who answer this well have been the only engineer
before and know what they owe you.
7. How do you work when nobody technical reviews your code?
Why ask it: listen for self-imposed structure: tests, checklists, an
outside reviewer they pay for, or a standard they hold themselves to.
WHAT A STRONG ANSWER SOUNDS LIKE
Strong candidates have a concrete story about not building something, and they
can explain a tradeoff in plain English without condescension. They treat
documentation as part of shipping, not as a favor. They ask what the business
is trying to achieve before they order the list of ten things.
A weak answer wants to rebuild everything, cannot explain anything without
jargon, and describes documentation as something they would do if there were
time.
NOTES
[Capture the buy-versus-build example, prioritization method, handover plan.]
Set 6: Scorecard and Red Flags
Eight scoring areas with space for evidence, a front-end-versus-back-end balance check, and a ten-item red flag checklist. Use it with every set above so the decision rests on written evidence.
Full Stack Developer Interview Scorecard and Red Flags
FULL STACK DEVELOPER INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Date: __
Score each area from 1 (poor) to 5 (excellent) and write one line of evidence
from the interview. Score every candidate on the same areas.
Communication with non-engineers Score: [ 1 2 3 4 5 ]
Evidence: __
Judgment and prioritization Score: [ 1 2 3 4 5 ]
Evidence: __
BALANCE CHECK
Full stack means both halves. Add the front end score and the back end score.
If one is 4 or 5 and the other is 1 or 2, you are looking at a specialist, not
a full stack developer. That can still be the right hire, but hire them for
what they are and plan for the other half.
Front end score: ____ Back end score: ____ Gap: ____
RED FLAGS CHECKLIST
[ ] Every story stops at one layer of the stack
[ ] Cannot explain why a server must re-validate browser input
[ ] Keeps API keys or passwords in the source repository
[ ] No rollback plan and no monitoring
[ ] Has a backup but has never restored from one
[ ] Wants to rewrite everything before understanding the business
[ ] Cannot explain a tradeoff without jargon
[ ] Vague or evasive about what they personally built
[ ] Declines a paid work sample without a clear reason
[ ] No references from anyone who managed or paid them
SUMMARY
Total score: ______ / 40
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: __
Interviewer signature: __
Note: If more than one person interviews, everyone scores independently before
the group talks, so the loudest opinion does not set the answer.
Judging Answers Without an Engineering Background
You do not need to grade code to run this interview well. You need to tell a specific, honest answer from a vague one, and a few questions have answers so clear-cut that anyone can score them. The comparisons below are the ones worth memorizing before the first call.
Walk me through one feature you built end to end.
Strong answer: The story has all three layers in it without you prompting: what the data looked like, what the server did, what the customer saw, and what went wrong on the way. They name specific choices and say why they made them.
Weak answer: The story lives on one layer and the rest is passive voice: the database was set up, the API was provided. That phrasing usually means somebody else did it.
A form validates in the browser and again on the server. Why both?
Strong answer: Browser validation is convenience and speed; server validation is security, because anything sent from a browser can be forged or bypassed. A strong candidate says this in one sentence without hesitating.
Weak answer: They call the second check redundant, or they cannot articulate the difference. For a developer who will own your customer data alone, this is a serious signal.
Where do passwords and API keys live in your projects?
Strong answer: In environment variables or a secrets manager, never in the source repository, with different values for local work and production. They may mention rotating a key after someone leaves.
Weak answer: Committed to the repository because the project was small. This is the single easiest disqualifying answer to recognize with no engineering background at all.
What do you back up, and when did you last restore from a backup?
Strong answer: They distinguish having backups from having tested a restore, and they can name a time they actually restored one. Very few candidates get this far, so it is a strong positive signal.
Weak answer: Backups are described as automatic and therefore fine, with no restore ever attempted. An untested backup is a guess, not a safety net.
Beyond those four, weight the general signals. Specificity beats fluency: a candidate who names the tool they used to measure a slow page is telling you something, and one who says they optimized performance is not. Ownership language beats we. Willingness to say I do not know beats a confident guess, because you will be relying on this person to tell you when they are out of their depth.
Breadth signals
Narrates a feature across all three layers
Names the tool used to measure, not the layer guessed
Has inherited and fixed code, not only built new
Depth signals
Asks clarifying questions before designing
Can say what a choice costs, not just what it does
Designs for failure: retries, timeouts, queues
Communication signals
Explains a tradeoff without jargon
Pushes back clearly, then commits
Writes a README you can actually follow
Red flags
Keys in the repository and no rollback plan
Wants to rewrite before understanding the business
Every claim is we, never I
If you want a second opinion, pay a trusted developer for an hour to review the work sample submissions. An hour of outside review costs less than a month of the wrong hire, and it is the cheapest way to add technical judgment to a process you are otherwise running alone. Pair it with a reference check that asks specifically what the candidate owned alone.
The Work Sample That Beats a Whiteboard
A small, paid, scoped work sample predicts real performance better than a whiteboard puzzle, because it tests the actual job: building something that runs, making sensible choices, and explaining them. Whiteboard tests mostly measure how recently someone practiced whiteboard tests.
The rules that make it work are simple. Keep it to three to five hours, pay for the time, give every finalist the same brief, and decide your scoring criteria before you read the first submission. A skills assessment loses its value the moment two candidates get different tasks or you start grading on vibes after the fact.
What to score
What a strong submission shows
Does it run
Clone, follow the README, and it works without you asking questions
Data model
Sensible tables and fields for the task, nothing wildly over-built
Validation
Input checked on the server, not only in the browser
Error handling
Failures are handled and explained, not left to crash
Readability
Another developer could pick it up without a tour
The README
Decisions explained, tradeoffs named, next steps listed
The README is the part most employers forget to require, and it is the single best predictor of whether you will be able to work with this person. A developer who explains their decisions in writing to a non-engineer during a hiring process will keep doing it after they are hired.
One boundary worth stating plainly: never use a work sample to get real production work done for free. Invent a task that resembles your problem without being your problem. It is both the fair thing to do and the way to avoid an argument about unpaid work later.
Security, Deployment, and the Bus Factor
If this developer will be your only engineer, security and deployment habits matter as much as coding ability, because nobody else will catch the mistakes. The three questions that separate candidates fastest are where the API keys live, how a bad release gets rolled back, and when they last restored from a backup.
Secure Development Is a Practice, Not a Feature
The federal Secure Software Development Framework, published by NIST as SP 800-218, sets out a core set of high-level practices grouped into preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities. It frames secure development as continuing practices rather than one-time tasks. A candidate who describes security as habits and process, not as a feature to add later, is answering the way the standard frames it.
The other half of the risk is organizational. When one person builds and holds everything, your bus factor is one: if they leave, get sick, or simply stop answering, nobody else can run the system. You cannot eliminate that at your size, but you can reduce it during hiring and the first month.
Own the accounts yourself
The domain, the hosting account, the code repository, and the database belong to the business, with the developer added as a user. Never the reverse, however small the company.
Require a README with every project
How to run it, how to deploy it, what breaks, and who to call. Ask for it in the work sample so you know what you are getting before you hire.
Ask for the rollback, not just the deploy
Any developer can describe shipping. The valuable answer is how they undo a bad release in minutes without you sitting there watching.
Test one restore in the first month
Have the new hire restore from a backup into a scratch environment while you watch. It is the cheapest hour of risk reduction you will ever buy.
Ask the handover question in the interview, not after the resignation. Candidates who have been the only engineer somewhere before answer it easily, because they know what they owed the last employer. Candidates who have always had a team behind them often have not thought about it at all, which is useful information rather than a rejection.
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Score every candidate on the same areas immediately after the interview, while the answers are fresh, and write the evidence rather than an adjective. The point of a scorecard is to make the decision comparable across candidates instead of resting on whichever conversation felt best.
Scoring area
What a 5 looks like
End-to-end ownership
Narrates a whole feature across data, server, and browser
Front end depth
Framework judgment, measured performance, real accessibility work
Back end and data
Asks before designing; indexes and failure handling explained
Security and secrets
Secrets as configuration; a checklist for inherited code
Deploy and recovery
Rollback in minutes, monitoring named, a tested restore
Work sample
It runs, it validates on the server, the README is clear
Communication
Explains a tradeoff to a non-engineer without jargon
Judgment
A real example of choosing not to build something
Then run the balance check: add the front end score and the back end score and look at the gap. A four-point spread means the candidate is a specialist who has worked near the other half. Hire accordingly, and be honest with yourself about what you will still be missing on day one.
If more than one person interviews, each scores independently before the group discusses, so the most senior voice does not anchor everyone else. Compare the written evidence first, then talk. That single habit does more for hiring quality at a small company than any additional interview round, and it feeds a cleaner interview feedback conversation afterward.
Fair, Legal, and Structured Interviewing
A good developer interview is fair, legal, and structured, and those three reinforce each other. Asking the same job-related questions of everyone keeps you compliant, reduces bias, and produces better information at the same time.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing a hiring decision on protected characteristics, and questions that probe them create risk even when they feel like small talk. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Developer interviews have two specific traps worth naming: guessing at a graduation year to estimate age, and asking where someone is originally from because of an accent or a name on a resume. Ask what they have built and how they built it. Every question in these sets is written to stay on the job. This is general information, not legal advice.
Same core questions, same order, every candidate
A structured interview, where every candidate answers the same job-related questions and is scored against the same rubric, predicts on-the-job performance better than a free-flowing technical chat and reduces the chance that the decision rests on rapport. This matters more for developers than for most roles, because technical conversations drift toward whatever the interviewer happens to know, and two candidates end up being asked completely different things. Pick your sets before the first interview, ask them in the same order, and score immediately afterward while the answers are fresh.
Pay for the work sample and keep it small
Unpaid multi-day take-home projects filter for candidates with free time rather than candidates with skill, and they are the most common reason strong developers drop out of a small business hiring process. Scope the brief to three to five hours, pay for the time at a fair rate, give every finalist the same brief, and score it against written criteria you decided in advance. Never use a work sample to get real production work done for free; that is both a bad look and a legal problem waiting to happen. This is general information, not legal advice.
Write down what you decided and why
Keep the completed scorecards, the notes, and the work sample results for every candidate you interviewed, not just the one you hired. Consistent, job-related records are what make a hiring decision defensible if it is ever questioned, and they are also how you improve the process next time. Record the evidence, not adjectives: the answer the candidate actually gave, the score, and the reason. Store them somewhere organized rather than in a personal inbox, and follow applicable federal and state recordkeeping requirements for application materials.
Structure Is the Part That Makes the Interview Predictive
Federal guidance from the Office of Personnel Management on structured interviews calls them among the most valid assessment tools available, reliable because interviewers rate answers against standardized scales instead of impressions, and more legally defensible than unstructured ones because the questions target job-related behaviors. OPM rates work sample tests at the top of the same list, which is why the paid work sample here sits at the center of the process. Asking the same questions of everyone also keeps you inside the EEOC rules on protected characteristics.
Technical interviews drift more than most, because the conversation follows whatever the interviewer happens to know. Writing the sets down in advance is what keeps two candidates from being asked two different interviews. This is general information, not legal advice; see the guide to questions employers cannot ask for the specifics.
Full Stack Developer Pay
There is no separate federal occupation called full stack developer, so benchmark against the two nearest classifications and adjust for your market. Software developers is the higher band and the better match for product work; web developers is the closer match for websites and simpler web applications.
Median $135,980 for Software Developers, $92,650 for Web Developers
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey, May 2025, software developers had a median annual wage of $135,980, with the lowest 10 percent under $82,460 and the highest 10 percent over $214,670. Web developers had a median of $92,650, ranging from about $48,100 to $162,290. Full stack developer is not a separate federal occupation, so treat both as bands rather than as a price.
Nearest federal occupation
Median (annual)
10th percentile
90th percentile
Software developers
$135,980
$82,460
$214,670
Web developers
$92,650
$48,100
$162,290
Where a candidate lands inside those bands depends on the depth you need in each half, your local market, and whether the role is an employee or a contractor. A developer who will be your only engineer, holding the passwords and owning deployment, sits higher than one joining an existing team, because you are paying for judgment as well as output. Compare against the software engineer job description level you are actually hiring at rather than the title on the resume.
Hiring a Full Stack Developer Without an HR Department
A larger company runs this hire through a recruiter, an engineering manager, and a panel that already knows what a good answer sounds like. A small business runs it through the owner, between everything else, usually without a single engineer on staff to ask. That reality should change how you run the process, not just how you feel about it.
You are hiring a developer and you cannot read code
Most owners making this hire have no engineering background, which is why generic question lists are useless: they hand you questions without telling you what a good answer sounds like. Every set here pairs the question with the reason it is worth asking and what a strong answer contains, so you can judge specificity, honesty, and method instead of grading syntax. Three answers are readable by anyone: whether the story covers all three layers, whether they can say why a server re-validates browser input, and where they keep API keys. Those three alone will sort most of a candidate pool.
Your first developer is also your only developer
At a company with an engineering team, a weak hire is absorbed by code review and a manager. At a small business the full stack developer works unsupervised, chooses the stack, holds the passwords, and is the only person who understands the system. That changes what you interview for: security habits, deployment and rollback, tested backups, documentation, and a realistic handover plan matter as much as coding skill. Ask the solo-ownership questions before you ask about frameworks. A brilliant developer who leaves you an undocumented system you cannot hand to anyone is a worse outcome than a solid one who writes things down.
The interview is step one; the offer, access, and onboarding are where it gets real
Once you choose someone, the work shifts from evaluating to hiring well: a written offer, a confidentiality agreement before they see customer data, access granted deliberately rather than all at once, and a structured first weeks so they ship something small early. FirstHR fits this people side: send the offer and the confidentiality agreement for e-signature, run the new hire paperwork through an onboarding workflow, track access and policy sign-off as tasks, and keep the signed documents on the employee profile. To be clear on scope, FirstHR is an onboarding and HR platform, not a developer tool, a code repository, or an applicant tracking system, so pair it with those. Applicant tracking is coming soon to FirstHR.
Keep the process short as well as structured. A 30 minute screen, a 60 minute technical conversation, and a paid work sample is enough for a decision, and the whole thing should fit inside about three weeks. Good developers hold several conversations at once, so a slow process loses them to a faster one long before your third interview round.
From Interview to Onboarding
Once you choose someone, the work shifts to hiring well: a written offer letter, a signed confidentiality agreement before they see customer data, access granted deliberately, and the new hire paperwork handled properly. For a developer, onboarding has one extra step most roles do not: a deliberate, recorded handover of accounts and access.
Offer and confidentiality agreement
Confirm role, pay, and start date in writing, and have the confidentiality agreement signed before the developer touches customer data or production systems.
Grant access deliberately
Add them to accounts the business owns, one system at a time, with an inventory of what was granted and by whom. Access is easier to widen than to claw back.
Ship something small in week one
A tiny, real, low-risk change teaches you their deploy process and gives them an early win. It also proves the rollback story they told you in the interview.
Set a documentation expectation
Agree in the first week what gets written down: how to run the system, how to deploy, what breaks, and who to call. Make it a task, not a hope.
Have the developer sign the confidentiality agreement before the first credential is issued, not after, and use an onboarding template so the access, policy, and documentation steps are tasks somebody owns rather than intentions. Applicant tracking is coming soon to FirstHR.
FirstHR connects the offer, the confidentiality agreement, e-signatures, the new hire paperwork, and the onboarding workflow in one place, and keeps the signed documents and access checklist on the employee profile, so a small business can run the whole hiring-to-onboarding path from one system. To be clear on scope, FirstHR is an onboarding and HR platform, not a developer tool or a code repository, so connect those separately. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Start with one question: walk me through a feature end to end, from the database table to the button the customer clicks.
Score the front end and back end halves separately and compare them; a large gap means you found a specialist, not a full stack developer.
Three answers are readable without an engineering background: layer coverage, why the server re-validates browser input, and where API keys live.
If this developer will be your only engineer, treat security, rollback, monitoring, and a tested backup restore as core interview topics.
Use a small paid work sample with the same brief for every finalist, and require a README explaining the decisions.
Benchmark pay against software developers and web developers, since full stack developer is not a separate federal occupation.
Frequently Asked Questions
What questions should I ask a full stack developer in an interview?
Ask questions that force the candidate across the whole stack rather than into one layer. The strongest opener is to have them walk you through one feature end to end, from the database table to the button the customer clicks, because the story either contains all three layers or it does not. Then test each half: framework judgment, mobile performance, and why a form must be validated on the server as well as in the browser; then data modeling, background jobs, third-party failure, and how they change a live database that holds real customer data. If the developer will be your only engineer, add security, deploy and rollback, monitoring, and tested backups. Finish with judgment questions on buy versus build, prioritization, documentation, and handover. This page gives you all of those as six downloadable sets, each question paired with the reason to ask it and what a strong answer sounds like.
How do I interview a developer if I cannot code myself?
You do not need to grade code; you need to tell a specific, honest answer from a vague one. Three checks are readable by anyone. First, does the end-to-end story actually cover the database, the server, and the browser, or does it stop at one layer and use passive voice for the rest. Second, can they say in one sentence why a server must re-validate anything the browser sends, which is that browser input can be forged. Third, where do they keep API keys and passwords, because the wrong answer, in the source repository, is easy to hear and effectively disqualifying. Beyond those, use a small paid work sample and read the README they write with it, then have a trusted technical friend or a paid contractor review the submission for an hour. Score everything on the same rubric so you compare evidence rather than impressions.
What is the difference between a full stack developer and a web developer?
The terms overlap and are often used interchangeably, but the useful distinction is scope. Web developer usually describes someone who builds websites and web applications, and the title says nothing about which half of the work they do. Full stack developer specifically claims both halves: the interface in the browser and the server, API, and database behind it, plus enough deployment knowledge to put it live. In practice many candidates who call themselves full stack are strong in one half and adequate in the other, which is exactly why the scorecard here includes a balance check that compares the two scores. If the gap is large, you are looking at a specialist. That can still be the right hire, but hire them for what they are and plan for the other half.
Should I give a full stack developer a coding test or a take-home project?
Give a small, paid, scoped work sample rather than a whiteboard test or a large unpaid take-home. Whiteboard puzzles measure interview practice more than the ability to own a real system, and multi-day unpaid projects filter for candidates with free time rather than candidates with skill, which is a common reason strong developers drop out of a small business process. Scope the brief to three to five hours, pay for the time, and give every finalist the same brief so the comparison is fair. Ask for a repository you can run plus a short README explaining their decisions and what they would do with another day. Score it against criteria you wrote in advance: does it run, the data model, input validation, error handling, readability, and the quality of the README. Never use a work sample to get real production work done for free.
What are the red flags in a full stack developer interview?
The clearest red flags are readable without an engineering background. Every story stops at one layer of the stack, or shifts to passive voice whenever the other half comes up. The candidate cannot explain why a server must re-validate browser input. API keys or passwords live in the source repository because the project was small. There is no rollback plan and no monitoring, so you would learn about an outage from a customer. They have backups but have never restored from one. They want to rewrite everything before understanding your business. They cannot explain a tradeoff without jargon. They are vague about what they personally built, saying we for every accomplishment. They decline a paid work sample without a clear reason, or cannot offer references from anyone who managed or paid them. The downloadable scorecard includes this as a checklist.
How much does a full stack developer cost to hire?
There is no separate federal occupation called full stack developer, so benchmark against the two nearest classifications. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey, May 2025, software developers had a median annual wage of $135,980, with the lowest 10 percent under $82,460 and the highest 10 percent over $214,670. Web developers, the closer match for someone building websites and simpler web applications, had a median of $92,650, with a range from about $48,100 to $162,290. Where a specific candidate lands depends on the depth you need in each half, your local market, and whether the role is employee or contractor. A developer who will be your only engineer, holding the passwords and owning deployment, sits higher in the range than one joining an existing team. This is general information, not financial advice.
Is it legal to ask about a candidate GitHub profile or side projects?
Yes. Asking to see code a candidate has published publicly, or asking about side projects they choose to mention, is job-related and permitted. Two cautions apply. First, a public profile can reveal protected characteristics such as age, national origin, or religion, so anything you learn that way must stay out of the decision; keep your evaluation anchored to the code and the scorecard. Second, do not treat a large public portfolio as a requirement, because it systematically disadvantages candidates with caregiving responsibilities or second jobs, and it correlates poorly with professional skill. Ask about work they did for employers as well, and use a paid work sample to give every finalist an equal chance to show what they can do. Keep every question tied to the job and ask the same core set of every candidate. This is general information, not legal advice.
How long should a full stack developer interview process take?
Three steps is usually enough for a small business. Start with a 30 minute screening call covering the end-to-end feature question and two or three basics, which will sort most of the pool quickly. Follow with a 60 minute technical conversation using the front end and back end sets, plus the security set if this person will be your only engineer. Then send the paid work sample to your two or three finalists and give them a week of calendar time for three to five hours of work. Score after every step while the answers are fresh, and make the decision within a few days of the last submission, because good developers hold multiple offers and a slow process loses them. Keep the total elapsed time under about three weeks from first call to offer.
