Tailwind CSS Interview Questions

Tailwind questions at 4+ years are rarely about remembering class names. Interviewers want to see that you know how the tool works, so you can explain why a class is missing, why one class beat another, and how to keep a large codebase tidy. They also check that your knowledge is current. Tailwind v4 changed the setup, the config and the names of many classes, and a lot of old interview material is now wrong.

I ran every Tailwind behaviour in this lesson with Tailwind 4.3.3 and compiled the TypeScript with TypeScript 7.0.2. The browser features behind Tailwind (cascade layers, container queries) are explained in HTML & CSS, Lesson 01. The typing side of cva is in TypeScript, Lesson 03.

Words used in this lesson

• Tailwind CSS is a CSS framework that gives you small single-purpose classes, so you build a design by putting many of them on an element. It is not a set of ready-made components.
• A utility class is a class that sets one thing, such as p-4 (padding) or text-center. Utility-first means you style by combining utility classes in your markup, instead of writing a new CSS class for each component.
• A design token is a named design decision, such as "brand colour" or "medium spacing". Everyday comparison: a paint swatch with a label, instead of a colour mixed by eye each time.
• A CSS variable (also called a custom property) is a name that holds a value in CSS. You write --brand: red; and read it with var(--brand). The browser resolves it while the page runs.
• A variant is a prefix that makes a utility apply only under a condition, such as hover:bg-blue-600 or md:flex.
• A cascade layer is a named group of CSS rules, made with @layer. The browser compares layers before it looks at selector strength, and later layers win. Rules that are not in any layer beat all layered rules.
• A container query is a CSS rule that depends on the width of a parent element, not of the whole window.

What changed in v4

Tailwind v4.0 came out in January 2025, and the current version while I wrote this is 4.3. Many tutorials still describe v3. Remember this table.

CSS-first config: @import "tailwindcss" and @theme

Theme variables are special CSS variables, defined inside @theme, that change which utility classes exist. This is the central idea of v4.

@import "tailwindcss";@theme {  --color-brand-500: oklch(0.62 0.19 259);  --font-display: "Satoshi", sans-serif;  --breakpoint-3xl: 120rem;}

Now bg-brand-500, text-brand-500, font-display and a 3xl: variant exist. The name prefix (the namespace) decides what a variable makes:

Three things to know:

• Extend or override. A new name adds a utility. Redefining a default name (--breakpoint-sm: 30rem) changes it. --color-*: initial; removes every default colour. I checked that bg-red-500 then makes nothing.
• Only used variables are written. I defined --color-unused-500 and used nothing from it. It was missing from the output CSS. @theme static { ... } forces all of them out.
• @theme inline is for a theme variable that points to another variable, such as --color-primary: var(--primary). Without inline, the utility reads --color-primary, which was resolved where it was defined. A different --primary set on an inner element would not be seen. With inline, the utility gets var(--primary) directly. I compiled it: bg-surface became background-color: var(--surface).

Why @theme and not :root? @theme makes a CSS variable and the classes for it. :root { --x: 1 } makes only a variable. Use :root for values that should not become classes.

How utilities get generated (the engine)

Tailwind v4 has a new engine called Oxide, whose scanner is written in Rust. Tailwind's changelog says full builds are up to 5 times faster and incremental builds (rebuilds after a small change) are over 100 times faster. Those are Tailwind's numbers, and I did not re-measure them.

The key point for interviews is how it finds classes:

1. It reads each source file as plain text. It does not parse or run your code.
2. It takes every word that could be a class name.
3. For each word it asks: "Do I know a utility with this name?" If yes, it writes the CSS. If not, it ignores the word.

That is why Tailwind can make bg-[#316ff6] on demand, and why the output stays small.

Automatic content detection is this scanning with no file list. It skips files in your .gitignore, node_modules, binary files, CSS files and lock files. You can change that:

@import "tailwindcss";@source "../node_modules/@acme/ui";           /* scan a package that is normally skipped */@source not "../src/legacy";                  /* do not scan this folder */@source inline("{hover:,}bg-red-{100,200}");  /* always write these classes (a "safelist") */

@import "tailwindcss" source(none) turns detection off, and source("../src") sets the folder to scan, which helps in a monorepo (many projects in one repository). I checked that @source inline(...) wrote bg-red-100, bg-red-200 and their hover: versions although no file used them.

Why dynamic class names break

Because the scanner reads text and never runs your code, it can only find class names that are written out in full.

// BROKEN: the scanner sees "bg-", "-600" and a variable. It never sees "bg-red-600".function BadgeBroken({ color }: { color: "red" | "blue" }) {  return <span className={`bg-${color}-600 text-white`}>New</span>;}// WORKS: every full class name appears in the source as text.const colors = {  red: "bg-red-600",  blue: "bg-blue-600",} as const;function Badge({ color }: { color: keyof typeof colors }) {  return <span className={`${colors[color]} text-white`}>New</span>;}

I tested both. The template string made no CSS. The lookup object made both classes. The same is true for text-{{ error ? 'red' : 'green' }}-600 in any template language.

If a value truly arrives at run time, from a database or a user setting, no class can work. The docs suggest an inline style, or a CSS variable that a static class reads:

<button  style={{ "--bg": brandColor } as React.CSSProperties}  className="rounded-md bg-(--bg) px-3 py-1.5 hover:opacity-90"/>

Arbitrary values, properties and variants

An arbitrary value is a one-off value in square brackets, for when the scale lacks what you need: w-[calc(100%-2rem)], bg-[#316ff6], grid-cols-[1fr_500px_2fr].

• Spaces are written as underscores: grid-cols-[max-content_auto]. (In v3, commas became spaces. In v4 they do not.)
• CSS variables use round brackets: bg-(--my-var). If the type is unclear, add a hint: text-(length:--my-size) or text-(color:--my-color).
• Arbitrary properties set any CSS property: [mask-type:luminance].
• Arbitrary variants write a selector in the class: [&_p]:mt-4 means "every p inside this element gets a top margin" (& is the element, _ is a space).

Variants worth knowing

A variant is a prefix, and prefixes stack. In v4 they read left to right, like CSS (*:first:pt-0; v3 used the opposite order).

<!-- Switches to a row when ITS OWN width is large, not the window's --><div class="@container">  <div class="flex flex-col gap-4 @md:flex-row">    <img class="size-16 rounded-full" src="/a.png" alt="" />    <p class="text-sm">Looks right in a narrow sidebar or a wide column.</p>  </div></div>

Difference in one line: md: asks "how wide is the window?"; @md: asks "how wide is my container?".

For dark mode with a toggle (a .dark class on a parent), override the variant once:

@import "tailwindcss";@custom-variant dark (&:is(.dark *));

I compiled this, and dark:bg-black became .dark\:bg-black:is(.dark *).

Layers: where custom CSS and @apply fit

Tailwind v4 uses real cascade layers in this order: theme, base, components, utilities. Later layers win, so a utility beats a component rule with no trick.

There is one trap. CSS that is not in any layer beats all layers. I compiled this and read the output:

/* NOT in a layer: written after the utilities layer, so it beats utilities */.btn { @apply rounded-lg px-4 py-2; }/* In the components layer: utilities can override it */@layer components {  .card { @apply rounded-lg p-4; }}

So <div class="btn rounded-none"> stays round, but <div class="card rounded-none"> is square. Put your own component classes in @layer components.

For a new utility, use @utility. It works with every variant, so md:tab-4 exists automatically:

@utility tab-4 {  tab-size: 4;}

What does @apply do, and when should you avoid it?

@apply is a directive that copies the CSS of existing utilities into your own CSS rule. It is useful for styling HTML you do not control, such as a third-party widget or Markdown that comes from a database.

Avoid it as your main way to reuse styles:

• You are back to naming things and jumping between files, which utility-first tried to remove.
• In v4, a CSS module or a Vue/Svelte <style> block is built alone and cannot see your theme. You must add @reference "../app.css"; at the top.
• Tailwind's docs rank the options for reuse: render in a loop, edit with multiple cursors, make a component, and only then write custom CSS.

cn(), clsx, tailwind-merge and cva

These three small libraries are in almost every React and Tailwind project. People mix them up.

• clsx is a function that joins class names and skips false values: clsx("a", isOn && "b"). It knows nothing about Tailwind.
• tailwind-merge (function twMerge) is a function that removes conflicting Tailwind classes, so the last one wins. It knows that p-4 conflicts with px-2.
• class-variance-authority (cva) is a function that builds a class string from named variants such as intent="danger", and it makes the prop types.

Most projects copy this helper:

import { clsx, type ClassValue } from "clsx";import { twMerge } from "tailwind-merge";export function cn(...inputs: ClassValue[]) {  return twMerge(clsx(inputs));}

Why is it needed? When two classes set the same property, the browser does not use the one written last in the class attribute. It uses the one that comes later in the generated stylesheet. I compiled class="p-4 p-2 grid flex". p-4 won over p-2, and grid won over flex, in any written order. So a component that does "p-4 " + props.className cannot be overridden safely. twMerge fixes this by deleting the loser.

Results from tailwind-merge 3.7:

A button with cva, cn and types (this compiled with React 19 types):

import type { ComponentProps } from "react";import { cva, type VariantProps } from "class-variance-authority";import { cn } from "./cn";const buttonVariants = cva(  "inline-flex items-center justify-center rounded-md text-sm font-medium disabled:opacity-50",  {    variants: {      intent: {        primary: "bg-blue-600 text-white hover:bg-blue-700",        danger: "bg-red-600 text-white hover:bg-red-700",      },      size: { sm: "h-8 px-3", md: "h-10 px-4", lg: "h-12 px-6" },    },    compoundVariants: [{ intent: "danger", size: "lg", class: "uppercase" }],    defaultVariants: { intent: "primary", size: "md" },  },);type ButtonProps = ComponentProps<"button"> & VariantProps<typeof buttonVariants>;export function Button({ intent, size, className, ...props }: ButtonProps) {  return <button className={cn(buttonVariants({ intent, size }), className)} {...props} />;}// <Button size="huge" />  -> compile error: "huge" is not a valid size

Note the order: variants first, then the caller's className, all inside cn. That lets className="px-10" replace px-6. If you pass className into buttonVariants, cva only appends it. I tested that: px-6 and px-10 both stayed. Only cn removed the loser.

Limits of tailwind-merge (its own docs list them, so they make good senior answers):

• It must know your theme. After you add --text-huge, twMerge("text-lg text-huge") keeps both. I ran it. Configure it with extendTailwindMerge({ extend: { theme: { text: ["huge"] } } }), and the result is text-huge.
• It guesses. An unknown size such as text-2xs is treated as a font size, so twMerge("text-sm text-2xs") drops text-sm, even if your text-2xs does something else.
• It costs bytes. Its docs say about 5 kB of its roughly 7 kB (minified and gzipped) is the rule table. A call took about a thousandth of a millisecond in my test, so speed is rarely the problem.
• It gives callers a lot of freedom. For fixed internal classes, twJoin (join without merging) is cheaper and clearer.

Design tokens, theming and shadcn/ui

A good setup has two levels of tokens:

1. Raw values: --color-blue-600. They say what it is.
2. Semantic tokens: --primary, --background, --border. They say what it is for. Components use only these.

shadcn/ui is a set of React components that a CLI copies into your project, so you own the code. It uses Radix or similar libraries for behaviour and Tailwind for style. Its CSS shows the two-level idea:

@import "tailwindcss";@custom-variant dark (&:is(.dark *));:root {  --background: oklch(1 0 0);  --primary: oklch(0.205 0 0);}.dark {  --background: oklch(0.145 0 0);  --primary: oklch(0.985 0 0);}@theme inline {  --color-background: var(--background);  --color-primary: var(--primary);}

Now bg-background and text-primary work, and components need no dark: prefix for those colours. Changing the theme means changing the variables under .dark. @theme inline is needed so the variable is read where it is used, and a .dark or brand block on an inner element is seen. For white-label customers, set the same variables under [data-brand="acme"]. No component changes. Its Button also sets data-slot="button", so parents can target it in CSS, and in React 19 it takes ref as a normal prop (no forwardRef).

Migrating from v3 to v4

My plan:

1. Check browsers. If you need older ones, stay on v3.4.
2. Make a branch and run npx @tailwindcss/upgrade (needs Node 20+). It updates dependencies, moves the config to CSS and renames classes in your templates.
3. Read the diff and look at the pages. Some changes are visual:

4. Replace postcss-import and autoprefixer with @tailwindcss/postcss (or use @tailwindcss/vite).
5. Keep the old JS config with @config while you move tokens to @theme. safelist, corePlugins and separator are not supported.
6. Sass, Less and Stylus are not supported. Tailwind is the preprocessor.

Performance

• Build time: the new engine is much faster. Do not point @source at huge folders.
• CSS size: only used utilities are written, so the file stops growing as features grow. Each arbitrary value adds a rule.
• Runtime: none. It is plain CSS, with no Tailwind JavaScript in the browser.
• Selectors: space-* and divide-* got a cheaper selector in v4 because the old one was slow on large pages.
• @apply in many files: Tailwind must process each rule. Using theme variables directly (color: var(--color-red-500)) avoids that work.

The criticisms of Tailwind, and fair answers

Be honest about the cost: a design change across 100 files is easy only if repeated markup was made a component.

Accessibility with Tailwind

Tailwind does not make a site accessible or inaccessible. Your markup does. But some classes are easy to misuse:

• Never remove focus without a replacement. v4 outline-none sets outline-style: none, and keyboard users lose the focus mark. Use focus-visible:outline-2 focus-visible:outline-offset-2. outline-hidden hides the outline in normal view but keeps it in forced-colours (high-contrast) mode.
• sr-only hides text visually but keeps it for screen readers. Use it for icon-only buttons: <span class="sr-only">Close</span>.
• motion-reduce: turns off animation for people who asked for less motion.
• Do not use colour alone, and check contrast for each colour pair (4.5 to 1 for body text). text-gray-400 on white fails.
• Style from state attributes (aria-expanded:, aria-invalid:), so the look follows the real state that assistive tools also read.
• hover: is an extra. Never put important information only in hover.

Common mistakes

1. Building class names from pieces (bg-${color}-500).
2. Writing custom CSS outside @layer, then wondering why utilities cannot override it.
3. Using @apply for everything, then needing @reference in every module.
4. Not using cn(), so a className prop cannot override defaults. Or passing className into cva() and expecting a merge.
5. Forgetting to configure tailwind-merge after adding custom tokens.
6. Copying v3 advice (content arrays, @tailwind base, outline-none as a reset).
7. Raw colours everywhere instead of semantic tokens.
8. Relying on class order in the class attribute. The stylesheet decides.

Interview questions

Key takeaways

• Tailwind v4 is CSS-first: @import "tailwindcss", @theme, @utility, @custom-variant. A JS config is not found automatically.
• It scans files as text, so class names must be written in full. Dynamic names break. Use lookup objects, cva, @source inline(...) or CSS variables.
• @theme makes variables and utilities. @theme inline is for variables that point to other variables, which is how theming works.
• Between two conflicting utilities, the one later in the stylesheet wins. Use cn() (clsx + tailwind-merge) in components, and configure tailwind-merge when you add custom tokens.
• Put your own component CSS in @layer components, because unlayered CSS beats utilities. Prefer components over @apply.
• Know the v3 to v4 changes: renames, new defaults, hover only on hover devices, browser baseline.
• Keep accessibility visible: focus styles, sr-only, motion-reduce, contrast and state attributes.

What's next

Lesson 03: TypeScript Interview Questions. You just typed a cva button. Next: what changed in TypeScript 6 and 7, the tsconfig flags that matter, module settings, type-safe API layers, and the errors that confuse people.