A baseline for front-end interviewees

(Rebecca Murphey recently published A Baseline for Front-End Developers which was well received and is the inspiration for this aside.)


It’s tough hiring top developers when the talent pool is so small and given that I work for an agency the available pool is even smaller. Those who have worked in the industry for some time are likely scarred by agency burnout and I think it’s reasonable to assume that the most highly skilled developers will have taken advantage of their scarcity and value to find great positions already. When attempting to hire I’m usually left looking through the details of pissed-off web journeymen and graduates.

Recruitment is made harder because CVs have limited value; skill cannot be deduced from big name clients (household brands push out heaps of expensive garbage) and portfolio websites can be a misrepresentation. If personal projects and published code are not available I may still have enough hope to invite a candidate for interview, as it’s (arguably) not fair to dismiss an applicant because they lack a GitHub account.

To help avoid frustrating already fraught interviewers, here is my baseline for front-end interviewees:

Be inspired

I want to see a candidate get animated describing a beautiful site they use, a cool talk they attended, someone they admired working with, who they retweet on Twitter, projects they follow or web experiments they don’t understand. A candidate must be able to show they have an interest and understanding of their industry; what else are we going to talk about? Maintaining a keen interest in interaction design and technology at all times is not an indicator of ability but it is within reason to expect candidates to be savvy enough to prepare for a question that will certainly be asked.

Be excited

It’s disappointing when a candidate states “HTML5” as a feature they are looking forward to. What about it? HTML5 officially covers a range of technologies so being knowledgeable about specific features will be an advantage. I don’t wish to downplay the significance of the improvements to HTML document outlines and the pain alleviated by additions to the CSS3 backgrounds and borders module but it’s not very interesting to discuss features that have been in widespread usage for some time and considered a standard tool. Being able to clearly convey your ideas for using the latest hotness will be far more engaging than discussing the drawbacks of sliding door sprite creation. An enthusiasm for evolving web technologies is vital.

Be discerning

A candidate must be able to choose reliable resources when in need. When asked where to find programming help “Google” is not an answer, only the first step. The competency to distinguish between a rated Stack Overflow answer from a criticised for-profit website is a required skill. There are many highly respected blogs and books to read so it is expected that a candidate can recall their favoured authorities.

Be pragmatic

Attacking programming issues or new features ignorantly creates difficulty for the team later. A decent understanding of how CSS, HTML and JavaScript are parsed and processed will make avoiding and solving problems easier (even unearthing the logic behind legacy Internet Explorer layout). In general the repetitive front-end sticking points of uniform cross-browser style and DOM manipulation can be fixed methodically rather than with brute-force. Front-enders will naturally amass trivia over time but recognising why a hack works is more important than blindly copying and pasting. The key to bug fixing code is working from the bottom-up, not top-down.

Be professional

I’ve interviewed plenty of devs who can talk-the-talk but have been unable to solve or even define basic programming problems when presented with them. Irritatingly candidates have then excused themselves by stating that they were “not expecting a test”. Regardless of pressure felt while under interview it is not unreasonable that (after years spent staring at code) spotting an obvious JavaScript syntax error or rewriting a ridiculous CSS rule set can be done without squirming. Candidates should under no circumstances state that they “know jQuery but not JavaScript” because it is a silly contradiction.


Hiring is a chiefly subjective process with many more factors not discussed by this article but front-end development—like other programming disciplines—can be an objectively testable skill (so long as you ask the right questions). In my experience conducting a simple test is the most useful way of determining if a candidate will fit into the team. We want interviewees to show passion and display a broad knowledge of technology but it is not until we see how they problem solve and test if their reasoning is sensible that we can make an informed decision.

comments powered by Disqus

About the Author

A photo of Matt Hinchliffe

Matt Hinchliffe

I'm a 26 year old UI developer working at Lonely Planet based in London. I specialise in crafting scalable, performance-driven code, tackle accessibility issues and keep an opinionated interest in the latest hotness. I like my tea robustly brewed, white and with no sugar, thanks!