Six question sets for owners running the interview themselves: core craft, responsive and accessible build, performance, frameworks and handover, a portfolio screen that needs no coding knowledge, and a scorecard with red flags. Download as DOCX.
The first front end developer I ever interviewed ran circles around me. He talked about hydration and bundle splitting for twenty minutes, I nodded, and I hired him. Three months later our checkout still did not work on an iPhone and nobody could deploy anything without him. The problem was not his skill. It was that I had no way to tell his answers apart from a confident guess, so I graded fluency instead of evidence.
That is the actual problem for most owners hiring this role. Front end work is highly visible and easy to talk about, which makes it unusually easy to interview badly. The fix is not learning to code. It is asking questions whose answers you can verify: open the live site, view it on your phone, ask what they personally built. Pair these sets with the front end developer job description you posted.
At FirstHR, we build for owners and managers who run these interviews themselves, without an engineering manager to lean on. These six sets cover the role the way a small business actually hires for it, and every question comes with a note on what a good answer sounds like. If the posting was broader, the web developer job description covers that version of the role.
TL;DR
Interview a front end developer on five things: core craft (semantic HTML, CSS, JavaScript), responsive and accessible build, page speed, shipped work they can open and explain, and handover risk. Judge evidence, not fluency. Add a small paid work sample. Download six question sets and a scorecard as DOCX.
What a Front End Web Developer Actually Does
A front end web developer builds everything the customer sees and touches in the browser: layout, responsiveness, page speed, forms, animation, and accessibility. The work is usually HTML, CSS, and JavaScript plus a framework, and it ends where the server begins. Everything the customer never sees, server code, databases, integrations, and security, belongs to the back end.
That boundary matters before you write a single question, because it decides which half of the risk you are hiring against. A marketing site, a landing page, or a storefront interface is mostly front end work. A booking system or a customer portal leans back end. If one person will own both, you are hiring full stack, and the broader web developer interview questions kit covers that shape better than this one does.
Responsibility
Front End Developer
Back End Developer
Web Designer
Builds the interface customers touch
Owns responsiveness and page speed
Makes the interface keyboard accessible
Writes server code and designs the data
Produces the visual design in the first place
Confusing a front end developer with a web designer is the most common posting mistake I see. A designer decides how it should look. A front end developer makes it work in a browser, on a phone, for a keyboard user, in under two seconds. Some people do both well, but you should ask for evidence of each rather than assuming the pair comes together.
Which Question Set Should You Use?
Pick the sets that match the actual work, then ask the same ones of every candidate for that role. The core set runs through all of them, and the other five add depth where your risk sits. More sets is not better; a focused interview scored consistently beats a long one scored by feel.
Core Front End
Start here
HTML, CSS, and JavaScript fundamentals, browser understanding, and shipped work they can open and explain. The base set for every front end hire.
Responsive + Accessibility
Customer facing
Phones, browsers, devices, keyboard operation, focus states, and contrast. Use whenever real customers will touch what this person builds.
Performance
Speed costs money
Page speed, what they measure, and how they keep a site fast after launch. Use when the site sells, ranks, or runs on mobile data.
Frameworks + Tooling
Owning a codebase
Framework depth, version control, deployment, documentation, AI tool use, and what happens to your code if they leave.
Portfolio + Work Sample
No coding needed
A 30 minute screen you can run yourself: open their live work, judge it on a phone, then set up a small paid task with the same brief for every finalist.
Scorecard + Red Flags
Rate and compare
A six-area rubric, a red-flag checklist, and a decision box, so you compare candidates on evidence instead of on whichever call felt best.
Match the Sets to the Hire
Customer-facing site or storefront: Core plus Responsive and Accessibility. A site that sells, ranks, or runs on mobile data: add Performance. Someone who will own or inherit a codebase: add Frameworks and Tooling. Nobody on your side writes code: run Portfolio and Work Sample first as a 30 minute screen, then a deeper round. Use the Scorecard with all of them. When in doubt, start with Core plus Portfolio and Work Sample.
6 Free Front End Question Sets to Download
Download all six as one Word document 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. More kits for this role and every other one sit in the hiring templates library.
Download All 6 Front End Question Sets
Core craft, responsive and accessibility, performance, frameworks and handover, a portfolio and work sample screen, and a scorecard with red flags. All in one DOCX.
Set 1: Core Front End Questions
The base set for every front end hire: semantic HTML, CSS organization, JavaScript, what the browser actually does, and live work they can open and explain. Start here regardless of the stack.
Core Front End Interview Questions
CORE FRONT END WEB DEVELOPER INTERVIEW QUESTIONS
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the starting set for every front end hire, whether they will build a
marketing site, a storefront, or an app screen. Ask 6 to 8 of these questions.
Each one has a note on what a good answer sounds like, so you can judge the
answer without writing code yourself. Score every candidate on the same rubric.
QUESTIONS
1. Show me two front end projects that are live today and walk me through what
you personally built.
(Good answer: opens the real site, points at specific parts they own, and is
honest about what a designer or teammate did instead.)
2. When you get a design file and a deadline, what are the first three things
you do?
(Good answer: checks the design against real content, agrees on breakpoints
and states, and flags anything ambiguous before writing code.)
3. How do you decide which HTML element to use for a button, a link, or a form
control?
(Good answer: chooses by meaning, not by looks. Knows a button submits or
acts and a link navigates. Mentions keyboard and screen reader behavior.)
4. How do you organize CSS on a project you expect to maintain for two years?
(Good answer: names an actual approach such as a utility framework, CSS
modules, or a naming convention, and explains why it fits the team size.)
5. Explain what happens when a user clicks a button on a page you built.
(Good answer: describes the event, the handler, the state change, and what
the user sees, in plain language a non-developer can follow.)
6. What does the browser do between the request and the page appearing?
(Good answer: HTML parsed, CSS and fonts loaded, JavaScript executed, page
painted. Depth here separates a copy-paste developer from a real one.)
7. Tell me about a bug that only showed up for real users, not on your machine.
(Good answer: a specific story with a cause, a fix, and a change to how they
test afterward.)
8. What part of front end work do you not enjoy or not do well?
(Good answer: a real, specific gap. Candidates who claim none are usually
guessing at what you want to hear.)
WHAT TO LISTEN FOR
•Live, shipped work they can open and explain, not screenshots
•Plain-language explanations of technical choices
•Honesty about what they owned versus what the team owned
•Curiosity about your users and your business, not just the stack
NOTES
__
__
Set 2: Responsive, Browser, and Accessibility Questions
For any customer-facing role: phones first, device and browser testing, keyboard operation, focus states, contrast, and how they check their own work. Use this whenever real customers will touch what this person builds.
Responsive, Browser, and Accessibility Questions
RESPONSIVE DESIGN, BROWSER, AND ACCESSIBILITY QUESTIONS
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
Use this set whenever the work is customer facing. Most of your traffic arrives
on a phone, and an interface that fails on a small screen or for a keyboard user
is a business problem, not a detail. These questions test whether the candidate
treats devices and accessibility as part of the job or as cleanup at the end.
RESPONSIVE AND BROWSER QUESTIONS
1. Walk me through how you build a page that works on a phone and a desktop.
(Good answer: starts from the small screen, uses fluid layout and a few
deliberate breakpoints, and tests on a real device, not only a simulator.)
2. Which browsers and devices do you test on before you call something done?
(Good answer: names a short list including at least one real phone, and asks
what our own analytics say rather than guessing.)
3. A layout breaks only on one older phone. How do you find the cause?
(Good answer: reproduces it first, isolates the component, checks feature
support, then fixes it without breaking everything else.)
4. How do you handle a design that a designer never drew at tablet width?
(Good answer: goes back and asks rather than inventing silently, and can
propose a sensible default.)
ACCESSIBILITY QUESTIONS
5. What does accessibility mean in the work you actually do day to day?
(Good answer: semantic markup, labeled form fields, keyboard operation, focus
states, color contrast, alternative text. Concrete, not a slogan.)
6. Can someone use the interface you built with a keyboard only? Show me how you
would check.
(Good answer: tabs through the page, watches focus order and visible focus,
and knows a custom widget needs extra work.)
7. What tools or checks do you run for accessibility, and what do they miss?
(Good answer: uses an automated checker and knows automated checks catch only
part of the problem, so manual keyboard and screen reader testing follows.)
8. Tell me about a time you pushed back on a design for accessibility reasons.
(Good answer: a real example, handled as a conversation about the user, not
as a fight about rules.)
WHAT TO LISTEN FOR
•Mobile treated as the default case, not an afterthought
•A concrete testing routine with named devices and browsers
•Accessibility described as habits, not as a compliance checkbox
•Willingness to raise problems with a design before building it
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
For sites that sell, rank in search, or serve customers on mobile data. These questions separate developers who measure before they change anything from developers who guess at fixes, which is the most useful single signal in the whole interview.
Performance and Page Speed Questions
FRONT END PERFORMANCE AND PAGE SPEED QUESTIONS
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
Use this set when the site sells something, ranks in search, or serves customers
on mobile data. Speed is the front end responsibility that costs money most
directly. These questions separate developers who measure from developers who
guess, which is the single most useful signal in this whole area.
QUESTIONS
1. Our page takes eight seconds to load on a phone. Walk me through your first
hour of work.
(Good answer: measures before changing anything, looks at what is downloaded
and when, and names the biggest item first. Anyone who starts guessing at
fixes without measuring is telling you something.)
2. Which speed numbers do you actually watch, and why those?
(Good answer: names loading, interaction, and layout stability metrics, and
ties them to what the user feels rather than to a score out of one hundred.)
3. What are the usual causes of a slow page in your experience?
(Good answer: oversized images, too much JavaScript, blocking third-party
scripts, unoptimized fonts, no caching. Real specifics with an order.)
4. Marketing wants to add four tracking scripts. What do you say?
(Good answer: agrees to measure the cost, loads them without blocking the
page, and can explain the tradeoff to a non-technical stakeholder.)
5. How do you handle images so they do not slow the site down?
(Good answer: modern formats, correct dimensions, compression, lazy loading
below the fold, and a real sense of file size budgets.)
6. How would you keep the site fast six months after launch?
(Good answer: a repeatable check rather than a one-time cleanup, plus a
budget or threshold that flags regressions.)
7. Show me a site you made faster and tell me the before and after numbers.
(Good answer: has the numbers, or admits honestly that they were never
measured.)
WHAT TO LISTEN FOR
•Measures first, changes second
•Talks about user experience, not only tool scores
•Can explain a tradeoff to a non-technical person
•Thinks about keeping speed, not just achieving it once
NOTES
__
Set 4: Frameworks, Tooling, and Code Quality Questions
For a hire who will own or inherit a codebase: framework depth tied to real projects, version control, safe deployment, documentation, how they use AI coding tools, and what happens to your code and accounts if they leave.
Frameworks, Tooling, and Code Quality Questions
FRAMEWORKS, TOOLING, AND CODE QUALITY QUESTIONS
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
Use this set when the hire will own or inherit a codebase. The goal is not to
quiz them on framework trivia. It is to find out whether they can work inside
your stack, hand work over cleanly, and leave the business able to hire the next
person. Ask what they built with a tool, never just whether they know it.
QUESTIONS
1. Which framework are you strongest in, and what did you ship with it?
(Good answer: one clear strength with a real project attached, plus honest
familiarity with one or two others.)
2. Our site is built on something you have not used. How would you approach it?
(Good answer: a concrete learning method and a realistic ramp estimate, not
an instant claim that it is easy.)
3. How do you decide whether something needs a framework at all?
(Good answer: matches the tool to the problem and the team size. A candidate
who reaches for a heavy stack on a five-page site is a cost risk.)
4. How do you use version control on a solo project?
(Good answer: commits regularly with meaningful messages, uses branches, and
can explain why it matters even with no teammates.)
5. How do you deploy a change without breaking the live site?
(Good answer: a staging or preview environment, a review step, and a way to
roll back. A candidate who edits production directly is a real risk.)
6. What does someone inheriting your code need in order to keep it running?
(Good answer: a README, documented environment setup, dependencies listed,
and no undocumented steps living only in their head.)
7. How do you use AI coding tools, and how do you check what they produce?
(Good answer: uses them as a speed-up and reviews the output. A candidate who
cannot explain the code they submitted is the risk this question finds.)
8. What happens to our site, code, and accounts if we stop working together?
(Good answer: repository, hosting, domain, and analytics all in your name,
with a clean handover. Anything else is a lock-in problem.)
WHAT TO LISTEN FOR
•One deep strength beats five shallow claims
•Owns the risk of deploying to a live site
•Leaves the business able to hire the next developer
•Your accounts stay in your name
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
A 30 minute screen for owners who do not write code. Open their live work, judge it on your own phone, cover how they work with clients, and set up a small paid task with the same brief for every finalist.
Portfolio Review and Work Sample (No Coding Needed)
PORTFOLIO REVIEW AND PAID WORK SAMPLE
For owners and managers who do not write code
Candidate: __
Business: __
Interviewer: __
WHEN TO USE THIS SET
Use this as a 30 minute first call when nobody on your side can evaluate code.
It replaces technical depth with evidence you can verify yourself: live work, a
clear explanation, and a small paid task. Run it before any deeper round, and
use it to shorten a long applicant list to two or three real candidates.
PART 1: PORTFOLIO WALKTHROUGH (15 MINUTES)
1. Open two sites you built and tell me what you did on each.
(Good answer: the sites load, and they separate their work from the team's.)
2. Who was the client, and what problem were they trying to solve?
(Good answer: talks about the business outcome, not only the visual design.)
3. Open one of them on your phone right now and show me.
(Good answer: it works. You can judge this without any technical knowledge.)
4. What would you change about this project if you built it again?
(Good answer: a specific regret. No regrets usually means no ownership.)
5. What did the client ask for that you talked them out of, and why?
(Good answer: shows judgment and the ability to say no politely.)
PART 2: WORKING WITH US (10 MINUTES)
6. How do you prefer to receive work, and how often will we hear from you?
7. What do you need from us to do your job well?
(Good answer: content, brand assets, a decision maker, and access. A
candidate who needs nothing has not done this before.)
8. How do you estimate, and what do you do when an estimate slips?
9. Are you looking for employment or contract work, and at what commitment?
PART 3: THE PAID WORK SAMPLE (SET IT UP ON THE CALL)
Offer a small, paid, time-boxed task that mirrors the real job. Pay for it. Keep
it under four hours. Give the same brief to every finalist.
Example brief:
Build one responsive page from the attached design. It must work on a phone,
be operable with a keyboard alone, load quickly on mobile data, and come with
a short note explaining your choices.
Score the result on:
[ ] Does it match the design at both phone and desktop width?
[ ] Does it work with a keyboard alone?
[ ] Does it load fast on a phone?
[ ] Is the note clear enough for a non-developer to follow?
[ ] Did they deliver when they said they would?
NOTES
__
Set 6: Front End Developer Scorecard and Red Flags
A six-area rubric, a red-flag checklist, and a decision box, so you compare candidates on written evidence instead of on whichever conversation felt best. Use it with any set above.
Front End Developer Scorecard and Red Flags
FRONT END DEVELOPER SCORING RUBRIC AND RED-FLAG CHECKLIST
Candidate: __
Business: __
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 showed. If more than one
person interviews, each scores independently before you compare. Use the same
rubric for every candidate for the same role. A consistent, evidence-based
process is fairer, easier to defend, and produces better hires.
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
Core front end craft: semantic HTML, CSS, JavaScript, browser understanding
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Responsive and accessible build: phones first, keyboard operable, contrast
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Performance: measures before changing, understands what costs speed
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Shipped evidence: live work they can open and explain honestly
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Handover and risk: version control, deployment, documentation, your accounts
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Communication: explains technical choices to a non-technical owner
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
RED FLAGS (WEIGH CAREFULLY)
[ ] Portfolio links are dead, or the sites are broken on a phone
[ ] Cannot say which parts of a project they personally built
[ ] Treats accessibility as somebody else’s job or as unnecessary
[ ] Starts fixing a slow page without measuring anything first
[ ] Edits the live site directly, with no staging and no way to roll back
[ ] Cannot explain code they submitted as their own work
[ ] Wants hosting, domain, or repository registered in their own name
[ ] Answers about past work are vague about dates, scope, or outcomes
DECISION
Total score: ______ / 30
Work sample completed: [ ] Yes [ ] No Score: ______
You do not need to grade the code; you need to tell a specific answer from a vague one. That distinction survives without technical background, because the pattern is consistent across every question in these sets: strong candidates name real projects, real constraints, and real mistakes, while weak candidates speak in categories.
Three questions carry most of the load. Each one has a strong version and a weak version that you can recognize on the call, without knowing what any of the terms mean.
How do you decide which HTML element to use for a button or a link?
Strong answer: Chooses by meaning rather than by appearance: a button performs an action, a link navigates somewhere. A strong answer connects that choice to keyboard users and screen readers, and mentions that styling a link to look like a button does not make it behave like one.
Weak answer: A weak answer says it does not matter, or picks whichever element is easier to style. That single answer predicts a lot of downstream accessibility work.
Our page takes eight seconds to load on a phone. What do you do first?
Strong answer: Measures before changing anything: opens the page on a throttled connection, looks at what gets downloaded and in what order, and names the largest offender before proposing a fix. Usually images, JavaScript, or third-party scripts.
Weak answer: A weak answer jumps straight to remedies, minify this, cache that, without looking at the actual page. Guessing at fixes is the most common front end failure mode.
Show me two sites you built and tell me what you personally did.
Strong answer: The links work, the sites load on a phone, and the candidate clearly separates their own work from the designer’s and the team’s. They can name a decision they made and why.
Weak answer: A weak answer offers screenshots instead of live links, dead URLs, or a claim of full ownership on a site that was obviously a team build.
Beyond the answers, weight the things you can verify yourself. Do the portfolio links load? Does the site work on your phone while you hold it? Can the candidate explain one decision in language you follow? A developer who cannot explain a choice to the person paying for it will be expensive to work with, whatever their skill.
Core craft
Picks HTML elements by meaning
Can organize CSS for the long term
Explains what the browser does
Accessible by habit
Labels every form field
Checks keyboard operation and focus
Knows automated checks miss things
Measures performance
Profiles before changing code
Knows what actually costs speed
Keeps a budget after launch
Safe to hand a codebase
Uses version control deliberately
Deploys with a way to roll back
Documents enough for the next hire
Responsive and Accessibility Questions
Ask responsive and accessibility questions of every front end candidate, even for a role you think of as cosmetic. Most of your traffic arrives on a phone, and an interface that fails on a small screen or for a keyboard user is a revenue problem before it is an engineering problem.
Ask
What a strong answer includes
How do you build for phone and desktop?
Starts small, fluid layout, few deliberate breakpoints, tests on a real device
Which browsers and devices do you test on?
A short named list, and asks what our analytics actually show
What does accessibility mean in your daily work?
Semantic markup, labeled fields, keyboard operation, focus, contrast, alt text
How do you check accessibility?
An automated tool plus manual keyboard testing, and knows what automation misses
Tell me about pushing back on a design
A real example framed around the user, not around rules
Accessibility is also the area where a weak answer costs the most later, because retrofitting it into a finished interface is far more expensive than building it in. Treat a dismissive answer here as a signal about everything else the candidate considers optional.
The ADA Reaches What You Ship on the Web
The Department of Justice states that it has consistently taken the position that the Americans with Disabilities Act applies to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web, and its guidance points to the Web Content Accessibility Guidelines and the Section 508 standards as the technical references businesses commonly use (ADA.gov guidance on web accessibility). This is general information, not legal advice.
Performance Questions That Reveal Experience
The most revealing question in a front end interview is the slow page question, because it exposes method rather than knowledge. Ask what they would do about a page that takes eight seconds to load on a phone, then listen for whether the first step is measuring or guessing.
Developers who have shipped to real users always start by looking: what is downloaded, in what order, and what is the largest single item. Developers who have not start reciting remedies. That difference predicts how they will behave on every future problem you hand them, which is why this set is worth running even for a small marketing site.
Ask
What a strong answer includes
Our page loads in eight seconds. First hour?
Measures on a throttled connection before touching anything
Which speed numbers do you watch?
Loading, interaction, and layout stability, tied to what users feel
Usual causes of a slow page?
Oversized images, heavy JavaScript, blocking third-party scripts, fonts
Marketing wants four tracking scripts
Measures the cost, loads them without blocking, explains the tradeoff
How do you keep it fast after launch?
A repeatable check and a budget that flags regressions
The Portfolio Review and Paid Work Sample
For a non-technical interviewer, the portfolio walkthrough and a small paid work sample are worth more than every verbal question combined. Both produce evidence you can judge directly, and both are hard to fake in the way a confident answer is easy to fake.
Run the portfolio review live rather than reading a PDF. Ask the candidate to open two sites, then open one yourself on your phone while they talk. Then give every finalist the same short brief, pay for the time, and score the result against criteria you wrote down before anyone submitted anything.
Open the live work on the call
Ask them to load two sites they built and view one on a phone while you watch. Broken links and broken mobile layouts end the question quickly.
Give every finalist the same brief
One responsive page from a design, keyboard operable, fast on mobile data, plus a short note explaining their choices. Same brief, same deadline, every time.
Keep it under four hours and pay for it
A paid, time-boxed task gets you serious candidates and keeps the exercise fair. Unpaid multi-day projects filter for desperation, not skill.
Score the result, not the vibe
Match to design at two widths, keyboard operation, load speed on a phone, clarity of the note, and whether they delivered on time. Five checks you can run yourself.
Keep the sample close to the real job and away from puzzles. Algorithm questions are a poor proxy for front end work, where the difficulty lives in browsers, devices, and users rather than in data structures. If you want a broader view of testing candidates on output, the guide to hiring assessments covers the tradeoffs, and skills-based hiring explains why the sample often beats the resume.
Scoring and Red Flags
Score each candidate on a written rubric immediately after the interview, while the answers are fresh. Rate the same six areas for everyone, anchored to what the candidate actually said or showed, so you compare on evidence rather than on whichever call left the best impression.
Scoring area
What a 5 looks like
Core front end craft
Picks elements by meaning, explains browser behavior plainly
Responsive and accessible build
Phones first, keyboard operable, checks contrast and focus
Performance
Measures before changing, knows what costs speed
Shipped evidence
Live sites that open, honest about what they owned
Handover and risk
Version control, safe deploys, docs, your accounts in your name
Communication
Explains a technical choice to a non-technical owner
The red flags worth weighing hardest are dead portfolio links, an inability to say which parts of a project they built, editing the live site directly with no way to roll back, and wanting hosting or the domain in their own name. If two people interview, each should score independently before you discuss, then compare notes in a structured interview feedback step.
Keep the completed scorecards with the rest of the hiring record rather than in scattered notebooks and inboxes, because the written evidence is what you fall back on if a decision is ever questioned months later. Applicant tracking is coming soon to FirstHR, and until then a single shared folder and a consistent file name per candidate do the job.
Front End Developer Pay and Classification
Benchmark against federal wage data first, then adjust for your market, the seniority you need, and whether you are posting remote. There is no separate federal occupation for front end developers specifically, so the nearest classifications are web developers and the adjacent web and digital interface designers.
Median $92,650 a Year (BLS OEWS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), web developers had a median annual wage of $92,650, about $44.54 an hour, with the lowest 10 percent under $48,100 and the highest 10 percent above $162,290 (U.S. Bureau of Labor Statistics). The related web and digital interface designers occupation reported a higher median of $104,000 in the same survey.
Four things move a candidate inside that band: years of shipped production work, depth in the exact stack you run, the local market, and whether the role is remote. A remote posting competes against national pay 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 start interviewing.
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 the design, development, testing, or modification of computer systems and programs, per Department of Labor Fact Sheet 17E. State rules can be stricter, and the employee versus contractor test follows the shape of the work rather than your preference.
Fair, Legal, and Structured Interviewing
A good technical interview is fair, legal, and structured, and the three reinforce each other. Asking the same job-related questions of every candidate and scoring them on a written rubric keeps you compliant, reduces bias, and produces better hires at once. This is the part the generic question lists skip entirely.
Same questions, same order
Pick your sets before the first call and ask every candidate for that role the same core questions. Consistency is what makes the comparison meaningful.
Score against a written rubric
Rate each area 1 to 5 with a note on what the candidate actually said. Written evidence beats memory, and it is what you rely on if a decision is ever questioned.
Keep every question job-related
Ask about the work: the code, the browsers, the deadlines. Avoid age, family plans, national origin, religion, disability, and salary history where local law restricts it.
Judge the sample, not the person
A paid work sample scored on stated criteria keeps the evaluation on the output. It also gives candidates from non-traditional backgrounds a fair path in.
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an open conversation. Asking the same job-related questions of everyone also keeps you inside the EEOC's rules against basing decisions on protected characteristics. This is general information, not legal advice.
Interviewing Without an HR Department
At a large company, a front end candidate runs through a panel of engineers with a recruiter managing the scorecards. At a small business the owner usually runs the whole thing alone, between everything else, and often without anyone who can evaluate code. That reality shapes the interview, and it is where the avoidable mistakes concentrate.
You are hiring a front end developer and nobody on your side writes code
This is the normal case at a small business, and it is why generic question lists fail here. A list of framework trivia is useless if you cannot grade the answer. What you can grade is evidence: whether the live sites open, whether they work on your own phone, whether the candidate can separate their work from the team’s, and whether they explain a technical choice in language you follow. Every question in these sets carries a note on what a good answer sounds like, so the judgment you make is about specificity and honesty rather than about syntax. Start with the portfolio and work sample set, then run a deeper round only on the two or three candidates who survive it.
The front end is where your customers actually meet your business
A back end fault is invisible until it breaks. A front end fault is the first thing every customer sees: a checkout that fails on a phone, a form nobody can complete with a keyboard, a page so slow that visitors leave before it paints. That makes responsiveness, accessibility, and speed business questions rather than engineering preferences, and it is why two of these six sets are devoted to them. Ask the accessibility and performance questions even for a role you think of as cosmetic. The answers separate a developer who has shipped to real users from one who has only ever built on a fast laptop.
One developer can leave you unable to change your own website
The most expensive front end hiring mistake at a small business is not a weak developer. It is a developer who leaves and takes the keys with them: hosting under their personal account, a domain they registered, a repository nobody else can reach, and setup steps that lived only in their head. Ask the handover questions in the frameworks set before you hire, not after. Once you choose someone, FirstHR handles the people side of that handover: the offer and a confidentiality agreement sent for e-signature, an onboarding workflow for system access and account ownership, and every signed document stored on the employee profile. FirstHR is an onboarding and HR platform, not a code hosting or project management tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
The interview is step one. Once you choose a developer, onboarding this role has a few extra steps because of the access involved: a signed offer letter and a confidentiality agreement, an intellectual property assignment, and repository, hosting, domain, and analytics access created under the business rather than under the developer, alongside the standard I-9 and W-4.
Send the offer and the agreements
Confirm role, pay, and start date in writing, and have the developer sign a confidentiality agreement and an intellectual property assignment before they touch the code.
Set up access under your accounts
Repository, hosting, domain registrar, analytics, and design files all owned by the business, with the developer added as a user rather than as the owner.
Give them a first task that ships
A small, real, low-risk change in week one tells you more about the hire than a month of setup, and it proves the deployment path works end to end.
Store the records
Signed offer, agreements, I-9, W-4, and policy acknowledgments organized in one place, along with the interview scorecards you used to decide.
Give the new hire one small, real change to ship in week one. It teaches you more than a month of setup and it proves the deployment path works end to end. Pair it with a structured onboarding template so the first thirty days have a shape, and keep the new-hire paperwork in the same place as the interview scorecards you used to decide.
FirstHR connects the offer, the agreements, e-signatures, and the onboarding workflow in one system, and stores every signed document on the employee profile, so a small business can run hiring through onboarding without a spreadsheet and four inboxes. FirstHR is an onboarding and HR platform, not a code hosting or project management tool, so connect those separately. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Judge evidence, not fluency: open the live sites, view one on your phone, and ask what the candidate personally built.
Ask responsive and accessibility questions of every front end candidate, because retrofitting either one is far more expensive than building it in.
The slow page question is the most revealing in the interview: strong candidates measure first, weak candidates start guessing at fixes.
Settle handover risk before you hire: version control, safe deployment, documentation, and every account registered to the business.
Run a small paid work sample with the same brief for every finalist, and score it on criteria you wrote down in advance.
Use BLS data as a baseline: web developers reported a median of $92,650 a year in the May 2025 survey.
Frequently Asked Questions
What questions should I ask a front end web developer?
Ask questions that produce evidence rather than opinions. The strongest openers are: show me two sites you built that are live today and tell me what you personally did; how do you decide which HTML element to use for a button or a link; walk me through building a page that works on a phone and a desktop; our page takes eight seconds to load on a phone, what do you do first; can someone use what you built with a keyboard alone; and what happens to our site, code, and accounts if we stop working together. Add framework and deployment questions if the hire will own a codebase. Close with a small paid work sample so you see real output before you decide. This page includes six ready-to-use sets and a scorecard, each question paired with a note on what a good answer sounds like.
How do I interview a front end developer if I cannot code?
You do not need to grade the code, you need to grade the evidence. Ask the candidate to open two live sites on the call, then view one on your own phone; a broken mobile layout is something anyone can see. Ask them to explain a technical decision in plain language, because a developer who cannot explain their choices to an owner will be expensive to work with. Listen for specificity and honesty: strong candidates name what they personally built and admit what a designer or teammate did. Then run a small paid work sample with the same brief for every finalist and score it on five things you can check yourself: match to the design at phone and desktop width, keyboard operation, load speed on a phone, clarity of their written note, and whether they delivered on time.
What is the difference between a front end and a back end developer?
A front end developer builds everything the customer sees and touches in the browser: layout, responsiveness, page speed, forms, animation, and accessibility, usually with HTML, CSS, and JavaScript plus a framework. A back end developer builds what the customer never sees: server code, the database, integrations with payments or email, security, and uptime. A full stack developer does both, which is what many small businesses actually need when one person owns the entire website. Decide which half carries the risk in your business before you write the questions. A marketing site, landing pages, or a storefront front end is mostly front end work. A booking system, a customer portal, or anything holding payment data leans back end. A web designer is a fourth thing again, closer to visual design than to code.
Should I give a front end developer a coding test?
A small paid work sample beats both a whiteboard test and an unpaid take-home project. Give every finalist the same brief, keep it under four hours, pay for the time, and make it mirror the actual job: build one responsive page from a design so that it works on a phone, is operable with a keyboard alone, loads quickly on mobile data, and comes with a short note explaining the choices. Score it on stated criteria before you look at who submitted it. Unpaid multi-day projects filter for candidates with free time rather than for skill, and strong developers frequently decline them. Algorithm puzzles are a poor proxy for front end work in particular, because the job is far more about browsers, devices, and users than about data structures.
Why do accessibility questions belong in a front end interview?
Because the front end is where accessibility is either built in or lost, and the cost of losing it lands on the business. The Department of Justice has consistently taken the position that the Americans with Disabilities Act applies to the goods and services a public accommodation offers on the web, and its guidance points to the Web Content Accessibility Guidelines and the Section 508 standards as the technical references most often used. A developer who labels form fields, keeps interfaces keyboard operable, maintains visible focus states, and checks color contrast prevents a category of problem that is far more expensive to retrofit than to build correctly. Ask what accessibility means in their day-to-day work and how they check it; vague or dismissive answers tell you what you will inherit. This is general information, not legal advice.
How much does a front end web developer cost?
Pay varies widely by experience, specialty, market, and whether the role is remote. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), web developers had a median annual wage of $92,650, about $44.54 an hour, with the lowest 10 percent under $48,100 and the highest 10 percent above $162,290. The closely related web and digital interface designers occupation reported a higher median of $104,000. The spread between the deciles is more than three to one, so the title alone tells you almost nothing about the number. Four factors move a candidate inside the band: years of shipped production work, depth in the exact stack you run, the local market, and whether you post the role as remote, because a remote posting competes against national expectations rather than local ones.
Are these front end developer interview questions legal to ask?
Yes. Questions about a candidate’s technical experience, how they build and test, which browsers they support, how they deploy, and what they shipped are job-related and permitted. The legal caution is general to all interviewing: avoid questions touching protected characteristics such as age, race, religion, national origin, disability, or family status, and note that a growing number of states and cities restrict asking about salary history. Keep every question tied to the work and ask the same core questions of every candidate for the same role. Using one structured set and one scorecard for everyone is itself a safeguard, because it documents that you evaluated candidates on the same job-related criteria. For specifics, consult EEOC guidance or a qualified employment advisor. This is general information, not legal advice.
Should I hire a front end developer as an employee or a contractor?
The decision follows the shape of the work, not your preference or your budget. A defined, project-shaped need with a clear end, such as rebuilding a marketing site, suits a contractor. Continuous work with ongoing direction, set hours, and your tools suits an employee. The classification test is legal rather than optional, and a long-term contractor whose work you direct closely can drift into employee territory over time. Whichever route you take, settle account ownership in writing before the first commit: repository, hosting, domain registrar, and analytics registered to the business, with the developer added as a user. Add a confidentiality agreement and an intellectual property assignment. This is the single most common gap I see at small businesses, and it is far cheaper to fix at the offer stage than after someone leaves.
