CSS Interview Questions 2025 (Junior & Mid) - Part 2

Imagine you go to five interview stages and nail all the 10-cal interviews, just to fail in the last interview because you don't know how to center a simple div. Today, we will answer the top most ask CSS interview questions, you'll also find out just how much CSS should a JavaScript developer learn, a simple trick you can apply right now to solve any CSS interview question you get, and the number one mistake developers make when answering CSS interview questions.

Now, why is learning CSS so frustrating for JavaScript developers? Well, CSS is hard because most developers think it's easy. You see, when learning a proper programming language, like JavaScript or Java, you expect it to be hard, you have to learn loops, variables and functions. But CSS it's very easy to start with, which is why developers never put the time and effort into understanding how it works.

They confuse easy with simple. The first thing you want to do before your next CSS interview question, it's a mindset shift. Yes, CSS is simple, but it's not easy. Now, let's move on with the first CSS interview question. Bodan, are you ready? Yes, let's go. Awesome, first question is, what is critical CSS? Critical CSS, it's the minimum CSS we need in order to render a first view of the web page when the user lands on it. And so basically, it's everything you need to display that that first uh thing they see and it's extremely important when it comes to web performance, you want to extract only the critical CSS and load only that CSS, because in big applications, if you were to load and render and parse all the CSS, you will end up having a very uh slow application and um your core web vitals, as they call them, they would they'll basically suffer.

Now, how can we extract that critical CSS in a normal JavaScript application? Let's say I have a react app and I want to make sure that the critical CSS is extracted and it's upper way. Uh so. the way you extract that it's you can use plugins for your module bundler that will actually render the page for a specific view port. You basically can specify the resolution and then we'll try to calculate using browser trolling.

They usually use poppeteer under the hood, um, and they'll try to calculate what is your CSS coverage? Basically, which CSS is actually being used and they'll extract that in a separate file, um, and then the module bundler would be able to load only that one file. Then render the whole page and then load the rest of the CSS. The reason we do this is because CSS is a global namespace where built to really load all the CSS that you specify in your head tag, all those links before they proceed with the rendering.

So as we like to say, is that CSS it's render blocking. That's why we want to load as little as possible in that initial page render. Awesome and by module bundler, I guess you mean Webpack or the Webpack config, right? Where we can specify that. Exactly. Awesome. Okay, well now let's move on with question number two, how do we create a mobile responsive layout without without using media queries?

So if we cannot use media queries, it means we cannot really specify different CSS properties for different widths. So we will probably have to find a way to tell the browser to calculate sizes itself. The way you could go about it, it's probably I would start with flex box or grid. Oh basically flex would allow you to float elements for many different device sizes without having to specify that. That would be number one.

I would probably try to use RAM and all the other relative sizing units for sizes of fonts and elements. Don't use pixels as a specification for sizes. Uh, so that would be number two, and I think with that you should be already pretty well set. Yeah, with these two things. Of course, I think there's one or two more things we could do with the images where we can specify the max width so they would fill up the space and so on.

But these two things. So basically using flex agreed, and then using relativizing for our element. Very nice, Bogdan. Now we're going to move on with question number three. This is one of the most asked CSS questions, and that is what are pseudo elements in CSS and what are pseudo selectors? If you could provide an example as you explain these things, it would be amazing. Pseudo elements are basically uh different elements that you can use in CSS to select, for example, the last part of a um element or for example, if we're talking about a paragraph, the first letter of that paragraph or the first line. So you're basically specifying those with double colon, um, and you are able to add content to it or to highlight it. So they're very good if you want to, for example, make the first letter of a paragraph bigger than the rest. Right, that's one of the things you can use it for, or highlight a specific part of a paragraph. You can use a pseudo element. And then for the pseudo selectors, I guess you're referring probably to pseudo classes, which are just the ones we can use to, for example, change the color of something when we hover with the mouse on top of it. So hover, it's one of them, active, it's another one of them, but there's a couple of them. Okay, Bogdan, next question, I sent you a code snippet. Could you just pull that up on the screen? Excellent. So, I want you to translate the following selector to plain English. Yes, you're referring to this one, uh, so I would say this would be select, we are selecting a P, okay, so we're selecting a P element. and we have a, we have an attribute, it's data type, attribute, attribute highlight, uh, Oh, but this is not equal. This is a matching selector, so I think this is probably starts with or contains. So I would say it's probably starting with, so we select a P element with data type with a data type attribute that starts with highlight and it must be

inside of a section, so inside of a section that is a child of an element with class article. Okay, let me give you this really quick class article. Can you just for us to to get a full picture on the screen? Yeah. Um so yes, so basically it's it's a P element that will have an attribute data type that starts must start with highlight. So it could be like highlight minus something, but it has to start with highlight.

It it is inside section, but it doesn't have to be a direct child. So, if we have this, I guess it will be a direct child. But it it just has to be like at some point, one of the parents of this P should be a section, but in the case of the section, there has to be the parent needs to have the class. article. And this brings me to the main mistake developers make when learning CSS. is that they get too distracted by media queries and so the elements and all these fancy words, instead of focusing on the fundamentals first.

By simply getting a good understanding of the box model and of CSS specificity and selectors, just like Bogdan did, you will be able to solve most CSS problems you face. And you can learn about both in the part one of this video, which you can see right now at the top of the screen. Now, now, even if you know these things, CSS might still be tricky. That's because in CSS, hundreds of properties interact with each other. Just like Bogdan said, CSS is a global language.

Which means it can be a bit hard to predict what happens. A rule of thumb to get unstuck in those situations is to never be more explicit than you need to be. Writing good CSS code means leveraging what's already there instead of overriding it. For example, use percentages instead of media queries or use min-width instead of width. And now on to CSS interview question number four, how would you create a dark team for a website using only CSS?

Could you demo that for me quickly? Sure. So I created one of those before using JavaScript. If I only had to use CSS, I'd probably go for custom CSS variables that are supported now. Um in most browsers. And I guess most of the teaming we can do with a bunch of colors, which would be color and background color. So, we can use a pseudo class, like the ones we discussed before, which would be root, and this will basically create a sort of a wrapper around our CSS and provide it provide us variables globally.

So in any CSS in this file now we can use this variables. And I would probably declare, um let's say this will be our main color. Um and in this case it will be red. And then um you can have like a secondary color and let's say this is blue. And basically right now, in the web page, I will just use this everywhere. So I see there's an H1, and we can start to style this H1 we see. And for the H1, let's say the color would be like the main color.

So we can use var, which is a CSS function, and provide the name of the variable. And tada, now it's good. And then the only thing we would need to do to switch team would be to either link this to um the browser default team, which sometimes relies on the operating system of the user. And then give the user the opportunity to change this. But probably there we need a bit of JavaScript to just manipulate the DOM and change the value of those variables.

Following up on that, how are CSS variables different from variables in CSS preprocessors like SASS or less? Um the biggest difference would probably be would probably be that you can change CSS variables and they are they are actually uh present at runtime versus SASS or less which are presented at build time. So in SASS or less, whenever we specify variable, once we compile our SAS files to CSS, that variable disappears and it basically gets replaced with the actual value. So those variables don't exist at a runtime.

When it comes to custom variables in CSS, they're always there. And that's why we're able to switch theme um whenever the user does something, rather than we wouldn't probably be able to do that with Sass unless. We'll actually have to use classes with something else to have this change in the variable value. So those variables are not really variables actually because they are being injected and once they're injected, they're actually not variables anymore, right? Exactly. Amazing Bogdan, final CSS interview question of this series. Can you explain how CSS in JS works under the hood? Um, sure, so CSS in JS is basically a tool that allows us to write CSS styles in JavaScript files. And the magic that happens with the module bundler that will pick up those styles and create unique class names based on those styles. So, basically it appear because we were having all these issues with, for example, class names, you're building a button, let's say, and you create a class, button, red, and somebody else in your team. Uh it's using the same class name for a totally different component, you then end up having all those conflicts and it'll be hard to figure them out because everybody, it's kind of working on their own components. We try to have components as isolated pieces of code. But CSS is a global namespace. So, whenever we were trying to add the selectors there, we will somehow couple our components. We defeat the whole isolation and reusability idea. So with CSS in JS or CSS classes get a unique name based on the hash, which as far as I know, Webpack generates based on the file name where you are. So you basically make sure it's always unique, and that guarantees the fact that the CSS you write for your specific file, it's really specific and scoped to your file and you won't affect any of the other CSS classes in the project. Is there any other advantage of have of using CSS in JS? Well, that big advantage I see is the fact that you can have very quickly dynamic styles. Because you have this styles now in the JavaScript file, we can always use variables to compute your styles. And you can very easily add interactivity, so when somebody clicks a button, you can make

kind of change colors very easily. It used to be a bit harder when you had your CSS in a CSS file, you had to look up in the CSS file and then code something in JavaScript, and then you have all these dependencies all over the place because there will be JavaScript code that you need to read and then you need to read the CSS file to see what these two things do together, whereas now you can do everything in your single component. Um okay, now two things I would like to know. It's number one, um, you know, is there any library that you recommend that you worked with that you have experience with working with CSS in JS? And and number two, cool, I mean it seems like CSS and JS has a lot of advantages, the scope isolation, the dynamic styling. Um, but what are some of the disadvantages when when choosing to use CSS and JS? So for question number one, I used pretty much all the time style components. Uh it was one of the main libraries that brought CSS JS to React. There's many libraries out there, but style components was one of the easiest and I would say the most popular one. And number two, when it comes to disadvantages, probably one of the biggest disadvantages in the beginning used to be debugging. Again, because you have all these unique hashes as CSS classes that get injected at uh build time. It's not so easy when you look at your dome and you like generated uh document object, you generated HTML by based on your JSX. It's not so easy to understand which was the CSS class that you need to change. Uh however, in style components you can now actually have a mix of a hash and the original CSS class name you gave. So that makes things a little bit easier. And of course, because you preprocess all this in your module bundler, you also add a bit more work for the module bundler to do when it builds the project. The other disadvantage and you need to be uh you need a special setup here, it's when we do server side rendering because the styles we render on the server have to match the styles on the client. So somehow you want to really do this CSS injection once on the server and make sure whenever we render on the client, we reuse that same style sheet.

Because if you run the algorithm again, it will maybe generate a different hash and then your styles won't match. Yeah, that's what makes SSI so complicated. Right now, you have the state that has to match for the rendering then you're adding CSS and then you realize oh actually maybe we weren't made to serve to to render on the on the server first, maybe. You know, we are doing things back things backwards, but that's a question for another video.

Now, for the people watching us, in order to properly understand CSJS, you also need a solid understanding of JavaScript first, module bundler, and of course, webpack, which is exactly what we talk about in this next video. With that being said, thank you for watching, if you are interviewing right now, check the description of this video, we have a bunch of resources including a free 10-call assessment for you to find out your gaps and better prepare for your next tech interview, and we will see you in the next one.