My CSS/Front-end Competency Test (for Interviews)

Here I will outline the test I’ve conducted during the CSS portion of my interviews which I briefly mentioned in my article “The death of ‘front-end developers’”. To summarize for those who haven’t (and doesn’t) want to read that article, many “front-end” developers neglect HTML/CSS in practice. In an effort to efficiently gauge candidate’s competency:

I show interviewees some CSS selectors and properties that ranges from basic to competently complex and they’re to describe what they believe the CSS is doing.

Instead of having the interviewees creatively style a solution I want them to act as a browser and describe what the selectors, properties and values are doing. In addition to being more efficient, I found that the coding challenge not always accurate and frustrating to review as solutions came in various shapes and form.

I also think this type of testing has become more important than ever as the realms of front-end development becomes more muddy and writing CSS does not mean the same thing anymore with the growth in popularity of CSS in JS and CSS frameworks.

Enough with the prelude, how does it work

It’s very simple, I write a bunch of CSS rulesets and show them to the candidate and they just talk about what they think is happening. It’s very open and they talk as much as they want until they say, “done”. I always tell the candidates, “there’s no right answers, but there are wrong ones (jokingly)”. This is because the answers are relative to the candidate’s knowledge and competency. In addition to the CSS I also tell the candidate they can talk about assumptions they’re making about the developer, the project, business etc — I sometimes throw in coding habits I have and see if these are caught such as properties ordering, selector naming, and more. Why? Because I think these are habits of good developers. If you’re collaborating with others the first thing you’ll probably do is align on conventions.

Some Rules To Follow

Here are some rules I follow as the test is conducted:

• No reaction to the answers provided.
• No inline feedback.
• No followup questions to extract more from the candidate.

These are important to not influence the answer/direction the candidate is working towards. I’ve seen strong candidates (weak in CSS) able to talk through the logic and arrive at accurate answers on their own. I’ve also seen those who were wrong dig further than the point of no return. One candidate went on and on about how if you set a height in CSS you have to set a width and vice-versa or else the code will break — what?!.

There are exceptions to the last point if you have additional techniques/practice you want to uncover, what I deter from is asking questions such as “what else is happening…” as if they missed something.

The Warmup

I usually start with a few warm up(s) to get everybody comfortable with the format. I’d show something really simple:

h1, h2, h3, h4, h5, h6 {
 color: #333333;
}
a {
 color: #6cb5f4;
 text-decoration: none;
}

Setting up the colour for H1-H6 as well as the anchor colour and removing the underline — simple.

The Actual Race

Once warmed up, I’d jump into some layout techniques such as flexbox, grid and sometimes some classic position techniques. Here’s an example of one of the flexbox code that I might present.

.blocks {
  display: flex;
  margin: 0 0 40px;
  justify-content: space-between;
  .blocks__block {
    display: flex;
    flex-direction: column;
    flex-basis: 33.3333%;
  }
  .blocks__block--header-col {
    flex-shrink: 1;
    flex-basis: 200px;
  }
  a {
    margin-top: auto;
  }
}

An alternative to the above if I want to be more SASS-y:

.blocks {
  display: flex;
  margin: 0 0 40px;
  justify-content: space-between;
  &__block {
    display: flex;
    flex-direction: column;
    flex-basis: 33.3333%;
    &--header-col {
      flex-shrink: 1;
      flex-basis: 200px;
    }
  }
  
  a {
    margin-top: auto;
  }
}

This test will look at various flexbox properties and beheviours but also look at BEM naming and nestings— still straightforward enough, right? But as the tests progress I start to sprinkle in other things that are not as obvious. For the example above:

• The .blocks__block--header-col as a modifier is actually nonsensical relative to the other blocks.
• There’s a property out of order (hopefully obvious by now primed by previous tests).
• The blocks aren’t actually 3 x nth row since flex-wrap by default doesn’t wrap.

There are definitely more one could point out if they want to be nit-picky such as the placement of the anchor selector or it could have a BEM named selector too as there could be more than one link in the block. As I mentioned there’s no single right answer, the candidate can keep talking as they wish and that will serve to paint a picture of their competency and experience with CSS.

The Last Lap

Depending on time and how well the candidate does following up to this I do have more complicated properties/value variations, selectors and SASS for example:

// @at-root test
.section {
  @at-root {
    h2#{&},
    h3#{&},
    h4#{&},
    h5#{&} {
      ...
    }
  }
}
// CSS Variables with SASS Variables
.block {
  --block-bg: #{$gray-300};
}

Highly Customizable

There is no limitations to the type of tests you could write. If you’re looking for a developer strictly skilled in supporting some legacy IE shit, throw in some IE hacks. If your projects are all Bootstrap/Tailwind based then test on configuration, utilities modification and output. You could even write CSS-in-JS tests. The only limitation is that this is all focused and tested on CSS. I’m not sure if it’ll be effective for anything else, although recently I’ve been thinking about doing this for HTML DOM structure, but since I haven’t been doing interviews for a while I haven’t had the need.

Is it perfect?

Definitely not, but it works (for me). Of the candidates that I recommended and did end up working with I was accurate in my evaluation — not the fact that they were able to output “pixel perfect” code but they understood CSS and was able to write competent code. That being said this is only a section of an interview that I’m typically part of, there’s usually a CSS discussion portion and others to interview for other skillsets, cultural fit, on and on. A strong candidate will not be dependent on succeeding on this test alone.