Technology interview warm-up
Practice HTML and CSS together for frontend UI rounds: connect semantic markup, accessible forms, component structure, layout behavior, and browser defaults in realistic code scenarios.
On this page
Popular clusters
Short answers
Semantic HTML uses elements that describe the meaning and structure of content, such as header, nav, main, article, section, button, and form. It helps browsers, search engines, assistive technologies, and other developers understand the page without guessing from class names. A common failure is replacing native buttons, links, and headings with generic div elements that then need extra keyboard and accessibility work.
Practice semantic HTML →The DOM is the browser-created object tree that represents the parsed HTML document. JavaScript reads and updates this tree, while CSS selectors match elements in it for styling. The source HTML and live DOM can differ after scripts run, so debugging often means inspecting the current DOM instead of only reading the original markup.
A form control needs a durable accessible name, usually from a label associated with for and id or by wrapping the control. Labels increase the clickable target and help screen-reader users understand the field. Placeholder text is not a replacement because it disappears during input and may not be announced as a stable label.
Build labeled forms →Accessibility means the UI can be understood and operated by people using keyboards, screen readers, zoom, high contrast, or other assistive technology. HTML provides much of the semantic contract, while CSS must preserve readable contrast, focus visibility, and usable layout. A design can look correct but still fail if focus order, labels, or hidden content are wrong.
Review accessibility fixes →Alt text describes the purpose of an image when the image carries information. Decorative images should usually have empty alt text so assistive technology can skip them. The edge case is an image inside a link or button, where the alt text may need to describe the action rather than the visual pixels.
Practice links and images →Use a link for navigation to another URL or location, and use a button for an action on the current page. Native elements provide the expected keyboard behavior, roles, focus handling, and activation events. A fake link or fake button often breaks keyboard access unless you rebuild behavior the browser already gives you.
Native validation uses attributes such as required, type, min, max, pattern, and minlength to let the browser check common constraints. It reduces custom JavaScript but should be paired with clear labels and useful error text. Server-side validation is still required because client-side validation can be bypassed.
Practice form validation →A production document should include charset, viewport, title, useful description, canonical when needed, and relevant social metadata. These tags help browsers render correctly and help crawlers understand the page. Missing viewport metadata is a common mobile bug because the layout may render at a desktop-style width on phones.
Review head metadata →HTML decides which elements and content make up the component, while the CSS box model determines the space each element occupies. Native elements also bring display defaults that affect sizing and flow. Debug the live element tree together with content, padding, border, margin, and box-sizing instead of treating the stylesheet as an isolated diagram.
Review the box model →Classes, data attributes, and ARIA states can expose meaningful component state for CSS without changing native semantics. The cascade then resolves competing base, component, state, and override rules. Prefer stable state hooks and predictable layers over selectors that depend on fragile DOM depth or visual-only class names.
Review cascade order →Start with the correct native elements and shallow component or state selectors, then let cascade layers define broader priority. Semantic markup removes many styling and behavior workarounds that otherwise invite deeply nested selectors. When a conflict appears, inspect the winning rule and simplify the selector contract instead of adding another ID or !important.
Practice specificity →Keep the navigation landmark, list, links, source order, and current-page semantics in HTML, then use Flexbox for one-dimensional alignment, spacing, and wrapping. The narrow layout must preserve every destination and a logical keyboard order. Flexbox should arrange the navigation, not replace its semantic structure.
Review Flexbox →Use landmarks, sections, articles, headings, and meaningful source order to describe the content, then let Grid place those elements in two dimensions. Visual placement must not create a reading or focus order that contradicts the DOM. Grid can remove layout-only wrappers, but it should not turn meaningful content into anonymous boxes.
Compare Grid and Flexbox →A positioned element depends on both its CSS position value and where it sits in the DOM. Positioned ancestors, transforms, and scroll containers can change the containing block used by absolute, fixed, or sticky elements. Keep source order meaningful, then inspect ancestor structure before changing offsets or z-index.
Review positioning →A modal needs an accessible dialog structure, predictable focus behavior, and placement outside clipping or lower stacking contexts. CSS z-index only compares elements inside the relevant context, so a large value cannot repair every ancestor problem. The DOM and overlay layer should keep the dialog visually above the page while background content is also isolated semantically.
Debug z-index →HTML should keep one meaningful source and reading order, while media queries change layout, spacing, and presentation when the available environment requires it. Responsive changes must preserve labels, controls, headings, and keyboard access. If a narrow layout hides content, the UI needs another semantic way to reach it.
Review media queries →Responsive images use srcset, sizes, picture, and modern loading attributes to let the browser choose an appropriate resource. The goal is to avoid shipping oversized images while preserving sharpness and layout stability. Width and height or aspect-ratio should be set so the page does not jump while images load.
HTML component boundaries identify where a token should be shared or overridden, while custom properties carry the value through the cascade. Keep global design tokens broad and expose narrowly named component hooks near the relevant markup. Test nested components because inherited values can cross a boundary farther than intended.
Native HTML exposes interaction states such as focus, checked, disabled, valid, and invalid that CSS can select without duplicating state in JavaScript. Pseudo-elements can add decoration, but they should not carry essential content that assistive technology needs. The markup owns meaning; selectors such as :focus-visible and :checked express its visual state.
Inspect the live HTML to find the element that exceeds its container, then check content length, fixed widths, min-size defaults, layout tracks, and positioned children. The fix must keep meaningful text and focused controls reachable. overflow: hidden can conceal the visual symptom while clipping content or keyboard focus users still need.
Practice responsive fixes →Layout shift happens when content moves after initial render because dimensions, fonts, ads, images, or async UI were not reserved. Set stable dimensions, reserve space for dynamic regions, and avoid inserting content above what the user is reading. The failure mode is a page that passes visual review but feels unstable while loading.
Focus states should be visible, consistent, and not depend only on color. Use :focus-visible to show keyboard focus without adding noisy outlines for pointer users. Removing outlines globally breaks keyboard navigation and makes interactive elements hard to locate.
Native elements have default display behavior, but changing display does not change an element’s semantic role. A link styled as a block is still a link, and a div styled like a button is still not a button. Choose HTML for meaning and interaction first, then choose block, inline, inline-block, flex, or grid for layout.
Use units according to the content contract: rem for root-relative type and spacing, em for component-relative sizing, percentages for containing contexts, and px where a CSS pixel is intentional. Do not lock text or controls into dimensions that break browser zoom or long labels. Test the actual headings, form fields, and actions at narrow widths and increased text size.
Start with semantic markup and fluid layout constraints, then add breakpoints only where the component actually needs a different structure. Use max-width, minmax(), flexible tracks, wrapping, responsive images, and stable spacing tokens. Test narrow widths, long text, zoom, keyboard focus, and overflow instead of only resizing a desktop viewport.
Practice responsive CSS →Beginner to experienced
Start with valid document structure, semantic elements, labels, forms, and small components where markup and layout must work together. The goal is to explain what the browser gives you before reaching for custom scripts or heavy abstractions.
Move into accessibility trade-offs, component-state styling, layout debugging, responsive images, stable dimensions, and browser behavior. Experienced answers should connect UI constraints to maintainable markup and styling decisions.
Semantics + forms
Landmarks such as header, nav, main, aside, and footer divide the page into recognizable regions. They help assistive technology users jump through the page without reading every element. The page should normally have one main landmark, and landmarks should represent real regions rather than decorative wrappers.
Review semantic elements →Headings create an outline that helps users scan the page and understand content hierarchy. Use heading levels for structure, not for visual size. Skipping levels or using headings only for styling can make the page harder to navigate with assistive technology.
Add ARIA when native HTML cannot express the role, state, or relationship you need. Native controls should come first because they already include keyboard and accessibility behavior. Misused ARIA can create a worse accessibility tree than plain semantic markup.
Practice accessibility review →Form errors should be visible, specific, and connected to the affected control. Use text near the field, update aria-describedby when helpful, and keep focus behavior predictable after submission. Color alone is not enough because users may miss the state or use assistive technology.
Build validation states →Data tables need real table markup, a useful caption when context is not obvious, and header cells that define row or column meaning. Complex tables may need scope or header associations. Layout tables should be avoided because they create misleading relationships for assistive technology.
A dialog should expose modal state, focus the right starting point, keep keyboard focus inside while open, and restore focus when closed. The native dialog element can help, but the surrounding interaction still needs careful labels and escape behavior. A visually correct overlay is incomplete if background content remains reachable by keyboard.
Practice dialog accessibility →Anchors activate with Enter and navigate, while buttons activate with Enter or Space and trigger actions. Using the wrong element changes expected keyboard behavior and screen-reader announcement. Styling can make them look alike, but semantics should follow the user action.
Check keyboard navigation, visible focus, labels, headings, landmarks, image text, and form errors before relying on automated tools. Then run a validator, axe or Lighthouse, and inspect the accessibility tree for names and roles. Automated checks catch many issues but cannot prove that the interaction makes sense.
Review an accessibility flow →Markup + layout
Choose landmarks, lists, articles, headings, and source order from the content meaning first. Then use Grid for two-dimensional region placement and Flexbox for one-dimensional alignment inside a region. Visual reordering must not create a reading or keyboard order that conflicts with the semantic DOM.
Compare layout systems →Markup exposes component and state hooks, while cascade layers define the priority of reset, theme, component, and override styles before specificity is compared. This keeps native states and ARIA-driven states predictable without escalating selectors. The layer model should match real ownership boundaries, not compensate for unstable DOM nesting.
Review cascade rules →Use shallow component classes and meaningful state attributes instead of selectors coupled to several ancestor levels. Correct native elements also remove many role and interaction workarounds. Cascade layers and custom properties can then express priority and variation without each new UI needing a more specific override.
Practice specificity →Sticky behavior depends on where the element sits, which ancestor establishes the scroll container, its offset, and the space available inside the parent. A wrapper with overflow can silently change that relationship. Inspect the ancestor structure and preserve a meaningful source order before changing z-index or offsets.
Review positioning →The overlay needs dialog semantics and predictable focus behavior as well as a DOM location that is not clipped or trapped in a lower stacking context. Transforms, opacity, filters, isolation, and positioned ancestors can create those contexts. Fix the overlay boundary and background isolation instead of only increasing z-index.
Debug stacking →Use document-level custom properties for broad design tokens and expose component-level hooks at the markup boundary that owns them. Because custom properties inherit, nested components may receive values unintentionally. Names, fallbacks, and the DOM boundary should make every override deliberate.
Choose a breakpoint when real headings, controls, navigation, or card content stop fitting their semantic structure, not only at common device widths. The adapted layout must keep every action reachable and preserve reading order. Content-driven breakpoints age better than a fixed device list.
Review media queries →Give components a stable semantic structure, explicit states, predictable selectors, and documented styling hooks. Prefer small layout primitives and clear ownership over deeply nested selectors tied to incidental wrappers. The contract fails when a harmless markup change requires another global or more-specific override.
Code scenarios
<input placeholder="Email" type="email">The input has no durable accessible label. Add a label connected with for and id so the field name remains available after the user starts typing. Placeholder text can still provide an example, but it should not be the only name.
Fix labeled forms →<a href="/pricing">
<img src="arrow.png" alt="arrow">
</a>The href makes this anchor a real hyperlink; an anchor without href is not a hyperlink. Its accessible name comes from the image alt text, so "arrow" still does not describe the destination or action. Use alt text such as "View pricing" or add visible text.
Practice links and images →.row { display: flex; }
.title { white-space: nowrap; }Flex items have an automatic minimum size that can prevent shrinking below content width. Add min-width: 0 to the flex child that must shrink, then apply overflow handling intentionally. Setting overflow hidden on the parent may hide the symptom without fixing the layout constraint.
Practice responsive fixes →.cards {
display: grid;
grid-template-columns: repeat(3, 1fr);
}Three fixed columns can exceed the viewport when the container is narrow. Use responsive tracks such as repeat(auto-fit, minmax(220px, 1fr)) or add a breakpoint. The fix should preserve card readability and avoid squeezing content below its usable width.
Build a responsive CSS Grid card gallery →.header { position: relative; z-index: 10; }
.page { transform: translateZ(0); }
.modal { position: fixed; z-index: 9999; }The transformed parent can create a stacking context that changes how the fixed modal is layered. A large z-index inside one context cannot beat a different parent context. Move the overlay to a safer root or adjust the stacking context hierarchy.
Review z-index →<div class="button" onclick="save()">Save</div>A div does not provide button semantics, keyboard activation, disabled behavior, or the expected role. Use a real button and style it with CSS. Rebuilding native behavior with roles and key handlers is more error-prone than using the correct element.
<img src="/hero.jpg" alt="Dashboard preview">The browser does not know the image dimensions before it loads, so surrounding content can move when the image appears. Add width and height or an aspect-ratio so space is reserved. Responsive CSS can still scale the image after the intrinsic ratio is known.
<input name="email" type="email" required>The browser can block common invalid submissions, but users or scripts can bypass client-side validation. Server validation protects the real data boundary and should return useful errors. Client validation improves user experience, not application trust.
Practice validation →Browser behavior
The browser parses HTML into the DOM, parses CSS into style rules, calculates computed styles, builds layout, paints, and composites layers. JavaScript or resource loading can interrupt parts of this process. Performance work starts by identifying whether the problem is style, layout, paint, compositing, or scripting.
A layout recalculation happens when the browser must recompute element geometry. It can be triggered by DOM changes, class changes, font loading, image sizing, or reading layout after writing styles. Batching reads and writes reduces repeated layout work.
Inspect whether another element is covering it, whether pointer-events is disabled, whether the element is outside its visible box, and whether it is actually a link or button. Stacking context and overflow clipping are common causes. The fix should preserve keyboard access, not only pointer clicks.
Review stacking behavior →Check whether the stylesheet loaded, whether the selector matches, whether another declaration wins in the cascade, and whether the property is valid for that element. DevTools computed styles show the winning and overridden declarations. The fastest path is to inspect the actual element state instead of reading the stylesheet in isolation.
Review the cascade →Check display, visibility, opacity, color contrast, clipping, overflow, positioning, transforms, and whether the content exists in the DOM. Content can be present but inaccessible if it is visually hidden incorrectly or removed from the accessibility tree. The fix depends on whether the content should be hidden from everyone or only visually.
Font loading can change text metrics and cause layout shifts when the final font replaces a fallback. Use good fallback stacks, font-display choices, size-adjust where appropriate, and stable layout constraints. Long labels should be tested because they often reveal font and wrapping issues.
Check the viewport meta tag, fixed widths, min-width values, overflowing grids, absolute positioning, and controls that do not wrap. Simulate narrow widths and zoom, then test on a real device when possible. The issue is often a single child that refuses to shrink.
Review viewport metadata →Navigate with the keyboard and compare the focus order to the visual and DOM order. Positive tabindex values usually create fragile ordering and should be avoided. If focus disappears into hidden or offscreen content, the hiding and modal behavior need to be fixed.
Practice focus handling →Adaptive UI
Mobile-first CSS starts with the narrowest useful layout and adds complexity as space becomes available. This usually creates fewer overrides because the base styles handle constrained screens. The edge case is a desktop-only component that still needs a usable narrow fallback.
Review responsive CSS →Media queries react to the viewport or environment, while container queries react to the size or style context of a container. Container queries make reusable components adapt where they are placed. They are most useful when the same component appears in a sidebar, grid, and full-width region.
The nav should preserve readable labels, reachable focus states, and clear current-location cues. Flex wrapping, overflow menus, or a disclosure pattern can work depending on item count. A responsive nav fails if it only hides links without giving users another path to them.
Build a responsive navbar with CSS Flexbox →Cards should keep readable text, stable media ratios, and consistent action placement as columns change. Grid with minmax() and auto-fit can reduce breakpoint code while preserving minimum card width. Test long titles and missing images because they expose fragile card layouts.
CSS Grid minmax() card gallery challenge →Long words, URLs, and user-generated strings can break otherwise clean layouts. Use overflow-wrap, min-width: 0, max-width constraints, and clear truncation rules when content must stay on one line. Truncation should not hide essential information without another way to access it.
Fix responsive overflow →Interactive controls need enough physical size and spacing to avoid accidental taps. CSS should not shrink buttons below a usable hit area just to fit a dense layout. If space is tight, wrapping or grouping controls is better than making them tiny.
The prefers-reduced-motion media query lets users request less animation. Use it to remove or simplify motion that can distract, delay, or cause discomfort. Essential state changes should still be visible without relying on animation.
Review media features →Test narrow and wide widths, zoom, long text, keyboard navigation, image loading, and common device sizes. Inspect overflow, focus visibility, layout shift, and readable contrast. A page that only passes one viewport can still fail real users because content and device constraints vary.
Practice responsive review →Critical for coding rounds and edge-case discussion.
Build a card layout that clearly demonstrates the CSS box model. Use padding to add internal breathing room, a border to visualize the box edge, and margins to separate multiple cards. The intent is to make each layer o…
Open CSS coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a semantic page layout using header, nav, main, section, article, and footer. Focus on correct landmarks, heading hierarchy, and structure rather than styling or layout hacks so the document outline remains clear…
Open HTML coding interview challenge →Critical for coding rounds and edge-case discussion.
Practice a realistic frontend interview prompt: build a responsive navigation bar with Flexbox, preserve readable links, keep the CTA reachable, and explain how the layout behaves when space gets tight.
Open CSS coding interview challenge →Critical for coding rounds and edge-case discussion.
Style form fields using :focus, :invalid, and :required to guide users. Show clear focus rings, error borders, and helper text without causing layout shifts, and make sure states are accessible (color contrast, focus vi…
Open CSS coding interview challenge →Critical for coding rounds and edge-case discussion.
Practice a realistic frontend interview prompt: create a responsive card gallery with CSS Grid, keep cards readable across widths, and explain how track sizing, gaps, and auto-placement work.
Open CSS coding interview challenge →Critical for coding rounds and edge-case discussion.
The goal is to provide a semantic table that screen readers can navigate, with a clear caption and correct header associations. Add headers with scope, captions, and keyboard considerations; test with screen readers and…
Open HTML coding interview challenge →Need more implementation reps? Open Frontend Coding Challenges or follow a study plan.
Frequently tested in explanation-heavy rounds.
Semantic HTML elements expose content roles like navigation, article, main content, and supporting sections. They improve accessibility landmarks, SEO structure, and teammate readability, and the common mistake is repla…
Open HTML interview question →Frequently tested in explanation-heavy rounds.
Margin creates space outside an element’s border (separating it from neighbors), while padding creates space inside the border (pushing the content inward). Understanding this distinction is central to mastering layout…
Open CSS interview question →Frequently tested in explanation-heavy rounds.
Understand the DOM as the browser's in-memory tree, how DOM mutations trigger real render work, and what to debug when selectors, timing, or frequent updates go wrong.
Open HTML interview question →Frequently tested in explanation-heavy rounds.
The <meta> tag configures how browsers, crawlers, and social platforms interpret a page, and the real production pitfall is shipping the wrong head metadata and debugging broken previews, indexing, or viewport beh…
Open HTML interview question →Frequently tested in explanation-heavy rounds.
The alt attribute gives an image a text alternative for screen readers, fallback rendering, and search understanding. The real production decision is whether an image is decorative, informative, or functional, because l…
Open HTML interview question →Frequently tested in explanation-heavy rounds.
CSS units use different reference points. Use rem for root-scaled typography, em for component-local scaling, % for parent-relative sizing, and px for precision-only edges. The common production pitfall is assuming % be…
Open CSS interview question →Need more concept coverage? Open the full concepts list or browse company packs.
Interview prep context
Content checks use runnable examples, regression tests, official-source checks where relevant, correction reports, and dated updates.
Quick answers
Yes. The page starts with beginner HTML and CSS fundamentals, then moves into experienced frontend topics such as accessibility, cascade strategy, layout debugging, browser rendering, responsive UI, and code scenarios.
Yes. It covers semantic HTML, labels, form validation, landmarks, focus states, alt text, dialog behavior, and quick accessibility testing for practical UI rounds.
It connects semantic structure, accessible controls, browser behavior, and layout implementation in the same scenarios. Use the dedicated CSS hub for deeper cascade, specificity, Flexbox, Grid, responsive CSS, and visual-debugging practice.
Start with the code scenarios and preview prompts on this page, then open the HTML/CSS coding list for forms, links, images, semantic layouts, Flexbox nav bars, and responsive card grids.
Start with one route first. Then expand into Frontend Coding Challenges, Study Plans, and Company Prep only when you need them.
Recommended preparation
Start with the interview preparation guide and shared baseline, then tighten HTML and CSS coding, concepts, and follow-up depth.