At just over a decade of experience of frontend-focused work, I’ve encountered a number of different interview styles – from the pop-quiz ‘Describe the array prototype methods’ style questions, to the tedious ‘create a todo list in React’. But I’ve never experienced an interview style like the one we hold for frontend-focused engineers at Plain.

Unfortunately your interview was not successful at this time...

Originally, it was a standard question/answer-style interview which let candidates demonstrate a good breadth of knowledge across a number of frontend concerns. But we found it often fell short in showing us how they would use this knowledge to make decisions and didn’t offer them the opportunity to show all of their knowledge if it wasn’t covered in the specific set of questions we asked. 

Following this, we moved to a take-home exercise as this would let candidates have that flexibility to shine and show us practical examples of their skillset. For successful candidates here, we’d review their code together over a call – but this was particularly onerous on both sides, and candidates would often spend up to double digit hours (even though we asked them not to!). We’d end up spending a significant amount of time ourselves reviewing it and coming up with bespoke questions for each solution provided.

We kept trying to iterate on our this interview, and we started providing a base codebase for them to work with to hopefully reduce time spent and avoid debugging issues like API key, but it just wasn’t hitting the mark. Candidates would still spend far too much time working on it and we’d do the same in reviewing it.

... But please try again in the future

During this time, the backend interview had remained relatively stable and successful – it’s a pretty standard fare systems design interview which has netted us some fantastic engineers. It was only when I had the opportunity to co-host some of these interviews that I realised we could actually do something very similar for the frontend.

Lo and behold, our frontend ‘systems design’ interview was born. We give the candidate an unfamiliar problem and let them adapt their existing knowledge to architect a solution. I recognise that many frontend engineers might not be experienced with this style of interview, so often we walk through it together. We guide them with questions such as what framework they’ll use, what their approach to styling will be, what browser APIs they’ll be using, how will they invoke any backend services etc…

Choosing the problem to solve is the real magic here, you want something that won’t be completely alien but is unusual enough to require some variation from their standard boilerplate approach. They might reach for websockets instead of HTTP requests, server-side rendering or not, localStorage over cookies, Tailwind vs CSS-in-JS etc…

The ideal candidate is going to have many such considerations and ultimately make a choice with a solid justification demonstrating their breadth/depth of knowledge, their problem solving skills and their flexibility.

The open-ended nature of this interview style means you can really hone in on an area where a candidate is particularly passionate or knowledgeable, you can introduce additional requirements which may make them discount their original choices entirely or you can test their product chops by getting them to go into details about the UI/UX.

Congratulations! You're hired

Ultimately, one of my favourite aspects of this interview style is that it really engages the interviewer and not just the candidate. I often have to adapt my questions to the choices the candidate is making, I may think their solution is incorrect and have to discuss that in a respectful manner, or they may talk about a technology or approach I’m completely unfamiliar with and I’ll have to ask them about it and intuit new questions from their explanation.

Having an engaging interview process as an interviewer is very important to me, as the technical interview is not just a barrier to employment but is often the first impression the candidate will have of the team they’ll likely be working with day to day. Plus I’m there for just as many minutes as the candidate is, so I might as well enjoy myself too.