HTML interview questions to ask candidates, written for employers: 6 sets on structure, forms, accessibility, and email, plus a scorecard and answer key.
Six question sets for employers assessing a candidate’s HTML skills without a CTO or an HR department: structure, forms, accessible markup, email and CMS work, a planted-problem review exercise with an answer key, and a weighted scorecard. Download as DOCX.
I once hired a contractor who told me he knew HTML, and I believed him because the pages he showed me looked good. They did look good. The contact form he built had no labels on any field, the newsletter he sent rendered as a single wall of grey text for anyone reading in a desktop mail client, and it took us two weeks to notice that quote requests had stopped arriving at all.
None of that was visible in a portfolio. All of it would have been visible in ten minutes if I had known what to ask. At FirstHR, we build for small businesses that hire without an HR department and usually without a technical lead either, so this page is the interviewer’s side of an HTML conversation: six question sets, each question with a stated reason it is worth asking and a note on what a strong answer sounds like.
Nothing here is written for a candidate preparing to answer. It is written for the person deciding what to ask, and it assumes you may not write markup yourself.
TL;DR
Assess HTML in five areas: semantic structure, forms and inputs, accessible markup, email and CMS context, and verification habits. The fastest signal is a short markup review exercise with problems planted in advance, because the answer key makes it scoreable even if you do not write HTML. Match the depth to the role, then score on a weighted rubric.
What HTML Skill Actually Looks Like on the Job
HTML skill shows up as pages that keep working when the content changes, forms that customers can complete, and templates a colleague can publish from without breaking anything. It rarely shows up as knowing what an obscure tag does. That is why an interview built on trivia questions predicts so little about the work.
There is a specific failure mode worth naming, because it is what my contractor had. A page can look completely correct and still be built entirely from generic containers, with no headings, no labels, and no real buttons. Everything renders. Nothing else works: keyboards, screen readers, search engines, and autofill all rely on what the markup says the content is, not on how it looks.
What to test
How to test it
Why it matters at your size
Semantic structure
One example where meaning beat appearance
Pages survive a redesign instead of being rebuilt
Forms and inputs
Build a contact form from the markup up
A form nobody can finish is lost revenue
Accessible markup
Alternative text, keyboard pass, data tables
Decided in the HTML, expensive to retrofit later
Email and CMS context
Where their markup lives and who maintains it
Your markup almost never stands alone
Verification habits
What they do before calling a page done
Nobody else is reviewing their work
The most reliable way to assess all five is a structured interview, where every candidate answers the same core questions scored on the same rubric. That is why this page is built around fixed sets and a scorecard rather than a list to improvise from.
Which Roles Need HTML, and How Deep
HTML is almost never the whole job at a small business. It is a skill inside a job, which means the right question is not whether a candidate knows HTML but how much of it this particular role actually uses. Interviewing a content editor against a front end developer standard wastes your time and loses good candidates.
Decide the depth before you write the questions. A marketing hire whose forms silently drop submissions is a real problem; a content editor who cannot explain ARIA is not. The table below maps the common cases to the sets worth running.
Role
How much HTML the job uses
Sets to run
Front end or web developer
Writes and owns markup daily
1, 2, 3, 4, plus 6
Designer adapting a theme
Edits templates, rarely builds from scratch
1, 2, 5, plus 6
Marketing or email specialist
Landing pages and campaigns
1, 3, 5, plus 6
Content editor or CMS publisher
Publishes, fixes pasted content
1 (light), 5, plus 6
Junior developer or intern
Learning on your existing site
1, 2, 4, plus 6
Support or QA hire
Reads markup to report bugs precisely
2 only
For a role where markup is one part of a broader technical job, the front end developer question set covers the surrounding ground, and the coding interview sets handle logic and debugging. This page stays on the markup itself.
The Six Question Sets
The sets below map to the five areas above, plus a scorecard. Run the core screening set with every candidate, add the review exercise for anyone who will touch a page, then pick the specialist sets that match the depth you decided on.
Core HTML Screening
Every candidate
How much of the markup they wrote by hand, how they decide on structure before styling, and where their HTML meets your CMS or email tool.
Markup Review Exercise
Scoreable without HTML
A 32 line page with eleven problems planted in it, plus the answer key. You already know what is wrong, so you can score any answer.
Forms, Inputs, Validation
Where markup meets revenue
Labels, input types, error messages, spam, and where the data goes after submit. The area where builder-only candidates separate fastest.
Accessible Markup
Decided in the HTML
Alternative text, keyboard operation, data tables, and native elements before ARIA. Habits rather than vocabulary.
HTML Email and CMS
A different discipline
Campaign markup, dark mode, blocked images, pasted word-processor markup, and templates a colleague can publish from safely.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric with suggested weights per role, an evidence line for every area, and a red-flag checklist.
Run the Review Exercise Before the Specialist Questions
Ten minutes on a real page tells you more than thirty minutes of questions, and it changes what is worth asking afterwards. A candidate who finds nine of the eleven planted problems has already answered most of the accessibility set, so spend the remaining time on forms and on your own setup instead. A candidate who finds two has answered the interview. Use an evaluation form to keep the notes in one place.
6 Free Question Sets to Download
Download all six as a single Word document, or copy individual sets. Each follows the same structure: when to use it, the questions with a reason to ask and a note on what a good answer sounds like, what to listen for, and space for notes. Set 2 is a ready-to-run exercise with its own answer key.
Download All 6 HTML Question Sets
Screening, a markup review exercise with an answer key, forms, accessible markup, email and CMS, and a weighted scorecard. All in one DOCX.
Set 1: Core HTML Screening Questions
The opening set for anyone whose job touches markup: which parts they wrote by hand, how they decide on structure before styling, and where their HTML meets your CMS, framework, or email tool.
Core HTML Screening Questions
CORE HTML SCREENING QUESTIONS
Candidate: __
Role: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Use this set with every candidate whose job will touch markup, whether that is
a developer, a designer adapting a theme, a marketing hire building landing
pages, or someone publishing in your CMS. Ask 5 to 7 of these. You are not
grading syntax and you do not need to write HTML yourself. You are finding out
how much of the markup they have actually written, how they decide what the
structure should be, and whether their answers get more specific when you push.
QUESTIONS
1. Show me a page you built and tell me which parts of the markup you wrote by
hand.
(Why ask: it separates writing HTML from arranging blocks in a builder in
the first five minutes, without treating either as wrong. Good answer: opens
something live, points at specific sections, and is plain about what a theme,
a builder, or a teammate produced.)
2. When you get a design, how do you decide what the structure should be before
you style anything?
(Why ask: candidates who start from structure produce pages that survive a
redesign. Good answer: reads the content first, works out the headings and
the sections, then styles. A weak answer starts and ends with appearance.)
3. Give me an example where you picked an element for what it means rather than
for how it looks.
(Why ask: this is the single most useful question on the page, because the
difference between markup that works and markup that only looks right is
almost always here. Good answer: a real example, usually a button, a link, a
heading, or a list, with a reason tied to keyboards or search engines.)
4. Where does your HTML end and someone else's system begin?
(Why ask: at a small business the markup is almost never standalone. It sits
inside a CMS, a framework, an email tool, or a store theme. Good answer:
names the boundary clearly and knows what they can and cannot change.)
5. How do you check a page actually works before you call it done?
(Why ask: verification habits predict how much rework you will pay for. Good
answer: a real routine, a validator or browser tools, a phone, a keyboard
pass, and the page opened as a visitor rather than as the author.)
6. Tell me about markup you inherited that was hard to work with. What was
wrong with it, and what did you do?
(Why ask: most of the job is changing pages someone else built. Good answer:
specific problems and a measured response, not contempt for the last person.)
7. What part of HTML do you look up every time, and where do you look?
(Why ask: nobody holds the whole specification in their head, and the answer
tells you whether they know where the authoritative reference is. Good
answer: names something concrete and a source they trust.)
8. What would you need from us in week one to be useful?
(Why ask: it reveals whether they have thought about your setup at all. Good
answer: asks about the CMS, the hosting, the review process, and who signs
off on published pages.)
WHAT TO LISTEN FOR
•Structure described before appearance
•Honesty about what a builder or a theme produced
•A real verification routine, not "I look at it in Chrome"
•Answers that sharpen under a follow-up rather than repeating
NOTES
__
__
Set 2: Markup Review Exercise, Answer Key, and Debrief
A 32 line page with eleven problems planted in it, the answer key, a scoring band, and four debrief questions. Because you already know what is wrong, you can score any answer without reading markup yourself.
Markup Review Exercise, Answer Key, and Debrief Questions
HTML MARKUP REVIEW EXERCISE
Candidate: __
Role: __
Interviewer: __
HOW TO RUN THIS EXERCISE
This is the exercise that lets a non-technical interviewer score HTML skill,
because the problems are planted in advance and the answer key is below. Share
the snippet on screen or send it ten minutes before the call. Say only this:
"This is a real page on a small business site. Tell me what you would change
and why." Then stop talking and take notes. Do not hint.
Give it 10 to 12 minutes. Score by how many of the eleven planted problems the
candidate finds, and by whether they explain the consequence of each one in
Where markup turns into revenue: labels, input types, validation and error messages, spam handling, and confirming that submissions actually arrive. The set that separates builder-only candidates fastest.
Forms, Inputs, and Validation Questions
HTML FORMS, INPUTS, AND VALIDATION QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHEN TO USE THIS SET
Use this set whenever the role will touch a form, which at a small business
means almost always: a contact form, a quote request, a booking, an application,
a newsletter signup. Forms are where markup quality turns directly into revenue,
because a form that is hard to complete is a customer who leaves. This is also
the area where builder-only candidates and real HTML candidates separate most
clearly.
QUESTIONS
1. Walk me through building a contact form, starting from the markup rather
than the styling.
(Why ask: it is the most common thing you will ever ask this person to
build. Good answer: fields chosen from what the business needs, every field
labeled, a real submit button, and a plan for what happens after submission.)
2. What actually goes wrong when a field has a placeholder but no label?
(Why ask: it is the most common defect in small business forms and a clean
test of whether accessibility is understood or recited. Good answer: the
hint vanishes once typing starts, assistive technology has nothing to
announce, and error messages have nothing to point at.)
3. Which input types do you use beyond plain text, and what do they buy you?
(Why ask: it is a small detail with an outsized effect on mobile completion
rates. Good answer: names email, telephone, number, and date, and explains
that the phone keyboard changes and the browser can autofill.)
4. How do you handle validation, and what does a good error message look like?
(Why ask: validation is where a form either helps someone or blames them.
Good answer: uses what the browser provides first, adds checks on the server
because anything in the browser can be bypassed, and writes messages that
say what to do rather than "invalid input".)
5. How do you keep a longer form from feeling like a tax return?
(Why ask: field count is the single biggest factor in completion. Good
answer: challenges which fields you actually need, groups what remains, and
is willing to argue with the request rather than build whatever was asked.)
6. What do you do about spam without making the form hostile to real people?
(Why ask: every small business form gets spam, and the usual fix punishes
customers. Good answer: mentions quiet approaches before it mentions a
puzzle that visitors have to solve.)
7. Where does the data go after someone clicks submit, and how do you confirm
it arrived?
(Why ask: forms that silently fail are the most expensive bug on a small
business site, because nobody reports them. Good answer: names the
destination, a confirmation to the visitor, and a test they run afterward.)
8. If we collect anything sensitive on a form, what changes about how you build
it?
(Why ask: an applicant form or a health intake form is not a newsletter
signup. Good answer: raises who can see the submissions and where they are
stored before it discusses markup.)
WHAT TO LISTEN FOR
•Labels described as structure, not as decoration
•Willingness to remove fields the business asked for
•Validation on the server as well as in the browser
•A test that confirms submissions actually arrive
NOTES
__
__
Set 4: Accessible Markup Questions
Alternative text and when to leave it empty, keyboard operation, data tables, reading order, and why a native element beats an attribute bolted on afterwards. Habits rather than vocabulary.
Accessible Markup Questions
ACCESSIBLE MARKUP QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHEN TO USE THIS SET
Use this set for any role that publishes to a page customers can reach. Most of
what makes a page usable with assistive technology is decided in the markup, not
in the design, which is why these questions belong in an HTML interview rather
than only in a design one. Listen for habits rather than vocabulary. Anyone can
say "accessibility matters." You are checking whether it shows up in how they
build, and whether they know what tools cannot catch.
QUESTIONS
1. Describe what a screen reader does with a page you have built.
(Why ask: it is impossible to fake with vocabulary. Good answer: describes
the reading order, the headings as a way to navigate, the landmarks, and
what happens at an unlabeled control.)
2. How do you write alternative text, and when do you deliberately leave it
empty?
(Why ask: knowing when to leave it empty is the tell of someone who has
really done this. Good answer: describes the purpose of the image, and
leaves it empty for purely decorative images so it is skipped rather than
read out as noise.)
3. When would you reach for an ARIA attribute, and when would you use a plain
HTML element instead?
(Why ask: misapplied ARIA is worse than none, and this question finds people
who sprinkle it as a fix. Good answer: prefers the native element every
time, and reserves ARIA for genuinely custom widgets.)
4. Show me how you would check this page with the keyboard only.
(Why ask: it is a live demonstration you can watch even without technical
knowledge. Good answer: tabs through in order, watches for a visible focus
outline, and notices anything that traps focus or is unreachable.)
5. How do you mark up a table of data so it still makes sense read aloud?
(Why ask: pricing tables and schedules are common on small business sites
and are frequently unreadable. Good answer: real header cells, a caption,
and a clear relationship between headers and data.)
6. A design has a visual order that does not match the reading order. What do
you do?
(Why ask: it tests whether they will raise the problem or silently build
something confusing. Good answer: goes back to the designer, because
reordering visually while leaving the source order wrong breaks keyboard use.)
7. Which accessibility problems can an automated checker find, and which can it
not?
(Why ask: it separates someone who runs a tool from someone who understands
the work. Good answer: tools catch missing alternative text, contrast, and
missing labels, and cannot judge whether alternative text is meaningful,
whether the reading order is sensible, or whether a custom control works.)
8. Tell me about a time you changed something for accessibility reasons and
someone pushed back.
(Why ask: real experience produces a real story. Good answer: handled as a
conversation about the customer, not as a citation of a rule.)
WHAT TO LISTEN FOR
•Native elements preferred over attributes bolted on afterwards
•Alternative text described by purpose, not by picture description
•Awareness of what automated checkers miss
•Accessibility treated as part of building, not as a final audit
NOTES
__
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
The set most interview kits skip entirely: campaign markup, dark mode and blocked images, pasted word-processor markup breaking a page, and templates a non-technical colleague can publish from safely.
HTML Email, CMS, and Template Questions
HTML EMAIL, CMS, AND TEMPLATE QUESTIONS
Candidate: __
Role: __
Interviewer: __
WHEN TO USE THIS SET
Use this set when the role touches campaigns, newsletters, transactional
messages, or a content management system, which covers most marketing and
content hires. HTML email is a genuinely different discipline from web HTML,
and a candidate who is strong on one may be weak on the other. Ask directly
rather than assuming the skills transfer.
HTML EMAIL QUESTIONS
1. How is building an HTML email different from building a web page?
(Why ask: the honest answer is "almost everything," and a candidate who
thinks they are the same has not shipped a campaign. Good answer: mentions
the older rendering rules, tables for layout, styles written inline, and
the limited support for anything modern.)
2. Which email clients do you test in, and what have you had to work around?
(Why ask: a specific war story is proof of real work. Good answer: names
clients, describes a concrete workaround, and asks what our own audience
opens messages in rather than guessing.)
3. How do you handle dark mode and blocked images?
(Why ask: both are now normal for a large share of recipients and both
silently ruin a campaign. Good answer: designs so the message still reads
with images off, and does not rely on a background color surviving.)
4. What do you do about the plain text version and the preview text?
(Why ask: two details that affect deliverability and open rates and that
builder-only candidates never mention. Good answer: writes both
deliberately rather than letting a tool generate them.)
5. How do you keep a campaign template reusable instead of rebuilding it every
time?
(Why ask: a small marketing team cannot afford a fresh build per send. Good
answer: a modular template with content slots and a documented way to change
copy without touching markup.)
CMS AND TEMPLATE QUESTIONS
6. Someone pastes text from a word processor into the CMS and the page breaks.
What is happening, and how do you stop it happening again?
(Why ask: this is the single most common markup problem in a small business
CMS. Good answer: explains the hidden markup that comes along with the
paste, and offers both a cleanup habit and a configuration fix.)
7. How would you set our templates up so a non-technical colleague can publish
without touching markup?
(Why ask: this is what you are actually buying, and it is the difference
between a hire who scales and one who becomes a bottleneck. Good answer:
constrained editing areas, sensible defaults, and short written instructions.)
8. Where do the page title, description, and social preview tags live in our
setup, and who owns them?
(Why ask: these live in the markup, get forgotten, and quietly affect search
and sharing. Good answer: knows where they sit, and asks who reviews them
before a page goes live.)
9. What happens to a template when a page has three times more content than the
design assumed?
(Why ask: real content always breaks an idealized design. Good answer: tests
with real content, and has an opinion about long headings and empty fields.)
WHAT TO LISTEN FOR
•Email described as its own discipline with its own constraints
•Named clients and concrete workarounds, not general complaints
•Templates designed so colleagues can publish safely
•Curiosity about your CMS and your audience before proposing anything
NOTES
__
__
Set 6: HTML Skill Scorecard and Red Flags
A weighted 1-to-5 rubric with suggested weights for each of the common roles, an evidence line per area, a slot for the review exercise result, and a red-flag checklist.
HTML Skill Scorecard and Red Flags
HTML SKILL SCORECARD
Candidate: __
Role: __
Interviewer: __
Date: _
HOW TO USE THIS SCORECARD
Set the weights before you meet anyone, because weights decided afterwards
become a justification for whoever felt most impressive. Score 1 to 5 in each
area with a line of evidence from the interview. If more than one person
interviews, everyone scores independently before the group discusses anything.
Suggested weights by role:
•Developer who owns the site Structure and forms weighted heaviest
•Designer adapting templates Structure and email or CMS weighted heaviest
•Marketing or email hire Email or CMS and forms weighted heaviest
•Content editor or publisher Email or CMS heaviest, structure light
•Junior or intern Verification habits and plain language
Can explain a technical choice to someone who does not write markup
Evidence: ____
Markup review exercise Problems found: ____ of 11
Evidence: ____
RED FLAGS
[ ] Cannot say which parts of a portfolio page they personally built
[ ] Treats every structural question as a styling question
[ ] Calls accessibility a legal box to tick rather than part of building
[ ] Reaches for attributes to patch a control instead of using the right element
[ ] Says placeholders replace labels
[ ] No verification routine beyond looking at it in one browser
[ ] Blames every previous client, agency, or codebase
[ ] Found two or fewer problems in the markup review exercise
[ ] Cannot explain a choice without the vocabulary
DECISION
Weighted total: ______
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Strengths: ____
Concerns: _____
Interviewer signature: ______
How to Score Answers If You Do Not Write Markup
You do not need to read HTML to run a good HTML interview. You need a written standard to compare answers against, and one exercise where you already know the right answer. The pattern is consistent: strong answers name a consequence for a person, and get more specific when you push.
Give me an example where you picked an element for what it means rather than for how it looks.
Strong answer: A specific example with a consequence attached: chose a real button so it works with a keyboard, or a real heading so the outline makes sense. The reason names a person who benefits, not a rule that was followed.
Weak answer: Restates the question as a principle, talks only about styling and class names, or explains that a container with the right styles looks identical anyway.
This is a real page from a small business site. Tell me what you would change and why.
Strong answer: Finds most of the planted problems, starts with the ones that cost you customers, and explains each in terms of what breaks for a visitor. Says plainly when something is a preference rather than a defect.
Weak answer: Says it looks fine and needs styling, lists only cosmetic issues, or reels off rule names without saying what actually goes wrong for anyone.
Where does the data go after someone clicks submit, and how do you confirm it arrived?
Strong answer: Names the destination, a confirmation for the visitor, and a test they run after every change. Treats a silently failing form as a serious bug because nobody ever reports it.
Weak answer: Assumes the form tool handles it, has never tested a live submission, or has no answer for what happens when the notification email stops arriving.
The mechanical trick that does most of the work is planting the problems yourself. A page you cannot read becomes a page you can grade the moment you hold the answer key, and the eleven defects in the downloadable exercise are all ones a competent candidate should spot inside ten minutes.
Signals of real markup work
Says which parts a theme or builder produced
Describes structure before appearance
Has an opinion about a page they inherited
Signals of good habits
A verification routine beyond one browser
Tests a live form submission after changes
Knows what an automated checker misses
Signals of a good colleague
Explains a choice without the vocabulary
Pushes back on a form field you do not need
Asks who publishes pages after they leave
Red flags
Every structural question answered as styling
Placeholders described as labels
Two or fewer problems found in the exercise
Ask the same follow-up every time, some version of what breaks for a customer because of that. A candidate with real experience answers immediately with a person and a situation. A candidate who has memorized rules restates the rule in different words, and you will hear the difference without knowing any HTML at all.
Assessing HTML Email and CMS Work
HTML email is a different discipline from web HTML, and a candidate strong in one may be genuinely weak in the other. Mail clients render with far older rules than browsers, which is why campaign markup still uses tables for layout and styles written inline, and why a modern web developer can produce a newsletter that falls apart.
The same gap exists around content management systems. Someone can build a beautiful page and still hand you a template that a colleague breaks on the first edit, which at a small business is the difference between a hire who scales and one who becomes a bottleneck for every publish.
Where it breaks
What to ask
What a good answer sounds like
Older mail clients
Which clients do you test in?
Names clients and a concrete workaround
Dark mode
How do you handle dark mode?
Does not rely on a background color surviving
Blocked images
What if images never load?
The message still reads with images off
Pasted word-processor text
Why does the page break?
Explains the hidden markup, offers a fix
Template handover
Can a colleague publish safely?
Constrained fields plus written instructions
Page title and description
Where do those live?
Knows the markup and who reviews it
If the role is mostly campaigns, weight this set heaviest and treat deep structural knowledge as a bonus. The email marketing job description is a useful place to write down how much markup the role really owns before you interview anyone.
Accessible Markup Is a Business Question
Most of what makes a page usable with assistive technology is decided in the markup rather than in the design: whether a heading is a real heading, whether a form field has a label, whether a button is a button. That is why these questions belong in an HTML interview and not only in a design one.
It is also a question with commercial consequences. The Department of Justice has published guidance on web accessibility under the ADA taking the position that the obligations of a business open to the public extend to what it offers online, which makes alternative text, heading order, and labeled fields legitimate things to ask about for anyone who publishes to your site.
The Question That Separates Habit From Vocabulary
Ask when a candidate deliberately leaves alternative text empty. Anyone can say that images need alternative text; knowing that a purely decorative image should be marked so assistive technology skips it, rather than described as noise in the middle of a sentence, is the answer of someone who has actually done the work. The same trick works on ARIA: a strong candidate says they reach for the plain HTML element first and reserve attributes for genuinely custom widgets.
Frame every one of these questions around the page rather than around the person. How do you build for assistive technology is a question about the work. Anything that drifts toward whether a candidate personally uses assistive technology is a question about a protected characteristic, which is covered in the next section.
Scoring an HTML Interview
Score every candidate on the same rubric immediately after the interview, and set the weights before you meet anyone. Weights decided afterwards are how a hiring decision quietly becomes a justification for whoever felt most impressive in the room.
Scoring area
What a 5 looks like
Weight it heavily when
Semantic structure
Chose elements by meaning, with reasons
The role builds pages you will keep for years
Forms and inputs
Labels, types, and a test that submissions arrive
The site collects leads, bookings, or applications
Accessible markup
Habits described, knows what tools miss
Customers reach the page directly
Email and CMS context
Knows where markup lives and who maintains it
The hire is marketing, content, or campaigns
Verification habits
A real routine on a phone and a keyboard
Nobody else reviews their work
Plain language explanation
Explains a choice without the vocabulary
You are the only person judging the output
If more than one person interviews, each should score independently before the group talks, so the most senior voice does not anchor everyone. A short feedback round comparing written evidence beats a discussion of impressions.
What it does
HTML trivia quiz
Markup review exercise
Resembles the work you are paying for
Scoreable if you do not write HTML
Rewards memorized specification details
Shows how they treat accessibility
Produces evidence you can compare
Fair, Legal, and Structured Interviewing
A good interview is fair, legal, and structured together or not at all. Asking the same job-related questions of every candidate keeps you compliant, reduces bias, and produces better hires at the same time. The EEOC list of prohibited practices is worth reading before you finalize your questions.
A markup exercise is a selection procedure
The moment a markup review, a take-home page build, or an HTML quiz decides who advances, federal employment law treats it as a selection procedure rather than as a friendly chat. In practice 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. The review exercise in this kit is easy to run this way: the same snippet, the same instruction, the same time, the same answer key, every candidate. Keep the completed exercises with your other hiring records, and if a task screens out a protected group at a noticeably lower rate, look at it before it becomes a legal problem. This is general information, not legal advice.
Ask about the markup, not the person
Federal anti-discrimination law prohibits basing hiring decisions on protected characteristics, and casual questions probe them just as effectively as deliberate ones. Technical interviews have specific traps worth naming. Asking when someone first built a website or which browser era they started in is an age proxy. Commenting on an accent during a screen share invites a question about national origin. A timed exercise can surface a disability the candidate never intended to discuss, and an accommodation request for it is an accommodation request, not a signal about ability. Keep every question tied to the work the role does. This is general information, not legal advice.
Set the weights before you interview
Decide which scoring areas matter most for this specific role and write the weights down before you meet anyone. A developer who will own the site needs structure and forms weighted heaviest. A marketing hire building campaigns needs email and template context weighted heaviest, and may reasonably score low on structure without that being disqualifying. A content editor publishing in your CMS needs almost none of the deep markup skill and a great deal of care with pasted content. Weighting after the fact is how a hiring decision becomes a rationalization, which is exactly the failure structure prevents.
Accessibility questions are job-related, and they matter
Asking how a candidate handles alternative text, keyboard operation, and labeled form fields is a question about the work product, not about any person in the room. The Department of Justice has taken the position that the accessibility obligations of a business open to the public extend to what it offers online, which makes these legitimate interview topics for anyone who publishes to your site. Keep the framing on the page rather than on the candidate: how do you build for assistive technology, not have you ever needed assistive technology. This is general information, not legal advice.
A Markup Exercise Is a Selection Procedure, Not a Chat
Any exercise you use to decide who advances is treated as an employment selection procedure under federal law, which means it should be job-related, consistent with business necessity, and administered on the same terms to every candidate for the role (EEOC guidance on employment tests). The review exercise in this kit is easy to run that way: same snippet, same instruction, same time limit, same answer key. Keep the completed exercises with your other hiring records. This is general information, not legal advice.
At a large company a candidate’s markup is reviewed by an engineering manager who writes it themselves, with a recruiter coordinating scorecards. At a small business the owner runs the whole thing alone, usually without writing markup, and often for a role where HTML is only part of the job.
You need to judge HTML skill and you do not write HTML
This is the normal situation at a small business, and it is why so many owners fall back on a portfolio that looks nice, which tells you nothing about the markup underneath. The way out is to test what you can score. Plant the problems yourself and you no longer need to know the answers: the review exercise in this kit comes with an answer key, so a page you cannot read becomes a page you can grade. Every question in the other sets carries a note on what a strong answer sounds like, so you are comparing each candidate against a written standard rather than against your own uncertainty.
HTML is rarely the whole job, so calibrate to how much you need
Very few small business roles are pure markup roles. It is a skill inside a job: a marketing hire who also builds landing pages, a designer who adapts a theme, an office manager who edits the CMS, a junior developer learning on your site. Interviewing all of them against a full front end standard wastes your time and loses good candidates. Decide first how deep the role goes, then run only the sets that match, and weight the scorecard accordingly. A content editor who cannot explain ARIA is not a failed hire; a marketing hire whose forms silently drop submissions is.
The interview is the easy part; access and handover are where it gets real
Once you choose someone, the work shifts from evaluating to hiring well: a written offer, the new hire paperwork, and access to the site, the CMS, the domain registrar, and the email platform, provisioned to what the role needs and removable when they leave. Contractors need the same discipline as employees here, plus a written agreement about who owns the markup they produce. FirstHR fits this people side for a small business: send the offer for e-signature, run the paperwork and the access checklist as an onboarding workflow, and keep the signed documents and the interview scorecards on the employee profile. FirstHR is an onboarding and HR platform, not a hosting provider or a code testing tool, so pair it with those.
If you are still deciding what the role is, write the posting first, because a clear web developer job description forces the scope decisions your questions then test. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
The interview is step one. Once you choose someone, onboarding a person who publishes to your site has specific steps: a signed offer, the standard new hire paperwork, access to the CMS and the domain registrar granted deliberately, and a first small page chosen in advance so they ship something in week one.
Offer and ownership in writing
A written offer, and for a contractor a clear statement that the markup, templates, and campaign files they produce belong to your business.
Access provisioned deliberately
CMS, hosting, domain registrar, email platform, and analytics granted to what the role needs, with no shared logins and a written removal step.
Keep the hiring record together
The scorecards, the completed review exercise, the signed offer, and the standard new hire forms stored in one place and easy to find later.
Ship one small page in week one
Name a first task, the person to ask, and what good looks like at thirty and ninety days, so a new hire builds momentum instead of reading documentation.
FirstHR connects the offer, the offer letter, e-signatures, the paperwork, and the access checklist in one place, and keeps the scorecards and signed documents on the employee profile. FirstHR is an onboarding and HR platform, not a hosting provider or a technical assessment tool, so connect those separately. Applicant tracking is coming soon to FirstHR.
For a broader technical hire the technical interview question sets cover IT and systems ground, and the rest of the hiring template library has the postings, forms, and checklists around them. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Assess HTML in five areas: semantic structure, forms and inputs, accessible markup, email and CMS context, and verification habits.
Plant the problems yourself so a page you cannot read becomes a page you can grade against an answer key.
Decide how deep the role goes before you interview, and run only the question sets that match it.
Forms are where markup turns into revenue, so test labels, input types, and whether submissions actually arrive.
Ask when a candidate deliberately leaves alternative text empty, because it separates habit from vocabulary.
Any exercise that decides who advances is a selection procedure, so keep it job-related and identical for every candidate.
Frequently Asked Questions
What HTML questions should I ask candidates?
Ask questions in five areas rather than trivia about tag names. First, screening: which parts of a page they wrote by hand, and how they decide on structure before styling. Second, semantic structure: an example where they picked an element for meaning rather than appearance. Third, forms: how they build a contact form, what goes wrong when a field has a placeholder and no label, and where the data goes after submit. Fourth, accessible markup: how they write alternative text, when they leave it empty, and how they check a page with a keyboard. Fifth, context: whether their markup will live in a CMS, an email tool, or a store theme, and who maintains it afterwards. Add a short markup review exercise, because watching someone react to a real page tells you more than any single question.
How do I test HTML skills if I do not write markup myself?
Plant the problems in advance so you already know the answers. Take a short page, roughly thirty lines, and deliberately include specific defects: an image with no alternative text, navigation built from clickable containers, two top-level headings, a form field with a placeholder and no label, a submit control that is not a real button. Then ask the candidate what they would change and why, and score by how many they find and whether they explain the consequence for a visitor. The downloadable exercise in this kit comes with a snippet and an answer key, so it works without any markup knowledge of your own. Beyond the exercise, ask for plain-language explanations and watch whether answers get more specific under follow-up or vaguer, which is a reliable signal in either direction.
Should I give an HTML test or a take-home task?
For most small business hires a short review exercise inside the interview beats a take-home build. A review exercise takes ten minutes, needs no unpaid work from the candidate, and produces evidence you can score against an answer key. A take-home build is worth it only when the role really is a building role and you need to see finished work, in which case cap it at two to four hours, pay for anything over an hour, publish the criteria in advance, and say that unfinished is acceptable if they explain what they would do next. Whichever you use, apply it identically to every candidate for the role, because any exercise that decides who advances is treated as an employment selection procedure under federal law rather than as an informal chat. This is general information, not legal advice.
How much HTML does a marketing or content hire really need?
Less than a developer, but more than none, and the gap is usually in a specific place. A marketing hire who builds landing pages and campaigns needs to handle forms competently, understand that HTML email follows older rendering rules than the web, and know why a heading has to be a real heading for search engines. A content editor publishing in a CMS mainly needs to avoid breaking pages, which in practice means understanding what happens when text is pasted from a word processor and knowing where the page title and description live. Neither needs to explain ARIA. Decide the depth before the interview, run only the sets that match, and weight the scorecard so a candidate is not failed for lacking a skill the role never uses.
Does it matter if a candidate uses a website builder or AI tools?
It matters less than what they can explain and verify. Most page building now involves a builder, a theme, or an assistant producing a first draft, so a policy of banning them mostly selects for people willing to hide it. The useful question is supervision: which parts of this page did you write, what did the tool get wrong, how did you catch it, what did you change. A candidate who can walk through a page they generated and explain every structural choice has done the work whatever produced the first draft. A candidate who cannot explain their own page has told you something important. Decide your policy before you interview anyone, write it into the brief, and apply it identically to every candidate for the role.
What are the red flags in an HTML interview?
The clearest one is answering every structural question as a styling question, because it means the candidate treats markup as a way to position things rather than as a description of what the content is. Others worth watching for: describing placeholders as a replacement for labels, reaching for attributes to patch a control instead of using the right element, calling accessibility a legal box to tick, having no verification routine beyond looking at a page in one browser, and being unable to say which parts of a portfolio page they personally built. In the review exercise, finding two or fewer of the planted problems is a strong signal on its own. None of these are about vocabulary. A candidate can lack the terminology and still build well, and the reverse is also common.
How long should an HTML interview take?
Plan 45 to 60 minutes: roughly ten minutes of screening questions, ten to twelve minutes on the markup review exercise, fifteen minutes on whichever specialist set fits the role, and the rest for the candidate’s own questions, which reveal how they think about your setup. That is enough for depth on a few strong questions, which beats a long checklist every time. If the role is senior or the site is central to your revenue, add a second conversation rather than extending the first one, and score immediately after each stage while the answers are fresh. Use the same structure for every candidate so the comparison is fair, and have each interviewer score independently before the group talks.
