Front-End Engineer / Developer Interview Questions

Throughout my career, I have interviewed lots of front-end developers, possibly in the hundreds. Below are some of my favorite questions to ask and why. Most of these have been taken from this excellent GitHub repo. These are pretty basic concepts, but you can adjust your expectations and follow up questions based on the experience you need for the role. These can be all be asked in about 20 minutes (perfect for a phone screen).

Warm Up

  • Tell me about the last project you worked on.
    I have their resume, so I don’t need their entire career history. I’d rather hear about what they have been doing most recently.
  • Which part are you most proud of?
    This usually gets people to talk about the specific parts they built rather than the overall project. It’s also a positive way to start the interview.
  • What would you do differently next time?
    Hopefully candidates will have learned something since they started their most recent project and would like to apply that to their next one. I like to hear how pragmatic they can be about choices that may have seemed correct at the time and only look bad in hindsight.

HTML / CSS

  • What is CSS selector specificity and how does it work?
    It is amazing how many senior level front-end engineers cannot answer this correctly. Really I’m just looking for someone to talk about how an ID is more specific than a class, or that the ordering of style definitions matters, or how you can add more selectors to get more specific. I often follow up with a specific example, like if you have two styles that change the color of the text, but one is an ID and one is a class, which one will take precedence? Sometimes this helps people understand the initial question more but sometimes it just proves how much they depend on Twitter Bootstrap to do all the styling for them.
  • What’s the difference between display: inline and display: block?
    To me this is very basic, but again I’m amazed how many people struggle to define this. If someone can’t remember or isn’t understanding the question, I usually follow up with an easier question: can you name some HTML tags that are inline by default? If they struggle with that, then I’ll ask if they think a <span> is inline or block.

JavaScript

  • Compare and contrast Angular with React.
    I will replace React with Vue/Backbone/Ember based on their experience. The goal is to find out how much time they’ve spent working with multiple libraries and learning the pros/cons and best use cases of each. This is also a good way to find out if someone is too dogmatic about any one particular framework.
  • What is the difference between “==” and “===”?
    Few people miss this one. It’s pretty basic, but it’s always nice to have people mention type conversion and get a small win, especially if they’ve been failing the CSS questions.
  • What are the differences between variables created using “var”, “let”, and “const”?
    I usually ask this if I’ve seen them mention ES6 on their resume. If not I will first ask them if they’ve used ES6. Even if someone has not used ES6 yet, I would hope they’ve at least heard of “let” and “const”.
  • Describe event bubbling.
    Many people get this confused with the event loop, or something else that they struggle to describe. I know React, Angular, and even jQuery to some extent have removed the need to deal with event bubbling and the weird side effects it can cause. But I like when people are at least aware of the concept. If they can talk intelligently about it, they obviously have a decent understanding of the DOM as well.
  • Explain how (the keyword) “this” works in JavaScript.
    Most people inherently get this (pun intended) and use it all the time, but it’s a difficult concept to verbalize. I think being able to describe programming concepts to other people is just as important as knowing them.

Testing

  • What tools would you use to test your code’s functionality?
    Not everyone writes unit tests. But almost everyone says they do. An easy way to see if they are bullshitting is to ask them to name their favorite tools. Hopefully they quickly respond with Mocha, Karma, QUnit, or something similar. If it sounds like they know what they are talking about I might delve deeper and see how passionate they are about TDD or code coverage.
  • What is the purpose of a code style linting tool?
    More recently I have simply asked: “Do you lint?”, but the end result is the same. People either use a linting tool and understand it’s purpose or they don’t. I personally would not want to work with someone who did not use a linting tool on a regular basis, but obviously there are people who do not.

Performance

  • Explain what a single page app is and how to make one SEO-friendly.
    These are great to see how well a person is able to communicate concepts like SPAs and how well they actually understand how they work and what their shortcomings are. Not everyone has done SEO optimization for their job, but I expect every mid to senior level engineer to at least know where to start. I expect them to mention meta tags, server-side rendering, semantic links, etc.
  • Name 3 ways to decrease page load (perceived or actual load time).
    This one is kind of a gimme, but it’s telling if a person rattles off a bunch or they just barely get to three. Much like SEO, I don’t expect everyone to have experience with performance optimization, but they should know the basics. Answers like “compress your images” or “caching” are fine, but I’m hoping a candidate will talk about minifying, gzip, code splitting, or other more advanced techniques.
  • What does CORS stand for and what issue does it address?
    Please at least say “Cross Origin” and mention “security” and you’ll get a pass. I have definitely heard candidates that say “oh yeah I work with this all the time” but then can’t describe why it exists. It’s one of those things that they just do, but they don’t know why.
  • Describe the difference between a cookie, sessionStorage and localStorage.
    Most people struggle with at least one of these. Cookies are a given, but depending on whether your experience is more back-end or more mobile, you may have never worked with session or local storage. But again, I’m hoping senior level candidates are at least aware of them as concepts and can describe what they are at a high level.

Hopefully these are helpful for anyone else who is interviewing front-end candidates or someone who is a front-end candidate. This is not an exhaustive list of everyone question I can or would ask, but it’s a good place to start. I will usually follow these up with a coding project and a more culture based interview with the rest of the team.

What I’ve Been Working On (Ionic and Angular Resources)

As you can see by my stale timeline, I haven’t updated this blog in awhile. I’ve been busy building the HomDNA app for iOS and Android using Cordova, Ionic, and Angular. Here’s what I’ve learned (more detailed posts to come):

AngularJS Architecture

AngularJS Plugins

AngularJS Optimizations

AngularJS Unit Testing

Cordova Plugins

Build Process with Gulp

Choosing a JavaScript Framework

I’ve been trying to convert IPOFest (a pet project started by Kyle and I) from all PHP to JavaScript that interfaces with a PHP API. At work we use Backbone.js and since I had never used it before, I practiced on IPOFest. First I started with Backbone and Knockout.js, with Knockback.js as a bridge. I didn’t go too far down that path, but it did feel a bit awkward and the Knockback documentation didn’t help very much. At work we use Handlebars for templates, so I started changing over to that. Continue reading

Learning Object Oriented Javascript

I’ve never considered myself a programmer. Developer yes, coder, sure, but not a programmer by any means. Although I took some computer science classes in college, I never learned the basic tenets of programming and instead always learned just enough to get by. Focusing on HTML, CSS, and jQuery has always been enough. With my new position at Incisent, I’ve had to dive into the deep end of some very complicated, custom Javascript. This code has huge custom classes, uses Underscore, fastFrag, and Lawnchair (three JS libraries I’d never heard of). Although it’s easy to fix bugs, given enough time, adding new features the “right way” requires a bit more knowledge.

A few weeks ago I saw this post: learning object oriented Javascript in 15 minutes or less and I knew I needed to walk through it. So I finally did. The best thing about this is that it was short. Like the title says, it took less than 15 minutes and I was able to understand some concepts that were always at the edge of my knowledge. So it was definitely successful.

From there, in the comments, someone linked to this short collection of OO JS articles. These obviously go more in depth and are helping to take my knowledge to the next level. Armed with this new information and I’m starting to really enjoy the challenges at work and I hope to apply what I’ve learned for some of my own after hours projects.

window.load

I ran into an interesting problem while working on a project for SiteGoals. We updated the code for an old design, moving it from tables to divs. This was relatively easy, except that the bottom divs needed to stretch to match the height of the tallest column. Sometimes that was the main content div, sometimes that was the sidebar items. I couldn’t fake it with a background image because of the quirks of the design and I’ve never had much luck with any of the pure CSS techniques, so I turned to javascript.

I found a pretty simple script for finding the tallest div and forcing the rest to match. The only problem I started to notice is that on the first load, before the images were cached, it was finding the height of the page BEFORE the images loaded, causing the content to spill over the set height. Since the site is in a CMS (Expression Engine), I couldn’t very quick add width and height tags to each image, nor could I expect the client to always do so in the future. So I had to find a way to set the height of the divs AFTER all the images were loaded. I thought this might be a more daunting task than it was. Thanks to a blog post I found, and with only a quick modification to my script, I was able to adjust the height AFTER the images and now the content no longer busts outside the fixed height of the div. Easy as pie!