Interviewers assess HTML proficiency by looking for a candidate's understanding of semantic structure, accessibility best practices, and how HTML integrates with CSS and JavaScript to build robust, maintainable, and user-friendly web experiences. They want to see that you can choose the right element for the job, not just any element.
16 questions (5 easy · 6 medium · 5 hard), each with what a strong answer covers and where people lose the point. Free to read, no account.
2.Explain the difference between the `<head>` and `<body>` sections of an HTML document.
Warm-up
What a strong answer covers
The `<head>` section contains metadata about the HTML document, which is not directly displayed on the web page.
Metadata includes the page title (`<title>`), links to stylesheets (`<link>`), script references (`<script>`), character set (`<meta charset>`), and viewport settings (`<meta name="viewport">`).
The `<body>` section contains all the visible content of the web page that users interact with, such as text, images, links, forms, and multimedia.
Content within `<body>` is rendered by the browser and forms the main user interface.
Where people lose the point
×Placing visible content like `<h1>` or `<img>` inside the `<head>`.
×Confusing metadata with actual page content.
×Not understanding that scripts and styles can be in both, but their primary purpose differs.
4.What is the difference between block-level and inline-level elements? Give examples.
Warm-up
What a strong answer covers
Block-level elements always start on a new line and take up the full available width, stacking vertically. Examples: `<div>`, `<p>`, `<h1>`, `<ul>`.
Inline-level elements do not start on a new line and only take up as much width as necessary for their content, flowing horizontally within a line. Examples: `<span>`, `<a>`, `<strong>`, `<img>`.
Block-level elements can contain other block-level and inline-level elements. Inline-level elements can generally only contain other inline-level elements or text.
CSS `display` property can change an element's default block/inline behavior.
Where people lose the point
×Incorrectly stating that inline elements can contain block elements.
×Confusing the visual appearance (e.g., `display: block` applied to an `<a>`) with the element's default semantic category.
×Providing examples that are not truly block or inline by default.
5.Why should you always use a `<label>` element with form inputs?
Warm-up
What a strong answer covers
Improves accessibility: Screen readers announce the label when the input field is focused, providing context for visually impaired users.
Enhances usability: Clicking on the label text will focus its associated input field, making it easier for users (especially on touch devices or for small input fields) to interact with forms.
Provides a larger clickable area for the input, improving user experience.
Semantically links the label to its input using the `for` attribute matching the input's `id`.
Where people lose the point
×Using `placeholder` text as a substitute for a `<label>`.
×Not linking the `<label>` to the input using `for` and `id` attributes.
×Only mentioning visual benefits and ignoring accessibility implications.
6.Describe the benefits of using semantic HTML5 elements (e.g., `<article>`, `<section>`, `<aside>`) over generic `<div>` elements.
Core
What a strong answer covers
**Accessibility:** Semantic elements provide a clear, logical structure for assistive technologies (like screen readers) to interpret and navigate content, improving the experience for users with disabilities.
**SEO (Search Engine Optimization):** Search engines can better understand the content and context of a page when semantic elements are used, potentially leading to improved rankings.
**Readability and Maintainability:** Code becomes more readable and easier for developers to understand and maintain, as the element names clearly indicate their purpose.
**Developer Collaboration:** Facilitates collaboration among developers by establishing a common, meaningful vocabulary for document structure.
**Future-proofing:** Provides a more robust and adaptable structure that can be more easily styled and manipulated by CSS and JavaScript without relying solely on class names.
Where people lose the point
×Only mentioning readability without explaining the deeper benefits for accessibility or SEO.
×Stating that semantic elements have inherent visual styling that `div`s don't (they don't, by default).
×Confusing semantic elements with styling frameworks or components.
7.When would you use ARIA attributes, and provide an example of a common ARIA role or property?
Core
What a strong answer covers
ARIA (Accessible Rich Internet Applications) attributes are used to enhance the accessibility of dynamic web content and user interface components that cannot be made accessible with native HTML alone.
They provide semantic meaning and behavioral information to assistive technologies (like screen readers) for elements that lack inherent semantics (e.g., a `div` used as a custom button or tab).
ARIA should be used sparingly and only when native HTML elements or attributes are insufficient (the 'first rule of ARIA' is to use native HTML whenever possible).
Example: `role="button"` on a `<div>` to indicate it functions as a button, or `aria-expanded="true"` on a toggle element to indicate its current state.
Where people lose the point
×Using ARIA attributes on native HTML elements that already have the desired semantic meaning (e.g., `role="button"` on a `<button>` element).
×Over-relying on ARIA instead of choosing appropriate semantic HTML elements first.
×Providing an example that doesn't clearly demonstrate ARIA's purpose (e.g., a simple `aria-label` on an `<img>` when `alt` is sufficient).
8.Explain the difference between `<input type="radio">` and `<input type="checkbox">`. When would you use each?
Core
What a strong answer covers
**Radio Buttons (`<input type="radio">`):** Used when the user must select *only one* option from a predefined set of mutually exclusive choices. All radio buttons in a group must share the same `name` attribute to ensure only one can be selected.
**Checkboxes (`<input type="checkbox">`):** Used when the user can select *zero, one, or multiple* options from a list. Each checkbox typically has a unique `name` attribute (or the same `name` with `[]` for multiple values in server-side processing).
**Use Cases:** Radio buttons are suitable for 'yes/no' questions, gender selection, or choosing a single shipping method. Checkboxes are suitable for 'opt-in' features, selecting multiple interests, or agreeing to terms and conditions.
Both types can be pre-selected using the `checked` attribute.
Where people lose the point
×Confusing the behavior of radio buttons and checkboxes, especially regarding single vs. multiple selection.
×Not mentioning the importance of the `name` attribute for grouping radio buttons.
×Suggesting inappropriate use cases for either type.
9.How do `<picture>` and `srcset` attributes contribute to responsive images?
Core
What a strong answer covers
**`srcset` attribute (on `<img>`):** Allows the browser to choose the most appropriate image source from a list based on device pixel ratio (e.g., `1x`, `2x`) or viewport width (e.g., `400w`, `800w`). It's typically used with the `sizes` attribute to inform the browser about the image's rendered size.
**`<picture>` element:** Provides more granular control than `srcset` alone. It acts as a container for multiple `<source>` elements and a fallback `<img>`.
**`<source>` element (within `<picture>`):** Allows developers to specify different image files based on media queries (e.g., `media="(min-width: 800px)"`) or image formats (e.g., `type="image/webp"`). This enables art direction (serving entirely different images for different layouts) or format optimization.
**Benefits:** Together, they ensure users download only the necessary image assets, improving page load performance, reducing data usage, and providing a better visual experience tailored to the user's device and network conditions.
Where people lose the point
×Confusing `srcset` with `<picture>` and not explaining their distinct use cases.
×Not mentioning the `sizes` attribute when discussing `srcset` for width descriptors.
×Failing to explain the 'art direction' capability of `<picture>`.
11.Explain the difference between `GET` and `POST` methods in an HTML form.
Core
What a strong answer covers
**`GET` Method:** Appends form data to the URL as query parameters. Data is visible in the URL, browser history, and can be bookmarked. It has limitations on the amount of data that can be sent. Primarily used for retrieving data (e.g., search queries).
**`POST` Method:** Sends form data in the body of the HTTP request. Data is not visible in the URL, not stored in browser history, and cannot be bookmarked. It has no practical limits on data size. Primarily used for submitting data that changes the server state (e.g., creating a new resource, submitting sensitive information).
**Security/Idempotence:** `GET` requests are generally considered idempotent (making the same request multiple times has the same effect as making it once) and less secure for sensitive data. `POST` requests are not idempotent and are more suitable for sensitive or large data submissions.
**When to Use:** Use `GET` for non-sensitive data retrieval (e.g., search, filtering). Use `POST` for submitting sensitive data (e.g., passwords), large amounts of data, or data that modifies the server (e.g., creating an account, placing an order).
Where people lose the point
×Incorrectly stating that `POST` is inherently 'secure' (it hides data from the URL, but doesn't encrypt it by default).
×Confusing the data visibility in the URL with actual encryption.
×Not mentioning the idempotence characteristic of `GET` requests.
12.How do custom elements (Web Components) extend HTML, and what are their primary use cases?
Hard
What a strong answer covers
Custom elements allow developers to define new HTML tags with their own custom behavior, markup structure, and styling, extending the native HTML vocabulary.
They are part of the Web Components standard, which also includes Shadow DOM, HTML templates, and ES Modules, enabling encapsulated and reusable components.
Custom elements are defined using JavaScript classes that extend `HTMLElement` and are registered with `customElements.define('my-element', MyElementClass)`. They can have lifecycle callbacks (e.g., `connectedCallback`, `attributeChangedCallback`).
Primary use cases include creating reusable UI widgets (e.g., a custom tab component, a date picker), encapsulating complex functionality, and building design systems with consistent, portable components that work across different frameworks or no framework at all.
Where people lose the point
×Confusing custom elements with JavaScript frameworks like React or Vue components.
×Not mentioning the `customElements.define()` method or the `HTMLElement` extension.
×Failing to highlight the encapsulation and reusability aspects as key benefits.
13.Briefly explain the concept of Shadow DOM and its relevance to HTML and Web Components.
Hard
What a strong answer covers
Shadow DOM is a web standard that allows for the encapsulation of a component's internal DOM structure and styles, separating them from the main document's DOM.
It creates a 'shadow tree' that is attached to a 'shadow host' element in the regular DOM. Content within the shadow tree is rendered but is isolated from the main document's CSS and JavaScript.
This encapsulation prevents styles from 'leaking' in or out of the component, ensuring that a component's internal styling doesn't affect the rest of the page, and vice-versa.
Shadow DOM is a fundamental part of Web Components, providing the necessary isolation for custom elements to be truly reusable and maintainable without fear of global style conflicts.
Where people lose the point
×Confusing Shadow DOM with a regular `<iframe>` or simply a nested `<div>`.
×Not emphasizing the encapsulation of both DOM and CSS as its primary feature.
×Failing to link it directly to the benefits of building robust, isolated Web Components.
14.Beyond `alt` text and labels, what are some other critical HTML accessibility best practices you would implement?
Hard
What a strong answer covers
**Semantic HTML Structure:** Use appropriate semantic elements (`<header>`, `<nav>`, `<main>`, `<article>`, `<footer>`, etc.) to provide a clear, logical document outline for screen readers and other assistive technologies.
**Keyboard Navigation:** Ensure all interactive elements (links, buttons, form controls) are reachable and operable using only the keyboard (e.g., via `Tab` key). Manage `tabindex` carefully if default order is insufficient.
**Language Declaration:** Always include the `lang` attribute on the `<html>` tag (e.g., `<html lang="en">`) to inform screen readers of the document's primary language for correct pronunciation.
**ARIA Roles and Attributes (Judiciously):** Use ARIA to add semantic meaning to custom widgets or dynamic content where native HTML is insufficient (e.g., `role="alert"`, `aria-live`, `aria-controls`, `aria-expanded`). Follow the 'first rule of ARIA': use native HTML if it exists.
**Focus Management:** Ensure that focus is visibly indicated (e.g., with CSS outlines) and that it moves logically, especially after dynamic content updates or modal dialogs open/close.
Where people lose the point
×Listing only CSS or JavaScript accessibility techniques without focusing on HTML.
×Suggesting overuse of ARIA attributes when native HTML would suffice.
×Not mentioning keyboard navigation or focus management, which are critical for many users.
15.What are the security considerations when using an `<iframe>` element, and how can they be mitigated?
Hard
What a strong answer covers
**Clickjacking:** Malicious sites can embed your page in an `<iframe>` and overlay transparent elements to trick users into clicking on your content. Mitigation: Use `X-Frame-Options` HTTP header (`DENY`, `SAMEORIGIN`) or `Content-Security-Policy: frame-ancestors`.
**Malicious Content:** Embedding content from untrusted sources can expose users to malware, phishing, or cross-site scripting (XSS) attacks if the embedded content is compromised. Mitigation: Only embed trusted content; use the `sandbox` attribute.
**Information Leakage:** The embedded page might access information about the parent page (e.g., URL, cookies) or vice-versa, potentially leading to data exposure. Mitigation: Use the `sandbox` attribute to restrict capabilities; implement `postMessage` for secure cross-origin communication.
**Performance Impact:** Iframes can negatively impact performance due to additional HTTP requests and rendering contexts. Mitigation: Lazy load iframes, use `loading="lazy"` attribute, or consider alternatives if possible.
**Mitigation with `sandbox` attribute:** This attribute enables a set of extra restrictions for the content within the iframe, such as preventing script execution, form submission, pop-ups, or access to the parent's DOM. You can selectively allow certain capabilities (e.g., `allow-scripts`, `allow-forms`).
Where people lose the point
×Only mentioning one or two security risks without discussing mitigation strategies.
×Not explaining the `sandbox` attribute's role in restricting iframe capabilities.
×Confusing iframe security with general network security issues.
16.Explain the purpose of the `<template>` and `<slot>` elements in HTML.
Hard
What a strong answer covers
**`<template>` element:** Used to declare fragments of HTML that are not rendered when the page loads but can be instantiated and inserted into the DOM at runtime using JavaScript. It's a way to define reusable, inert content.
**Purpose of `<template>`:** Ideal for defining the structure of Web Components, dynamic UI elements, or any content that needs to be cloned and used multiple times without being visible initially.
**`<slot>` element:** Used within a Shadow DOM (often inside a custom element's template) to create placeholders where content from the light DOM (the parent document) can be inserted.
**Purpose of `<slot>`:** Enables content distribution, allowing users of a custom element to inject their own markup into specific areas of the component's shadow tree, making components more flexible and customizable. Slots can be named (`<slot name="header">`) for targeted content insertion.
Where people lose the point
×Confusing `<template>` with a regular `<div>` that is hidden with CSS.
×Not linking `<slot>` directly to Shadow DOM and content distribution.
×Failing to explain how they work together to create flexible Web Components.
A question a HTML panel actually asks, answered out loud, scored on what you said and how you said it. Under two minutes, and nothing to sign up for.
“What is the purpose of the `<!DOCTYPE html>` declaration?”
We never store the audio. Your answer is deleted within 24 hours unless you save the result.
How HTML answers get judged
The weights a HTML interviewer is holding, whether or not they say so out loud. Round Zero scores your practice answers against exactly these, and quotes your own words back as the evidence for each.
Technical Accuracy
40%
The answer demonstrates a precise and correct understanding of HTML concepts, syntax, and specifications. No factual errors or misinterpretations.
Conceptual Depth
30%
The answer goes beyond surface-level definitions, explaining the 'why' behind concepts, their implications, and underlying principles. Shows a strong grasp of how HTML works.
Adherence to Best Practices
20%
The answer incorporates and emphasizes industry best practices, particularly regarding accessibility, semantic usage, and performance considerations.
Clarity and Conciseness
10%
The answer is well-organized, easy to understand, and directly addresses the question without unnecessary jargon or verbosity. Examples are clear and relevant.
You have read what strong HTML answers contain. The next thing that moves the needle is producing one under time, out loud, and finding out where it falls apart.
Start with the core areas HTML interviewers probe: What is the purpose of the `<!DOCTYPE html>` declaration; Explain the difference between the `<head>` and `<body>` sections of an HTML document.; Why is the `alt` attribute important for `<img>` tags. This page outlines strong answers and common mistakes, and the scored path drills each one with follow-ups.
Is the HTML practice free?
Yes. The HTML path runs free inside Round Zero: lessons, practice questions and flashcards. Drills are unlimited on every plan, free included. So is the full scorecard. Free also covers 3 complete scored interviews, no card.
How is this different from a HTML question list?
A static list gives you questions with no feedback. Round Zero runs a live scored practice that probes your actual answers, rotates difficulty, and tells you exactly what to fix, grounded in a HTML rubric.
How should I prepare for a HTML interview?
Learn the concepts, drill the questions until answers come fast, then prove it in a scored mock. Round Zero sequences all three so you know you are ready, not just that you read about HTML.
How is a HTML answer scored?
HTML answers are scored on technical accuracy, conceptual depth, adherence to best practices, clarity and conciseness, with evidence quoted from what you actually said, so feedback is specific instead of generic praise.
More free tools
Try everything. Sign up only when you want the full version.