Web Developer Interview Questions and Scorecard

The first developer I ever interviewed ran circles around me. He used words I did not know, answered every question with total confidence, and I hired him because he sounded like the smartest person in the room. Three months later I had a half-finished site, no documentation, and a hosting account in his name. The problem was not that I lacked technical knowledge. The problem was that I asked questions I had no way to score.

At FirstHR, we build for owners and managers who run these interviews themselves, without an engineering manager to lean on. These six question sets cover the role the way a small business actually hires for it: a core set, front end, back end, full stack, a founder screen that needs no coding knowledge, and a scoring rubric with red flags.

What a Web Developer Actually Does

A web developer builds and maintains websites and web applications: the browser-side interface, the server code and database behind it, the integrations with payments, email, and booking tools, and the deployment that puts changes live. At a small business the job is almost always broader than the posting suggests, because there is nobody else to hand the rest to.

That breadth is the thing to interview for. The federal occupational profile for web developers and digital designers projects 7 percent employment growth from 2024 to 2034, much faster than the average across occupations, with about 14,500 openings a year. You are competing in a tight market, so a sloppy interview costs you the good candidates as well as the bad hires.

Three labels cover most of the market, and they are worth separating before you write a single question. Front end is everything the customer sees and touches in the browser: layout, responsiveness, speed, forms, accessibility. Back end is everything they never see: server code, the database, integrations, security, uptime. Full stack is one person doing both. A web designer is a fourth thing again, closer to visual design than to code, and confusing the two is the most common posting mistake I see.

Decide before you interview which half of that carries the risk in your business. If your site is a storefront or a marketing site, the customer-facing work dominates. If it holds customer data, takes payments, or runs a booking system, the server side is where a mistake actually hurts. Most small businesses end up needing someone who can do both, which is a full stack role whether or not the title says so.

Which Question Set Should You Use?

Pick the set that matches the actual work, then ask the same set of every candidate for that role. The core questions run through all of them, and each specialty set adds the questions that only matter for that half of the job. The founder screen and the scorecard work alongside any of the others.

6 Free Web Developer Question Sets to Download

Download all six as separate Word files in one ZIP, or copy individual sets. Each follows the same structure: when to use it, the questions with good-answer notes, what to listen for, and space for notes. The rubric adds scoring rows, a ten-item red-flag checklist, and a paid work-sample planner. Fill in your details and use.

Set 1: Core Web Developer Questions

The base set for any developer hire: shipped work, stack, debugging, security, deploys, and situational judgment, each with a note on what a good answer sounds like. Start here for every candidate.

Set 2: Front End Developer Questions

For the part customers see: responsive layout, page speed, forms, accessibility, testing on real devices, and working with designers. Use alongside the core set when the customer-facing site is the job.

See who is on track and who is stuck

Active Onboardings lists every new hire in progress. Late items are marked, so you see them without messaging anyone.

Start free trialSee how onboarding works

Active OnboardingsTrack and manage employee onboarding progress#EmployeeStageProgressStatus1Angela MartinSenior AccountantStagePre-boardingProgress1/9 tasksStatusOn Track2Darryl PhilbinWarehouse ForemanStageFirst DayProgress4/10 tasksStatusOverdue3Ryan HowardSales AssociateStageFirst WeekProgress7/11 tasksStatusOn Track4Kelly KapoorCustomer Service RepresentativeStageFirst MonthProgress10/12 tasksStatusOn Track

Set 3: Back End Developer Questions

For the part customers never see: server code, data modeling, integrations, security, database performance, backups, deploys, and monitoring. The higher-risk half for most small businesses.

Set 4: Full Stack Developer Questions

For the one technical hire who owns everything: prioritization without supervision, documentation, buy-versus-build decisions, and an honest read on which half of the stack is their weaker side.

Active Onboardings

Ryan HowardFirst WeekOn Track

Darryl PhilbinFirst DayOverdue

Kelly KapoorFirst MonthOn Track

Onboarding Wizard

1 · EmployeeRyan Howard

2 · TemplateSales Associate

3 · Review & Launch11 items

Onboarding Templates

Sales Associate11 steps

Warehouse Foreman10 steps

Customer Service12 steps

Onboarding

Each new hire, set up in one go

Put tasks, documents to sign and courses into one plan, then send all of it with one launch.

Start free trial

Set 5: Founder Screening Set

Built for owners who cannot evaluate code. Every question is scored on explanation, ownership, and honesty rather than technical correctness, so you can run a useful 30 minute screen with no coding knowledge at all.

Set 6: Scoring Rubric and Red Flags

A developer-specific scorecard across six areas, a ten-item red-flag checklist, and a paid work-sample planner, so you compare candidates on evidence instead of on whoever sounded most confident.

How to Judge Technical Skill If You Are Not Technical

You do not need to read code to hire a developer well; you need to stop scoring things you cannot score. Confidence, vocabulary, and speed of answer tell you almost nothing. Live work, a clear explanation, and a paid work sample tell you a great deal, and all three are available to any owner.

The pattern in strong answers is consistent across every question: they are specific, they include a tradeoff, and they distinguish what the candidate did from what the team did. Weak answers are confident and general. Here is what that looks like on three questions from the core set.

It is equally useful to know what to stop doing. Copying a list of trivia questions off the internet and reading them out will not help you, because you cannot tell a correct answer from a plausible one. Neither will asking a candidate to write code on a whiteboard while you watch, which mostly measures nerve. Skip anything you cannot score, and spend the time you save on the demo and the work sample instead.

One more habit worth building: ask the same questions in the same order to every candidate, and write down the answers as you go. That is the core of a structured interview, and it is what makes the comparison at the end meaningful instead of a memory contest.

The Paid Work Sample

A small, paid, time-boxed work sample is the single most useful step in a developer interview, and it beats an unpaid puzzle test almost every time. Give a task that resembles the real job, cap it at a few hours, pay a fair rate, and tell the candidate exactly what you will judge before they start.

The cost is small and the return is large. A four-hour sample at a fair rate costs less than a single week of a wrong hire, and it is the only part of the process where you see the actual work product rather than a description of it. Candidates who are strong tend to welcome it, because it favors them over whoever interviews best. A candidate who refuses a paid, scoped, time-boxed sample is telling you something worth hearing.

The clarifying questions a candidate asks before starting are often more revealing than the finished work. A developer who asks what the task is for, who uses it, and what happens if it fails is showing you exactly how they will behave on the job. If you cannot judge the submission yourself, this is the moment to buy that one hour of outside review.

Red Flags in a Web Developer Interview

Most bad developer hires at small businesses are visible in the interview, but only if you know which signals to weight. None of the following is automatically disqualifying on its own; two or three together usually are. The scorecard set includes the full ten-item checklist.

Portfolio verification deserves its own minute. Ask which specific parts of each project the candidate wrote, then open the site during the call and have them point at those parts. Agency and team work gets described in the first person by everyone who was in the room, which is not dishonesty so much as habit, but you need to know what this person did with their own hands before you build a role around it.

Ownership of the code, domain, hosting, and accounts deserves special weight because it is the flag that can cost you the business rather than a few weeks. Ask it directly in every interview, and never accept an arrangement where a person outside the company holds the domain or the production accounts in their own name. Then verify the rest through a proper reference check, which is where inflated portfolio claims usually come apart.

Scoring and the Hiring Decision

Score each candidate right after the interview, while it is fresh, on the same six areas every time. Anchor every number to something the candidate actually said or showed you, so the final comparison rests on evidence rather than on whichever conversation felt best.

If more than one person interviews, each should score independently before comparing, because the first opinion spoken out loud tends to anchor everyone who follows. Collect the sheets, then run a short interview feedback conversation where each disagreement gets traced back to a specific answer. Applicant tracking is coming soon to FirstHR.

Consistency is also your legal safety net. Asking every candidate the same job-related questions and scoring them on the same criteria is the practice that keeps an interview clear of the prohibited employment practices the EEOC describes. Most accidental problems start in the informal small talk, not in the technical questions.

Web Developer Pay and Classification

Benchmark against federal wage data first, then adjust for your market, the specialty, and the seniority you need. Pay is also where the classification question surfaces, and getting that wrong is more expensive than paying slightly above market.

Four things move a candidate inside that band: years of shipped production work, specialty (back end and infrastructure skills tend to price above pure front end work), the local market, and whether the role is remote. A remote posting competes against national pay expectations rather than local ones, which is the single biggest surprise for owners in lower-cost markets. Decide the remote question and publish a range before you start interviewing, because both change the pool you get.

On classification, the Fair Labor Standards Act computer employee exemption is not automatic. It requires payment on a salary or fee basis of at least $684 per week, or at least $27.63 an hour, plus qualifying duties such as systems analysis or the design, development, testing, or modification of computer systems and programs, per Department of Labor Fact Sheet 17E. State rules can be stricter.

The employee-versus-contractor decision follows the shape of the work, not your preference. Project-shaped needs suit a contractor; continuous work suits a hire. Either way, the classification test is legal rather than optional, and a long-term, fully directed contractor can drift into employee territory over time.

Interviewing a Developer at a Small Business

A large company interviews developers through an engineering manager, a panel, and a code review process. A small business interviews through the owner, between everything else, usually with no technical backup at all. That gap is where the avoidable mistakes live, and it is worth naming them directly.

There is also a sequencing point. Run the founder screen first, as a short call, and only spend a technical round and a paid sample on the two or three candidates who clear it. Owners tend to do the reverse, burning their limited technical review budget on the first person who sounds impressive. Screening on explanation and ownership costs you nothing and removes most of the field before the expensive part starts.

The simplest rule I have found: hire the candidate who made you understand something, not the one who made you feel behind. Technical depth matters, and a work sample plus an hour of outside review will confirm it. Everything else about whether this hire succeeds at your size comes down to explanation, prioritization, and ownership.

From Interview to Onboarding

Once you pick someone, a developer hire has onboarding steps that most roles do not. Get the intellectual property assignment and a confidentiality agreement signed before the first line of code, alongside the standard I-9 and W-4 paperwork. Then set up access properly.

The account ownership step is the one people skip and regret. Create the repository, hosting, domain, and analytics accounts in the business name and invite the developer into them, rather than inheriting accounts registered to an individual. Pair that with an onboarding template so the first week has a plan beyond a laptop and a password.

FirstHR connects the offer, the agreements, e-signature, the new-hire paperwork, and the access-and-policy checklist in one place, so a small business can onboard a technical hire with the paperwork and the provisioning tracked from a single system. FirstHR is an onboarding and HR platform, not a payroll provider, so connect payroll separately. Applicant tracking is coming soon to FirstHR.

Set up your next new hire in FirstHR

4.7 on G2

Start free trial

Offer LetterSigned

Welcome courseCompleted

Frequently Asked Questions