Technology interview warm-up
CSS interview questions and answers hub with coding prompts, concept questions, follow-ups, and common mistakes. Practice concise answers first, then expand into Study Plans, guides, and Company Prep.
On this page
Popular clusters
Short answers
CSS is the styling language browsers use to control presentation, layout, and visual states for HTML documents. It maps selectors to declarations, then the browser resolves those declarations through the cascade and computes final styles. CSS can fail in surprising ways because multiple rules, inherited values, browser defaults, and responsive constraints all interact.
Review CSS basics →The cascade decides which declaration wins when more than one rule applies to the same property. It evaluates origin, importance, cascade layers, specificity, scoping proximity, and source order. Source order only wins after the higher-priority cascade factors are tied.
Review cascade order →Specificity is the selector weight used when competing declarations are in the same origin and layer. Inline styles, IDs, classes or attributes, and element selectors carry different weight. Specificity fixes can become a maintenance problem when every override needs a stronger selector.
Practice specificity →Inheritance lets some computed values pass from parent elements to children. Text-related properties such as color and font-family commonly inherit, while layout properties such as margin and border usually do not. Bugs happen when a component unexpectedly receives typography, color, or custom property values from a parent context.
The box model describes how content, padding, border, and margin create an element box and spacing around it. With content-box, width applies only to content; with border-box, width includes padding and border. Many layout bugs come from mixing those sizing assumptions in the same component.
Review the box model →Padding creates space inside an element between its content and border. Margin creates space outside the element between it and neighboring boxes. Margin can collapse vertically in normal flow, while padding affects the element box and background area.
Compare margin and padding →The display property controls how an element generates boxes and how its children participate in layout. Block, inline, flex, grid, and none all create very different layout behavior. Changing display can also change whether width, height, alignment, and child placement rules apply.
Review display and Flexbox →Flexbox is best for one-dimensional layouts where items need alignment, distribution, wrapping, or ordering along a row or column. It is well suited for nav bars, toolbars, centered content, and small component internals. For layout where rows and columns both matter, Grid is usually clearer.
Review Flexbox →CSS Grid is best for two-dimensional layouts where rows and columns need to be controlled together. It handles page regions, card galleries, dashboards, and layouts with explicit tracks or areas. It can be more structure than needed for a single row of aligned controls.
Compare Grid and Flexbox →Positioning controls whether an element stays in normal flow and what box its offsets use. Relative keeps its original space, absolute positions against a containing block, fixed uses the viewport, and sticky switches as the user scrolls. Positioning bugs often come from the wrong containing block or scroll container.
Review positioning →A stacking context is a layer group where child z-index values are compared internally. Transforms, opacity, filters, positioned elements, isolation, and other properties can create new stacking contexts. An element with a large z-index can still appear behind another element if its parent context is lower.
Debug stacking contexts →z-index controls stacking order only for positioned or stacking-context-aware elements. It does not create a global ranking across the whole page. If two elements are in different stacking contexts, changing the child z-index may not change which one appears on top.
Review z-index →px is an absolute CSS pixel unit, rem is relative to the root font size, em is relative to the current element font size, and percent depends on the property and containing context. rem is predictable for global spacing and type scales, while em is useful for component-relative sizing. Percent values can surprise you because width, height, transforms, and padding can use different reference boxes.
Review CSS units →Media queries apply CSS when viewport, device, environment, or user preference conditions match. They are used for responsive layouts, reduced motion, color scheme, print styles, and input capabilities. Good media queries respond to layout constraints instead of copying a fixed list of device sizes.
Review media queries →Container queries let a component adapt to the size or style context of its container instead of only the viewport. They are useful when the same component appears in a sidebar, grid, and full-width region. The component needs a defined query container, otherwise the query has no useful container to evaluate.
Responsive design means the UI adapts to different widths, input modes, zoom levels, content lengths, and user preferences. CSS tools include fluid units, media queries, container queries, flexible tracks, wrapping, and stable aspect ratios. A responsive layout should be tested with long content and narrow widths, not only common device presets.
Practice responsive CSS →CSS custom properties are variables declared with names like --space and read with var(). They cascade and inherit, so themes and component overrides can be controlled at runtime. The risk is accidental inheritance or missing fallbacks that make a component pick up the wrong value.
Review custom properties →Pseudo-classes select elements in a state, such as :hover, :focus-visible, :checked, or :nth-child(). Pseudo-elements style generated parts of an element, such as ::before, ::after, or ::marker. Focus styles are a practical edge case because removing outlines globally breaks keyboard navigation.
Review pseudo selectors →BEM is a naming convention that separates blocks, elements, and modifiers to make selector intent explicit. It avoids deep descendant selectors and helps teams reason about component state. It is a convention, not a browser feature, so it works only when the team applies it consistently.
Find the element that is wider or taller than its container, then inspect fixed widths, min-width defaults, grid tracks, absolute positioning, and long unwrapped text. Flex and grid children often need min-width: 0 or min-height: 0 to shrink correctly. Hiding overflow can mask the problem while making content or focus unreachable.
Fix responsive overflow →min-width prevents an element from shrinking below a threshold, while max-width prevents it from growing beyond a threshold. They are useful for readable cards, text columns, and media, but they can also create overflow if the minimum is too large. In flex and grid layouts, automatic minimum sizes are a common reason content refuses to shrink.
Practice responsive sizing →Transforms change how an element is visually moved, scaled, rotated, or skewed without changing normal document flow. Transitions animate a property change between two states. Transform and opacity animations are usually cheaper than animating layout properties like width, height, or top.
CSS animations should support the UI state without delaying essential information or causing motion discomfort. Use prefers-reduced-motion to simplify or remove nonessential motion for users who request it. Animating layout-heavy properties can create performance problems on slower devices.
Review media features →Start by measuring whether the problem is style recalculation, layout, paint, compositing, or JavaScript. Prefer stable layout dimensions, avoid repeated layout reads after writes, and animate transform or opacity when possible. Hardware acceleration can help specific compositing cases, but it is not a universal fix.
Review CSS performance →Inspect the element in DevTools, check the computed styles, and identify the actual constraint that fails. Then isolate cascade conflicts, box sizing, display mode, positioning, overflow, and responsive breakpoints. Guessing from the stylesheet alone is slower because the live DOM state may differ from the source you are reading.
Practice layout debugging →Beginner to experienced
Start with selectors, the cascade, inheritance, the box model, display, Flexbox, Grid, positioning, units, and media queries. The goal is to explain what the browser does before adding complicated patterns.
Move into cascade architecture, specificity control, responsive component constraints, stacking contexts, performance measurement, design tokens, and visual debugging. Experienced answers should connect CSS choices to maintainability and production UI failures.
Cascade + specificity
The cascade evaluates origin and importance first, then cascade layers, specificity, scoping proximity, and source order. This means a later rule does not always win. Debugging should start with the computed style panel because it shows which cascade factor won.
Review cascade order →Specificity compares selector weight from IDs, classes or attributes, pseudo-classes, elements, and pseudo-elements. It is compared only after higher cascade factors such as origin and layers are resolved. Inline styles and !important can change the conflict path and should be treated carefully.
Practice specificity →Cascade layers let you define priority groups such as reset, base, components, utilities, and overrides. A declaration in a later layer can beat a more specific declaration in an earlier layer. This reduces specificity escalation because priority can be modeled by layer order.
Review cascade layers →Inheritance reuses a computed value from the parent when a property is inheritable. An initial value is the property default defined by CSS when no cascade or inherited value applies. The distinction matters when reset styles or component wrappers unexpectedly change text, color, or spacing behavior.
:is() and :has() can make selectors more expressive, while :where() always contributes zero specificity. :has() can select a parent based on children or state, which avoids some JavaScript but can make selectors more complex. These selectors should be used with specificity and performance awareness.
Review pseudo selectors →!important raises a declaration above normal declarations in the same cascade path. It can be justified for utility overrides, accessibility helpers, or third-party constraints, but it should not be the default way to fix conflicts. Overusing it makes later changes harder because every override needs another escalation.
Review importance rules →ID selectors have high specificity and are harder to override than class selectors. They can be useful for anchors or unique DOM targets, but they often make component styles rigid. Class-based selectors are usually easier to compose and maintain.
Keep selectors shallow, prefer stable class names, avoid styling through fragile DOM depth, and use layers or utilities for planned overrides. Deep descendant selectors break when markup changes. A good selector should describe the styling contract, not the entire DOM path.
Box model + overflow
content-box applies width and height to the content area only. border-box includes padding and border inside the declared width and height. border-box is often easier for responsive components because padding does not unexpectedly increase the outer size.
Review box sizing →Padding is part of the element box, so with content-box it adds to the declared width or height. With border-box it is included inside the declared size. The active box-sizing mode determines whether padding causes overflow.
Review the box model →Vertical margins can collapse between block elements in normal flow, including parent and child edges under certain conditions. Padding, borders, flex, grid, and overflow contexts can stop collapse. Unexpected margin collapse often looks like spacing is being applied to the wrong element.
With content-box, padding and border are added on top of the 100% content width. Fixed children, long words, minimum sizes, and scrollbar space can also push the box wider than its container. The fix depends on the exact source, not only changing overflow.
Debug box sizing →Flex and grid items can have automatic minimum sizes based on their content. Long text, tables, images, and nowrap content can keep an item wider than its container. Setting min-width: 0 or min-height: 0 on the right child often lets the layout shrink correctly.
Fix shrink issues →visible lets content escape the box, hidden clips it, and auto adds scrolling only when needed. hidden can be useful for masks, but it can hide focus outlines or important content. auto is safer when content must remain reachable.
Use min-width, max-width, width, aspect-ratio, and content-aware layout rules to define what a component can tolerate. A component should have a stable minimum usable size and a clear maximum reading width when needed. Without constraints, it may look fine in one viewport and break with real content.
Practice sizing constraints →Scrollbars can consume space, create nested scrolling, and change available width depending on platform and styling. Components with fixed widths can shift or overflow when scrollbars appear. Testing with real overflow content exposes issues that empty mock states hide.
Review sizing units →Layout systems
Flexbox uses a main axis and a cross axis. justify-content distributes along the main axis, while align-items and align-content control the cross axis. Direction and wrapping change which axis each property affects.
Review Flexbox →Grid tracks are rows and columns defined with fixed, flexible, minmax, auto, or named sizes. The browser places items into grid cells and can create implicit tracks when items exceed the explicit grid. Track sizing bugs usually come from confusing available space with content minimums.
Review Grid →Use Flexbox when the nav is a row of items that can align, distribute, and wrap. Preserve readable labels and visible focus states as items move to another line or into a disclosure pattern. Hiding links without an alternate path creates a navigation failure.
Build a Flexbox nav →An absolutely positioned element uses the nearest positioned ancestor or another containing-block-creating ancestor for offsets. If none exists, it may position relative to the initial containing block. Unexpected absolute positioning usually means the intended parent was not actually the containing block.
Review positioning →Sticky positioning depends on a scroll container, an inset value, and enough room inside the parent to move. Overflow on an ancestor can create a different scroll container than expected. Debug sticky by checking ancestor overflow and the element offset before changing z-index.
Debug sticky positioning →Overlays should be placed in a predictable layer with clear stacking context ownership. A transformed or opaque parent can trap an overlay below other page regions. Moving the overlay to a root layer is often cleaner than increasing z-index values indefinitely.
Review stacking behavior →auto-fit with minmax() lets the grid create as many columns as fit while preserving a usable minimum column width. It reduces breakpoint code for card galleries and dashboards. The minimum value should be chosen from content needs, not an arbitrary device width.
Build a responsive grid →Float is mostly legacy for page layout but still useful for text wrapping around media. Modern layout should use Flexbox or Grid for component and page structure. Legacy float bugs often involve clearing behavior and parents that collapse around floated children.
Responsive CSS
Mobile-first CSS starts with the narrowest useful layout and adds rules as more space becomes available. It usually reduces overrides because the base styles already handle constrained screens. The component still needs to be tested with long text and zoom, not only a phone-width viewport.
Review media queries →Media queries react to viewport or environment conditions, while container queries react to a component container. Container queries make reusable components adapt based on placement. They work best when component boundaries and container names are intentional.
clamp() sets a minimum, preferred, and maximum value in one expression. It is useful for fluid typography, spacing, and widths that should scale but stay bounded. Without reasonable min and max values, fluid sizing can become too small or too large.
Practice fluid sizing →Cards should keep stable media ratios, readable text, predictable action placement, and enough space for long titles. Grid with minmax() can adapt columns without many breakpoints. Test missing images and long content because they expose fragile card layouts.
Build card grids →Navigation should preserve reachable links, visible focus, and clear current-state cues. Wrapping, scrolling, disclosure menus, or priority links can work depending on item count. Simply hiding links for small screens removes navigation rather than making it responsive.
Build a responsive nav →Long content can break cards, tables, buttons, and grids. Use overflow-wrap, min-width: 0, max-width constraints, and intentional truncation rules. Truncated important content should have another way to be read.
Fix responsive overflow →Use prefers-reduced-motion to simplify or remove nonessential motion for users who request it. State changes should still be understandable without animation. Reduced motion is not only an accessibility detail; it also prevents motion-heavy UI from delaying important feedback.
Review media features →CSS variables let themes change tokens such as color, spacing, radius, and shadows through the cascade. They can be scoped globally, per component, or by state such as dark mode. The fallback and inheritance path should be clear so components do not receive accidental theme values.
Build theme variables →Debugging + performance
Check whether the stylesheet loaded, whether the selector matches the live DOM, whether the declaration is valid, and whether another rule wins. DevTools computed styles show both winning and overridden declarations. Reading the stylesheet alone is slower because the element state may differ at runtime.
Review cascade debugging →Inspect the losing declaration and compare layer, importance, specificity, and source order against the winner. Lowering the winning selector or using a planned layer is often better than adding a stronger selector. Specificity escalation makes the next change harder.
Practice specificity →Find the stacking contexts first, then compare z-index values inside the relevant context. Transforms, opacity, filters, isolation, and positioned ancestors can change the layer model. A huge z-index cannot escape a lower parent stacking context.
Debug z-index →Identify the element wider than the viewport, then inspect fixed widths, min-width defaults, grid tracks, absolute positioning, and long unwrapped content. Temporarily outlining elements can reveal the offender quickly. The durable fix should remove the bad constraint instead of hiding the page overflow.
Practice overflow fixes →Layout thrashing happens when code repeatedly writes styles and then reads layout values that force the browser to recalculate geometry. CSS-heavy UI can suffer when animations or scripts keep changing layout properties. Batch reads and writes, and avoid animating properties that trigger layout when possible.
Hardware acceleration can help when animations are moved to composited layers, often with transform or opacity. It does not fix expensive layout, paint, or JavaScript work by itself. Too many promoted layers can increase memory use and make performance worse.
Review acceleration →Maintainable CSS has predictable selectors, controlled cascade layers, reusable tokens, explicit states, and limited global leakage. Components should expose styling hooks intentionally instead of depending on deep DOM selectors. CSS becomes fragile when every change requires a more specific override.
Review CSS tokens →Common mistakes include guessing before inspecting computed styles, hiding overflow without finding the source, increasing z-index blindly, and fixing specificity by nesting more selectors. Another failure is testing only one viewport with short placeholder text. CSS debugging should isolate the constraint, verify the winning rule, and test realistic content.
Practice responsive debugging →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 responsive navbar using Flexbox. Align brand left, links center or right, and actions to the end. Use gap for spacing, keep items aligned on one row, and ensure the layout wraps cleanly on small screens without…
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.
Create a responsive card gallery using CSS Grid that adapts from 2 to 4 columns. Use `repeat()` with `minmax()` for flexible tracks, and `gap` for consistent spacing. Demonstrate how the grid naturally flows extra cards…
Open CSS coding interview challenge →Critical for coding rounds and edge-case discussion.
Create a themeable panel using ONLY CSS custom properties. Define light defaults on :root, redefine the SAME variables for OS dark mode via @media (prefers-color-scheme: dark), then add a manual override using html.them…
Open CSS coding interview challenge →Critical for coding rounds and edge-case discussion.
This pattern is used in notifications, status indicators, and card metadata, so the badge should remain anchored even as content size changes. Edge cases include long titles and responsive cards; test overlap and ensure…
Open CSS coding interview challenge →Need more implementation reps? Open the full coding list or follow a study plan.
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.
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 →Frequently tested in explanation-heavy rounds.
This question is specifically about selector scoring (specificity points), not the full cascade algorithm. Explain how selector weights are computed and compared, then mention tie-breakers briefly. Use it to debug why o…
Open CSS interview question →Frequently tested in explanation-heavy rounds.
The CSS cascade resolves conflicts by comparing importance (!important), origin (user vs author), specificity, and source order. More specific selectors win; if specificity ties, later rules take precedence. Edge cases…
Open CSS interview question →Frequently tested in explanation-heavy rounds.
Use media queries as a production breakpoint strategy: adapt layouts, respect user preferences, and avoid responsive pitfalls caused by viewport-only thinking.
Open CSS interview question →Frequently tested in explanation-heavy rounds.
display:flex is a layout system, not a centering spell. Explain main vs cross axis, direct-child constraints, and common production bugs around shrinking, overflow, and unexpected stretching.
Open CSS interview question →Need more concept coverage? Open the full concepts list or browse company packs.
Interview prep context
CSS questions are reviewed for practical UI debugging and interview-ready trade-off language.
Quick answers
Yes. The page starts with CSS fundamentals, then moves into experienced-developer topics such as cascade architecture, specificity control, responsive constraints, stacking contexts, performance, and visual debugging.
Yes. It covers cascade order, layers, specificity, inheritance, pseudo selectors, !important, selector strategy, and how to debug conflicting declarations.
Yes. It covers when to use Flexbox, when to use CSS Grid, Flexbox vs Grid trade-offs, alignment, wrapping navigation, responsive grids, positioning, sticky behavior, and z-index.
Yes. It covers responsive CSS, media queries, container queries, clamp(), fluid sizing, responsive navigation, card layouts, long text, reduced motion, and theme variables.
Yes. It covers missing styles, specificity conflicts, horizontal scroll, stacking bugs, layout thrashing, hardware acceleration, custom properties, and maintainable CSS.
Start with the CSS coding preview on this page, then move into Flexbox navbar, Grid card gallery, fluid clamp sizing, theme variables, and responsive layout drills.
Start with one route first. Then expand into Question Library, Study Plans, and Company Prep only when you need them.
Recommended preparation
Start with the interview preparation guide and shared baseline, then tighten CSS coding, concepts, and follow-up depth.