HTML Interview Questions for 3 Years Experience

At 3 years, HTML interview questions rarely ask you to define a tag. They hand you markup that looks fine and isn't, or ask you to build something ordinary, a form, an image gallery, a page layout, and watch whether you get the details right without being told to. This guide works through 6 of those questions, each with a broken-then-fixed example rather than a definition.

That's the axis worth being precise about, because it's easy to get wrong. The difference between this level and a senior round is not that the questions get harder in the abstract. A senior round pushes into newer platform APIs like the Popover API or Shadow DOM, and into how markup decisions ripple through the accessibility tree, ground that GreatFrontEnd's senior HTML guide (https://www.greatfrontend.com/blog/senior-html-developer-interview-questions-advanced-topics-and-answers) already covers well and this guide deliberately does not repeat. At 3 years, the bar is narrower and more concrete: can you write correct, accessible, working HTML using features that have been standard for years, and can you spot what's broken in someone else's markup.

What actually changes at 3 years

A fresher can usually recite what an alt attribute is for. At 3 years, the expectation is that you'd notice its absence in a code review without being prompted, and can explain what breaks for a screen reader user if it's missing. The knowledge is often the same; what's different is whether you apply it unprompted, under time pressure, on markup you didn't write.

Question 1: Here's a page's markup. What's wrong with its structure, and how would you fix it?

How to approach it

The most common failure at this level isn't ignorance of header, nav, main, and footer, it's using them decoratively rather than structurally. A page with a <div class="header"> styled to look identical to a <header> element passes a visual review and fails every landmark-based navigation tool a screen reader user relies on.

The kind of thing you're looking for, and the kind of fix an interviewer wants to see you make unprompted:

<!-- Before: divs doing semantic work by convention only -->
<div class="header">
  <div class="logo">Site</div>
  <div class="nav">
    <a href="/">Home</a>
    <a href="/about">About</a>
  </div>
</div>
<div class="content">
  <div class="title">Page Title</div>
  <div class="section">...</div>
</div>
<div class="footer">© 2026</div>

<!-- After: real landmarks, one h1, a sane heading order -->
<header>
  <div class="logo">Site</div>
  <nav>
    <a href="/">Home</a>
    <a href="/about">About</a>
  </nav>
</header>
<main>
  <h1>Page Title</h1>
  <section>...</section>
</main>
<footer>© 2026</footer>

Question 2: Here's a form that looks validated but isn't. What's actually broken, and how do you fix it?

How to approach it

HTML ships a real validation system, and a common interview task is either building a form with it or debugging one that silently doesn't work.

<!-- Before: looks validated, isn't -->
<form>
  <input type="text" placeholder="Email" />
  <input type="text" placeholder="Age" />
  <button type="submit">Submit</button>
</form>

<!-- After: the browser's own constraint validation does the work -->
<form>
  <label for="email">Email</label>
  <input id="email" type="email" required />

  <label for="age">Age</label>
  <input id="age" type="number" min="13" max="120" required />

  <button type="submit">Submit</button>
</form>

The line worth stating precisely, because it's an easy thing to get backwards under interview pressure: this validation runs client-side and improves the experience, it never replaces server-side validation. A candidate who presents HTML validation as sufficient on its own is missing half the answer.

Question 3: An image with a srcset isn't downloading the size you'd expect. Why, and what's the fix?

How to approach it

This is a common "why doesn't this work" prompt, because the mechanism is genuinely non-obvious the first time you trace it.

<img
  src="photo-800.jpg"
  srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="A description of the photo"
/>

One more gotcha worth naming specifically: loading="lazy" defers loading until the image nears the viewport, which is good for performance, but a lazy image with no explicit width and height renders at zero by zero pixels until it loads. That's a real, sourced caveat, not a style preference: it causes layout shift when the image does load, and in the worst case, an image that never scrolls into view, one sitting inside a collapsed accordion or an inactive tab, may never load at all. Setting explicit width and height alongside loading="lazy" is the fix, and being able to name that specific interaction is the difference between having read about lazy loading and having actually used it.

Question 4: What do the viewport and description meta tags actually control?

How to approach it

This one is short by design, because it's easy to turn into an SEO essay that isn't what a 3-year HTML question is testing. The two that come up in practice: <meta name="viewport" content="width=device-width, initial-scale=1">, without which mobile browsers render the page at a fixed desktop-like width and then scale it down, and <meta name="description">, which controls the snippet a search engine shows, not the page's ranking directly. Knowing the difference between what a meta tag actually controls and what it merely correlates with is the actual signal here.

Question 5: This dropdown menu is marked up as divs, not a list. Does it matter if it looks identical?

How to approach it

A related pattern shows up with data that has real structure: a set of related items, or genuinely tabular data. Marking up a navigation menu or a set of options as bare divs stacked with CSS spacing, instead of a ul with li items, is the same category of mistake as the landmark issue in Question 1, it looks right visually and loses the structural relationship that assistive technology and, in some cases, search engines rely on to understand that the items are a set.

<!-- Before: visually a list, structurally nothing -->
<div class="menu">
  <div class="menu-item">Dashboard</div>
  <div class="menu-item">Settings</div>
  <div class="menu-item">Logout</div>
</div>

<!-- After: an actual list, still styled however you want -->
<ul class="menu">
  <li class="menu-item">Dashboard</li>
  <li class="menu-item">Settings</li>
  <li class="menu-item">Logout</li>
</ul>

Question 6: Someone used a table to lay out a page, not to show tabular data. What's wrong with that?

How to approach it

This is the mirror-image of Question 5. Using a table for layout purposes, arranging unrelated content into rows and columns purely to get a visual grid, applies tabular semantics to content that isn't actually tabular data, the same category of mistake as div-soup, in the opposite direction. A prompt that asks "is this the right element for this content" is testing whether you default to what the content actually is, not to whichever element happens to produce the right visual result fastest.

A weak answer pattern-matches: it recognizes that a fix is needed and applies it without being able to say why. A solid answer connects the fix to the actual mechanism, explaining that sizes in Question 3 defaults to 100vw because that's what makes an unspecified size safe rather than broken, or that a landmark element in Question 1 matters because of how screen reader users jump between regions, not because it happens to be convention. If you can't trace why a fix works, that's worth noticing in your own prep before an interviewer notices it for you.

What's out of scope at 3 years

Newer platform APIs like the Popover API, deep Shadow DOM encapsulation trade-offs, and detailed accessibility-tree mechanics are the next rung up, covered in GreatFrontEnd's senior HTML developer interview questions (https://www.greatfrontend.com/blog/senior-html-developer-interview-questions-advanced-topics-and-answers). At 3 years, you're generally not expected to reach for those, correct, standard-issue HTML applied without being told to is the actual bar.

Common mistakes

• Using landmark elements as styling hooks rather than for their structural purpose, which passes a visual check and fails an assistive-technology one.
• Treating HTML form validation as sufficient on its own, without mentioning that server-side validation is still required.
• Omitting sizes and not knowing it defaults to 100vw, which quietly changes what the browser downloads.
• Adding loading="lazy" without explicit width and height, inviting layout shift or an image that never loads.
• Explaining a fix as "best practice" without being able to trace the actual mechanism behind why it matters.

Frequently asked questions

Do I need to memorize every ValidityState property? No, but you should be able to name the common ones, valueMissing, patternMismatch, rangeUnderflow, rangeOverflow, and explain how :invalid and checkValidity() relate to that same underlying state, rather than treating validation as a black box.

Is semantic HTML mostly about accessibility or about SEO? Both benefit from it, but they're separate concerns with separate mechanisms, accessibility through how assistive technology parses landmarks and headings, SEO through how a crawler interprets structure and content. Conflating the two in an answer is a common but avoidable imprecision.

What if the interview prompt is "build a form" rather than "debug this form"? Build it with the constraint validation attributes from the start, required, appropriate type values, min/max where relevant, and be ready to explain what each one is doing rather than treating them as boilerplate.

Is this level expected to know CSS as well as HTML? Often yes in practice, since real layout and form-styling questions blend the two, but this guide stays scoped to the HTML mechanics specifically.

Why does it matter whether I use a ul or a styled div if they can look identical? Visual appearance is only half of what markup communicates, see Question 5. Two pages can be pixel-identical and communicate two different structures to a screen reader, which is exactly why an interviewer asking "is this the right element" cares about more than how it renders.

How to prepare

Take a real page you didn't build, from an open-source project or your own older code, and read it the way an interviewer would: is there more than one h1, are landmarks used structurally, does every image have real alt text, does the form validate without JavaScript. Finding five real issues in code that already exists is better practice than writing new markup from scratch, because debugging someone else's HTML is closer to what the interview actually tests.

Conclusion

HTML interview questions for 3 years experience test whether standard, already-shipped features are used correctly and unprompted, not whether you've kept up with the newest platform APIs. Structuring a page with real landmarks, validating a form with the Constraint Validation API and knowing its limits, and tracing exactly how srcset and sizes interact are the recurring topics across these 6 questions, and being able to explain the mechanism behind a fix is what separates a solid answer from one that's just pattern-matching.