Backend Engineer Interview Questions and Scorecard
Six question sets for employers hiring a backend engineer without a CTO or an HR department: screening, API design, data modeling, reliability, security and integrations, plus a weighted scorecard. Every question states why it is worth asking and what a strong answer sounds like. Download as DOCX.
The hardest part of hiring a backend engineer at a small business is that almost none of the work is visible. A front end candidate can show you a screen. A backend candidate describes systems you cannot see, in language you may not speak, and the consequences of getting it wrong surface eighteen months later inside a data model nobody wants to touch.
At FirstHR, we build for owners and managers who make this hire themselves, without an HR department and usually without a CTO. These six sets cover screening, API design, data modeling, reliability, security and integrations, and a weighted scorecard. Every question states why it is worth asking and what a strong answer sounds like, so you grade the substance rather than the confidence.
TL;DR
Interview a backend engineer on five things: what they personally built and ran, API and service design judgment, data modeling and query performance, production and incident ownership, and security with customer data and vendor integrations. Two questions almost nobody asks carry the most signal: how do you change a table with millions of live rows in it, and who has restored one of your backups. Use federal wage data as a baseline, a median of $135,980 for software developers. Download six sets and a weighted scorecard as DOCX.
What to Assess in a Backend Engineer
Assess five things: what the candidate has personally built and run on the server side, how they design and change APIs, how they model data and diagnose slow queries, how they behave when production breaks, and how they treat credentials and customer data. Every other backend topic is a detail of one of those five.
Notice what is absent. Algorithm puzzles, language trivia, and questions with one clever trick predict very little about whether someone will keep your systems fast, correct, and up. They persist because they are easy to grade, not because they work, and a small employer has no reason to inherit that habit from companies with entirely different problems.
Ownership signals
Names the system, the users, and the numbers
Draws a clean line around their own work
Knows what broke after they handed it over
Data judgment
Asks business rules before designing tables
Measures a slow query before guessing
Has changed a live table without downtime
Production behavior
Stabilizes first, diagnoses second
Owns an outage they personally caused
Watches signals that page a human
Red flags
Says we for every component, never I
Proposes a rewrite before reading the code
Adds infrastructure before finding the bottleneck
The most useful move in any of these areas is to follow up until the answer becomes concrete. Which table, how many rows, how long did it take, what did you change first. Strong backend engineers get sharper under that pressure because they were there. Weaker candidates get vaguer, and the difference usually shows within two follow-ups.
Decide the Scope Before You Interview
Write down what the backend engineer must own in their first ninety days before you speak to anyone, because scope decides which sets you use and what you should pay. The most common small-business mistake is interviewing for a generic engineer and then discovering the role was really about integrations, or really about one database that has outgrown its design.
What the role is really about
Weight these sets
The question that decides it
One growing database behind one application
Data modeling, screening
How do you change a live table without downtime?
Vendor APIs, payments, and webhooks
Security and integrations, reliability
How do you verify a webhook is genuinely from the vendor?
Systems that must stay up during business hours
Reliability, screening
What did you do in the first thirty minutes of an outage?
A public or partner-facing API
API design, security
How do you change an API other systems depend on?
Your first and only engineer
All six, reliability weighted highest
What happens the week you take a vacation?
Scope also settles the title question. A backend specialist goes deeper on data and reliability, while a full stack developer covers the screens too at a shallower depth in each area. Neither title is reliable on a resume, so judge by what the person has personally owned. If the role is really about infrastructure and deploys rather than application code, the DevOps questions fit better than these.
Both Directions Are Expensive
Paying senior rates for mid-level judgment is the failure everyone anticipates. The one that catches small businesses more often is hiring a junior backend engineer into a role with nobody available to review their work, because the budget fit felt right. That arrangement fails the business and it is unfair to the person, who needed a mentor and received a database instead. If nobody here can review their work weekly, do not hire at that level.
The Six Question Sets
Use the core screening set with every candidate and pick the rest based on what the engineer will actually own. For a first engineer who will hold the database and the deploy access, reliability matters more than almost anything else you could test.
Core Backend Screening
Every candidate
What they built on the server side, which part was theirs, whether it still runs, and how they get productive in code they did not write. Eight questions, all levels.
API and Service Design
Anyone defining contracts
Changing an API other systems depend on, repeated requests, error design, pagination, and when one service should become several.
Data Modeling and Performance
The set most lists skip
Schema design against your real business, diagnosing a slow page, the cost of an index, migrating a live table, transactions, and restoring a backup.
Reliability and Incidents
Highest signal for a first hire
The worst incident they were part of, an outage they caused, what they monitor, retries and queues, scaling, deploys, and honest on-call expectations.
Security and Integrations
Nobody is reviewing behind them
Where secrets live, injection, access control on every request, personal and payment data, vendor APIs, webhook verification, and AI-assisted code.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric with space for written evidence, a ten-item red-flag checklist, and a level check to run before any offer goes out.
Which Sets to Use for Which Hire
First and only engineer: screening, reliability, data modeling, and security. Adding to an existing team: screening, API design, and data modeling. A contractor for a defined project: screening, API design, and the handover questions inside reliability. A junior hire with a reviewer available: screening and data modeling, scored against a junior expectation. Use the scorecard with every combination, and pair the result with the level you actually posted in the back end developer job description.
6 Free Question Sets to Download
Download all six as a single Word document, or copy the individual sets you need. Each follows the same structure: why the set exists, the questions with a stated reason for asking and what a strong answer sounds like, what to listen for, and space for notes. Fill in the blanks and use them as they are.
Download All 6 Backend Engineer Question Sets
Screening, API design, data modeling, reliability and incidents, security and integrations, and a weighted scorecard with red flags. All in one DOCX.
Set 1: Core Backend Screening Questions
The opening set for every candidate at every level: what they built on the server side, which part was theirs, whether it still runs, and how they get productive in code they did not write. Start here.
Core Backend Screening Questions
CORE BACKEND SCREENING QUESTIONS
Candidate: __
Interviewer: __
Date: __
WHY THIS SET EXISTS
Every backend candidate gets this set, at every level. It establishes what the
person has actually built on the server side, how much of it was theirs, and
whether the systems they name are still running in production today. Ask all
eight. The follow-ups matter more than the questions.
QUESTIONS
1. Describe a backend service you built. What did it do, who used it, and how
much traffic or data did it handle?
Why ask: it sets the scale the rest of the interview is calibrated against.
Strong answer: names the users, the request volume, the data size, and the
constraint that made the work hard. Weak answer: describes the technology
stack and never mentions a user or a number.
2. On that system, what did you personally write and what did someone else write?
Why ask: this single follow-up separates the engineer who built the thing
from the engineer who was nearby while it was built.
Strong answer: draws the line immediately and without defensiveness.
Weak answer: says "we" for every component and cannot get more specific.
3. Is it still running? What has broken since you left it?
Why ask: systems that survive contact with real users teach different lessons
than prototypes.
Strong answer: knows what happened after handover, or says plainly that they
lost visibility. Weak answer: has never thought about it.
4. Walk me through what happens between a user pressing a button and the data
landing in the database.
Why ask: it tests whether they hold the whole request path in their head, and
a non-technical interviewer can grade the clarity of the explanation.
Strong answer: a clean narrative through the API, validation, business logic,
and storage, in plain language. Weak answer: jargon with no sequence.
5. How do you get productive in a codebase you did not write?
Why ask: your first weeks depend on this and almost nobody asks it.
Strong answer: reads the tests and the deploy path, traces one request end to
end, ships something small early. Weak answer: proposes a rewrite.
6. What is the part of your last system you would build differently now?
Why ask: engineers who cannot criticize their own work do not improve it.
Strong answer: one specific decision, the reason it was made at the time, and
what changed. Weak answer: nothing, everything was fine.
7. Which languages, frameworks, and databases are you genuinely strong in, and
which have you only touched?
Why ask: it invites honesty and rewards it.
Strong answer: a short strong list and an honest thin list.
Weak answer: claims deep strength in everything on the resume.
8. What would you need from us in your first month to be effective?
Why ask: it reveals whether they have thought about your side of the hire.
Strong answer: access, a point of contact, one clear first task, and the
business context. Weak answer: no requirements at all.
WHAT TO LISTEN FOR
•Specific systems, specific users, specific numbers
•A clean line between their work and the team's work
•Plain language when explaining to a non-engineer
•Honesty about the limits of what they know
NOTES
__
__
Set 2: API and Service Design Questions
For anyone who will define contracts other software depends on: breaking changes, repeated requests, error design, pagination, and when one service should become several.
API and Service Design Questions
API AND SERVICE DESIGN QUESTIONS
Candidate: __
Interviewer: __
Date: __
WHY THIS SET EXISTS
An API is a promise you cannot cheaply take back once other software depends on
it. Use this set for anyone who will design endpoints, define contracts, or
decide how services talk to each other. These are judgment questions, and the
reasoning matters more than the vocabulary.
QUESTIONS
1. Walk me through an API you designed. Why did the endpoints look the way they
did?
Why ask: design intent is visible in the reasons, not the routes.
Strong answer: ties the shape of the API to how clients actually use it.
Weak answer: recites a convention with no reason behind it.
2. How do you change an API that other systems already depend on?
Why ask: this is the most common real backend task and the easiest place to
break a customer.
Strong answer: additive changes first, versioning or a deprecation window,
communication with the callers, a plan for the old clients that never update.
Weak answer: change it and tell people afterward.
3. A client sends the same request twice because of a network retry. What
happens to the second one?
Why ask: duplicate charges and duplicate orders come from exactly this.
Strong answer: explains making an operation safe to repeat, with request keys
or a uniqueness constraint, and knows which operations need it.
Weak answer: has not considered it.
4. How do you return errors, and what does a caller do with them?
Why ask: error design is where junior and senior work visibly differ.
Strong answer: distinguishes caller mistakes from server failures, returns
something actionable, and never leaks internals. Weak answer: a generic
failure for everything.
5. An endpoint returns a list that is now far larger than when you built it. What
do you change?
Why ask: it tests whether they think past the first version.
Strong answer: pagination or streaming, a cap, and a migration path for
existing callers. Weak answer: add more memory.
6. How do you decide between one service and several?
Why ask: premature splitting is the most expensive avoidable decision at a
small company.
Strong answer: starts simple, splits only for a named reason such as separate
scaling or a separate team. Weak answer: several services because that is
modern architecture.
7. How do you document an API so the person calling it does not have to ask you?
Why ask: at a small business, documentation is the difference between one
engineer and a bottleneck.
Strong answer: generated reference plus real examples, kept close to the code.
Weak answer: documentation is written when there is time.
WHAT TO LISTEN FOR
•Thinks about the caller, not only the server
•Treats a published contract as a commitment
•Reaches for the simplest structure that meets the requirement
•Has been burned by a breaking change and learned from it
NOTES
__
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Set 3: Data Modeling and Database Performance Questions
The set most interview lists skip and the one with the longest tail: schema design against your real business, diagnosing a slow page, the cost of an index, live migrations, transactions, and restoring a backup.
Data Modeling and Database Performance Questions
DATA MODELING AND DATABASE PERFORMANCE QUESTIONS
Candidate: __
Interviewer: __
Date: __
WHY THIS SET EXISTS
Application code gets rewritten. The data model outlives it, and a bad one taxes
every feature you ship for years. This is the set most interview lists skip and
the one that separates a strong backend hire from a competent one. Ask it of
anyone who will design tables or own queries.
QUESTIONS
1. Design the tables for one part of our business. Talk me through the choices.
Why ask: it is the closest thing to a live sample of the work.
Strong answer: asks about the business rules before drawing anything, names
the tradeoff they are making. Weak answer: starts typing immediately.
2. A page that used to load instantly now takes eight seconds. How do you find
out why?
Why ask: systematic debugging is the skill, not the answer.
Strong answer: measures before guessing, looks at the query plan, checks for
a query running once per row. Weak answer: a list of guesses in no order.
3. When would you add an index, and what does adding one cost?
Why ask: it separates memorized advice from understanding.
Strong answer: faster reads paid for with slower writes and more storage, and
knows an unused index is pure cost. Weak answer: indexes make things fast.
4. How do you change the shape of a table that has millions of live rows in it?
Why ask: migrations are where small teams take real downtime.
Strong answer: backwards-compatible steps, deploy in stages, tested on a copy,
with a way back. Weak answer: run the migration and hope.
5. When do you use a transaction, and what goes wrong without one?
Why ask: money and inventory bugs live here.
Strong answer: a concrete example of two writes that must both succeed.
Weak answer: defines the word without an example.
6. When would you not use a relational database?
Why ask: it tests judgment rather than preference.
Strong answer: a specific fit, such as caching, search, or event data, and
still defaults to a relational store. Weak answer: a blanket preference.
7. Who has restored one of your backups, and when?
Why ask: an untested backup is a hope, not a backup, and this question is
almost never asked.
Strong answer: has actually restored one, and knows how long it took.
Weak answer: backups run nightly, described with no restore.
WHAT TO LISTEN FOR
•Asks business questions before designing tables
•Measures before optimizing
•Treats migrations and backups as production work
•Names the cost of every choice, not only the benefit
NOTES
__
__
Set 4: Reliability, Scale, and Incident Questions
The highest-signal set for a small employer, because incident behavior is nearly impossible to fake: the worst outage they saw, one they caused, what they monitor, retries and queues, deploys, and honest on-call expectations.
Reliability, Scale, and Incident Questions
RELIABILITY, SCALE, AND INCIDENT QUESTIONS
Candidate: __
Interviewer: __
Date: __
WHY THIS SET EXISTS
For a small business, the backend engineer is usually the person an outage
wakes. Incident behavior is close to impossible to fake, which makes this the
highest-signal set on the page. Use it for anyone who will hold production, and
weight it heavily for a first engineering hire.
QUESTIONS
1. Tell me about the worst production incident you were part of. What did you do
in the first thirty minutes?
Why ask: it shows priorities under pressure better than any hypothetical.
Strong answer: stabilize first, find the cause second, communicate throughout,
write it up after. Weak answer: a heroic story with no timeline.
2. Tell me about an outage you caused.
Why ask: everyone with real production experience has one, so a blank here is
either inexperience or a missing sense of ownership.
Strong answer: owns it plainly and names the guardrail added afterward.
Weak answer: has never caused one after many years of shipping.
3. What do you watch to know the system is healthy right now?
Why ask: it reveals whether they operate systems or only write code.
Strong answer: a handful of meaningful signals, error rate, latency, queue
depth, and an alert that pages a human. Weak answer: the server is up.
4. A job that talks to a third-party service keeps failing. How do you make that
path reliable?
Why ask: most small-business backends are mostly integrations.
Strong answer: timeouts, limited retries with growing waits, a queue, a dead
letter path, and an alert. Weak answer: retry forever.
5. Traffic is going to be ten times higher next month. What do you look at first?
Why ask: it distinguishes measured scaling from cargo-culted scaling.
Strong answer: finds the actual bottleneck first, usually the database, and
picks the cheapest fix. Weak answer: reaches for infrastructure immediately.
6. How does a change of yours reach customers, and how do you undo it?
Why ask: for a first engineer this is your entire risk profile.
Strong answer: automated tests, a repeatable deploy, and a rollback they have
actually used. Weak answer: a manual process only they can run.
7. What is your honest view on being on call at a company this size?
Why ask: an unspoken mismatch here ends the hire within a year.
Strong answer: direct about what they will and will not accept, and asks about
your incident volume. Weak answer: whatever you need, with no questions.
WHAT TO LISTEN FOR
•Stabilizes before diagnosing
•Owns a failure without being asked twice
•Monitoring described as a habit, not a tool purchase
•Realistic and specific about on-call expectations
NOTES
__
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Security and Third-Party Integration Questions
Where secrets live, keeping untrusted input out of the database, checking permissions on every request, handling personal and payment data, vendor APIs, webhook verification, and AI-assisted code.
Security and Third-Party Integration Questions
SECURITY AND THIRD-PARTY INTEGRATION QUESTIONS
Candidate: __
Interviewer: __
Date: __
WHY THIS SET EXISTS
A backend engineer at a small business holds the customer data, the payment
integration, and the production credentials. Nobody is reviewing that work
behind them. These questions are answerable in plain language, so a
non-technical interviewer can score them honestly.
QUESTIONS
1. Where do production secrets live, and who can read them?
Why ask: credentials in a repository or a chat thread are a common and
expensive small-company failure.
Strong answer: a secret store or the platform's own mechanism, access limited,
rotation possible. Weak answer: in a config file, everyone has it.
2. How do you keep untrusted input from reaching the database as a command?
Why ask: injection remains among the most common real-world vulnerabilities.
Strong answer: parameterized queries as a rule, validation at the boundary,
never string concatenation. Weak answer: sanitizes input by hand.
3. How do you decide who is allowed to see a given record?
Why ask: broken access control lets one customer read another customer's data,
which is the failure that ends small companies.
Strong answer: checks authorization on every request at the server, never
trusts an identifier from the client. Weak answer: the interface hides it.
4. How do you handle personal or payment data differently from other data?
Why ask: your obligations follow the data, not the codebase.
Strong answer: collects less, encrypts in transit and at rest, keeps payment
details with the processor, limits who can query it. Weak answer: treats all
data the same.
5. Walk me through integrating a vendor API you had never used before.
Why ask: this is the daily reality of most small-business backend work.
Strong answer: reads the documentation, builds against a sandbox, handles the
error cases and rate limits, isolates the vendor behind one module.
Weak answer: describes the happy path only.
6. How do you verify that an incoming webhook is genuinely from the vendor?
Why ask: an unverified webhook is an open door into your system.
Strong answer: signature verification, replay protection, and a queue so a
slow handler does not drop events. Weak answer: has not thought about it.
7. Where have you used an AI assistant to write backend code, and what do you
check before it ships?
Why ask: the honest answer is now part of judging code quality.
Strong answer: uses it, reviews every line, is specific about what it gets
wrong. Weak answer: either never, or ships the output unread.
WHAT TO LISTEN FOR
•Treats credentials and customer data as a standing responsibility
•Checks permissions on the server, every time
•Isolates vendors so one integration does not spread through the code
•Honest and specific about AI-assisted work
NOTES
__
__
Set 6: Scorecard and Red Flags
A weighted 1-to-5 rubric with space for written evidence, a ten-item red-flag checklist, and a level check to run before any offer goes out. Use it with every set above and for every candidate.
Backend Engineer Scorecard and Red Flags
BACKEND ENGINEER INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Date: __
Level posted: [ ] Junior [ ] Mid-level [ ] Senior
Score each area 1 to 5 and write the evidence, not the impression. Every
If no, resolve it now rather than after the paperwork.
DECISION
Weighted total: ______ / 5
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: ___
Interviewer signature: _
What a Strong Backend Answer Sounds Like
Strong answers share a shape whatever the topic: they are specific, they name a tradeoff, and they admit something. Weak answers stay abstract, present every decision as obvious, and contain no mistakes. You can recognize that pattern without reading a line of code.
Walk me through what happens between a user pressing a button and the data landing in the database.
Strong answer
A sequence in plain language: the request arrives, it is validated, a rule is applied, one or two records are written, a response goes back. They name where it could fail.
Weak answer
A list of technology names in no particular order, with nothing describing what actually happens to the request.
A page that used to load instantly now takes eight seconds. How do you find out why?
Strong answer
They measure before touching anything: check whether it is one slow query or a query running once per row, read the query plan, then change one thing and measure again.
Weak answer
A list of guesses with no method for choosing between them, or an immediate proposal to add servers or caching.
Where do production secrets live, and who can read them?
Strong answer
A named place that is not the code repository, access limited to the people who need it, and a way to rotate a key when someone leaves.
Weak answer
In a configuration file that everyone on the team has a copy of, described as normal and not as a problem to fix.
None of those three requires technical knowledge to grade, which is deliberate. The questions in these sets were chosen because a non-technical interviewer can score them honestly, a constraint most technical hiring advice quietly ignores. If you also want a general engineering read, the software engineer questions cover leveling and code review in more depth.
The Data Questions Most Interviews Skip
Ask about migrations and backups. Application code gets rewritten every few years, but the data model outlives it and taxes every feature you ship until someone pays to fix it. Two questions carry most of the signal here, and neither appears on the usual lists.
The first is how they change the shape of a table that already holds millions of live rows. A strong answer moves in backwards-compatible steps, deploys in stages, tests on a copy of real data, and keeps a way back. A weak answer describes running the migration and hoping, which is how a small business takes an unplanned outage on a Tuesday afternoon.
The second is who has restored one of their backups, and when. An untested backup is a hope rather than a backup, and the candidate who has actually done a restore will tell you how long it took and what surprised them. If the role is mostly about the database itself rather than application code, the database administrator questions go further into that ground.
Ask Them to Design Against Your Real Business
Replace the abstract design question with something from your actual operation: model orders and returns, appointments and cancellations, or subscriptions and plan changes. A strong candidate will ask about the business rules before drawing a single table, which is the behavior you want from the person who will own that model for years. A candidate who starts naming tables immediately is showing you how the design will go once they are hired.
A Work Sample That Matches Backend Work
A short, paid work sample that resembles your real backend work predicts performance better than an algorithm puzzle, and candidates resent it far less. Keep it to two or three hours with a hard cap, publish the criteria you will score against, and give every candidate the same brief so the comparison means something.
Good backend briefs are small and realistic: add one endpoint to a tiny existing service, write an integration against a vendor sandbox API, or find and fix a deliberately slow query in a sample database. Pay for the time. Unpaid multi-day projects screen out precisely the experienced people with current jobs and family responsibilities you most want to reach. Federal guidance treats any test used to make employment decisions as something that should be job-related and consistent with business necessity, which is one more reason to keep the task close to the actual work.
The Debrief Matters More Than the Code
Score the conversation about the work sample, not only the submission. Ask what they would do with two more days, what they deliberately left out and why, where they used an AI assistant and what they changed about its output, and what error cases they decided to skip. A candidate who submits ordinary code and debriefs brilliantly is usually the better hire, because you are buying judgment for years rather than one afternoon of output.
Scoring a Backend Engineer Interview
Score immediately after each conversation, while the evidence is fresh, and anchor every rating to something the candidate actually said. Set the weights before you meet anyone, so the areas that matter for your systems are decided by the job rather than by whichever answer impressed you most.
Scoring area
Suggested weight
What a 5 looks like
Backend depth and ownership
25%
Built and ran real server-side systems; clear about their own part
API and service design judgment
20%
Designs for the caller; treats a published contract as a commitment
Data modeling and query performance
20%
Asks business rules first, measures before optimizing, tests migrations
Reliability and production ownership
20%
Stabilizes first in an incident, monitors, owns an outage they caused
Communication with non-engineers
15%
Explains a system plainly and flags risk before a deadline slips
If more than one person interviews, each scores independently before the group talks, so the most senior voice does not anchor everyone else. Compare written evidence first and discuss the gaps second. The same questions and the same rubric for every candidate is the whole of a structured interview, and those scores feed a clean interview feedback step before you decide.
Run one more check before any offer goes out: compare the scope the candidate actually demonstrated against the scope you posted. If they do not match, resolve it now rather than after the paperwork, using a consistent evaluation form across everyone you spoke to.
What a Backend Engineer Costs
There is no separate federal occupation for backend engineers, so the closest published benchmark is software developers. Use it as a national baseline, then adjust for your market, the scope you are genuinely hiring, and whether the role is an employee or a contractor.
Median $135,980 a Year (BLS OEWS, May 2025)
Software developers had a median annual wage of $135,980, about $65.38 an hour, according to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025). The spread inside the occupation is unusually wide: the lowest 10 percent earned under $82,460 and the highest 10 percent over $214,670, with the 25th percentile at $105,210 and the 75th at $171,980 (U.S. Bureau of Labor Statistics).
A spread of more than $130,000 between the tenth and ninetieth percentile inside one job title is exactly why a resume title tells you almost nothing about cost. A backend engineer who will be your only one, holding the database and the deploy access, sits higher in the band than one joining an established team, because you are paying for judgment and availability as well as output. If you are weighing an employee against a contract engagement, the employee versus contractor distinction changes the cost and the questions you should ask about who owns the work. For a senior scope, the senior backend developer job description spells out what that level should cover.
Fair, Legal, and Structured Interviewing
A fair interview, a legal interview, and an effective interview are the same interview. Asking the same job-related questions of every candidate keeps you compliant, reduces bias, and produces better hires at the same time. Backend interviews carry a few specific traps worth naming.
Keep every question on the work
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 arrive as friendly small talk. Do not ask about age, race, religion, national origin, sex, pregnancy or family plans, disability, or genetic information. Engineering interviews have their own version of this trap: asking what year someone finished school, guessing at an accent, or joking about whether a candidate is too experienced. Graduation year is an age question wearing a technical costume. Every question in these sets is written to stay on the work itself. This is general information, not legal advice.
Ask the same core questions of everyone
A structured interview, where every candidate faces the same questions scored against the same rubric, predicts on-the-job performance far better than a free-flowing technical conversation, and it protects you at the same time. Backend interviews drift more than most, because a shared enthusiasm for one database can quietly turn into forty minutes that no other candidate received. Write the set in advance, ask it in the same order, and keep the exploratory conversation for after the scored questions. The sets and scorecard here are built to make that the easy path rather than the disciplined one.
Treat a coding exercise as a selection test
Federal guidance treats any test used to make an employment decision as something that should be job-related and consistent with business necessity, and that includes a take-home exercise or a live coding session. Practically, that means giving every candidate the same brief, publishing the criteria you will score against, and keeping the task close to work your business actually does. A puzzle unrelated to the job is both a weaker predictor and a harder thing to defend. Cap the time, pay for it, and score it on a written rubric. This is general information, not legal advice.
Match the questions to your actual backend
A backend engineer for a business running one application on a managed database and one running a distributed platform are different hires. If your systems are mostly integrations with vendor APIs, weight the security and integration set and the reliability set. If you are carrying years of data in one growing database, weight the data modeling set heavily. Decide what the role must accomplish in the first ninety days and interview for exactly that, rather than for a generic large-company engineer you do not need and cannot keep busy.
Structure Is Both the Fairer and the More Effective Choice
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you inside the EEOC rules against basing decisions on protected characteristics, and any test used to select employees falls under the Uniform Guidelines on Employee Selection Procedures.
Keep every question tied to the work and skip the small talk that drifts toward age, origin, or family. The questions employers cannot ask are worth reading once before you interview, because most violations are accidental rapport rather than intent. This is general information, not legal advice.
Interviewing a Backend Engineer Without HR
A large company runs a backend candidate through coordinated panels with a recruiter managing scorecards and a committee calibrating levels. A small business runs the founder, alone, between everything else, often with nobody technical in the room. That reality changes what a good process looks like, and it is where the avoidable mistakes cluster.
You are the only interviewer, and you may not be an engineer
A large company puts a backend candidate through coordinated panels with a recruiter tracking scorecards and a committee calibrating levels. At a small business the founder runs the whole thing alone, between everything else, often with nobody technical in the room. That is why every question in these sets carries a stated reason for asking and a description of what a strong answer sounds like. You are grading the shape of the answer, specific, honest, aware of a tradeoff, and that is something you can judge without reading a line of code.
This person will hold the database, the credentials, and the deploy button
Your backend engineer is often the only one who can restore the data, rotate a key, or ship a fix at ten at night. That concentration of access is the real reason to weight the reliability and security sets so heavily, and the reason handover belongs in the interview rather than in the exit conversation. Ask who owns the hosting account, who else has read the deploy documentation, and what happens the week they take a vacation. A candidate who answers those calmly is telling you they have been the single point of failure before and took it seriously.
One bad engineering hire costs more than the salary
A weak backend hire leaves a data model and a set of decisions that the next person pays for over years, which is a longer tail than most roles carry. Structure is the cheapest protection available: the same written questions for every candidate, a short paid work sample, and a weighted rubric filled in before anyone debates. If you want a technical read you do not have in-house, pay a senior engineer you trust for two hours to sit in on one interview and review the work sample. That is a fraction of the cost of a miss. Applicant tracking is coming soon to FirstHR.
A written question set and a rubric exist to make one person's interview as rigorous as a hiring committee's without the overhead of one. Where you find candidates shapes your pipeline more than any single question does, so it is worth deciding how you will source developers before you start. Browse the rest of the hiring templates if you need the posting, the evaluation form, or the offer to go with it.
From Interview to Onboarding
The interview is step one. Onboarding a backend engineer carries extra steps because of the access involved: a written offer and a confidentiality agreement signed before the first commit, repository, hosting, and database access provisioned from accounts the business owns, and the standard new hire paperwork alongside it.
Score before you discuss
Each interviewer fills the weighted rubric alone, with written evidence, then the group compares notes rather than impressions.
Offer and confidentiality
Put the level, pay, and start date in writing, and get the confidentiality agreement signed before the first commit lands.
Access from company accounts
Provision the repository, hosting, and database access from accounts the business owns, never from the engineer’s personal ones.
Ship something small in week one
A tiny real change tests the whole path from a laptop to a customer and exposes every broken step in your setup early.
Give the new engineer something small and real to ship in the first week. Shipping once beats two weeks of reading, because it tests the entire path from a laptop to a customer and exposes every broken step in your setup while someone is paid to notice. A structured developer onboarding plan and a clear offer letter handle most of the rest. Applicant tracking is coming soon to FirstHR.
FirstHR connects the offer, the confidentiality agreement, e-signatures, the new hire paperwork, and the access and policy checklist in one place, and stores the signed documents and interview records on the employee profile where you can find them a year later. FirstHR is an onboarding and HR platform, not a code repository, a deployment tool, or an applicant tracking system, so connect those separately. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Assess five things: what they personally built and ran, API design judgment, data modeling, production ownership, and how they treat credentials and customer data.
The highest-yield question is a follow-up: on that system, what did you write and what did someone else write.
Ask the two questions most interviews skip: how do you change a live table without downtime, and who has restored one of your backups.
Weight reliability heaviest for a first engineer, because that person is the one an outage wakes and the one who holds the deploy access.
Use a short paid work sample built from your real work, and score the debrief as heavily as the code.
Score on a weighted rubric independently, then check the demonstrated scope against the scope you posted before any offer.
Use BLS data as a baseline: the closest occupation, software developers, reported a median of $135,980 a year in May 2025.
Frequently Asked Questions
What questions should I ask a backend engineer in an interview?
Ask questions that force specifics about server-side work the candidate has actually shipped, across five areas: what they built and personally owned, how they design and change APIs, how they model data and fix slow queries, how they behave during a production incident, and how they handle credentials, customer data, and vendor integrations. The highest-yield question in any backend interview is a follow-up: on the system you just described, what did you personally write and what did someone else write. Two more that almost nobody asks are worth stealing: how do you change the shape of a table that has millions of live rows in it, and who has restored one of your backups and when. Both separate an engineer who has run production from one who has only written code. Skip algorithm trivia that has no relationship to your codebase. This page provides six ready-to-use sets, each question paired with why it is worth asking and what a strong answer sounds like.
How do I interview a backend engineer if I am not technical?
You can run a strong backend interview without reading code, because the questions that predict success are about judgment and habits rather than syntax. Ask the candidate to walk you through what happens between a user pressing a button and the data landing in the database; an engineer who cannot make that legible to a non-engineer will be expensive to work with regardless of the code they write. Ask what they personally wrote, how they found the cause of a slow page, what they did in the first thirty minutes of an outage, and where production secrets live. Each of those has a recognizable strong answer that needs no technical knowledge to spot: specific, sequenced, honest about a mistake, and aware of a tradeoff. If you want a technical read on top of that, pay a senior engineer you trust for two hours to sit in on one interview and review a work sample. That costs a small fraction of a bad hire.
What is the difference between a backend engineer and a full stack developer?
A backend engineer owns the server side: the APIs, the business logic, the database, the background jobs, and the integrations with outside services. A full stack developer covers that ground plus the user interface, which in practice means broader coverage at a shallower depth in each area. For a small business the choice is usually about what breaks first. If your risk is data integrity, slow queries, payment or vendor integrations, and systems that must stay up, hire a backend specialist and weight the data and reliability questions. If you need one person to ship whole features including the screens, a full stack developer fits better. Job titles are unreliable here, so judge by what the candidate has personally owned rather than by the words on the resume, and ask the backend sets in either case if the server side matters to you.
What technical questions should I ask about databases and APIs?
The most revealing database questions are practical rather than definitional. Ask how they would design the tables for one real part of your business and listen for whether they ask about the business rules first. Ask how they diagnose a page that used to load instantly and now takes eight seconds, and listen for measurement before guessing. Ask what adding an index costs, how they change a table with millions of live rows in it without downtime, and when they last restored a backup. On the API side, ask how they change an endpoint other systems already depend on, what happens when a client sends the same request twice because of a network retry, and how they return errors a caller can act on. Each of these has a clear strong answer written out in the downloadable sets on this page, so you can score them without an engineering background.
What are red flags in a backend engineer interview?
The most reliable red flag is a candidate who says we for everything and cannot say what they personally wrote when asked directly. Others worth weighing: claiming deep strength in every technology on the resume, having never caused or been near a production problem after years of shipping, proposing a rewrite of your system before understanding it, reaching for extra services or infrastructure before finding the actual bottleneck, being unable to describe a database change that does not take the site down, having never restored a backup, and dismissing tests, documentation, or handover as overhead. Resistance to discussing account ownership and handover is a serious one for a small business, because a backend engineer usually holds the keys to everything. Treat any single item as a prompt to probe rather than an automatic rejection. Three together is a pattern.
Should I give a backend candidate a take-home coding test?
A short, paid work sample that resembles your real backend work predicts performance better than a whiteboard puzzle, and candidates resent it far less. A good backend brief is small and realistic: add one endpoint to a tiny existing service, or write the integration against a vendor sandbox API, with a hard cap of two or three hours. Publish the criteria you will score against and give every candidate the same brief so the comparison means something. Pay for the time, because unpaid multi-day projects screen out exactly the experienced people with current jobs that you most want to reach. Federal guidance treats any test used to make an employment decision as something that should be job-related and consistent with business necessity, which is another reason to keep the task close to the work. Score the debrief conversation as heavily as the code. This is general information, not legal advice.
How much does a backend engineer cost to hire?
There is no separate federal occupation for backend engineers, so the closest benchmark is software 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, about $65.38 per hour. The spread inside that single occupation is unusually wide: the lowest 10 percent earned under $82,460 and the highest 10 percent over $214,670, with the 25th percentile at $105,210 and the 75th at $171,980. Treat those as a national baseline and adjust for your market, the scope you are actually hiring, and whether the person will be an employee or a contractor. A backend engineer who will be your only one, holding the database and the deploy access, sits higher in the range than one joining an existing team, because you are buying judgment and availability as well as output.
How long should a backend engineer interview process be?
Two or three conversations is enough for most small businesses, and adding rounds past that usually loses good candidates rather than improving the decision. A sensible shape is a forty-five minute screening call using the core set, a longer technical conversation covering the two sets that matter most for your systems, and a short paid work sample with a debrief. Score each stage on the rubric immediately afterward while the evidence is fresh. Tell candidates the full shape of the process at the start, including the number of stages and whether the work sample is paid, because backend engineers with options drop out of processes that keep growing. If you need a technical opinion you do not have in-house, bring that person into the second conversation rather than adding a fourth stage.
