Anatomy of a frontend tech interview

Raoul George
Sep 6, 2018 · 5 min read
Photo by Markus Spiske on Unsplash

There are a plethora of articles on what to expect in a frontend tech interview. But not too many opinions on how exactly to conduct a great interview.

Front end tech interviews these days are a mess. From asking potential candidates a slew of syntax oriented questions, to expecting them to implement Ukkonen’s algorithm in 15 minutes, most interviews don’t really focus on the right skills to test.

A typical frontend interview consists of questions that test Javascript, HTML and CSS.

These are the skills that I would usually test a frontend developer on-:

  • A simple fizzbuzz problem to set the ball rolling.
  • A small algorithm/data-structure problem. Nothing too complex.
  • Ability to write object oriented JavaScript.
  • Questions pertaining to typical problems that a FED is bound to have experienced - asynchronous requests, change detection, DOM manipulation, inadvertent closures etc.
  • Design patterns and separation of concerns.
  • Writing structured, readable CSS.
  • understanding the importance of concise, semantic HTML.
  • Unit testing
  • Tooling IE. Webpack/grunt/gulp

Fizzbuzz

I usually start with a simple fizzbuzz problem. This accomplishes two things -:

  • Allows the candidate to relax a bit as 9/10 programmers will be able to solve this.
  • Acts as a gatekeeping question to weed out people who have atleast done some level of coding versus the pretenders

Getting that first question correct always provides a moment of relief to the candidate and eases nerves.

Object oriented javascript

Most people underestimate the power of OOPS in front end development. In a world where we inherited codebases with 1000’s of lines of spaghetti jQuery strewn around, using basic object oriented concepts brings some method to this madness.

This is when I usually ask some basic questions about classes, objects, inheritance, encapsulation, polymorphism. A good way to test a candidate’s familiarity with these concepts is to ask him to build a class modelling a real world problem and then slowly deep-dive into how to go about implementing these concepts into the class definition and implementation.

Structured CSS

CSS skills are an other overlooked piece of the puzzle. Usual CSS questions revolve around concepts like the box-model, positioning etc. However, I see most value in understanding how the candidate has wrestled with the problem of writing maintainable css. Preprocessors like SASS/LESS are commonly (mis)used, but following certain coding guidelines make things a lot more organised. This is what I usually evaluate when it comes to CSS.

System design

This part is what I consider one of the most important skills that an experienced FED must possess. OOPS and CSS are skills that one can pick up by doing some amount of research. But designing a system from scratch is something that can only be learnt by experience. Understanding how to structure your codebase, conceptualize the different components that make up your application, deciding which one of the several JS frameworks to go with and why, taking care of messaging, routing, eventing, server side rendering, performance and the list goes on.

I like giving the candidate a problem statement and then sitting down with him as a peer and figuring out the best solution to it. This not only tests the hard skills above, but also serves as a great indicator of your prospective colleague’s attitude and interpersonal skills.

Familiarity with atleast one JS framework

Too many choices(image credit: brewhouse.io)

The JS ecospace is flooded with frameworks and I don’t expect any developer to know all of them. Having said that, I would be hard pressed to call someone a modern front end developer if he has never worked with a framework or library before ( jQuery doesn’t count).

This is where I like to understand which framework he has worked on and the reasons why he chose that framework. Choosing the right framework for your application is an important decision — from valuing an opinionated framework like Angular which comes bundled with the everything and kitchen sink, to a more flexible library like react or vue which leaves a lot of the decision making to you, but also lacks in other areas like routing etc.

ES6

Surprisingly, a lot of very senior JS Dev’s ( > 10 years of experience ) haven’t really adopted ES6 and the massive number of quality-of-life features it provides. Again, I don’t expect them to know about every single piece of syntax here, but concepts such as object spreading, destructuring, arrow functions are a few things that a frontend developer must know about in 2018.

Unit testing

This can be a contentious point when it comes to front end development, but I always prefer a candidate who has worked on and believes in the value that good unit tests bring to the stability of an application, rather than someone who thinks its a waste of time.

I usually ask the candidate to write some unit tests for the fizzbuzz problem above and this gives me a chance to understand his opinion of unit testing.

Conclusion

So these are the usual topics I like to discuss with potential candidates.

At Sixt R&D, we look at hiring the right people who can tell us what to do rather than wait to be told what to do.

Always remember, it is not just your potential candidate who is being judged, but opinions will be formed about you and the company you work for based on the quality of your interviews.


The views, thoughts, and opinions expressed in this article are my own, do not necessarily represent or reflect the views of Sixt

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade