HTML

HTML is the content and its meaning, CSS is the presentation, JavaScript is the behaviour.

Separating them means the same markup can be restyled without touching content, and can still be read by a screen reader or a crawler that runs neither of the other two.

What it is really testing. Whether you think in layers. Candidates who cannot separate them tend to write markup that only works with their stylesheet.

No. It is a markup language: it describes structure and meaning, with no variables, loops or conditionals.

This is not a criticism. HTML is declarative - you say what something is, and the browser decides how to present it. That is why the same page works in a browser, a screen reader and a search index.

What it is really testing. Whether you can explain the difference without sounding defensive about it. The follow-up is usually what declarative means.

It tells the browser to use standards mode rather than quirks mode.

Without it browsers fall back to emulating decades-old behaviour, where the box model and several layout rules differ. The modern doctype is a single short line with no DTD because HTML5 is not based on SGML.

What it is really testing. Whether you know it affects rendering rather than validation. Many candidates think it declares the HTML version.

Using elements that describe what the content is rather than how it should look.

A heading marked as a heading can be navigated to, listed in an outline, and understood by a search engine. The same text in a styled div is invisible to all three.

What it is really testing. Whether you can name a consequence. 'It is better practice' is the weak answer; 'a screen reader can jump between headings' is the real one.

A div has no meaning and groups things for styling; a section is a thematic grouping that belongs in the document outline.

A section should have a heading. If you cannot name what the section is about, it is probably a div. Using section everywhere produces an outline full of unnamed regions, which is worse than using div.

What it is really testing. Whether you reach for semantics by default or by habit. The honest answer includes when div is correct.

When the content would still make sense on its own, removed from the page.

A blog post, a comment, a product card, a news item. The test is syndication: if it could be published independently, it is an article. A chapter of a longer piece is a section.

What it is really testing. Whether you have a rule rather than a feeling. Interviewers ask because both elements are routinely misused.

header, nav, main, aside, footer and article - plus section when it is labelled.

They give assistive technology a map of the page, so a user can skip straight to the main content rather than listening to the navigation on every page. There should be exactly one main per page.

What it is really testing. Whether you know what landmarks are for. Listing them is easy; explaining the skip-to-content benefit is the answer.

One, naming what the page is about.

The heading levels form an outline and should nest without skipping. Using h3 because h2 looked too large is choosing a heading for its font size, which is what CSS is for.

What it is really testing. Whether you treat headings as structure or as styling. Expect a follow-up asking what happens if you skip a level.

It is what the image says, for someone who cannot see it - and it should be empty when the image is purely decorative.

An empty alt tells a screen reader to skip the image. Omitting alt entirely is different: the reader falls back to announcing the file name, which is noise.

What it is really testing. Whether you know empty and missing are not the same. This single distinction separates people who have tested with a screen reader from people who have not.

A link navigates somewhere; a button performs an action on the current page.

A link can be opened in a new tab, bookmarked and copied. A button responds to both Enter and Space. A screen reader announces them differently, which sets the user's expectation of what will happen.

What it is really testing. Whether you know styling one as the other is fine but swapping the element is not. The worst answer is a clickable div.

It is not focusable, has no role, and does not respond to the keyboard - so it works only with a mouse.

Rebuilding it with tabindex, role and key handlers reproduces button badly. Using the right element gets all of it for free, including the focus ring and the operating system's accessibility tree entry.

What it is really testing. Whether you have thought about keyboard users at all. This is one of the most common real defects in production code.

It names a form field, and connects to it so that clicking the label focuses the input.

The for attribute must match the input's id. Without the connection a screen reader announces the field as unlabelled, and the clickable area stays small, which matters on a phone.

What it is really testing. Whether you know placeholder is not a substitute. The follow-up is usually why.

It disappears as soon as the user types, taking the only description with it.

It also tends to have low contrast, it is not reliably announced, and a user returning to a half-filled form has no way to know what a field was for. Use both if you like, but never placeholder alone.

What it is really testing. Whether you have watched somebody fill in a form. This is a design mistake almost everybody makes once.

Validation, and the right keyboard on a phone.

type=email produces an @ key, type=tel a numeric pad, type=number spinners. The browser also validates the format before submission, so the user finds out immediately rather than after a round trip.

What it is really testing. Whether you think about mobile. The keyboard answer is the one that shows you have used your own form on a phone.

It tells the browser what a field holds so it can fill it in.

autocomplete='email' or 'cc-number' or 'one-time-code' lets the browser or password manager help. It is one of the highest-value, lowest-effort attributes in HTML and it is almost always missing.

What it is really testing. Whether you optimise for the person filling the form. Few candidates mention it, which makes it a strong answer.

GET puts the data in the URL and should not change anything; POST sends it in the body and is expected to change state.

Because GET is cacheable, bookmarkable and logged, putting a delete behind one means a crawler or a prefetch can trigger it. Search forms are GET; anything that writes is POST.

What it is really testing. Whether you know it is about semantics rather than hiding data. POST is not a security measure.

It stops submission until the field has a value - and no, it is not enough.

Client-side validation is a convenience for honest users. Anyone can send a request without it, so the server must validate everything again. Treat the attribute as a user experience feature, not a control.

What it is really testing. Whether you understand that the client cannot be trusted. This is the gateway to the security half of the interview.

An id identifies one element and must be unique; a class marks a group and can repeat.

Duplicate ids break fragment links, label associations and anything that queries by id - and the browser will not warn you. Classes are the default; reach for an id when something genuinely needs naming.

What it is really testing. Whether you know duplicates are invalid rather than merely untidy.

Attaching custom data to an element without inventing non-standard attributes.

data-user-id or data-state keeps markup valid and is readable from JavaScript through the dataset property. The alternative - making up attributes - produces invalid HTML that may behave differently later.

What it is really testing. Whether you know there is a sanctioned way to do this. The follow-up is how you read them.

It tells a mobile browser to use the device width rather than pretending to be a desktop.

Without it a responsive layout still renders at an assumed desktop width and is zoomed out, so a site that works perfectly at small sizes appears as a tiny unreadable version of itself.

What it is really testing. Whether you have debugged a page that was responsive and still looked wrong on a phone.

The browser must know how to decode the bytes before it can parse them.

It should be in the first kilobyte of the document. Get it wrong or leave it out and non-ASCII characters become mojibake - and the symptom appears in content rather than in code, so it is often blamed on the database.

What it is really testing. Whether you understand encoding happens before parsing.

Both download in parallel; defer runs after parsing in document order, async runs as soon as it arrives in no guaranteed order.

Without either, the parser stops while the script downloads and runs. defer is the safe default for scripts that depend on the DOM or on each other; async suits independent things like analytics.

What it is really testing. Whether you know why a script at the end of body was the old workaround.

localStorage persists until cleared, sessionStorage until the tab closes, and cookies are sent to the server with every request.

The last part is the key difference. Cookies cost bandwidth on every request and are the right tool only when the server needs the value. Storage is read by JavaScript and never leaves the browser on its own.

What it is really testing. Whether you pick based on who needs the data. Storing a session token in localStorage is a common mistake.

A block element starts on a new line and takes the full width; an inline element flows within text and only takes the space it needs.

Width, height and vertical margins do not apply to pure inline elements, which is why setting a height on a span does nothing. inline-block gets both behaviours, and modern layout usually makes the distinction less relevant.

What it is really testing. Whether you can explain why a style you applied had no effect.

Not validly in most cases - though an anchor is a deliberate exception and may wrap block content.

Putting a div inside a span produces unpredictable rendering because the parser tries to repair it. The anchor exception was added precisely because wrapping a whole card in a link is a real need.

What it is really testing. Whether you know the parser repairs bad nesting silently rather than erroring.

The parser has specified error recovery - it builds the best document it can rather than failing.

That is deliberate and good for the web, and it means bad markup looks like it works. The damage shows up for screen readers, search engines and reader mode, none of which report a bug.

What it is really testing. Whether you know the failure is invisible. This is the argument for running a validator.

Elements like img and br have no content; the trailing slash is optional in HTML and required in XHTML or inline SVG.

In HTML the parser ignores it. In XML-based contexts it is mandatory, which is why the habit persists and why copying an SVG into HTML sometimes behaves differently from how it did standalone.

What it is really testing. Whether you know the parsing context changes the rules.

Serving different image files for different conditions - screen width, pixel density, or format support.

It lets you ship a modern format with a fallback, and a smaller crop on a phone, with the browser choosing before downloading. srcset on an img handles the resolution case alone; picture handles format and art direction.

What it is really testing. Whether you have optimised images for mobile. The follow-up is usually about srcset and sizes.

loading='lazy' defers offscreen images until they are near the viewport.

It reduces initial bandwidth considerably on long pages. Applying it to an image above the fold is a mistake - it delays the largest visible element and makes the perceived load slower, which is the opposite of the intent.

What it is really testing. Whether you know where NOT to apply it. Lazy-loading the hero image is a common and measurable mistake.

The source is text; the DOM is the tree the browser built from it, including repairs and anything scripts changed.

View-source shows what the server sent; the inspector shows the current DOM. They differ whenever the parser fixed invalid markup or JavaScript modified the page, which is why a bug can be invisible in the source.

What it is really testing. Whether you know where to look when the page does not match the file.

It names the table so assistive technology can announce and skip it.

A table without one is a block of numbers with no context. Together with th and scope, the caption is what turns a visual grid into something that can be read aloud coherently.

What it is really testing. Whether you know accessible tables need more than the table element.

It says whether the header applies to a column or a row, so a screen reader can pair each cell with its header.

Without it, reading a table aloud produces a stream of disconnected values. With it, the reader announces 'Fee: free' rather than 'free', which is the difference between usable and not.

What it is really testing. Whether you have thought about how a table sounds rather than how it looks.

For layout. It is the right element for tabular data and nothing else.

The advice has been over-learned into avoiding tables entirely, which is also wrong. If the position of a cell carries meaning - a row and a column both mean something - it is a table.

What it is really testing. Whether you can defend using one. Candidates often apologise for tables that are entirely correct.

alt is the text alternative to an image; title is advisory text shown as a tooltip.

title is not reliably announced, is invisible on touch devices, and should never carry information that is not available elsewhere. It is close to useless as an accessibility tool, which surprises people.

What it is really testing. Whether you know a table needs header association to be readable aloud at all.

It tells a screen reader which pronunciation rules to use, and helps translation tools.

English read with another language's phonetics is close to unintelligible. It belongs on the html element, and on any element whose language differs from the page's.

What it is really testing. Whether you consider non-visual users. It is one line and almost always missing.

It embeds another document, and the risks are clickjacking, performance, and third-party content you do not control.

The sandbox attribute restricts what the frame may do, and omitting allow-same-origin gives it an opaque origin so it cannot reach your page. X-Frame-Options and frame-ancestors control who may embed you.

What it is really testing. Whether you know title is not an accessibility feature. Many candidates recommend it for exactly the wrong reason.

noopener stops the new page accessing window.opener; noreferrer also withholds the referrer header.

Without noopener, a page opened with target=_blank can navigate your original tab to a phishing site. Modern browsers imply noopener for target=_blank, but older ones do not and the attribute costs nothing.

What it is really testing. Whether you know both directions - what you embed, and who embeds you.

Start with markup and server-rendered content that already works, then enhance it.

A form that posts, links that navigate, and content present in the HTML will work for a crawler, a slow connection and a failed script. Progressive enhancement is less a philosophy than a resilience strategy.

What it is really testing. Whether you know the attack it prevents. 'Security' alone is not an answer; tabnabbing is.

display:none and hidden remove the element from layout and from the accessibility tree; visibility:hidden leaves the space but hides it.

There is a fourth case worth knowing: visually hidden but still announced, used for skip links and screen-reader-only labels. Using display:none for those removes them from the users who needed them.

What it is really testing. Whether you treat JavaScript as an enhancement or an assumption. The follow-up is often what happens on a flaky connection.

Read the headings alone, tab through with no mouse, disable CSS, and run a validator.

Each one catches a different class of problem: structure, keyboard access, meaning that lived only in the stylesheet, and invalid markup the browser silently repaired. None takes more than a few minutes.

What it is really testing. Whether you have a method rather than an opinion. This is often the closing question and a good answer leaves a strong impression.