Six question sets for employers hiring a developer without a CTO or an HR department: screening, code review, debugging, tradeoffs, a take-home brief, and a weighted scorecard, every question with what a strong answer sounds like. Download as DOCX.
The first time I hired a developer, I did what most founders do: I found a list of coding questions online, asked them in order, and had no idea what to make of the answers. The candidate solved the puzzle. He also could not explain why he had chosen the approach, and six weeks later nobody could change the code he left behind. The questions were fine. I had no standard to judge them against.
At FirstHR, we build for small businesses that hire without an HR department, and often without a CTO either. This page is the interviewer's side of a coding interview: 35+ questions grouped into six sets, each with a stated reason it is worth asking and a note on what a strong answer sounds like, plus a weighted scorecard so the decision rests on written evidence.
Nothing here is written for a candidate preparing to answer. It is written for the person deciding what to ask, and it assumes you may not read code yourself.
TL;DR
A coding interview should test five things: real experience with code the candidate shipped, code reading and review, debugging method, design judgment, and communication. Replace algorithm puzzles with a short code reading exercise on your own system and a capped, paid work sample. Set scorecard weights before you interview, score independently, and compare evidence. Download 35+ questions and the scorecard as DOCX.
What a Coding Interview Should Test
A coding interview should test whether someone can read, change, and be trusted with the code your business depends on, which is a different question from whether they can invent an algorithm on a whiteboard. Developers spend far more time reading and modifying existing code than writing new code from scratch, so reading is the skill worth the most interview minutes.
For a small business the weighting shifts further. You are usually hiring one person, not a team, and that person will inherit whatever exists, work with incomplete information, and make decisions nobody reviews. Debugging method and maintainability matter more here than they would at a company with layers of review around every change.
What to test
How to test it
Why it matters at your size
Real coding experience
Code they wrote and shipped, in their words
You are buying one person’s output, not a team’s
Code reading and review
40 to 80 lines of your own code, one planted bug
Most of the job is changing code someone else wrote
Debugging method
A slow page with nothing in the logs
Nobody else will diagnose it for them
Design judgment
Two ways they could have built the last project
You live with decisions you cannot cheaply reverse
Communication
Explaining any of the above in plain language
You need to understand what you are paying for
The most reliable way to assess all five is a structured interview, where every candidate answers the same core questions scored on the same rubric. That is why this page is built around fixed question sets and a scorecard rather than a loose list to improvise from.
Why Algorithm Puzzles Misfire at a Small Business
Algorithm puzzles measure recent practice with a particular style of problem, which is a defensible proxy at a company running thousands of standardized interviews a year and a poor one when you are hiring a single developer to maintain your product. They also produce a score you cannot interpret if you do not code.
There is a second cost. Puzzle-heavy interviews favor candidates who have been drilling for interviews over candidates who have been shipping software, and those are frequently different people. If your goal is someone who can take a vague request and turn it into a working, maintainable change, test that directly.
What it does
Algorithm puzzle
Code reading + work sample
Resembles the actual job
Interpretable by a non-coder
Rewards recent interview practice
Shows how they handle your codebase
Produces evidence you can score
None of this means the interview should be soft. A code reading exercise with a planted bug is harder to fake than a memorized puzzle, and a capped work sample with published criteria gives you something concrete to score. Replace the puzzle with work, not with conversation alone.
The Six Question Sets
The sets below map to the five areas above, plus a scorecard. Use the core screening set with every candidate, then add the sets that fit the role: code reading for anyone joining an existing codebase, design and tradeoffs for anyone whose decisions you will live with.
Core Coding Screening
Every candidate
The opening set for any coding hire: code they are proud of, what they personally wrote, what is still running, and when they ask for help. Start here.
Code Reading and Review
The skill most kits skip
Send 40 to 80 lines of your own code with one planted bug and ask what it does. Works even if you cannot read the code yourself.
Debugging and Problem-Solving
How they think
The highest-value set for a small business: a slow page with no errors, an unreproducible bug, and the first ten minutes of an outage.
Design and Tradeoffs
Choices you live with
For anyone making decisions you cannot cheaply reverse: two ways to build it, build versus buy, and keeping it simple enough for a tiny team.
Work Sample and Debrief
Show, do not tell
A fill-in take-home brief with a time cap, stated scoring criteria, and an AI-tool disclosure, plus the eight debrief questions that follow it.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric plus a red-flag checklist, so the decision rests on written evidence rather than on who interviewed most smoothly.
Match the Sets to the Hire
First developer who will own everything: screening, debugging, design and tradeoffs, plus the work sample. Junior joining an existing codebase: screening, code reading, debugging. Contractor building something you will inherit: design and tradeoffs plus the work sample, weighted toward documentation. A specialist role such as a Python developer or a QA engineer takes the same shape with language-specific follow-ups added on top.
6 Free Question Sets to Download
Download all six as a single Word document or copy individual sets. Each follows the same structure: how to use it, the questions with a reason to ask and a note on what a good answer sounds like, what to listen for, and space for notes. The work sample set is a fill-in brief you can send as is.
Download All 6 Coding Question Sets
Screening, code review, debugging, design, a work sample brief, and a weighted scorecard. All in one DOCX.
Set 1: Core Coding Screening Questions
The opening set for any coding hire: code they are proud of, what they personally wrote, what is still running and what broke, and how they decide to ask for help. Start here with every candidate.
Core Coding Screening Questions
CORE CODING SCREENING QUESTIONS
Candidate: __
Role: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the opening set for any coding hire, from a junior developer to a
senior one. Ask 5 to 7 of these. You are not grading syntax and you do not
need to code yourself. You are checking that the candidate has actually
written and shipped the code they claim, can explain it in plain language,
and gets more specific when you push rather than vaguer. Use the "why ask"
and "good answer" notes to judge each response.
QUESTIONS
1. Show me a piece of code you are proud of and walk me through what it does.
(Why ask: it moves the interview off resume claims and onto real work
within five minutes. Good answer: explains the problem first, then the
code, and names what they would change today.)
2. What did you personally write in your last project, and what did others
write?
(Why ask: on a small team you are buying one person's output, not a
team's. Good answer: draws a clear line without diminishing colleagues.)
3. Which language or stack are you strongest in, and which do you avoid?
(Why ask: honest self-assessment predicts behavior when they hit something
unfamiliar. Good answer: names both sides plainly and gives an example of
learning something outside their comfort zone.)
4. Tell me about code you wrote that is still running. What broke, and what
did you do about it?
(Why ask: writing code is easy, owning it is hard. Good answer: a real
failure, the fix, and the change that stopped it recurring.)
5. How do you decide when to write a test, and what do you test first?
(Why ask: it separates people who ship something maintainable from people
who ship something that works once. Good answer: has a rule of thumb tied
to risk, not a rehearsed slogan about coverage percentages.)
6. How do you decide a problem is above your level and you need help?
(Why ask: a developer who stays silently stuck for three days is expensive
on a small team. Good answer: has a time box or a clear trigger.)
7. What is the most recent thing you learned, and what made you learn it?
(Why ask: self-directed learning is the cheapest training you will ever
get. Good answer: a specific thing driven by a specific problem.)
WHAT TO LISTEN FOR
•Specifics that get sharper under follow-up, not vaguer
•Ownership language: what they did, not what "the team" did
•Honest boundaries around what they have not built
•Plain explanations a non-technical listener can follow
NOTES
__
__
Set 2: Code Reading and Code Review Questions
Send 40 to 80 lines of your own code with one planted bug, one unclear name, and one risky shortcut. Because you know what is in there, you can score the answers without reading the code yourself.
Code Reading and Code Review Questions
CODE READING AND CODE REVIEW QUESTIONS
Candidate: __
Role: __
Interviewer: __
HOW TO RUN THIS SET
Developers spend far more time reading code than writing it, so reading is
the skill worth testing. Send a short sample of real code from your own
system, 40 to 80 lines, ten minutes before the call, or share it on screen.
Pick something with one genuine bug, one unclear name, and one risky
shortcut. Then ask the questions below. This set works even if you cannot
read the code yourself, because you already know where the problems are.
QUESTIONS
1. Read this through and tell me what it does, in plain language.
(Why ask: comprehension comes before critique. Good answer: a short,
accurate summary without jargon, and honest about the parts they are
unsure of.)
2. What would you change first, and why that first?
(Why ask: it tests judgment about priority, not just taste. Good answer:
picks correctness or a real risk over formatting preferences.)
3. Is there a bug in here? Walk me through how you would confirm it.
(Why ask: finding the planted bug is good, describing how they would
verify it is better. Good answer: names a way to test the theory.)
4. What would you leave alone, even though you would have written it
differently?
(Why ask: a developer who rewrites everything they inherit is a risk on a
small system. Good answer: separates preference from problem.)
5. How would you tell the author about this in a code review?
(Why ask: review tone shapes whether a small team stays functional. Good
answer: specific, kind, focused on the code rather than the person.)
6. What would you want to know about the rest of the system before changing
this?
(Why ask: strong developers ask about context. Good answer: names
dependencies, callers, tests, or data volume.)
7. How do you handle a review comment you disagree with?
(Why ask: you are hiring a colleague. Good answer: makes the case once
with reasoning, then commits to the decision.)
WHAT TO LISTEN FOR
•Reads before judging, and says what is unclear
•Prioritizes correctness and risk over style preferences
•Explains the code to you, not at you
•Review feedback you would be comfortable receiving yourself
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
The highest-value set for a small business: a slow page with nothing in the logs, an unreproducible bug, and the first ten minutes of an outage. Ask them to reason out loud and do not rescue them early.
Debugging and Problem-Solving Questions
DEBUGGING AND PROBLEM-SOLVING QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHY THIS SET MATTERS MOST
For most small businesses, the highest-value coding skill is not knowing a
particular framework, it is fixing something broken with incomplete
information. This is the closest thing to a live sample of how a candidate
thinks. Ask them to reason out loud, and do not rescue them too early. A long
silence followed by a good question is a strong signal.
QUESTIONS
1. A customer says a page is slow. There is no error in the logs. What do you
check first, second, and third?
(Why ask: it tests method over memory. Good answer: reproduces it, narrows
the scope, checks recent changes, measures before guessing.)
2. Walk me through the last bug you could not reproduce. How did it end?
(Why ask: unreproducible bugs are where discipline shows. Good answer:
describes logging and narrowing, and is honest if it stayed unsolved.)
3. Something broke in production and you do not know why. Do you roll back or
fix forward? Talk me through the call.
(Why ask: judgment under pressure. Good answer: restores service first,
then investigates, and knows why that order matters.)
4. How do you tell a symptom from a root cause?
(Why ask: symptom-patching becomes the debt you pay for later. Good
answer: gives a concrete example of each and knows when a quick patch is
still the right call.)
5. Tell me about a bug you shipped. How did you find out, and what changed
afterward?
(Why ask: everyone ships bugs, and how they respond is the signal. Good
answer: no defensiveness, a concrete process change.)
6. You have two hours and three broken things. How do you decide the order?
(Why ask: prioritization is most of the job on a small team. Good answer:
ranks by customer impact and reversibility, and says so out loud.)
7. What do you do when you have been stuck on the same problem for an hour?
(Why ask: it reveals whether they have a reset habit. Good answer: a
specific tactic, plus a point where they ask someone.)
WHAT TO LISTEN FOR
•A method they follow, not a lucky guess they remember
•Measures and reproduces before changing anything
•Restores service first, investigates second
•Says "I do not know yet, here is how I would find out"
NOTES
__
Set 4: Design, Tradeoffs, and Maintainability Questions
For anyone making choices you cannot cheaply reverse: two ways to build it, build versus buy, deliberate technical debt, and what makes code easy for the next person to change. Ask these even for a junior hire.
Design, Tradeoffs, and Maintainability Questions
DESIGN, TRADEOFFS, AND MAINTAINABILITY QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHEN TO USE THIS SET
Use this set for anyone who will make choices you cannot cheaply reverse: a
first developer, a senior hire, or a contractor building something you will
own afterward. You are not testing whether they can design a system for
millions of users. You are testing whether they will build something the next
person can understand and change.
QUESTIONS
1. Describe two ways you could have built your last project, and why you
picked one.
(Why ask: it surfaces real tradeoff thinking. Good answer: names the cost
of the road not taken and what would change their mind.)
2. When have you chosen the simpler option over the more interesting one?
(Why ask: small businesses are hurt far more by over-engineering than by
under-engineering. Good answer: a real example, with the reasoning.)
3. How do you decide between building something and using an existing tool?
(Why ask: a developer who builds everything from scratch is expensive.
Good answer: weighs maintenance cost, not just build time.)
4. What makes code easy for the next person to change?
(Why ask: on a one or two person team, you are the next person. Good
answer: names naming, small units, tests, and a written reason for odd
decisions.)
5. How much documentation do you write, and what kind?
(Why ask: the bus factor is real when you have one developer. Good answer:
documents decisions and setup, not every line.)
6. Tell me about technical debt you took on deliberately. What was the plan?
(Why ask: deliberate shortcuts are fine, forgotten ones are not. Good
answer: named the shortcut, wrote it down, and revisited it.)
7. If you joined us and inherited this codebase, what would your first two
weeks look like?
(Why ask: it tests whether they have thought about the actual job. Good
answer: read, run it, ship something small, ask a lot of questions.)
WHAT TO LISTEN FOR
•Tradeoffs stated as costs, not as absolutes
•Prefers boring and simple where it fits your size
•Thinks about the person who maintains it next
•Writes down decisions, not just code
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Coding Work Sample Brief and Debrief Questions
A fill-in take-home brief with a time cap, published scoring criteria, and a written AI-tool policy, followed by the eight debrief questions that turn a submission into a conversation you can score.
Coding Work Sample Brief and Debrief Questions
CODING WORK SAMPLE BRIEF AND DEBRIEF QUESTIONS
Candidate: __
Role: __
Sent on: _ Due: _
THE BRIEF (FILL THIS IN AND SEND IT)
Task: ___
__
Why this task: it is a realistic slice of the work this role does.
Time cap: [ ] 2 hours [ ] 3 hours [ ] 4 hours (stop at the cap, unfinished
is fine, tell us what you would do next)
Paid: [ ] Yes, $______ flat [ ] No (only for tasks under one hour)
What you may use: any language, library, editor, search engine, or AI coding
assistant you would normally use. Tell us in the write-up what you used and
where it helped or misled you.
What we score (in this order):
1. Does it do what the brief asked
2. Can we read and change it
3. Tests or checks where they matter
4. The write-up: what you chose, what you skipped, what you would do next
What we will not score: framework choice, styling polish, commit message
format, or whether you finished every optional item.
Deliverable: a repository or archive, plus a write-up of no more than 300
words.
DEBRIEF QUESTIONS (ASK THESE LIVE, 30 MINUTES)
1. Walk me through your solution as if I have never seen it.
2. What did you deliberately leave out, and why?
3. Where did you spend the most time, and was that the right call?
4. What would you do differently with another four hours?
5. Which part are you least confident about?
(Why ask: candid answers here correlate strongly with good colleagues.)
6. What did you use an AI assistant for, and where did you have to correct it?
(Why ask: it tests whether they can supervise generated code rather than
paste it. Good answer: specific about what it got wrong.)
7. If this had to run for three years with no one maintaining it, what would
you change?
8. What was unclear in our brief?
(Why ask: their questions tell you how they will handle vague tickets.)
WHAT TO LISTEN FOR
•Can explain every line they submitted, including generated code
•Made scope choices on purpose and can defend them
•Names their own weak spots without prompting
•Asks about the brief, rather than guessing silently
NOTES
__
Set 6: Coding Interview Scorecard and Red Flags
A weighted 1-to-5 rubric with an evidence line for every area, plus a red-flag checklist. Set the weights before you interview anyone, and have each interviewer score independently.
Coding Interview Scorecard and Red Flags
CODING INTERVIEW SCORECARD AND RED-FLAG CHECKLIST
Candidate: __
Role: __
Interviewer: __
Date: _
HOW TO SCORE
Score each area from 1 to 5 right after the interview, while it is fresh.
Anchor every score to something the candidate actually said or wrote. Set the
weights below BEFORE you interview anyone, so the role decides what matters
rather than the candidate you liked most. If more than one person interviews,
each scores independently first, then compare written evidence.
Rating scale:
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
SCORING AREAS
Real coding experience: has written and shipped what this role needs
You do not need to grade the code to run a good coding interview, you need a written standard to compare answers against. The pattern is consistent across every question in this kit: strong answers start with the problem, get more specific when you push, and name their own weak spots without prompting. Weak answers do the reverse.
Show me a piece of code you are proud of and walk me through what it does.
Strong answer: Explains the problem before the code, says what their part was, and names one thing they would change today. A strong candidate adjusts the level of detail when they notice you are not following, and gets more specific when you ask a follow-up.
Weak answer: Recites the technology stack instead of the problem, cannot say which parts they wrote, or answers a clarifying question with the same sentence again, only slower.
A page is slow and there is nothing in the logs. What do you check first?
Strong answer: Reproduces the problem, narrows the scope, asks what changed recently, and measures before touching anything. A strong answer treats the missing log line as information rather than an obstacle, and says which measurement would settle it.
Weak answer: Jumps straight to a favorite cause (the database, the network, the framework) with no way to confirm it, or starts changing things to see what helps.
What did you deliberately leave out of the work sample, and why?
Strong answer: Names specific cuts and the reasoning: skipped an admin screen to spend the time on correctness, left one function untested because the risk was low. A strong candidate can explain every line they submitted, including anything an assistant generated.
Weak answer: Claims nothing was left out, cannot explain part of their own submission, or blames the time cap without saying what they prioritized inside it.
Two mechanical tricks do most of the work. First, plant the problems yourself: a bug you already know about in a code sample turns an unreadable exercise into a scoreable one. Second, ask the same follow-up every time, some version of what happened next, and watch whether the answer sharpens or dissolves.
Signals of real experience
Answers sharpen under follow-up questions
Explains the problem before the technology
Names code that is still running, and what broke
Signals of method
Reproduces and measures before changing
Restores service first, investigates second
Has a trigger for asking someone else
Signals of a good colleague
Review feedback you would accept yourself
Says which part they are least confident about
Asks what was unclear in your brief
Red flags
Cannot explain code they submitted
Blames every past team and codebase
Never says the words I do not know
If the hire is important, buy one paid hour from a developer you trust to review the strongest work sample. That is cheaper than a bad hire by an enormous margin, and it fits neatly after your own scoring rather than replacing it.
Interviewing When Candidates Use AI Coding Tools
Decide your AI-tool policy before you send anything, write it into the brief, and apply it identically to every candidate. Most development work now involves AI assistance, so an unstated ban mostly tests who is willing to hide it, which is not a trait worth selecting for.
The useful signal is supervision, not abstinence. A developer who can explain every line they submitted has done the work whatever produced the first draft, and one who cannot explain their own submission has told you something important. Ask what the assistant got wrong, how they caught it, and what they changed.
Instead of asking
Ask this
Did you use an AI assistant?
What did you use it for, and where did it mislead you?
Write this without any tools
Walk me through this line and tell me why it is there
Can you code without help?
Which part of this are you least confident about?
Is this all your own work?
What would you change if this had to run for three years?
Note that a live conversation about code is naturally resistant to this problem, which is another argument for weighting the code reading set heavily. You are asking about code that already exists, in real time, and the follow-ups go wherever the answers do.
Running a Take-Home Work Sample Fairly
A work sample only beats a puzzle if you run it fairly: a realistic slice of real work, a hard time cap, published criteria, and payment for anything over an hour. Without those four, a take-home becomes an unpaid audition that filters for free time rather than for skill.
Keep the scope small enough that a strong candidate can finish inside the cap and a rushed one still submits something scoreable. Say explicitly that unfinished is acceptable if they explain what they would do next, because that instruction is what turns the exercise into a test of judgment rather than of endurance.
A Coding Test Is a Selection Procedure, Not a Chat
Any exercise you use to decide who advances is treated as an employment selection procedure under federal law, which means it should be job-related, consistent with business necessity, and administered on the same terms to every candidate for the role (EEOC guidance on employment tests). Keep the completed samples with your other hiring records, and review any exercise that screens out a protected group at a noticeably lower rate. This is general information, not legal advice.
The same standards are set out in the federal Uniform Guidelines on Employee Selection Procedures, which apply to tests and to any other formal or informal procedure used to make a hiring decision. In practice, writing the criteria into the brief before you send it satisfies most of what those standards ask for.
Scoring a Coding Interview
Score every candidate on the same rubric immediately after each stage, while the answers are fresh, and set the weights before you meet anyone. Weights decided afterward are how a hiring decision quietly becomes a rationalization of whoever felt most impressive in the room.
If more than one person interviews, each should score independently before the group talks, so the loudest or most senior voice does not anchor everyone else. Use an evaluation form to keep the written evidence in one place, then run a short feedback round comparing notes rather than impressions.
What Developers Cost
Developer pay is high relative to most small business roles, which is exactly why the interview is worth structuring. Use federal survey data as a baseline, then adjust for your market, the seniority you actually need, and whether the role is full-time, part-time, or contract.
Median $135,980 a Year for 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 an hour, with the 10th percentile at $82,460 and the 90th at $214,670 across roughly 1.69 million jobs (U.S. Bureau of Labor Statistics). The spread between the 10th and 90th percentile is wider than in most occupations, so the level you hire at matters more than the title.
The practical read for a small business: the bottom quartile of that range is where junior and early-career hires sit, and the interview should be calibrated to that level rather than to a senior one you are not paying for. Write the level into the job description before you interview, and keep the questions aimed at what the role actually needs.
Fair, Legal, and Structured Coding Interviews
A coding interview is fair, legal, and structured together or not at all: asking the same job-related questions of every candidate keeps you compliant, reduces bias, and produces better hires at once. Federal law prohibits basing hiring decisions on protected characteristics, and the EEOC list of prohibited practices is the reference worth reading before you write your questions.
A coding test is a selection procedure
The moment a coding exercise, a take-home task, or a technical quiz decides who advances, it is a selection procedure under federal employment law rather than a casual conversation. That means it should measure something the job actually requires, it should be given on the same terms to every candidate for the role, and you should be able to explain why it is job-related. Keep the task a realistic slice of the work rather than an abstract puzzle, cap the time, publish the criteria in advance, and keep the completed samples with the rest of your hiring records. If a test screens out a protected group at a noticeably lower rate, that is worth taking seriously before it becomes a legal problem. This is general information, not legal advice.
Ask about the code, not the person
Federal anti-discrimination law prohibits basing hiring decisions on protected characteristics, and questions that probe them create risk even when they are asked as friendly small talk. In a coding interview the traps are specific: do not ask when someone graduated or started programming, which is an age proxy; do not ask where they are originally from because of an accent on a video call; do not ask about family plans, health, or a disability that surfaces during a timed exercise. If a candidate requests an accommodation for a coding test, handle it as an accommodation question, not as a signal about their ability. Keep every question tied to the work. This is general information, not legal advice.
Set the weights before you interview
Decide which scoring areas matter most for this specific role before you meet anyone, and write the weights down. A first developer who will own everything needs design judgment and debugging method weighted heavily. A junior joining an existing codebase needs code reading and coachability. Setting weights afterward is how a hiring decision quietly becomes a rationalization of whoever felt most impressive in the room. The scorecard in this kit has a weight column for exactly that reason, and each interviewer should fill in their scores independently before the group discusses anything.
Decide your AI-tool policy in advance, and say it out loud
Candidates use AI coding assistants, and pretending otherwise just means you test who is best at hiding it. Pick a policy, write it into the brief, and apply it to everyone: either tools are allowed with disclosure, which is what most day-to-day work now looks like, or the exercise is a live conversation about code where tools are beside the point. The useful question is not whether they used an assistant but whether they can supervise it: what did it get wrong, how did you catch it, what did you change. A developer who cannot explain generated code has not really written it.
Technical interviews have their own version of the small-talk trap: asking when someone started programming or graduated is an age proxy, and a timed exercise can surface a disability the candidate never intended to discuss. Keep every question on the work, and treat an accommodation request as an accommodation request. This is general information, not legal advice, so check the specific questions to avoid before you finalize your list.
Running a Coding Interview Without HR
At a large company a developer runs a gauntlet of coordinated panels with a recruiter managing the scorecards and an engineering manager calibrating the bar. At a small business the owner runs the whole thing alone, frequently without writing code themselves, and a single miss is expensive. Here is how to make that interview as rigorous as a full hiring team's.
You are hiring a developer and you do not write code yourself
Most owners hiring their first or second developer cannot grade the code, which is why so many small businesses outsource the judgment to an algorithm puzzle they found online and then cannot interpret the result. The way out is to test what you can actually evaluate: whether the candidate explains their work in plain language, whether their answers get more specific under follow-up, whether they can find a bug you already planted in your own code, and whether their work sample does what the brief asked. Every question in this kit carries a note on what a strong answer sounds like, so you are comparing answers against a written standard rather than against your own uncertainty.
One developer on a small team is a single point of failure
At a large company a weak coding hire is absorbed by the team around them. At a small business that person may be the only one who understands how the product runs, which turns an ordinary hiring miss into an operational risk. That is why this kit weights maintainability and documentation as heavily as raw ability: you want someone who writes code the next person can change, records the reasoning behind odd decisions, and tells you when they are stuck instead of disappearing for three days. Ask the design and tradeoff questions even for a junior hire, because the habits show up long before the seniority does.
The interview is the easy part, the offer and the access are where it gets real
Once you pick someone, the work shifts from evaluating to hiring well: a written offer, a confidentiality and intellectual property acknowledgment signed before day one, repository and system access provisioned with least privilege, and a first project chosen in advance so a new developer ships something small in week one. FirstHR fits this people side for a small business: send the offer for e-signature, run the new hire paperwork and the access checklist as an onboarding workflow, and keep the signed documents and interview records on the employee profile. To be clear on scope, FirstHR is an onboarding and HR platform, not a code hosting service or a technical assessment tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
If you are still deciding what the role even is, write the posting first: a clear programmer job description forces the level and scope decisions that your interview questions then test. Founders hiring their first technical person often find where to find developers is the easier half of the problem.
From Interview to Onboarding
The interview is step one. Once you choose someone, onboarding a developer has extra steps because of the access involved: a signed offer and confidentiality agreement, repository and system access provisioned with least privilege, and a first small change chosen in advance so they ship something in week one. Developer onboarding done well is the difference between productive in a week and productive in a quarter.
Offer and confidentiality
A written offer plus a confidentiality and intellectual property acknowledgment signed before the first day, since a developer touches your source code and customer data.
Access with least privilege
Repositories, environments, and accounts provisioned to what the role needs, no shared logins, multi-factor everywhere, and a written removal step for when someone leaves.
Store the hiring record
Keep the scorecards, the work sample, the signed offer, and the standard new hire forms in one place, organized and easy to find months later.
Ship something in week one
Name the first small change, the person to ask, and what good looks like at thirty, sixty, and ninety days, so a new developer builds momentum instead of reading forever.
Once the decision is made, an offer letter template handles the offer and an onboarding workflow handles everything after it. FirstHR connects the offer, the confidentiality agreement, e-signatures, the new hire paperwork, and the access checklist in one place, and keeps the scorecards and signed documents on the employee profile. FirstHR is an onboarding and HR platform, not a code hosting service or a technical assessment tool, so connect those separately. Applicant tracking is coming soon to FirstHR.
For a broader hire that is technical but not strictly a coding role, the technical interview question sets cover the same ground for IT, data, and systems people, and the rest of the hiring template library has the postings, forms, and checklists around them. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Test five things: real coding experience, code reading and review, debugging method, design judgment, and communication.
Replace algorithm puzzles with a code reading exercise on your own system and a capped, paid work sample.
Plant the problems yourself: a bug you already know about makes a code sample scoreable even if you do not code.
Decide your AI-tool policy in advance and interview the supervision, not the abstinence.
Any exercise that decides who advances is a selection procedure, so keep it job-related and identical for every candidate.
Set scorecard weights before you interview, score independently, and compare written evidence rather than impressions.
Frequently Asked Questions
What coding interview questions should I ask candidates?
Ask questions that test five things: real coding experience, code reading and review, debugging method, design judgment, and communication. Strong openers include show me a piece of code you are proud of and walk me through it, what did you personally write versus what did others write, and tell me about code you wrote that is still running and what broke. Follow with a code reading exercise using 40 to 80 lines of your own system, a debugging scenario such as a slow page with nothing in the logs, and a tradeoff question about two ways they could have built their last project. Every question should have a stated reason you are asking it and a note on what a good answer sounds like, so you are scoring against a written standard. This page gives you six downloadable sets built that way, plus a weighted scorecard.
Should I use a live coding test or a take-home work sample?
For most small businesses a short paid take-home work sample beats a live coding test, because it looks more like the actual job and does not select for people who perform well under artificial pressure. Keep it a realistic slice of real work, cap the time at two to four hours, pay for anything over an hour, publish the evaluation criteria in advance, and ask for a short write-up of the choices the candidate made. Then spend the interview debriefing it: why this approach, what did you leave out on purpose, which part are you least confident about. Never use a work sample as unpaid work you intend to ship. Any exercise used to decide who advances counts as a selection procedure under federal employment law, so it should be job-related and given on the same terms to every candidate. This is general information, not legal advice.
How do I interview a developer if I am not technical?
Test what you can actually evaluate rather than trying to grade syntax. Three things work well without any coding ability of your own. First, ask for plain-language explanations and watch whether answers get more specific under follow-up or vaguer. Second, run a code reading exercise on a short sample from your own system where you have already planted one bug, one unclear name, and one risky shortcut, so you know in advance what a good answer finds. Third, use a take-home work sample with written criteria and score whether it did what the brief asked and whether the write-up explains the choices. Bring in a trusted developer or contractor for one paid hour to review the top candidate submission if the hire is important. Score every candidate on the same rubric and compare written evidence, not impressions.
Are algorithm and whiteboard puzzles worth using?
Usually not for a small business. Algorithm puzzles measure recent practice with a specific style of problem, which is a reasonable proxy at a company running thousands of interviews a year with heavily standardized roles, and a poor one when you are hiring a single developer to maintain your product. They also disadvantage strong candidates who have been shipping real software for years instead of drilling puzzles, and they push you toward a scoring standard you cannot interpret. Replace them with work that resembles the job: read this code and tell me what it does, here is a bug and no error message, here is a two-hour slice of a real task. If you do use a puzzle, use it the same way for every candidate and be able to explain why it is job-related.
Should candidates be allowed to use AI coding assistants?
Decide in advance, write the policy into the brief, and apply it to everyone. Most day-to-day development now involves AI assistance, so banning it in a take-home mostly tests who is willing to hide it. The more useful approach is to allow tools with disclosure and then interview the supervision: what did you use it for, where did it get things wrong, how did you catch that, what did you change. A developer who can explain every line they submitted has done the work regardless of what generated the first draft, and a developer who cannot explain their own submission has told you something important. If you prefer a tool-free signal, get it from a live conversation about code rather than from an honor system on a take-home. State the policy in writing so it is consistent across candidates.
How long should a coding interview be?
Plan 45 to 60 minutes for a focused conversation, plus a separate 30 minute debrief if you use a take-home work sample. That is enough to cover two or three questions from each area you care about, ask real follow-ups, and leave room for the candidate’s own questions, which reveal how they think about the role. Resist cramming in a long checklist, because depth on a few strong questions beats breadth every time. A practical shape for a small business is a 30 minute screen, a two to four hour paid work sample, and a 60 minute final conversation that debriefs the sample and covers design and collaboration. Score immediately after each stage while the answers are fresh, and keep the same structure for every candidate.
What is a coding interview scorecard?
A coding interview scorecard is a rubric that rates a candidate from 1 to 5 on each area that matters for the role, with space for the evidence behind every score. Typical areas are real coding experience, code reading and review, debugging method, design judgment, work sample quality, and communication. The version in this kit adds a weight column, because a first developer who will own everything needs design judgment weighted heavily while a junior joining an existing codebase needs code reading and coachability. Set the weights before you interview anyone, have each interviewer score independently, and compare written evidence before discussing. Without a scorecard, a hiring decision tends to become a rationalization of whoever felt most impressive in the room, which is exactly the failure mode structure prevents.
Are coding tests legal to use in hiring?
Yes, coding tests are legal, but any test used to decide who advances is treated as an employment selection procedure under federal law rather than as an informal chat. In practice that means the exercise should measure something the job actually requires, it should be given on the same terms to every candidate for the role, and you should be able to explain why it is job-related. Keep the task a realistic slice of real work, cap the time, publish the criteria in advance, and retain the completed samples with your other hiring records. Handle accommodation requests for a timed exercise as accommodation questions, not as signals about ability. If a test screens out a protected group at a noticeably lower rate, review it before it becomes a legal problem. This is general information, not legal advice.
