What do you like and dislike about CSS preprocessors?

The short answer

Preprocessors like Sass added features that CSS badly needed — variables, nesting, and reusable mixins. But they also introduced complexity: a build step, debugging difficulty, and temptation to over-nest. Now that CSS has native variables and nesting, the case for preprocessors is weaker than it used to be.

What I like

• Variables made it easy to maintain consistent colors, spacing, and fonts across a large codebase
• Nesting let you write styles that mirror the HTML structure, making them easier to read
• Mixins allowed reusable style blocks, reducing repetition
• Partials and imports helped organize large stylesheets into manageable files

What I dislike

• Build step — you cannot just open the CSS file and edit it. You need a compiler running
• Deep nesting — it is easy to nest too deep, creating overly specific selectors that are hard to override
• Debugging — the CSS in the browser does not match your source files. Source maps help, but it adds complexity
• Team dependency — everyone needs to know the preprocessor syntax

The shift to native CSS

Many preprocessor features now exist in native CSS:

• CSS custom properties replace Sass variables (and they are more powerful because they work at runtime)
• CSS nesting is now supported in modern browsers
• @layer helps manage specificity
• @scope provides scoping

For new projects, you might not need a preprocessor at all. For existing projects that already use Sass, there is no urgent reason to migrate away.

Why interviewers ask this

This tests your CSS experience and your ability to evaluate tools critically. Interviewers want to hear a nuanced opinion, not just "I like it" or "I do not like it." Having opinions about CSS tools shows you have used them enough to form those opinions.