Senior Web Developer Interview Questions and Scorecard

The first senior web developer I ever hired was chosen badly. I asked what frameworks he knew, he answered fluently, and I mistook fluency for judgment. Six months later the site was rebuilt on something nobody else could maintain, the hosting account was registered to his personal email, and I learned what a senior title costs when you interview for vocabulary instead of decisions.

A senior web developer is not a mid-level developer with more years. They are the person who decides what gets built, what gets bought, what gets left alone, and who gets called at midnight when the site is down. At a small business they usually make those calls with nobody above them to catch a bad one, which is why the interview has to test judgment directly.

At FirstHR we build for small businesses that hire without an HR department, where the owner or a single lead runs the whole process. These six question sets are written for that reader. Every question comes with why it is worth asking and what a strong answer sounds like, plus a live site audit exercise that works even if you do not write code, and a scorecard so the decision rests on evidence.

What a Senior Web Developer Owns

A senior web developer owns outcomes rather than tickets: the architecture of the site or application, its speed and accessibility, its security, its deployment path, and the standard that every other developer who touches it will inherit. The code is the visible part. The decisions are the part you are actually paying for.

At a small business the scope is wider still. The same person often chooses the stack, sets up hosting, handles the deploys, answers the outage, writes whatever documentation exists, and explains a tradeoff to an owner who does not code. If you are hiring your first developer, the sourcing side is covered in our guide to technical recruitment; this page is about the interview itself.

That breadth changes what you should test for. A candidate who is brilliant inside a large team, with code review and a QA function around them, can still be the wrong hire here, because the traits that make the arrangement work at your size are restraint, documentation, and honesty about what they do not know. Those are all interviewable, and the sets below test them on purpose.

Which Question Set to Use

Pick the sets that match what the role actually owns, then use them unchanged for every candidate. Most small businesses use the architecture set plus the audit exercise as the backbone, and add the security set whenever the site handles payments, logins, or customer data.

6 Question Sets to Download

Download all six as a single Word document, or copy the sets you need. Each one lists how to use it, the questions with why each is worth asking, what a strong answer contains, what to listen for, and space for notes. The final file is the scorecard.

Set 1: Architecture and Technical Decisions

Stack choice, build versus buy, the rewrite question, data modeling, dependency judgment, and hosting. This is the set that separates a senior title from a senior salary, and the one most interview lists skip entirely.

Set 2: Performance, Accessibility, and Search

Page speed method, real performance targets, images and third-party scripts, accessibility built into the markup, and the parts of search performance a developer genuinely controls. Every answer here should end in a number or a test.

Set 3: Security, Reliability, and Production Ownership

How small business sites actually get compromised, where secrets live, the first thirty minutes of an outage, backups that have been restored at least once, and who owns the domain and hosting accounts.

Set 4: Live Site Audit Exercise

A twenty five minute exercise that replaces the whiteboard: send a real URL, ask what they would fix first, and score the order of the findings. It works over a video call and it works if you do not code.

Set 5: Seniority, Mentoring, and Communication

Owned decisions, pushing back on requirements, explaining a tradeoff to a non-technical owner, mentoring, documentation, technical debt, and estimates. Often the set that matters most when this is your only developer.

Set 6: Scorecard, Seniority Guide, and Red Flags

A six-area rubric with space for evidence, a senior versus mid-level comparison you can hold a candidate against, and a twelve-item red-flag checklist. Use it with any of the sets above and fill it in alone.

How to Judge Answers If You Do Not Write Code

You do not need to grade the implementation. You need to grade the reasoning, and reasoning is gradeable by anyone who listens for the right shape. Senior answers name the constraints before the choice, state the cost alongside the benefit, and survive a follow-up question without changing story.

Three habits make this reliable. Ask "what did that cost?" after every success story, because a candidate who has genuinely owned decisions has the number and one who has not will change the subject. Ask them to explain one tradeoff as though you know nothing, and score whether you understood it afterward. And ask for live URLs of work they personally built, then have them walk you through the parts that were theirs while you watch.

If you want technical confirmation, buy it rather than fake it. One paid hour from a developer you trust, spent sitting in on the audit exercise or reviewing a code sample, costs less than a week of a bad hire. Our guide to finding developers for a small company covers how to build that outside opinion into a small process.

What Separates Senior from Mid-Level

Seniority is scope, not years. A mid-level developer completes assigned work well; a senior developer defines what the work should be and can defend the definition. Someone with eight years of ticket work may still be mid-level, and someone with four years of owned outcomes may already be past it.

The most reliable single probe is asking for a decision they owned end to end, from the problem through the result. Listen for whether the answer is built around "I decided" or around "we were asked to." Both are honest, but only one of them is the job you are hiring for.

The second probe is a decision they got wrong. Everyone senior has one. Candidates who cannot produce one have either not owned enough to be wrong yet, or are managing the interview rather than answering it, and both are worth knowing before an offer goes out.

The Live Site Audit Exercise

Replace the whiteboard with a real website. Send a live URL at the start of the call, give the candidate twenty minutes, and ask a single question: what would you fix first, and why. It grades exactly what the job involves, it needs no technical knowledge from you, and it takes less of the candidate's time than any take-home project.

What you are watching for is order. A senior candidate asks what the site is for before critiquing it, checks the mobile view within the first two minutes, finds a real performance problem and points at the specific cause, tries tabbing through the navigation with the keyboard, and then ranks the findings by business impact rather than by personal taste.

The two follow-up questions do most of the work. "What would that cost to fix?" separates people who have shipped from people who have opinions. "What would you deliberately leave alone?" is the senior question, because restraint is the trait that is hardest to fake and most valuable when nobody is checking their work. This exercise also respects the candidate, which matters when you are competing with faster employers for the same person.

Red Flags Worth Ending a Process Over

Most red flags are worth a follow-up question rather than a rejection, but a few are not. Holding client domains, hosting, or repositories in a personal account is the one I would stop for immediately, because it is how small businesses end up locked out of the website they paid for.

Treat two or more of these as a stop rather than a negotiation. The remaining flags are softer and deserve a probe: a candidate who has never tested a restore is common and can be trained, while a candidate who thinks documentation is beneath them is a genuine risk when they are your only developer and their notice period is two weeks.

Scoring the Interview

Score six areas from 1 to 5 with written evidence, immediately after each interview while the answers are still fresh. The scorecard is not bureaucracy, it is the thing that stops a confident final candidate from erasing your memory of a stronger earlier one.

If two or three people interview, each should score alone before the group talks, or the most technical voice in the room anchors everyone else. Trace every disagreement back to a specific answer during the feedback conversation, and record the outcome on a shared evaluation form so the reasoning survives the week. Applicant tracking is coming soon to FirstHR.

Senior Web Developer Pay and Classification

Benchmark against federal wage data first, then adjust for specialty, market, and remote scope. The band for this occupation is unusually wide, so the title on its own tells you very little about the number you should be offering.

Four things move a senior candidate inside that band: years of shipped production work, specialty, the local market, and whether the role is remote. A remote posting competes against national expectations rather than local ones, which is the biggest surprise for owners in lower-cost markets. Decide the remote question and publish a range before you interview, because both change the pool you get.

Classification matters as much as the number. Under the Fair Labor Standards Act, the computer employee exemption can cover a skilled worker paid on a salary or fee basis of at least $684 per week, or at least $27.63 an hour, whose primary duties involve systems analysis or the design, development, testing, or modification of computer systems and programs. Duties and pay decide it, not the title, and some states apply a stricter test.

Whether this is a hire or a contract engagement follows the shape of the work rather than your preference: project-shaped work suits a contractor, continuous work suits an employee, and the classification test is legal rather than optional. If the role is not written out yet, the senior frontend engineer templates are the closest starting point in our library. This is general information, not legal advice.

Fair, Legal, and Structured Interviewing

A good technical interview is fair, legal, and structured, and the three reinforce each other. Asking every candidate the same job-related core questions keeps you compliant, reduces bias, and produces a better decision, which is the part most engineering question lists leave out entirely.

On a senior technical hire the most common accidental problem is age, because seniority gets read as a proxy for years and the small talk drifts toward when someone graduated. Keep the questions on scope, decisions, and evidence. For the general version of this discipline, see our guides on running an interview and on questions employers cannot ask. This is general information, not legal advice.

Interviewing Without an HR Department

A large company interviews a senior web developer through an engineering manager, a panel, and a code review round. 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.

Two practical rules follow. Weight documentation, testing, and production discipline above raw delivery speed, because at your size nothing that slips gets caught by anybody else. And move quickly once you decide, since the same candidate is usually talking to two other employers. More question sets for the rest of the team sit in the hiring templates library, including a broader web developer question kit if the role you are filling is not a senior one.

The simplest rule I have found for this hire: choose the candidate who made you understand something, not the one who made you feel behind. Technical depth matters, and an hour of outside review will confirm it. Everything else about whether a senior developer succeeds at a small company comes down to judgment, restraint, and whether they write anything down.

From Interview to Onboarding

The interview is step one, and a strong hire who lands badly still leaves within a year. Move fast from decision to a written offer letter, run a reference check that confirms what the candidate personally built rather than what the team shipped, and have access ready before day one instead of during it.

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 a confidentiality agreement and an intellectual property assignment signed before the first commit, alongside the standard new hire paperwork.

Then give the first ninety days a shape: a small shipped change in week one, ownership of one area by month two, and a written check-in at thirty, sixty, and ninety days. Our guide to developer onboarding covers the access and environment side, and an onboarding template keeps the first week from being a laptop and a password.

FirstHR connects the offer, the agreements, e-signature, the paperwork, and the access-and-policy checklist in one place, so a small business can onboard a senior technical hire with everything 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.

Frequently Asked Questions