Software Engineer Interview Questions and Scorecard
Six question sets for employers hiring a software engineer without a CTO or an HR department: screening, design judgment, code quality, production ownership, leveling calibration, and a weighted scorecard. Every question states why it is worth asking and what a strong answer sounds like. Download as DOCX.
The first software engineer I ever hired interviewed brilliantly and could not ship. He answered every technical question I asked, and I asked the wrong ones. What I never asked was which part of his last project he had personally written, or what he had done the last time production went down at nine on a Friday night. Those two questions would have saved me four months.
Interviewing a software engineer is hard for a small business for a reason that has nothing to do with technology: the title covers a pay range wider than most entire professions, and the standard advice assumes you have a technical interviewer on staff. You often do not. So the questions have to be answerable in plain language and still tell you something real.
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, design judgment, code quality, production ownership, leveling, and a weighted scorecard. Every question states why it is worth asking and what a strong answer sounds like, so you can judge the response rather than the delivery.
TL;DR
Interview a software engineer on five things: what they personally built and own, design judgment at your scale, testing and review habits, production ownership, and communication with non-engineers. The highest-yield question is a follow-up: on that system, what did you write and what did someone else write. Decide the level before you interview, since the same occupation spans a median of $135,980 with a tenth percentile near $82,460. Download six sets and a weighted scorecard as DOCX.
What to Assess in a Software Engineer
Assess five things: what the candidate has personally built and owned, how they choose between imperfect design options, how they test and review, how they behave when a live system breaks, and whether they can explain technical work to someone who is not an engineer. Everything else is a detail of one of those five.
Notice what is missing from that list. Algorithm trivia, obscure language features, and puzzles with a single clever trick predict very little about whether someone will improve the product your business runs on. They persist because they are easy to grade, not because they work. A small employer has no reason to inherit that habit from companies with entirely different problems.
Ownership signals
Names what they personally wrote
Knows if the system is still in production
Criticizes their own past decisions
Judgment signals
Asks questions before designing
Names tradeoffs in cost and time
Buys anything that is not the core product
Production signals
Stabilizes before diagnosing
Has a rollback path and uses it
Owns an outage they caused
Red flags
Only says "we", never "I"
Strong in every technology listed
Dismisses tests and documentation
The most useful thing you can do in any of these areas is follow up until the answer becomes specific. Which users, how much data, what did it cost, what would you do differently. Strong engineers get sharper under that pressure. Weaker candidates get vaguer, and the difference is usually visible within two follow-ups.
Decide the Level Before You Interview
Write down what junior, mid-level, and senior mean at your company before you speak to a single candidate, because level is decided by scope of past ownership rather than by years or by the title on a resume. Mis-leveling is the most expensive mistake small employers make in engineering hiring, and it happens in both directions.
Level
Scope they can own
What to expect
Fit for a small business
Junior
A well-defined task inside someone else's feature
Learns fast, asks good questions, ships small changes safely
Only if someone here can genuinely mentor them
Mid-level
A whole feature, requirement to production, light review
Reliable delivery, sound tests, honest estimates
Good second hire once patterns exist
Senior
An ambiguous problem, not a specification
Design judgment, incident ownership, early risk flags
Usually the right level for a first engineer
Staff and above
Problems crossing systems, teams, or direction
Influence without authority, multiplies others
Rarely needed and hard to keep busy
The leveling set below uses the same questions for every level and scores the depth of the answer against that ladder. A candidate describing a task they completed is answering at junior scope; one describing an ambiguous problem they decided the approach for is answering at senior scope, regardless of the words on their resume.
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 into a role with nobody available to supervise them, because the budget fit felt right. That arrangement fails the business and it is unfair to the person, who needed a mentor and got a title. If nobody here can review their work weekly, do not hire at that level.
The Six Question Sets
Pick the sets that match the role and use them consistently. Core screening applies to every candidate; the rest are chosen based on what the engineer will actually own. For a first engineer who will hold the deployment and the passwords, production ownership matters more than almost anything else.
Core Screening
Every candidate
What they built, what part was theirs, and whether it is still running. Includes the single most useful screening question there is. Start here.
Design and Architecture
Decisions you live with
Tradeoffs at your actual scale, buy versus build, and keeping a system simple enough for one person to maintain after the hire leaves.
Code Quality and Review
Daily habits
What they test and what they skip, how they review, how a change reaches customers safely, and how they verify AI-generated code.
Production Ownership
The set most lists skip
Incidents, deploys, monitoring, and after-hours reality. At a small business the person who built it is the person the outage wakes.
Leveling Calibration
Junior to staff
The same questions with different expected depth, plus a ladder to score against. Mis-leveling is the costliest small-business hiring error.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric with space for written evidence, a level check, and the red-flag list. The asset most question lists leave out.
Which Sets to Use for Which Hire
First engineer who will own everything: screening, production ownership, design judgment, and leveling. Adding to an existing team: screening, code quality and review, and leveling. Contractor for a defined project: screening, design judgment, and the handover and ownership questions inside production. A junior hire with a mentor available: screening and code quality only, scored against the junior column. Use the scorecard with every combination, and pair the result with the software engineer job description level you actually posted.
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 Software Engineer Question Sets
Screening, design judgment, code quality, production ownership, leveling calibration, and a weighted scorecard with red flags. All in one DOCX.
Set 1: Core Screening Questions
The opening set for every candidate at every level: what they built, what part was theirs, whether it is still running, and how they get productive in unfamiliar code. Start here.
Core Software Engineer Screening Questions
CORE SOFTWARE ENGINEER SCREENING QUESTIONS
Candidate: __
Role / level: __
Interviewer: __
Date: _
WHY THIS SET
This is the opening set for every software engineer candidate, at every level.
It is not about trivia. It is about establishing what the person has actually
built, what part of it was theirs, and whether the system is still running.
Ask these first, in this order, and let the follow-ups do the work.
QUESTIONS
1. Walk me through a system you built that is still running today. What does it
do and who uses it?
Why ask: A resume lists projects. This question tests whether any of them
survived contact with real users, which is the difference between a demo and
engineering.
Strong answer: Names a specific system, describes the users and the problem,
and knows whether it is still in production and roughly how much traffic or
data it handles. Talks about what it does before what it was built with.
Weak answer: Stays at the level of technology names, or cannot say whether
anyone still uses it.
2. On that system, what did you personally write, and what did someone else
write?
Why ask: The single most useful screening question. It separates the engineer
who built the thing from the engineer who was standing nearby when it was
built.
Strong answer: Draws a clear, unembarrassed line. "I owned the billing
integration and the background job runner. Another engineer did the front
end." Credits teammates by contribution.
Weak answer: Uses "we" for everything and cannot narrow it down when pushed.
3. What is a technology or part of the stack you are genuinely strong in, and
one you have used but would not call yourself strong in?
Why ask: Calibrated self-assessment predicts how much supervision the person
will need. It also tells you whether they will admit a gap on the job.
Strong answer: Gives a real, specific split and can go deep on the strong
side when you follow up. Being honest about the weak side is the signal.
Weak answer: Claims strength in everything, or gives a list with no depth
behind any item.
4. Tell me about a time you joined an unfamiliar codebase. How did you get
productive?
Why ask: At a small business the new engineer inherits code nobody has
documented. How they orient themselves predicts their first month.
Strong answer: Describes a method: run it locally, follow one real request
end to end, read the tests, make a small change and ship it, ask targeted
questions. Mentions writing down what confused them.
Weak answer: "I just read through everything." No method, no first small win.
5. What is something you built that you would build differently now?
Why ask: Tests whether the candidate learns from their own work rather than
defending it. Engineers who cannot criticize their past code rarely improve
the code they write for you.
Strong answer: A specific decision, why it seemed right at the time, what it
cost later, and what they would choose instead. No blame shifting.
Weak answer: "Nothing, it was fine," or a criticism of someone else's choice.
6. When do you ask for help, and what does that look like?
Why ask: A stuck engineer who stays silent for three days is expensive, and
at a small company nobody is watching closely enough to catch it.
Strong answer: Names a rough time box, describes what they try first, and
comes with what they have already ruled out rather than just "it does not
work."
Weak answer: "I figure it out myself." Treated as a point of pride.
7. What are you building or learning outside of assigned work, if anything?
Why ask: Optional signal, not a filter. Some excellent engineers have no side
projects and full lives. Treat a real answer as a bonus, never the absence of
one as a negative.
Strong answer: Anything concrete and honest, including "nothing right now,
I have young kids and I learn on the job."
WHAT TO LISTEN FOR
•Specifics over vocabulary: users, traffic, data, outcomes
•A clean line between their work and the team's work
•Honest calibration about strengths and gaps
•A repeatable method for getting productive in unfamiliar code
NOTES
__
__
Set 2: Design and Architecture Judgment
For anyone making decisions you cannot cheaply reverse: real tradeoffs, buy versus build, deliberate technical debt, and keeping a system small enough for one person to maintain.
Design and Architecture Judgment Questions
DESIGN AND ARCHITECTURE JUDGMENT QUESTIONS
Candidate: __
Role / level: __
Interviewer: __
WHY THIS SET
Use this set for any engineer who will make decisions you cannot cheaply
reverse: the database, the hosting setup, whether to build or buy. At a small
business, the cost of over-engineering is as high as the cost of under-
engineering, and most generic system design questions test for neither. These
questions test judgment at your actual scale.
QUESTIONS
1. Describe a design decision where there were two reasonable options. What did
you pick and why?
Why ask: The whole set in one question. Engineering is choosing between
imperfect options and living with the consequences.
Strong answer: States both options fairly, names the tradeoff in concrete
terms (time, cost, operational burden, team size), and explains what would
have changed the decision. Often mentions what they gave up.
Weak answer: Presents one option as obviously correct, or picks based on what
is currently fashionable.
2. Here is a feature we want to build. [Describe one real feature from your
roadmap in two or three sentences.] How would you approach it?
Why ask: Uses your actual product instead of a generic puzzle. You will learn
more in ten minutes here than from an hour of abstract architecture talk.
Strong answer: Asks clarifying questions before designing. Sketches the
simplest version that would work, then names what would need to change if
usage grew ten times. Flags what they are unsure about.
Weak answer: Starts designing immediately with no questions, or reaches for
heavy infrastructure before understanding the requirement.
3. When would you buy or use an existing service instead of building it?
Why ask: A small company cannot afford an engineer who builds their own
authentication, payment handling, or email delivery for pride.
Strong answer: Defaults to buying anything that is not the core of the
business, and can name the specific cases where building wins: unusual
requirements, cost at scale, or genuine differentiation.
Weak answer: Wants to build everything, or has never thought about it.
4. How do you keep a system simple enough for a very small team to maintain?
Why ask: The most common way a small business gets hurt is an architecture
that needed the team that built it. If your engineer leaves, what is left has
to be operable by one person.
Strong answer: Talks about fewer moving parts, boring and well-documented
technology, and choosing constraints deliberately. Recognizes that every
service added is a service someone has to run.
Weak answer: Describes an architecture appropriate to a company a hundred
times your size.
5. Tell me about technical debt you chose to take on deliberately. How did you
track it?
Why ask: Distinguishes an engineer who trades speed for cleanliness on
purpose from one who leaves a mess and calls it pragmatism.
Strong answer: A specific shortcut, the reason (a deadline, an unproven
feature), where it was written down, and either how it was repaid or why it
never needed to be.
Weak answer: Treats all debt as either unacceptable or invisible.
6. How do you decide what to work on when everything is described as urgent?
Why ask: At a small business the engineer often does their own prioritizing
because there is no product manager to do it for them.
Strong answer: Asks about business impact, talks to whoever owns the outcome,
and pushes back with options rather than a flat no.
Weak answer: Waits to be told, or picks whatever is most technically
interesting.
WHAT TO LISTEN FOR
•Questions asked before answers are given
•Tradeoffs named in cost, time, and operational burden
•A bias toward the simplest thing that works at your scale
•Comfort saying "I do not know yet, here is how I would find out"
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Daily habits rather than recall: what they test and what they skip, how they review, how a change safely reaches customers, and how they verify AI-assisted code before it ships.
Code Quality, Testing, and Review Questions
CODE QUALITY, TESTING, AND CODE REVIEW QUESTIONS
Candidate: __
Role / level: __
Interviewer: __
WHY THIS SET
This set covers what the engineer does every day rather than what they can
recall under pressure. It works even if you cannot read code yourself, because
every question is about habits and reasoning, not syntax. These habits are what
you will live with for years after the hire.
QUESTIONS
1. What do you choose to write tests for, and what do you deliberately not test?
Why ask: "Do you write tests" gets a yes from everyone. Asking what they skip
forces a real position and reveals whether they think about cost.
Strong answer: Tests the parts where a bug would be expensive or hard to
detect: money, permissions, data integrity, complicated business rules. Skips
trivial code and volatile interface details on purpose.
Weak answer: "Everything," "one hundred percent coverage," or "we did not
have time for tests" with no further thought.
2. Walk me through how you review someone else's code. What are you looking for?
Why ask: Review is where an engineer's standards become visible to others,
and it is how a second hire eventually learns your codebase.
Strong answer: Correctness first, then readability and maintainability, then
style. Distinguishes blocking comments from suggestions. Mentions asking
questions rather than issuing verdicts.
Weak answer: Only style and formatting, or "I approve it if the tests pass."
3. Tell me about feedback you received on a code review that you disagreed with.
What happened?
Why ask: Tests ego and collaboration in a place where both actually show up.
A small team cannot absorb an engineer who fights every review.
Strong answer: Describes disagreeing openly, giving reasons, and either
changing their mind or accepting the decision without resentment.
Weak answer: Cannot recall any disagreement, or the story ends with everyone
agreeing they were right.
4. How do you make sure a change you ship does not break something else?
Why ask: The core competence for anyone touching a live system that a
business depends on for revenue.
Strong answer: A real chain: automated tests, running it locally against
realistic data, a staging step or feature flag, a small deploy, and watching
something afterward.
Weak answer: "I test it manually," with no automation and nothing watched
after release.
5. What does a good commit or pull request look like to you?
Why ask: Small, well-described changes are the difference between a codebase
you can hand to someone else and one you cannot.
Strong answer: Small and focused, with a description that explains why rather
than what, and enough context for someone reading it in a year.
Weak answer: Has no view, or describes very large batched changes as normal.
6. How do you use AI coding assistants, and how do you check what they produce?
Why ask: Nearly every engineer now uses them. The differentiator is not
whether they use the tools but whether they review the output before it
reaches your customers.
Strong answer: Open about using them, describes them as a fast first draft,
and always reads and tests the result. Knows where the tools are unreliable.
Weak answer: Denies using them at all, or accepts generated code without
review.
7. What is your approach to documentation?
Why ask: At a company with one or two engineers, undocumented systems become
unmaintainable the moment that person is unavailable.
Strong answer: Writes down what is not obvious from the code: setup steps,
deployment, decisions and why. Documents while doing the work, not after.
Weak answer: "The code documents itself," or promises documentation later.
WHAT TO LISTEN FOR
•A defensible position on what is worth testing
•Review habits that separate blocking issues from preferences
•A real safety chain between writing code and it reaching users
•Honesty about AI tools plus a verification habit
NOTES
__
Set 4: Production Ownership and Incidents
The set most question lists omit and the one that often predicts most for a small employer: incidents, unreproducible bugs, deploys, monitoring, and after-hours reality.
Production Ownership and Incident Questions
PRODUCTION OWNERSHIP, DEPLOYS, AND INCIDENT QUESTIONS
Candidate: __
Role / level: __
Interviewer: __
WHY THIS SET
At a company with a large engineering organization, an incident wakes a
dedicated on-call rotation. At a small business, it wakes whoever built it, and
often that is your only engineer. This set is the one most generic question
lists omit, and for a small employer it is frequently the most predictive.
Use it for anyone who will own anything customers depend on.
QUESTIONS
1. Tell me about the worst production incident you have been part of. What did
you do in the first thirty minutes?
Why ask: Incident behavior is nearly impossible to fake, and the first thirty
minutes reveal whether someone stabilizes or panics.
Strong answer: Stop the bleeding first (roll back, disable the feature,
failover), communicate to whoever is affected, then find the cause. Says
plainly what they got wrong.
Weak answer: Jumps straight to root-cause analysis while customers are down,
or has never seen a real incident and does not say so.
2. Describe a bug that only happened in production and could not be reproduced
locally. How did you track it down?
Why ask: The hardest class of debugging, and the one that decides whether an
engineer can support a live product.
Strong answer: A narrowing method: logs, timing, what changed recently, which
users are affected, adding instrumentation on purpose. Distinguishes evidence
from guessing.
Weak answer: A trial-and-error story with no structure, or restarting the
server as the solution.
3. Walk me through how you deploy. What happens between finishing a change and
customers seeing it?
Why ask: Deployment tells you what kind of engineering culture the candidate
has lived in and what they will build for you.
Strong answer: An automated or at least written and repeatable path, with a
way to roll back. Comfortable deploying small changes often.
Weak answer: A long manual ritual, or deploys so rare and risky that they
happen at night.
4. What do you monitor, and how would you find out something broke before a
customer told you?
Why ask: Whether the engineer takes responsibility for the system running,
The same five questions with the expected depth spelled out for junior, mid-level, senior, and staff, plus calibration rules so the title on a resume does not set your pay band.
Leveling Questions: Junior, Mid, Senior, Staff
LEVELING QUESTIONS: JUNIOR, MID-LEVEL, SENIOR, AND STAFF
Candidate: __
Level being hired: __
Interviewer: __
WHY THIS SET
"Software engineer" is one title covering a pay range wider than most entire
professions. The same national occupation reports a tenth percentile near
$82,000 and a ninetieth above $214,000. Mis-leveling is the expensive mistake
small employers make most often: paying senior rates for mid-level judgment, or
hiring a junior into a job that has nobody to supervise them.
The method here is not different questions per level. It is the SAME questions
with different expected depth. Ask, then compare the answer against the ladder.
THE LADDER (ADAPT THE WORDING TO YOUR COMPANY)
JUNIOR
Scope: a well-defined task. Needs a person available to unblock them.
Expect: learns fast, asks good questions, ships small changes safely.
Do not expect: design decisions, estimates, or working without support.
Only hire at this level if someone here can actually mentor them.
MID-LEVEL
Scope: a whole feature, from requirement to production, with light review.
Expect: reliable delivery, sound tests, honest estimates, few surprises.
Do not expect: choosing the architecture or setting technical direction.
SENIOR
Scope: an ambiguous problem, not a specification. Decides how it gets built.
Expect: design judgment, incident ownership, raising risks early, making other
people better through review and documentation.
This is the level most small businesses actually need for a first engineer.
STAFF AND ABOVE
Scope: problems that cross systems and teams, or a technical direction.
Expect: influence without authority, and multiplying other engineers' output.
Most small businesses do not need this level and cannot keep it busy.
QUESTIONS AND THE LEVEL EACH ANSWER SIGNALS
1. Tell me about the largest piece of work you owned end to end.
Junior: a task inside someone else's feature.
Mid-level: a complete feature, delivered to production.
Senior: an ambiguous problem where they decided the approach.
Staff: a body of work spanning systems or several people.
2. How do you estimate?
Junior: has not really had to.
Mid-level: breaks work down and gives a range for the pieces.
Senior: gives a range, names the specific unknowns that would move it, and
raises slippage before the date, not on it.
Staff: reframes the request when a cheaper approach gets most of the value.
3. What happens when the requirement you were given turns out to be wrong?
Junior: reports it and waits.
Mid-level: reports it and proposes an option.
Senior: goes to whoever owns the outcome, presents choices with costs, and
drives it to a decision.
4. How have you made other engineers better?
Junior: not expected.
Mid-level: careful code review, helpful answers.
Senior: documentation, review that teaches, onboarding a teammate.
Staff: standards, tooling, or a decision that improved everyone's work.
5. What would you do in your first ninety days here?
Junior: learn the codebase and ship small changes.
Mid-level: take a feature and deliver it.
Senior: understand the business, find the largest risk, and fix or flag it.
Any level: they should have asked enough questions to answer this at all.
CALIBRATION RULES
•Decide the level BEFORE you interview, and write down what it means here.
•Title on the resume is not the level. Scope of past ownership is.
•Years of experience correlate weakly. A candidate can repeat one year eight
times, or reach senior scope in four.
•If a candidate interviews a level above your posting, decide whether you can
pay for it and keep it interesting. If not, be honest rather than hopeful.
•If a candidate interviews a level below, do not talk yourself into it because
you like them. Hiring a junior with nobody to mentor them fails both of you.
NOTES
__
Set 6: Scorecard and Red Flags
A weighted 1-to-5 rubric with space for written evidence, a level check to run before the offer, and a red-flag checklist. Use it with every set above and for every candidate.
Software Engineer Scorecard and Red Flags
SOFTWARE ENGINEER INTERVIEW SCORECARD AND RED-FLAG CHECKLIST
Candidate: __
Level being hired: __
Interviewer: __
Date: _
HOW TO USE THIS
Fill this in immediately after the interview, while the evidence is fresh.
Anchor every score to something the candidate actually said. If more than one
person interviews, each scores independently BEFORE anyone discusses, so the
loudest opinion does not set the tone. Use the same scorecard for every
candidate at the same level.
Set your weights before you interview anyone. The weights below are a starting
point for a small business hiring an engineer who will own a live product.
Change them to fit the job, then leave them alone.
Rating scale:
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or a red flag
SCORING AREAS
Engineering depth and real ownership Weight: 25%
Built and owned real systems; clear about their own contribution.
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Design judgment at our scale Weight: 20%
Names tradeoffs; picks the simplest thing that works; buys before building.
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Code quality, testing, and review habits Weight: 15%
Defensible testing position; reviews for correctness; ships safely.
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Production ownership Weight: 20%
Stabilizes first in an incident; monitors; owns the system running.
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Communication with non-engineers Weight: 20%
Explains technical work plainly; flags risk early; asks before building.
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Weighted total: ______ / 5
LEVEL CHECK
Level we posted: _____ Level this candidate demonstrated: _____
If these do not match, resolve it before the offer, not after.
RED FLAGS (WEIGH CAREFULLY, DO NOT AUTO-REJECT)
[ ] Uses "we" for everything and cannot say what they personally wrote
[ ] Claims deep strength in every technology named
[ ] Has never caused or been near a production problem, in years of work
[ ] Dismisses testing, review, or documentation as overhead
[ ] Reaches for heavy infrastructure before understanding the requirement
[ ] Blames previous employers, teammates, or "bad management" for everything
[ ] Cannot explain any technical decision in plain language
[ ] Will not discuss code ownership, accounts, or handover
[ ] Resists a paid work sample while giving no alternative evidence
DECISION
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Biggest strength: _____
Biggest concern: ______
What would resolve the concern: _____
Interviewer signature:
What a Strong Answer Sounds Like
Strong answers share a shape regardless of the topic: they are specific, they name a tradeoff, and they admit something. Weak answers stay abstract, present decisions as obvious, and contain no mistakes. You can recognize that pattern without reading a line of code.
On that system, what did you personally write, and what did someone else write?
Strong answer: Draws a clear line without embarrassment: owned the billing integration and the job runner, another engineer built the front end. Credits teammates by specific contribution rather than in general. This is the fastest way to tell a builder from a bystander, and it costs you one follow-up question.
Weak answer: Everything is "we". Pushed once, the answer gets vaguer rather than sharper, or the scope quietly expands to cover the whole system.
What do you choose to write tests for, and what do you deliberately not test?
Strong answer: Takes a real position: tests where a bug would be expensive or silent, such as money, permissions, and data integrity, and skips trivial code on purpose. The willingness to name what they skip is the signal, because it shows they weigh cost rather than reciting a rule.
Weak answer: "Everything" or "one hundred percent coverage," which usually means no considered position, or a flat "we never had time" with no further thought.
Tell me about the worst production incident you were part of. What did you do in the first thirty minutes?
Strong answer: Stops the bleeding first: rolls back, disables the feature, or fails over. Tells whoever is affected. Only then hunts the cause. Names plainly what they got wrong. Anyone with real production experience has a story here and does not need to search for it.
Weak answer: Begins root-cause analysis while customers are still down, or claims never to have seen an incident after years of production work.
Notice that none of those three requires technical knowledge to grade. That is deliberate. The questions in these sets were chosen because a non-technical interviewer can score them honestly, which is the constraint most technical interview advice quietly ignores.
First Engineer vs Adding to a Team
Hiring your first engineer and adding a third engineer to an existing team are different jobs that share a title. The first engineer sets patterns nobody will revisit for years and becomes a single point of failure for the systems the business runs on. Weight the interview accordingly.
What you are testing for
First engineer
Joining an existing team
Production ownership and incident response
Design judgment on irreversible decisions
Documentation and handover discipline
Code review and collaboration habits
Ramping inside patterns someone else set
Communication with non-engineers
A false value above does not mean the trait is irrelevant, only that it is not what decides the hire. For a first engineer, the question that matters most is what happens the day they leave, which is why handover, documentation, and account ownership belong in the interview rather than in the exit conversation. If you are still deciding whether to hire an employee or a contractor at all, that choice shapes the questions too, and the route you use to find candidates shapes your pipeline more than any single question does.
Work Samples Beat Whiteboard Puzzles
A short, paid work sample that resembles your real 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.
Pay for the time. Unpaid multi-day projects screen out precisely the experienced people with current jobs and family responsibilities that a small business most wants 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 they would need from you to make the same decision better. A candidate who submits mediocre code and debriefs brilliantly is usually a better hire than the reverse, because you are buying judgment for years, not one afternoon of output.
Scoring a Software Engineer Interview
Score immediately after each interview, 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 this specific role are decided by the job rather than by whichever answer impressed you most.
Scoring area
Suggested weight
What a 5 looks like
Engineering depth and ownership
25%
Built and owned real systems; clear about their own contribution
Design judgment at our scale
20%
Names tradeoffs, buys before building, picks the simplest thing that works
Code quality, testing, review
15%
Defensible testing position; reviews for correctness before style
Production ownership
20%
Stabilizes first in an incident; monitors; owns an outage they caused
Communication with non-engineers
20%
Explains technical work plainly and flags risk before it lands
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 level the candidate demonstrated against the level 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 Software Engineer Costs
Software engineer pay varies more by level than by any other factor, which is why the leveling work above matters more than any salary benchmark. Use federal data as a national baseline, then adjust for your market, the level 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. The occupation held roughly 1.69 million jobs in 2024, with about 115,200 openings projected each year through 2034 (U.S. Bureau of Labor Statistics).
That range spans more than $130,000 between the tenth and ninetieth percentile for a single job title, which is exactly why a resume title tells you almost nothing about cost. An engineer who will be your only one, holding deployment and the credentials, sits higher in the band than one joining an established team, because you are paying for judgment as well as output. If you are weighing an employee against a contract engagement, the employee versus contractor distinction changes both the cost and the questions you should ask about ownership of the work.
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 simultaneously. Engineering interviews have a few specific traps worth naming.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that touch them create risk even when they are meant as friendly conversation. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Engineering interviews have their own version of this trap: asking where someone learned to code as a proxy for age, asking about a visible accent or where they are originally from, or asking about family commitments in the context of on-call. Ask instead whether the candidate can perform the essential functions of the role and whether they are authorized to work. This is general information, not legal advice.
Same questions, same order, every candidate
Structured interviewing is the single highest-leverage habit available to a small employer. Write the questions before you meet anyone, ask the same core set of every candidate at the same level, and score against the same rubric. It predicts on-the-job performance far better than a conversation that goes wherever rapport takes it, and it makes bias harder to act on because you compare written evidence rather than impressions. It also protects you: a consistent, job-related process is far easier to explain later than a series of one-off chats. The sets on this page are built to be used exactly this way.
Treat coding tests as selection procedures
A take-home task, a live coding exercise, or an automated screen is a selection procedure, and federal guidance treats any test used to make employment decisions as something that should be job-related and consistent with business necessity. Practically, that means the task should look like the work: a small change to realistic code, not a puzzle unrelated to anything you do. Give every candidate the same brief, the same time cap, and the same stated scoring criteria. Pay for anything that takes meaningful time, and keep it short enough that people with caregiving responsibilities or a current job are not screened out by availability. This is general information, not legal advice.
Decide the level before you interview
Write down what junior, mid-level, and senior mean at your company, and what the role must accomplish in its first ninety days, before you speak to a single candidate. Without that, interviews drift toward whoever is most impressive in conversation rather than whoever fits the job, and the pay conversation becomes a negotiation you have not prepared for. A written level definition also makes the interview fairer, because every candidate is measured against the same standard rather than against the last person you spoke to. It is the cheapest possible preparation and it prevents the most expensive mistake.
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 job 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 an Engineer Without HR
A large company runs a software engineer through coordinated panels with a recruiter managing scorecards and a hiring committee calibrating levels. A small business runs the founder, alone, between everything else, often without anyone technical in the room. That reality changes what a good process looks like, and it is where the avoidable mistakes cluster.
You are interviewing an engineer and you cannot read the code yourself
Most owners hiring their first engineer are not engineers, and the standard advice, run a technical screen, assumes a technical interviewer you do not have. You do not need one to interview well. Every question in these sets is answerable in plain language, and every one comes with what a strong answer sounds like, so you are judging structure and honesty rather than syntax. Ask the candidate to explain a past project to you as if you were a customer: an engineer who cannot make their work legible to a non-engineer will be expensive to work with regardless of how good the code is. If you want a technical read on top of that, pay a trusted senior engineer for two hours to sit in on one interview. That is far cheaper than a bad hire.
Your first engineer holds the passwords, the code, and the keys to the business
At a company with an engineering department, no single person is a point of failure. At a small business, the first engineer often is: they own the deployment, the domain, the hosting account, and the only copy of how any of it works. That changes what you interview for. Weight production ownership and documentation heavily, ask directly about a handover they have actually done, and settle ownership before the engagement rather than at the end of it. Register domains, repositories, and hosting to the company with you holding administrative access, and put the intellectual property assignment in writing, especially for a contractor. A candidate who resists any of this is telling you something worth hearing.
Mis-leveling costs more than any single interview question
The wage range for this one occupation is enormous, and the title on a resume does not tell you where a candidate sits inside it. Small employers get burned in both directions: paying senior rates for mid-level judgment, or hiring a junior into a role with nobody available to mentor them, which fails the business and the person. Decide the level before you interview, write down what it means at your company, and score every candidate against that definition rather than against each other. If someone interviews a level above the job, be honest about whether you can pay for it and keep it interesting, because the alternative is a resignation in eight months. The leveling set on this page exists for exactly this.
The interview is the easy part; the offer and the first ninety days decide whether it works
Once you choose someone, the job shifts from evaluating to hiring well: a clear written offer, a confidentiality and intellectual-property agreement signed before the first commit, access provisioned from company-owned accounts, and a first task small enough to ship in week one. FirstHR fits that side for a small business: send the offer for e-signature, run the new hire paperwork and onboarding workflow, assign the access and policy tasks, and keep the signed documents and interview records on the employee profile where you can find them later. To be clear on scope, FirstHR is an onboarding and HR platform, not a code repository, a deployment tool, or an applicant tracking system, so pair it with those. Applicant tracking is coming soon to FirstHR.
The whole point of a written question set and a rubric is to make one person's interview as rigorous as a hiring committee's without the overhead of one. Browse the rest of the hiring templates if you need the posting, the evaluation form, or the offer to go with it. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
The interview is step one. Onboarding an engineer carries a few extra steps because of the access involved: a written offer and a confidentiality agreement signed before the first commit, repository and hosting access provisioned from company-owned accounts, and the standard new hire paperwork alongside it.
Offer, confidentiality, and IP
Confirm role, level, and pay in writing, and have the engineer sign a confidentiality and intellectual-property agreement before the first commit.
Access from company accounts
Repositories, hosting, and tools provisioned from accounts the business owns, with you holding administrative rights and least privilege elsewhere.
Ship something in week one
Name a small, real first change. Shipping once beats two weeks of reading, and it tests the whole path from laptop to customer.
Define thirty, sixty, ninety
Say what good looks like at each mark and who to ask, so a new engineer builds momentum instead of guessing at priorities.
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 surfaces 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.
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, design judgment, testing and review habits, production ownership, and communication with non-engineers.
The highest-yield question is a follow-up: on that system, what did you write and what did someone else write.
Decide and write down the level before you interview, because scope of past ownership sets the level, not the title on a resume.
Weight production ownership heavily for a first engineer, since they will be the person an outage wakes.
Use a short paid work sample that resembles real work, and score the debrief rather than the code alone.
Score on a weighted rubric independently, then check the demonstrated level against the posted level before any offer.
Use BLS data as a baseline: software developers reported a median of $135,980 a year in May 2025.
Frequently Asked Questions
What questions should I ask a software engineer in an interview?
Ask questions that force specifics about work the candidate has actually done, across five areas: what they built and personally owned, how they make design tradeoffs, how they test and review code, how they handle production incidents, and how they communicate with non-engineers. The highest-yield question in any software engineer interview is a follow-up: on the system you just described, what did you personally write and what did someone else write. It separates the engineer who built the thing from the engineer who was nearby when it was built, and it takes ten seconds to ask. Add a question about the worst production incident they were part of, because incident behavior is nearly impossible to fake. Avoid trivia and algorithm puzzles that have 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 software engineer if I am not technical?
You can run a strong interview without reading code, because the questions that predict success are about judgment and habits rather than syntax. Ask the candidate to explain a past project as if you were a customer; an engineer who cannot make their work legible to a non-engineer will be costly to work with no matter how good the code is. Ask what they personally wrote, what they choose not to test and why, what they did in the first thirty minutes of an incident, and when they buy instead of building. Each of those has a recognizable strong answer that requires no technical knowledge to spot: specific, structured, honest about mistakes. If you want a technical read on top of that, pay a trusted senior engineer for two hours to sit in on one interview and review a work sample. That costs far less than a bad hire.
What is the difference between a junior, mid-level, and senior software engineer?
The difference is scope of ownership, not years of experience. A junior engineer completes a well-defined task and needs someone available to unblock them, so only hire at that level if you actually have a person who can mentor. A mid-level engineer takes a whole feature from requirement to production with light review and gives honest estimates. A senior engineer is handed an ambiguous problem rather than a specification, decides how it gets built, owns incidents, raises risks before deadlines slip, and makes other engineers better through review and documentation. That senior level is what most small businesses genuinely need for a first engineering hire. Staff and above operate across systems or set technical direction, which most small companies cannot keep busy. Judge the level by the scope of past ownership, not by the title printed on the resume.
Should I give a coding test or a take-home assignment?
A short, paid work sample that resembles your real work predicts performance better than a whiteboard puzzle, and candidates resent it far less. Keep it to two or three hours with a hard cap, base it on a realistic task rather than an algorithm riddle, publish the criteria you will score against, and give every candidate the same brief. Pay for the time; unpaid multi-day projects screen out exactly the experienced people with jobs and families 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 another reason to keep the task close to the work. The debrief matters more than the code: ask what they would do with two more days, what they left out deliberately, and where they used AI assistance. This is general information, not legal advice.
What are red flags in a software 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 listed on the resume, having never caused or been near a production problem after years of work, dismissing testing or documentation as overhead, reaching for heavy infrastructure before understanding the requirement, blaming previous employers for every difficulty, and being unable to explain a technical decision in plain language. Resistance to discussing code ownership, account access, or handover is a serious one for a small business, because your first engineer often holds the keys to everything. Treat each as a prompt to probe rather than an automatic rejection; a nervous candidate can produce one of these and still be excellent. Two or three together is a pattern.
How much does a software engineer cost to hire?
Pay varies enormously by level, location, and industry, which is why deciding the level first matters more than any salary benchmark. 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 one 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 level you are actually hiring, and whether the person is an employee or a contractor. An engineer who will be your only one, holding deployment and the passwords, sits higher in the range than one joining an existing team, because you are buying judgment as well as output.
What questions are illegal to ask a software engineer candidate?
Avoid anything that probes characteristics protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Engineering interviews have their own versions of these traps. Asking when or where someone learned to code can function as a proxy for age. Asking about a candidate's accent or where they are originally from touches national origin. Asking whether family commitments would interfere with on-call touches family status and disability. You may ask whether the candidate can perform the essential functions of the role, whether they can meet a stated on-call expectation you apply to everyone in the job, and whether they are legally authorized to work. Asking the same job-related questions of every candidate is the simplest protection available. This is general information, not legal advice.
How long should a software engineer interview process take?
Two or three rounds is enough for most small businesses, and speed is a competitive advantage when you are hiring against larger employers. A practical shape is a 30 minute screening conversation, a 60 minute structured interview using two or three of the question sets on this page, and a short paid work sample with a 30 minute debrief. Score after each stage while the evidence is fresh rather than at the end. Resist adding rounds because a decision feels hard; more interviews rarely produce more information, and every extra week loses candidates to employers who moved faster. If you genuinely cannot decide, the missing evidence is usually a work sample rather than another conversation. Tell candidates the shape of the process up front and hold to it.
