Two caveats before I dive into this one.
For starters, the following is what I’m generally interested in when doing an interview. It doesn’t represent in any official way what my current employer and my boss might be looking for in a candidate. It’s not my group, so this is only part of the picture.
Secondly, this is based on the “Front End Developer” role I outlined in my previous post. That’s what I do and what I’ve interviewed people for over the past few years, so if you’re looking for insights into interviewing for another role, adjust accordingly.
Also, and this should go without saying, the following is simply what I look for in a candidate. This is entirely personal and biased. If you look for other things or don’t care about some of the things that I value that’s cool. There are infinite ways to get to the same result here. We all want to hire good people.
What I Do
I’m a whiteboard/coding quiz kind of guy. Some people don’t like that approach. I do.
As a note, I’ve recently started using jsFiddle in addition to the traditional whiteboard. jsFiddle is the best. I can set up code, candidates can hack and test their solutions right there. It’s like magic.
Why I Prefer This Approach
While I try to make it as comfortable as possible and set up an environment that feels almost collaborative when it’s working properly; I do want the candidate to be under a little bit of pressure. The agency/consulting world is a constant source of pressure (deadline, cost, quality, customer service, etc.) so seeing how people think and react about technical issues in a stressful environment is telling.
Also, after having read dozens of resumes with a the right acronym soup on them (HTML,CSS< JavaScript, jQuery, etc.) on them and then seeing what the candidate actually knew, I've decided actually having them demonstrate some knowledge is the only way to go. With the prevalence of libraries, plugins, frameworks and tutorials people can produce nice marketing sites with just copy and paste skills. The thing is, with the kind of work we do it's so much better to have someone who can just jam on a complex problem without having to spend 5 hours on Google every day while they put together a Frankensite. This is especially true for more senior resources, but practically anyone on a team can end up being tasked with something novel to implement. I want to find people who can create (or have the potential to create) something beyond what's on the 1st page of a Google search. Giving them some problems to solve helps me see how they think on their feet.
My Focus
I basically focus on three general technology buckets. I don’t ask or focus directly on character or personality. While personality and manner are very important in what we do, I feel like questions of temperament, professionalism and approach will shake themselves out during the course of the interview.
JavaScript
My number one focus is core JavaScript. I love candidates who can speak to something beyond their library of choice. Libraries and frameworks are great, but having people that can only work with something like jQuery limits what a group is capable of accomplishing. With people who can roll up their sleeves and just hack away at whatever needs hacking the range of solutions on offer grows exponentially. When I’m talking to a client or internal resource, I never want to say “no.” The worst I want to tell someone is “it’ll take some time, but we can make that happen.” If we’re limited by what jQuery and the associated sea of plugins can offer I’m potentially going to have to say “no” more often than makes me happy.
I also don’t believe in the growing monoculture of jQuery. I would much prefer to have someone working with me who can switch over to core JS, Dojo or YUI without missing a beat. This is especially true as applications get more and more complex. To me, the idea of shoe-horning a bunch of stuff on top of jQuery to make it behave more like YUI or Dojo for application development misses the point. jQuery is great for certain types of projects, other libraries and frameworks are going to be better for others. I’m not so much of a fan that I’m compelled to use it for everything at the cost of my sanity.
Beyond that, a solid understanding of JavaScript also makes people better at their job when they’re working in the context of a library or framework. Knowing what a library papers over and understanding (at least at an intuitive level) how it’s implemented can lead to simple optimizations and more efficient choices throughout the development cycle. Think of avoiding the (much slower) convenience of $.each for large collections or simply referencing this.href instead of something like $(this).attr("href") inside the body of a function when grabbing the contents of a link to manipulate as a string. Someone who only knows the “jQuery way” might not even know that this.href even exists.
I wrote about an example of the kind of JavaScript questions I ask a few months ago.
Libraries
Okay, so I just went on about how much I want to know about core JavaScript and how much I value someone who can work without the safety of a friendly API. Now I’m going to talk about how much I value someone who understands those friendly APIs…
I should point out, to me at least, this is less important the more senior a person is. Someone who’s written a ton of complicated JavaScript should be able to pick up a new library without too much trouble. They may not understand all the library specific quirks right off the bat, but they’re going to understand code organization and patterns well enough to be able to play catch-up on the job. That and they can do the hard stuff while someone who knows the library can do the easier, library specific stuff.
This is flipped on its head for more junior resources. The perfect junior resource is someone who’s done a bunch of jQuery (since that’s what we use on most projects) over the past two or three years and has also cracked open a book or two about the core language. I love to see them moving beyond just jQuery. That speaks to good development potential. Thing is, a junior resource needs to be able to get work done right now, so for them understanding jQuery in a healthy way is incredibly important.
One of the ways I test this is with a really horrible block of jQuery. I ask the candidate to improve it in whatever way they can. It’s a pretty open-ended exercise since the code is terrible in terms of both jQuery conventions and general organization. It’s always interested to see the things that people spot right away and which come out later on in the exercise. It also allows me to ask a bunch of good questions about the code and their knowledge off the library.
Markup and Style
While the definition of “front end” has expanded beyond the “Markup Master” of yesteryear, there’s still a need for strong markup and style skills. So, I invariably spend a good amount of time talking about this stuff in interviews. I want to find people who understand the building blocks of a modern layout.
As a jumping off point, I use a potentially very simple layout test. It’s a simple 3 column layout exercise with a twist or two thrown in just for fun. If the candidate knows their stuff, the solution is maybe 25-30 lines of HTML and CSS and can be finished in 5-10 minutes. If they don’t know how to solve it right off the bat, the solutions they attempt are always really telling. By design the problem illustrates how well they understand floats, the box model and how they react to a novel problem.
When people don’t know the answer I’m always slightly disappointed when the answer is something like “I’ve been using the ‘super fancy grid system’ for the past couple of years” and slightly pleased when there’s a whole litany of options the candidate rolls through trying to solve the problem. Even if they don’t get it right away, talking about using positioning or improperly structure floats tells me the candidate has the experimental nature needed to sort through the kinds of problems we see on a day-to-day basis.
We do so many custom layouts and are constantly forced to implement so many novel design elements I have to see people who can think on their feet and pull from a large reservoir of CSS tricks to get the job done. We’re often caught between the hammer of design and the anvil of CMS constraints. Getting out of there without getting crushed takes flexibility.
And that’s it. These three pieces can expand and contract depending on the role and the level of the candidate. Everything else, from a technology perspective, is secondary to these three buckets. IDEs, environments and tools are all going to be secondary to the skill areas listed above. We can support someone who’s never used Eclipse or Visual Studio, we can’t support someone who has to go to Google every time they have to solve something slightly off-the-wall.