Developer Interview Questions and Scorecard

The first developer interview I ever ran, I asked almost nothing that mattered. I asked about frameworks, nodded at answers I could not evaluate, and hired the person who sounded most confident. Six months later I learned the difference between a developer who ships and a developer who talks well about shipping, and it cost a great deal more than a better interview would have.

At FirstHR, we build for small businesses that hire without an HR department, and the developer hire is the one owners most often tell me they felt unqualified to run. You do not need to read code to interview well. You need the right questions, a way to recognize a strong answer, and a scorecard so the decision rests on evidence instead of on whoever interviewed most smoothly.

This page gives you six question sets covering screening, code quality and debugging, scoping and delivery, owner fit and handover, a paid work sample brief, and a weighted scorecard with red flags. Every question comes with why it is worth asking and what a strong answer contains.

What to Assess in a Developer

Assess five things: shipped experience, problem-solving method, code quality habits, scoping and delivery, and communication with non-technical people. Everything else, including the specific language or framework on the resume, is secondary to whether this person has built real software that real people used and can tell you honestly how it went.

Small businesses tend to over-weight the stack and under-weight the last two. A developer who writes elegant code but cannot estimate, cannot explain the work to you, and disappears until the deadline will be far more expensive than one who is merely competent and completely transparent. The sets below are ordered so the highest-signal questions come first.

Notice how much of that list is about behavior rather than knowledge. That is deliberate. Knowledge questions are easy to prepare for and easy to fake in a conversation; habits show up in the specifics, which is why the follow-up question matters more than the original one.

How to Interview When You Cannot Read Code

Grade method, specificity, and honesty rather than code. Every one of those is visible to a non-technical interviewer, and together they separate strong developers from confident talkers more reliably than a technical quiz you cannot score.

The practical technique is simple: ask an open question, then push twice. Ask how they debugged something hard, then ask what the first piece of evidence was, then ask how they knew the fix worked. A developer with real experience gets more concrete each time. Someone reciting a pattern they read about gets vaguer and starts using terminology instead of detail.

If the role is senior or business-critical, borrow one hour of a developer you trust to review a work sample. One hour of outside review at the end of a structured process is worth far more than an extra interview round, and it costs less than the first month of a wrong hire.

Junior, Mid-Level, and Senior

Level is scope of independence, not years on a resume. A junior finishes well-defined tasks with review, a mid-level developer takes a feature from description to production alone, and a senior scopes ambiguous problems and makes decisions that are hard to reverse. Decide which you need before you write the questions, because the same answer can be excellent from one level and disqualifying from another.

A small business hiring its only developer usually needs at least mid-level, because there is nobody to review the work. If the budget only reaches junior, plan for outside review from the start and be honest about that in the job description and the interview. Hiring a junior into an unsupervised role and hoping is the most common way this goes wrong.

Which Question Set to Use

Use core screening for every developer candidate, then add the sets that match the role. The six sets below are five of questions plus a scorecard, and each one carries the reason each question is worth asking alongside what a good answer contains.

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.

Set 1: Core Developer Screening Questions

The opening set for any developer hire: real systems built and owned, honest depth in named tools, how they get up to speed in an unfamiliar codebase, and when they ask for help. Start here for every candidate.

Set 2: Code Quality, Testing, and Debugging Questions

The habits you will live with: version control, code review, what they choose to test, and the first three steps on a production bug that nobody can reproduce. Ask them to reason out loud.

Set 3: Scoping, Estimating, and Delivery Questions

For anyone who will turn your two-sentence request into working software: breaking work down, estimating in ranges, raising slippage early, and getting a change safely in front of real users.

Set 4: Working With a Non-Technical Owner and Handover Questions

The set most developer question lists skip: explaining technical work in plain language, saying no with a reason, documentation, account ownership, and what happens the day this person leaves.

Set 5: Paid Work Sample Brief and Debrief Questions

A fill-in brief with a time cap, a payment line, and published criteria, plus the debrief questions that turn a submitted task into evidence you can actually score.

Set 6: Developer Interview Scorecard and Red Flags

A weighted 1-to-5 rubric with space for written evidence, plus the red-flag checklist. Use it with any of the sets above so the decision rests on a record rather than a memory.

What a Strong Answer Sounds Like

A strong developer answer is specific, names a real tradeoff, 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 terminology when questioned. That pattern holds regardless of the language or the stack, which is what makes it usable by a non-technical interviewer.

The most useful follow-up in the whole interview is some version of what happened next. Real projects have consequences, and a candidate who owned the work remembers them. Ask what broke, what users said, and what they would change now, and listen for whether the story survives the detail.

Why a Paid Work Sample Beats a Puzzle

A short, paid, job-realistic task produces better evidence than an algorithm puzzle, because it tests the work the person will actually do. Keep it to a few hours with a hard time cap, give every candidate for the role the same brief, and publish the criteria in advance so the score is not a matter of taste.

Pay for the time. Unpaid multi-day projects screen out strong candidates who already have jobs or caring responsibilities, which means they filter on availability rather than on skill. A few hours, paid on submission regardless of outcome, gets you a much better pool and a much cleaner conscience.

The debrief is where most of the signal is. Ask why they chose that approach, what they assumed, what they cut because of the cap, and where it is most likely to break. A candidate who talks honestly about the weakest part of their own submission is showing you exactly how they will behave on your codebase.

Handover, Access, and Who Owns the Code

If this is your only developer, continuity is a real part of the evaluation, not a formality. Ask directly what you would need to keep the business running if they left tomorrow, and treat the reaction to the question as informative as the answer itself.

The account-ownership question is worth asking of every candidate, employee or contractor. Domains, hosting, app store listings, and repositories registered in a developer's personal account is one of the most common and most damaging mistakes a small business makes, and it is almost always discovered at the worst possible moment. A good candidate will agree immediately and often raise it before you do.

For contractors, settle intellectual property in writing before work begins, alongside the usual employee or contractor classification questions. A clean handover at the end of an engagement should be part of the scope, not a favor you negotiate afterwards.

Scoring a Developer Interview

Score every area from 1 to 5 immediately after the interview, with written evidence for each number, and weight the areas that matter most for the role. Scoring from memory a week later is barely better than a coin toss, because what you remember is how the conversation felt rather than what was said.

Have every interviewer score independently before anyone discusses, so a strong opinion does not anchor the group. Compare the written evidence first and the impressions second. That single habit is most of what separates a structured interview from a conversation, and it feeds a much cleaner interview feedback step before you decide.

Keep the completed scorecards for every candidate for the role together in one place, alongside the work sample submissions and the notes. That record is what lets you compare a candidate you met on Monday with one you meet three weeks later, and it is what you will want if a decision is ever questioned. Applicant tracking is coming soon to FirstHR.

What Developers Cost

Developer pay varies widely by seniority, location, and specialty, so use federal survey data as the baseline and adjust from there. Salary is also only part of the cost: payroll taxes, benefits, equipment, and software licenses all sit on top of it.

Those national medians run above what many small businesses expect, which is worth confronting before you post the role rather than after three candidates decline. If the number does not work, the honest options are a narrower scope, a part-time arrangement, a contractor, or a more junior hire with outside review budgeted in. Adjusting the title while keeping senior expectations is not one of them.

Where the work is closer to sites and interfaces than to systems, the web developer benchmark is usually the better anchor. Write the level and the pay range into the posting, and keep the interview questions matched to the level you are actually paying for.

Fair, Legal, and Structured Interviewing

A fair interview and an effective one are the same interview. Asking every candidate for a role the same job-related questions, scored on the same rubric, is what makes the comparison meaningful, and it happens to be the simplest way to keep the process defensible.

Technical interviews drift more than most, because two engineers talking naturally follow whatever the candidate is best at. Write the questions down and keep the improvisation to the follow-ups, and read up on the questions you cannot ask before the first call. This is general information, not legal advice.

Interviewing a Developer Without HR

At a large company a developer runs a gauntlet of coordinated panels with a recruiter managing the scorecards. At a small business the owner runs the whole thing alone, usually without the background to grade the technical answers and without a team to compare notes with. Here is how to make one founder's interview as rigorous as a full hiring team's.

None of that requires an HR department or a recruiter. It requires the questions written down before the first call, one hour of preparation, and the discipline to score before the next conversation starts. If you are still filling the pipeline, our guide on where to find developers covers the step before this one, and how to conduct an interview covers the mechanics that apply to every role.

From Interview to Onboarding

The interview is step one. Once you choose someone, the job becomes hiring them well and quickly, because developers usually have options and a silent week after a good final round loses the candidate you wanted. Put the offer in writing, run the new hire paperwork, and plan the first month rather than improvising it.

A developer's first month has extra moving parts: a confidentiality and intellectual-property agreement, repository and hosting access granted from company-owned accounts, and a small real task that ships in week one. Our guides on developer onboarding and onboarding remote developers cover the sequence in detail.

FirstHR connects the offer, the agreements, e-signatures, the new hire paperwork, and the access and policy checklist in one place, and stores the signed documents on the employee profile so the record is there when you need it. FirstHR is an onboarding and HR platform, not a code hosting service or a payroll provider, so connect those separately. Applicant tracking is coming soon to FirstHR. You can browse the rest of the hiring templates for the offer, the reference-check script, and the rest of the process.

Frequently Asked Questions