Free technical interview questions for employers hiring without a CTO: 6 sets, good-answer guides, a work sample brief, and a scorecard. Download as DOCX.
Six question sets for employers hiring a technical person without a CTO or an HR department: screening, troubleshooting, tradeoffs, security, a work sample brief, and a weighted scorecard, each question with what a strong answer sounds like. Download as DOCX.
The first technical person I ever hired interviewed brilliantly and could not ship anything. I asked the questions I had read on a list, got fluent answers I had no way to grade, and hired on the strength of the conversation. Six weeks later I understood that I had tested how well someone talks about engineering, not whether they could do the work my business needed.
Most technical interview advice online is written for the candidate, telling them how to answer. This page is the other side of the table. At FirstHR, we build for owners and managers who hire without an HR department and often without a CTO, so every question below comes with the reason it is worth asking and a note on what a strong answer sounds like.
Six question sets follow: core screening, troubleshooting, tradeoffs and judgment, security and reliability, a work sample brief with communication questions, and a weighted scorecard with a red-flag checklist. Download them all as one Word document, or copy the sets you need.
TL;DR
A technical interview should test five things: hands-on experience, problem-solving method, judgment and tradeoffs, security habits, and plain-language communication. Ask every candidate the same core questions, send the same short paid work sample, and score on a weighted 1-to-5 rubric. If you are not technical, grade specificity under follow-up, not the code. Download six sets and a scorecard.
What a Technical Interview Should Test
A technical interview should test whether a candidate can do the work your business actually needs, which is rarely the same thing as recalling computer science trivia. For a small company, that means five areas: hands-on experience close to the role, a repeatable problem-solving method, judgment about tradeoffs, security and reliability habits, and the ability to explain technical work to people who are not technical.
The mistake almost every first-time technical interviewer makes is borrowing the format used by large technology companies. Those algorithm-heavy loops exist to filter enormous applicant volumes, and they select for interview practice as much as for capability. You are hiring one person, so you can afford a process that looks like the job.
The second mistake is asking questions with no scoring plan. A question you cannot grade produces a conversation, not evidence. Every question in the sets below states why it is worth asking and what a strong answer contains, which is what turns a list of questions into a decision you can defend later.
How to Interview When You Are Not Technical
You do not need to grade the code; you need to change what you are grading. Four signals are available to any interviewer regardless of technical background, and together they predict a great deal about how a technical hire will work out on a small team.
First, specificity under follow-up. Real experience gets sharper when you ask one more question, and invented experience gets vaguer. Ask what exactly did you do, what broke, what number changed. Second, ownership. A candidate who can name a technical decision they got wrong, what it cost, and what they changed is telling you something a reference check would take a week to confirm.
Third, plain language. At a small business, the technical person talks to you, to customers, and sometimes to a vendor, so ask them to explain their work as though you know nothing. Fourth, a small work sample that actually runs and does what was asked. Those four, plus a reference check, are a genuinely strong process.
The Six Question Sets
The questions are grouped into six sets, five of questions and one scorecard. Pick the sets that match the role, then use the same ones for every candidate for that role. The core screening set applies to every technical hire; the others get weighted differently depending on what the person will own.
Core Technical Screening
Every candidate
The opening set for any technical hire: real past work, honest strengths, what they still maintain, and when they ask for help. Start here.
Problem-Solving and Troubleshooting
How they think
The highest-value set for a small business: diagnosing a slow system, an unreproducible bug, and the first thirty minutes of an outage.
Depth and Tradeoffs
Decisions you live with
For anyone making choices you cannot easily reverse: two ways to build it, buy versus build, and keeping it simple enough for a tiny team.
Security, Data, Reliability
No security team here
For anyone touching customer data or production: secrets, access control, backups that have actually been restored, and breach response.
Work Sample and Communication
Show, do not tell
A fill-in work sample brief with a time cap and stated criteria, plus the debrief questions and plain-language communication checks.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric and a red-flag checklist, so the decision rests on written evidence rather than on who interviewed most smoothly.
Match the Sets to the Hire
Hiring your only technical person: use all six, and weight tradeoffs, security, and communication heavily, because nobody will review their decisions. Adding a specialist to an existing technical team: weight core screening and the work sample higher, since the judgment layer already exists. Hiring for a support or operations role: lean on troubleshooting and communication. Contractor or agency: the tradeoffs set plus the work sample brief tells you the most in the least time. When in doubt, start with core screening and the scorecard.
6 Free Question Sets to Download
Download all six as a single Word document or copy the sets you need. Each question carries a short note on why it is worth asking and what a strong answer contains, plus a what-to-listen-for summary and space for notes. Fill in the details and use them as they are.
Download All 6 Technical Question Sets
Core screening, troubleshooting, tradeoffs, security, a work sample brief, and a weighted scorecard with red flags. All in one DOCX.
Set 1: Core Technical Screening Questions
The opening set for any technical hire: real past work, honest strengths and gaps, what they still maintain, and when they ask for help. Start here for every candidate.
Core Technical Screening Questions
CORE TECHNICAL SCREENING QUESTIONS
Candidate: __
Role: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the opening set for any technical hire: engineer, developer, IT
specialist, data or systems person. Ask 5 to 7 of these. You are not grading
syntax, you are checking that the candidate has actually done the work, can
describe it plainly, and gets more specific when you push, not vaguer. Use the
"good answer" notes to judge the response even if you do not code yourself.
QUESTIONS
1. Walk me through the piece of work in your last job that is closest to what
this role needs. What was your part of it?
(Why ask: it anchors the whole interview in real work instead of resume
claims. Good answer: names the system, their specific contribution, who
else was involved, and what shipped.)
2. Which parts of your stack are you strongest in, and which do you avoid?
(Why ask: honest self-assessment predicts how they behave when they hit
something they do not know. Good answer: names both sides plainly and gives
an example of learning something outside their comfort zone.)
3. Tell me about something you built that is still running. What broke, and
what did you do about it?
(Why ask: building is easy, owning is hard. Good answer: describes a real
failure, the fix, and what they changed so it did not happen again.)
4. How do you decide something is above your level and you need help?
(Why ask: on a small team, a person who stays stuck for three days silently
is expensive. Good answer: has a time box or a clear trigger for asking.)
5. What is the most recent thing you learned, and what made you learn it?
(Why ask: technical skills go stale fast and self-directed learning is the
cheapest form of training you will ever get. Good answer: a specific thing
driven by a specific problem, not a generic "I read a lot".)
6. What would you need from us in your first month to be effective?
(Why ask: it reveals whether they have thought about the actual job. Good
answer: access, context, a named first project, and a person to ask.)
WHAT TO LISTEN FOR
•Specifics that get sharper under follow-up questions
•Ownership language: what they did, not what "the team" did
•Honest boundaries around what they have not done
•Plain explanations that a non-technical listener can follow
NOTES
__
__
Set 2: Problem-Solving and Troubleshooting Questions
The highest-value set for a small business: a slow system with no error message, an unreproducible bug, and the first thirty minutes of an outage. Ask them to reason out loud.
Problem-Solving and Troubleshooting Questions
PROBLEM-SOLVING AND TROUBLESHOOTING QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHY THIS SET MATTERS MOST
For most small businesses, the highest-value technical skill is not knowing a
particular framework, it is diagnosing something that is broken with incomplete
information. This set is the closest thing to a live sample of how the
candidate thinks. Ask them to reason out loud and do not rescue them too early.
QUESTIONS
1. A customer reports that the system is slow. There is no error message. What
do you do first, second, and third?
(Why ask: it tests method over memory. Good answer: reproduces the problem,
narrows the scope, checks recent changes, uses data 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, narrowing, and either the root cause or an honest
account of what they were left with.)
3. How do you tell a symptom from a root cause?
(Why ask: symptom-patching creates the technical debt you will pay for.
Good answer: gives a concrete example of both, and knows when a quick
patch is the right call anyway.)
4. Tell me about a time you fixed something fast and then had to go back and
fix it properly.
(Why ask: it separates people who track their own shortcuts from people who
forget them. Good answer: names the shortcut, why it was right at the time,
and how they closed the loop.)
5. Something critical went down outside working hours. Walk me through your
first thirty minutes.
(Why ask: at a small company there is no on-call rotation to hide behind.
Good answer: restore service first, communicate early, investigate after.)
6. Describe a problem you solved by deleting or simplifying something rather
than adding to it.
(Why ask: on a small team, the cheapest system to run is the smallest one.
Good answer: a real case, with the reasoning for what came out.)
WHAT TO LISTEN FOR
•A repeatable method, not a lucky story
•Comfort saying "I would look at the data before I guess"
•Communicates status to non-technical people during an incident
•Curiosity about the actual cause, not just closing the ticket
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Set 3: Depth, Tradeoffs, and Design Judgment Questions
For anyone making choices you cannot easily reverse: two ways to build it, buy versus build, and keeping the system simple enough for a team of three to maintain.
Depth, Tradeoffs, and Design Judgment Questions
DEPTH, TRADEOFFS, AND DESIGN JUDGMENT QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHEN TO USE THIS SET
Use this set for anyone who will make choices you cannot easily reverse:
a first engineer, a lead, a solo IT owner, or a contractor building something
you will live with for years. Skip the whiteboard puzzle. Ask about tradeoffs
in the context of a business your size, where simplicity beats cleverness.
QUESTIONS
1. Here is something we actually need to build. Give me two ways to do it and
tell me which you would choose and why.
(Why ask: it is the single most informative technical question you can ask.
Good answer: two genuinely different options, an explicit tradeoff, and a
recommendation tied to our constraints, not to what is fashionable.)
2. When would you buy or use an existing service instead of building it?
(Why ask: a candidate who builds everything from scratch will burn your
budget. Good answer: has a rule of thumb, usually around whether it is core
to the business, plus real examples of both calls.)
3. Tell me about a technical decision you got wrong. What did it cost and what
did you change?
(Why ask: seniority is mostly a record of corrected mistakes. Good answer:
a real, specific decision, owned without blaming, with the lesson applied
later.)
4. How would you keep this simple enough for a team of two or three to
maintain after you take a two-week vacation?
(Why ask: it tests for a mindset built for our size. Good answer: talks
about documentation, boring technology, few moving parts, and handover.)
5. What would you do differently if this had to handle ten times the load?
And what would you deliberately not do yet?
(Why ask: it checks that they can scale their thinking both up and down.
Good answer: knows premature optimization is a real cost.)
6. How do you decide what is worth automating?
(Why ask: it reveals whether they weigh effort against payoff. Good answer:
frequency, error rate, and time saved, with an example they chose not to
automate.)
WHAT TO LISTEN FOR
•Real tradeoffs, with named downsides on both sides
•Answers scaled to your business, not to a large tech company
•"It depends" followed immediately by what it depends on
•Willingness to recommend the boring option
NOTES
__
Set 4: Security, Data, and Reliability Questions
For any hire touching customer data or production systems: secrets handling, access control on a small team, backups that have actually been restored, and breach response.
Security, Data, and Reliability Questions
SECURITY, DATA, AND RELIABILITY QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHEN TO USE THIS SET
Use this set for any technical hire who will touch customer data, credentials,
or production systems, even if security is not in the job title. A small
business rarely has a dedicated security person, so these habits have to come
in with the hire. Ask at least three of these of every technical candidate.
QUESTIONS
1. How do you handle credentials and secrets in a project?
(Why ask: it is the fastest way to spot sloppy habits. Good answer: a
secrets manager or environment variables, never in the code repository,
rotation when someone leaves.)
2. We store customer data. What would you check first if you joined tomorrow?
(Why ask: it tests instincts, not policy recall. Good answer: who has
access, what is stored and why, where backups live, and whether anything is
exposed publicly.)
3. How do you set up access control on a small team where everyone wears
several hats?
(Why ask: least privilege is harder and more important at small scale. Good
answer: role-based access, no shared logins, multi-factor authentication,
and a removal step when someone leaves.)
4. How do you handle backups, and how do you know they actually work?
(Why ask: most small businesses have backups nobody has ever restored. Good
answer: automated backups plus a tested restore, not just a schedule.)
5. Walk me through what you would do in the first hour of a suspected breach.
(Why ask: calm sequencing matters more than technical depth here. Good
answer: contain, preserve evidence, notify the owner early, then
investigate, and knows there may be legal notification duties.)
6. What is a security practice you have pushed for that got pushback, and how
did you handle it?
(Why ask: security work at a small company is mostly persuasion. Good
answer: framed the risk in business terms and found a practical middle.)
WHAT TO LISTEN FOR
•Habits described as routine, not as a special project
•Least privilege and multi-factor authentication mentioned unprompted
•Backups that have actually been restored in a test
•Explains risk to a non-technical owner in business terms
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Work Sample Brief and Communication Questions
A fill-in brief with a time cap and published criteria, plus the debrief and plain-language communication questions that turn a work sample into real evidence.
Work Sample Brief and Communication Questions
WORK SAMPLE BRIEF AND COMMUNICATION QUESTIONS
Candidate: __
Role: __
Interviewer: __
PART 1: WORK SAMPLE BRIEF (FILL IN AND SEND)
Task: ___
(Use a small, realistic slice of the actual job. Never unpaid work you
will ship.)
Time cap: ______ hours. Do not exceed it. Send us what you have at the cap.
Paid: [ ] Yes, $______ flat [ ] No (only for tasks under one hour)
What we will evaluate, in order:
1. Does it work and do what was asked
2. Is it readable and simple enough for someone else to maintain
3. Did you say what you would do differently with more time
4. Clarity of the write-up
What we will NOT evaluate: choice of editor, formatting preferences, or
anything you were not asked to do.
Deliverable: the work itself plus a short write-up (half a page) covering your
approach, the tradeoffs you made, and what you left out on purpose.
Give every candidate the same brief, the same time cap, and the same criteria.
PART 2: DEBRIEF AND COMMUNICATION QUESTIONS
1. Walk me through your work sample. Why did you make that choice here?
(Why ask: the debrief is where the sample earns its value. Good answer:
explains decisions and names what they would change.)
2. Explain what you built to me as if I have no technical background.
(Why ask: at a small company, engineers talk to customers and owners. Good
answer: plain language, no jargon, right level of detail.)
3. Tell me about a time a non-technical colleague asked for something that was
a bad idea technically. What did you do?
(Why ask: it predicts how they will handle you. Good answer: understood the
underlying need and proposed an alternative, rather than refusing flatly.)
4. How do you write things down so the next person can pick up your work?
(Why ask: documentation is survival insurance on a small team. Good answer:
a habit with examples, not a promise.)
5. How do you estimate, and what do you do when an estimate is wrong?
(Why ask: bad estimating breaks small-business planning. Good answer:
breaks work down, gives ranges, and flags slippage early instead of at the
deadline.)
WHAT TO LISTEN FOR
•Working, simple output over clever output
•Honest account of what was skipped and why
•Plain-language explanations without condescension
•Early, proactive communication about slippage
NOTES
__
Set 6: Technical Interview Scorecard and Red Flags
A weighted 1-to-5 rubric with space for written evidence, plus a red-flag checklist. Use it with any of the sets above so the decision rests on a record, not a memory.
Technical Interview Scorecard and Red Flags
TECHNICAL INTERVIEW SCORECARD AND RED-FLAG CHECKLIST
Candidate: __
Role: __
Interviewer: __
Date: _
HOW TO SCORE
Score each area from 1 to 5 immediately after the interview, while it is fresh.
Anchor every score to something the candidate actually said or did. If more
than one person interviews, each scores independently before the group talks,
so the most senior voice does not anchor everyone else. Use the same rubric
and the same weightings for every candidate for this role.
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
Relevant hands-on experience: has done work close to this job
A strong technical answer is specific, names real tradeoffs, and gets more detailed when you push. A weak answer does the opposite: it stays general, presents one option as the only option, and retreats into jargon when questioned. The pattern holds across every technical discipline, which is what makes it usable by a non-technical interviewer.
A customer says the system is slow, and there is no error message. What do you do first?
Strong answer: Reproduce it, then narrow the scope: is it everyone or one user, everything or one screen, since when, and what changed recently. Checks data and logs before guessing, and says out loud what would prove or disprove each theory. A strong answer treats the first step as gathering information, not fixing.
Weak answer: Jumps straight to a fix, blames the network or the user, or lists tools without a method for choosing between them.
Give me two ways to build this and tell me which you would choose.
Strong answer: Offers two genuinely different approaches, names a real downside of each, and recommends one based on your constraints: team size, budget, and how long you have to maintain it. A strong answer often recommends the simpler, more boring option and explains why that is the right call at your size.
Weak answer: Gives one option presented as the only option, or picks the newest technology without connecting it to anything about your business.
Tell me about a technical decision you got wrong.
Strong answer: A specific decision, what it cost in time or money, and what they changed afterward. Owns it in the first person without blaming a manager or a deadline. A strong answer shows the lesson being applied to a later decision, which is what separates experience from tenure.
Weak answer: Cannot think of one, or offers a non-answer like choosing a tool that was later deprecated, with no cost, no ownership, and no lesson.
How do you handle credentials and secrets?
Strong answer: Names a concrete practice as routine: a secrets manager or environment variables, nothing sensitive in the code repository, multi-factor authentication, and rotation when someone leaves. A strong answer treats this as ordinary hygiene rather than as a special project someone else owns.
Weak answer: Vague reassurance, admits to sharing credentials over chat or email, or treats security as purely someone else's responsibility.
Notice that none of those judgments require you to evaluate code. They require you to listen for structure, ownership, and honesty about limits, and to ask one more question than feels comfortable. When you are unsure, the most useful follow-up is simply: what exactly did you do, and what happened?
Work Samples Beat Whiteboard Puzzles
A short, paid, realistic work sample tells you more than any interview question, because it shows the candidate doing a version of the actual job rather than describing it. For a small business it is also the fairest option, since it does not select for people who happen to perform well under artificial time pressure in front of an audience.
What it does
Live coding test
Paid take-home sample
Looks like the real job
Works for candidates who freeze under observation
Produces something you can re-read a week later
Gives fast signal in under an hour
Needs a technical person present to run it
Keep the task small and bounded. Cap it at two to four hours, pay for anything over an hour, publish the evaluation criteria before you send it, and ask for a short write-up of the tradeoffs the candidate made. Then spend interview time debriefing it, because the explanation of the choices is worth more than the artifact itself.
Rule
Why it matters
Use a realistic slice of the actual work
Abstract puzzles measure practice, not job performance
Cap the time and say so in writing
Protects candidates with jobs and children from being outspent
Pay for anything over an hour
Signals you value their time and widens your candidate pool
Publish the criteria in advance
Lets candidates optimize for what you actually care about
Give every candidate the same brief
Makes the results comparable and the process defensible
Never ship unpaid sample work
It is unpaid labor and it destroys your reputation quickly
One caution worth taking seriously: a technical test used to decide who advances is a selection procedure under federal employment law, not a casual exercise. Keep it job-related, give it on the same terms to everyone, and keep the completed samples with your other hiring records.
Follow-Ups, Signals, and Red Flags
The prepared questions open the door; the follow-ups are where the evidence is. Push once more on every answer that sounds polished, and pay attention to which direction the answer moves. Specificity that increases is the strongest positive signal in a technical interview.
Signals to chase
Answers get more specific under follow-up
Names the actual tool, file, or number
Volunteers what they would do differently
Method over memory
Narrows a problem before proposing a fix
Uses data instead of guessing out loud
Knows when a quick patch is the right call
Ownership habits
Still maintains something they built
Tested a restore, not just a backup
Writes things down for the next person
Red flags
Vaguer under pressure, not sharper
Cannot name a decision they got wrong
Wants to rebuild everything before reading it
Two red flags deserve extra weight at a small business. A candidate who wants to rebuild everything before understanding what exists will spend your first year rewriting working systems. And a candidate who dismisses documentation, testing, or backups as someone else's job is describing a job that does not exist on a team of three.
Scoring a Technical Interview
Score immediately after each interview, while the answers are fresh, and anchor every score to something the candidate actually said or did. Decide the weightings before you meet anyone, so you are not quietly retuning the rubric to fit a candidate you already like.
Scoring area
What a 5 looks like
Relevant hands-on experience
Has shipped and maintained work close to this role
Problem-solving method
Narrows before fixing, uses data, finds root causes
Judgment and tradeoffs
Two options, real downsides, choice fits your size
Security and reliability habits
Least privilege, secrets managed, restores tested
Communication
Explains the work clearly to a non-technical listener
Work sample result
Runs, does what was asked, simple and well explained
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, then discuss the gaps. That is the core of a structured interview, and it feeds a clean interview feedback step before you decide.
Fair, Legal, and Structured Technical Interviewing
Fair, legal, and structured are the same discipline seen from three angles: ask every candidate for a role the same job-related questions, give the same technical task on the same terms, and score on the same rubric. That approach reduces bias, produces better hires, and is far easier to explain if anyone ever asks.
A technical test is a selection procedure
The moment you use a coding exercise, a take-home task, or a technical quiz to decide who advances, it counts as a selection procedure under federal employment law, not as 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, and keep the completed samples with your other hiring records. If a test screens out a protected group at a noticeably lower rate, that is a problem worth taking seriously before it becomes a legal one. This is general information, not legal advice.
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 probe them create risk even when they are asked as friendly small talk. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews have their own version of this trap: graduation years, how long have you been doing this as a proxy for age, questions about visible accents or origin, and speculation about whether someone will fit in with a young team. Ask what they have built, how they solved it, and what they would do next. Every question in these sets is written to stay on the work. This is general information, not legal advice.
Same questions, same task, same rubric
Structure is what makes a technical interview both fairer and more accurate. Ask every candidate for the role the same core questions in the same order, give them the same work sample brief with the same time cap, and score them on the same weighted rubric with written evidence. This is the single highest-leverage habit for a small business, because it replaces a vague sense of who you clicked with by a record you can compare side by side weeks later. It also protects you: a consistent, job-related process is far easier to explain than a series of freeform conversations that each went somewhere different.
Do not borrow a large company's interview
The algorithm-heavy interview loops used by large technology companies are designed to filter enormous applicant volumes, and they select for interview practice as much as for skill. A small business hiring one person does not have that problem and should not import that process. Weight your questions toward what the role will actually do in its first ninety days: keeping things running, shipping something small and useful, and explaining it to people who are not technical. If your candidate will be the only technical person, weight judgment and communication higher than raw depth in any single technology.
A Coding Test Is a Selection Procedure, Not a Chat
Under the federal Uniform Guidelines on Employee Selection Procedures, a selection rate for any race, sex, or ethnic group that is less than four-fifths, or 80 percent, of the rate for the highest-scoring group is generally regarded by federal enforcement agencies as evidence of adverse impact. Any technical test you use to decide who advances falls under that framework, so keep it job-related, consistent, and documented. The EEOC enforces the underlying anti-discrimination rules.
Keep the small talk on the job too. Graduation years, questions about accents or origin, and speculation about fitting in with a young team are the technical interview versions of the questions employers already know to avoid. For a broader walkthrough of the structured approach, SHRM publishes a practical interviewing toolkit. This is general information, not legal advice.
Running a Technical Interview Without HR
A large company runs technical candidates through coordinated panels with a recruiter managing scorecards and a hiring committee reviewing the evidence. A small business runs the whole thing through one owner who is usually not technical and is doing it between everything else. That reality should change the process, not just shrink it.
You are hiring a technical person and you are not technical yourself
This is the normal case at a small business, and it is why generic question lists fail: they hand you questions with no way to judge the answers. The fix is not to fake technical depth, it is to change what you are grading. You can reliably tell whether an answer gets more specific or vaguer under follow-up, whether the candidate owns a past mistake, whether they can explain their work in plain language, and whether a small work sample actually runs. Those four signals are available to any interviewer. Every question in these sets comes with a note on what a strong answer sounds like, so you can score the response without grading the code.
Your first technical hire will make decisions you cannot easily reverse
When you have no engineering team, the first technical hire chooses the stack, the hosting, the data model, and the habits, and you will live with those for years. That is why the depth and tradeoffs set matters more here than at a company with a review process to catch bad calls. Ask for two options and a recommendation, ask what they would deliberately not build yet, and ask how the system survives their two-week vacation. A candidate who recommends the boring, maintainable option for a team of three is usually the safer hire than the one with the most impressive architecture.
You cannot judge the code, but you can borrow someone who can
If the hire is important enough, buy ninety minutes of a trusted engineer's time: an advisor, a contractor you already work with, or a friend in the field. Give them the same written scorecard and the same specific questions rather than turning them loose for an open chat, and ask them to write evidence for each score. One structured technical session plus your own judgment on communication, ownership, and the work sample is a genuinely strong process. Once you choose someone, the work turns into hiring them properly: FirstHR handles the offer and e-signature, the new hire paperwork, the access and policy checklist, and the document storage. FirstHR is an onboarding and HR platform, not a developer tool or a code-testing service, so pair it with those. Applicant tracking is coming soon to FirstHR.
The security set deserves particular attention when you have no security team. NIST publishes a free Small Business Cybersecurity Corner that is a reasonable baseline for what to expect a technical hire to already know about access control, backups, and incident response. If a candidate finds those practices unfamiliar or annoying, that is worth a note on the scorecard.
From Interview to Onboarding
The interview is step one. Once you choose someone, a technical hire has a few extra onboarding steps because of the access involved: a signed offer and confidentiality agreement, accounts provisioned with least privilege, and an acceptable-use acknowledgment, alongside the standard new hire paperwork. Getting this right on day one is also your first internal control.
Write the questions first
Pick the sets that match the role, decide the order, and use the same core questions for every candidate so the comparison is fair.
Score with weights
Rate each area 1 to 5 with written evidence and weight the areas that matter most for this specific role before you interview anyone.
Send the offer
Confirm the role, pay, and start date in writing, with e-signature so the record is clean and the candidate can accept the same day.
Set up access on day one
Accounts, repositories, and systems provisioned with least privilege, plus a signed confidentiality and acceptable-use acknowledgment.
Plan the first ninety days before the start date. Name the first real project, the person to ask when they get stuck, and what success looks like at thirty, sixty, and ninety days. A technical hire who spends three weeks waiting for access and context is a technical hire you are paying to sit still, and a structured onboarding plan prevents exactly that.
Offer and confidentiality
A written offer plus a confidentiality and intellectual property acknowledgment, signed before the first day, since a technical hire touches your systems and data.
Access with least privilege
Provision only what the role needs, no shared logins, multi-factor authentication on everything, 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 organized in one place and easy to find later.
Plan the first ninety days
Name the first real project, the person to ask, and what success looks like at thirty, sixty, and ninety days so a technical hire ramps fast.
Once the decision is made, the offer letter template covers the offer itself. FirstHR connects the offer, e-signatures, the paperwork, and the access-and-policy checklist in one place, and stores the signed documents on the employee profile, so a small business can run hiring-to-onboarding from one system. FirstHR is an onboarding and HR platform, not a developer tool or a code-testing service, so connect those separately. Applicant tracking is coming soon to FirstHR.
If you have not written the posting yet, the matching job description is a useful companion. Start from the software engineer job description or the IT support job description, then adapt the requirements to the questions you plan to ask.
The rest of the hiring templates cover the neighboring roles, from QA engineer questions to network and developer sets. Applicant tracking is coming soon to FirstHR, so for now pair these templates with whatever you use to collect applications.
Key Takeaways
Test five areas: hands-on experience, problem-solving method, judgment and tradeoffs, security habits, and plain-language communication.
Every question needs a stated reason for asking it and a note on what a strong answer contains, or you collect answers you cannot score.
If you are not technical, grade specificity under follow-up, ownership of mistakes, plain language, and whether the work sample runs.
A short, paid, realistic work sample beats a whiteboard puzzle, and the debrief is worth more than the artifact.
Any technical test used to decide who advances is a selection procedure, so keep it job-related, consistent, and documented.
Score on a weighted 1-to-5 rubric with written evidence, independently, and set the weights before you interview anyone.
Frequently Asked Questions
What technical interview questions should I ask a candidate?
Ask questions that cover five areas: relevant hands-on experience, problem-solving method, judgment and tradeoffs, security and reliability habits, and communication with non-technical people. Strong openers include walk me through the work in your last job that is closest to this role, a customer says the system is slow and there is no error message so what do you do first, give me two ways to build this and tell me which you would choose, how do you handle credentials and secrets, and explain what you built as if I have no technical background. Every question should have a stated reason you are asking it and a note on what a good answer sounds like, otherwise you collect answers you cannot score. Avoid trivia and algorithm puzzles, which measure interview practice more than job performance. This page groups the questions into six downloadable sets with answer guidance and a scorecard.
How do I interview a technical candidate if I am not technical myself?
You do not need to grade the code; you need to grade four things any interviewer can judge. First, whether answers get more specific under follow-up questions or vaguer, since real experience sharpens under pressure and invented experience does not. Second, whether the candidate owns a past mistake concretely instead of blaming other people. Third, whether they can explain their work in plain language, which matters because at a small company technical people talk to owners and customers. Fourth, whether a small, paid work sample actually runs and does what was asked. For the code itself, buy ninety minutes from a trusted engineer or advisor and give them the same written scorecard rather than an open conversation. That combination is a genuinely strong process for a business without a CTO.
Should I use a 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 it does not select for people who perform well under artificial pressure. Keep it to 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 tradeoffs the candidate made. Then spend the interview debriefing it: why this choice, what would you change, what did you leave out on purpose. Never use a work sample as unpaid work you intend to ship. Note that any test 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.
What is a technical interview scorecard?
A technical interview scorecard is a rubric that rates a candidate from 1 to 5 on each competency the role requires, with space for written evidence and a weighting for the areas that matter most. Typical areas are relevant hands-on experience, problem-solving method, judgment and tradeoffs, security and reliability habits, communication with non-technical people, and the work sample result. Decide the weightings before you interview anyone, so you are not tuning the rubric to fit a candidate you already like. Each interviewer scores independently first, then the group compares written evidence before discussing, which stops the most senior or loudest voice from anchoring the decision. A scorecard is what makes candidates comparable weeks later, and it is the asset most technical question lists leave out. A ready-to-use one is included on this page.
Are brain teasers and algorithm puzzles good technical interview questions?
Generally no, not for a small business. Algorithm-heavy interview loops exist at large technology companies mainly to filter enormous applicant volumes, and they reward candidates who have practiced that specific format rather than candidates who will do your job well. Brain teasers are worse: they measure a moment of insight that has little to do with day-to-day work. A small business hiring one person gets far more signal from a realistic work sample, a troubleshooting scenario drawn from something that actually broke for you, and a tradeoffs question about something you genuinely need to build. Those questions also give the candidate a fair picture of the role, which helps you compete for good people without a big brand name behind you.
What questions are illegal to ask in a technical interview?
Avoid questions that probe characteristics protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews have their own versions of this trap, such as asking what year someone graduated, how long they have been in the field as a proxy for age, where an accent is from, or whether someone will fit in with a young team. You may ask whether a candidate can perform the essential functions of the job and whether they are legally authorized to work. Keep every question tied to the work itself, and apply the same questions and the same technical test to every candidate for the role, which is both the fairest and the most defensible approach. This is general information, not legal advice.
How many rounds should a technical interview process have?
For a small business, two to three touchpoints is usually right: a short screening conversation, a paid work sample, and one longer interview that debriefs the sample and covers judgment, security habits, and communication. Adding rounds beyond that mostly adds delay, and delay is how small companies lose good technical candidates to faster-moving employers. If you are borrowing an outside engineer for a technical session, fold it into the longer interview rather than making it a separate round. Decide the stages, the questions, and the scorecard before you talk to anyone, tell candidates the process up front, and keep the total elapsed time to about two weeks. Speed with structure beats either speed alone or structure alone.
How should I weight the scorecard for a first technical hire?
When the person will be your only technical employee, weight judgment, communication, and ownership habits higher than depth in any single technology. A first technical hire chooses your stack, hosting, data handling, and working habits, and you will live with those decisions for years without a review process to catch bad ones. So the tradeoffs questions, the security and reliability set, and the plain-language explanation matter more than whether they know one particular framework, which they can learn. If instead you are adding a specialist to an existing technical team, invert that: weight hands-on depth in the specific area higher, because the judgment layer already exists around them. Set the weights before you interview anyone. This is general guidance; adjust it to your team and stage.
