The CSS questions I ask in a frontend interview

CSS is the part of a frontend interview candidates prepare for least, and it is often where I learn the most. Almost everyone can build a component that works. Fewer people can tell me why it broke when someone put it inside a narrower column, or why their style stopped applying after a teammate added a class.

I am Harry Ashton. I built CodePrepped so engineers stop guessing what hiring managers look for. This post sits alongside the accessibility questions I ask and the performance questions I ask. Together they cover most of what I mean when I say "frontend fundamentals".

Photo: Negative Space / Pexels.

Why I still ask about CSS

Component libraries and utility classes mean a lot of people write less raw CSS than they used to. That is fine. But the bugs still land on your desk: the layout that collapses on a small phone, the modal that sits behind the header, the button that looks right everywhere except one page. I want to know you can reason about those without trying random values until something sticks.

"Why is this style not applying?"

I usually open with a small broken example. A rule that should make a button red, and the button stays blue. Strong answers walk through the cascade in order: is the selector matching at all, is another rule more specific, does something later in the file win, is there an !important or an inline style somewhere, and is the style coming from a layer or a component library I cannot see yet.

I also want to see you open the browser's developer tools and look at the computed styles, rather than guessing. Crossed-out declarations tell you most of the story. Someone who reaches for !important as the first fix gets a follow-up question about what happens the next time somebody needs to override it.

If you mention cascade layers and how they let a team decide that component styles always beat reset styles, regardless of specificity, that tells me you have kept up with how CSS is organised now.

"Flexbox or grid for this?"

I show a layout, usually a card list or a page with a sidebar, and ask which you would use. There is no single right answer. What I listen for is the reasoning.

• Flexbox is good when content decides the size and items flow in one direction, like a row of buttons or a nav bar.
• Grid is good when the layout decides the size and you care about rows and columns lining up, like a card grid or a page shell.

Candidates who have used both often say "grid for the page, flexbox inside the pieces", which is a reasonable default. Bonus points if you can explain what minmax() and auto-fill are doing in a responsive grid without looking it up, or when subgrid saves you from fiddly alignment hacks.

"This card looks wrong in the sidebar. What changed?"

This is my responsive design question. The card is fine on the main page and cramped in a narrow sidebar on a wide screen. Media queries do not help, because the screen is wide. I want to hear you notice that the problem is the container, not the viewport.

Container queries are the modern answer here, and they work in current major browsers. If you have not used them, it is fine to say so and talk me through how you would solve it otherwise. What I do not want is a plan to add a special class for every place the card might appear.

"Why is the dropdown behind the header?"

Stacking problems come up in almost every real codebase, and they make a good interview question because the obvious fix rarely works. Raising z-index to a huge number does nothing if the dropdown is trapped inside a parent that creates its own stacking context.

A strong answer names a few things that create a stacking context, like position with a z-index, transform, opacity below one, or isolation: isolate, and suggests checking the parents before touching the number. If you mention rendering the dropdown at the top level of the page, or using the browser's top layer for dialogs and popovers, even better.

"How would you style a parent based on its children?"

For a long time the honest answer was "you cannot, use JavaScript". Now :has() lets you write things like "style this form group differently when its input is invalid". I ask because it shows whether you have looked at what CSS can do today, and because the follow-up is interesting: when would you still keep that logic in JavaScript instead?

A thoughtful answer talks about readability and who maintains the code. A clever selector that nobody on the team understands is not a win.

"How do you keep CSS from getting out of hand?"

This is the senior question. I am not looking for a favourite methodology. I want to hear how you have dealt with styles growing over time: naming conventions, scoping styles to components, design tokens as custom properties, removing dead CSS, and agreeing as a team how overrides should work.

If you have strong views on utility classes versus CSS modules versus CSS in JS, great, but tell me the trade-offs you have actually lived with. "We used X and it was fine until Y" is far more useful than a sales pitch.

Answers that make me write a careful note

• Fixing every layout bug with fixed pixel widths and magic numbers.
• Using !important as the first move, not the last.
• Saying CSS "does not really matter" because the design system handles it.
• Not being able to explain a line of their own CSS from a take-home.

None of these sink an interview on their own. They are prompts for a follow-up, and "I would not do that now, here is why" is a perfectly good recovery.

How to prepare

Pick one page you have built and break it on purpose. Shrink the container, add a long word with no spaces, nest a dropdown inside a transformed card, add a second stylesheet that fights the first. Fix each problem and write one sentence about why it broke. That gives you real stories, which is what I want to hear.

Then practise explaining them out loud. CodePrepped's mock interviews and AI Trainer let you rehearse follow-ups like "why did that fix work?" before someone like me asks. If you are applying now, the shortlist scorecard shows what to work on before your next screen.

Do I need to memorise specificity rules?

No. Knowing that IDs beat classes and classes beat element selectors, and knowing where to check in developer tools, is enough. I care more about how you debug than whether you can calculate a score in your head.

Will I be asked to write CSS live?

Sometimes, usually something small like centring a box or building a simple responsive layout. Talk through what you are doing. A layout that is nearly right with clear reasoning reads better than one that is right by luck.

I mostly use Tailwind. Is that a problem?

Not at all. Utility classes are still CSS underneath. If you can explain what the classes are doing and how you would debug a layout that is not behaving, the tool does not matter.

Is CSS only asked about in junior interviews?

No. I ask everyone. The questions get more about architecture and team habits as the level goes up, but the basics come up at every level.