Question 1

What is an SCSS mixin?

Accepted Answer

Reusable block of styles included with @include, optionally parameterized — expands at compile time. Unlike functions, mixins can emit CSS declarations/selectors. Great for repeated patterns with hooks.

Question 2

Mixin vs function vs placeholder (%extend) — differences?

Accepted Answer

Functions return values; mixins emit CSS; placeholders share declarations via @extend with selector merging trade-offs. Prefer mixins for parametric CSS. @extend can create odd selector groups — use carefully.

Question 3

How do you pass content blocks into mixins?

Accepted Answer

@content directive lets callers pass nested CSS into the mixin wrapper (e.g., media query mixins). Powerful for breakpoint mixins. Document whether content is wrapped or merged.

Question 4

Argument defaults and keyword args in mixins?

Accepted Answer

Parameters can have defaults; call with named args for clarity on multi-arg mixins. Avoid long positional lists. Prefer maps for option bags when many flags exist.

Question 5

When is a mixin better than a duplicated class in HTML?

Accepted Answer

When the pattern is stylistic sugar without semantic meaning, or needs parameters per use. If it is a real UI component, prefer a component class over include soup. Mixins should not replace design-system components.

Question 6

Scenario: mixin outputs vendor prefixes still — problem?

Accepted Answer

Autoprefixer/Browserslist should own prefixes; mixins become stale and noisy. Remove prefix mixins from modern stacks. Keep mixins for design patterns not browser archaeology.

Question 7

How can mixins hurt CSS bundle size?

Accepted Answer

Each @include duplicates declarations; heavy parametric mixins can bloat output. Prefer shared classes or CSS variables for repeated values. Measure compiled CSS size.

Question 8

Write a clear API for a typography mixin.

Accepted Answer

Accept size/weight/line-height with defaults; map to tokens; avoid magic numbers inside. Centralize type ramp in tokens; mixin applies consistently. Expose responsive variants carefully.

Question 9

Mixin that optionally emits a modifier class — pattern?

Accepted Answer

Use parameters/flags or @content; or generate with @each over a map of variants. Generation from maps scales better than hand-maintained includes.

Question 10

Debugging: mixin undefined after @use migration.

Accepted Answer

Mixins are namespaced — @include forms.card or @use 'forms' as *. Forward public mixins via @forward with show/hide. Don't re-expose everything.

Question 11

Should mixins contain @extend?

Accepted Answer

Usually avoid — combining both increases complexity and surprising selector output. Keep mixins straightforward. Prefer composition of smaller mixins over clever extend chains.

Question 12

Compare mixins to CSS @apply (Tailwind) philosophically.

Accepted Answer

Both reuse chunks of declarations; Sass mixins are build-time and more programmable; @apply ties to utility frameworks. Choose based on stack. Don't mix three reuse systems without rules.

Question 13

Architecture: public mixin API for an SCSS library.

Accepted Answer

@forward selected mixins, document args, provide examples, and version breaking changes. Stability of mixin signatures matters like JS public API. Deprecate with comments/changelogs.

Question 14

Lead: reduce mixin sprawl across 50 repos.

Accepted Answer

Publish a versioned SCSS kit, codemod common includes, ban local copies of core mixins, and review new mixins centrally. Metric: duplicate mixin definitions. Prefer tokens plus fewer powerful mixins.

Question 15

Output thinking: @mixin center { display:flex; justify-content:center; align-items:center; } then .hero { @include center; } ?

Accepted Answer

.hero { display:flex; justify-content:center; align-items:center; } — declarations inlined. Simple includes are readable; still consider a utility class if reused everywhere.

Mixins SCSS Interview Questions

Other SCSS interview topics