Testing HTML/CSS/Javascript skills when hiring

Question

When hiring a front-end developer, what specific skills and practices should you test for? What is a good metric for evaluating their skill in HTML, CSS and Javascript?

Obviously, table-less semantic HTML and pure CSS layout are probably the key skills. But what about specific techniques? Should he/she be able to effortlessly mock up a multi-column layout? CSS sprites? Equal height (or faux) columns? Does HTML tag choice matter (ie, relying too heavily on <div>)? Should they be able to explain (in words) how floats work?

And what about javascript skills? How important is framework experience (jQuery, Prototype, etc). today?

Obviously, the details of the position and the sites they'll be working on are the best indication of what skills are needed. But I'm wondering what specific skills people might consider to be deal-breakers (or makers) when creating tests for candidates.

Solution 1

When I interview people for a position of Client-Side developer I try to figure out:

1) Understanding DOM (what is that, how is it related to HTML etc)
2) Understanding XML/namespaces
3) Understanding JavaScript (object-oriented? what otherwise)
4) Knowing approaches to componentization (XBL, HTC) - plus
5) Understanding OO principles
6) JavaScript closures
7) Memory leaks in browsers

The only simple test case I give right away:

<script type="text/javascript">
var a = 1;
</script>

I suggest interviewee to explain in technical terms that line.

And I also check on overall awareness of the current state of the Web technologies, among other questions I suggest designing a web-browser where interviewee is suggested to pick technologies he would put into his brand-new creature, suggest ones that might be missing from the current client-side platform.

Solution 2

I can suggest you online test, that includes HTML, CSS and JavaScript together.

http://tests4geeks.com/test/html-css-javascript

It has 60 questions (20 for each subject). And you will recieve the report via email, when the candidate finishes the test.

Solution 3

Sergey and swilliams both gave great answers, in particular, swilliams mention of asking for a portfolio is key. With a portfolio you can also test for items like,

• does the html and css validate?
• does the presentation render consistent across browsers?
• does the candidate have JavaScript errors? if they do, does the person let them bubble up to the presentation layer or do they at least catch them with a try/catch block?
• in terms of JS, how advanced is the person? Can they do form validation? Can they do regex? Are they relying on MM_Preloader? (Yuck!)

A portfolio can also give a sense of how passionate someone is about web development. Moreover, if they've done a site for someone else, that alone presents an opportunity to talk about a number of things with a candidate,

• how did they go about developing the UI?
• what kind of planning went into the site?
• how were user expectations uncovered/met?
• what kind of challenges during construction came into play?

Beyond these items, one other approach you might want to consider is a developer test that you could send a prospective hire. Nothing too hard that would take more than a day, but enough of a brain teaser to see if they can work through a CSS or JS problem.

Solution 4

At my company we don't work with tests and the portfolio is more important, especially because we tend to look at the candidate's personal motivation and passion for doing front-end development.

But if I should give the candidate a test before hiring, I would go about it this way:

Hand over a print-out of a photoshopped web page representing a clear semantic component tree underneath. Ask the person how he or she would come to a result in html. Just ask him or her to think out loud. What goes through one's head when seeing a page, knowing it needs to be developed.

Then it comes down to the approach the candidate takes.

Choosing the best available markup for each specific html section is one (important) aspect, but can be mastered with experienced people around to guide a new employee. Being able to properly break down a design into its semantic components, identifying sections and separating primary and secondary content from navigation is not math or science and therefore hard to test. But a conversation about the approach of breaking down a page might separate experienced people from beginners.

But as I said in my first line, we usually ask for what kind of web-related work a person has done in his or her free time, such as a blog, game or demo. If done anything, the person usually was really good at front-end development or was eager to learn and adapt.

Solution 5

Ask for a portfolio, and then review it with your team. That takes care of posers and people who "don't handle interviews well."

Other than that, I'd present them with something relatively simple to mock up and a laptop and say 'have at it.'

Maybe ask them what they like most about web design today, and what they hate the most. Ask them about their opinions about what is on the horizon (HTML 5, IE 8, Chrome, etc) to see if they keep abreast of what's coming out.

Ask them if they have a favorite JavaScript framework and why. Maybe have them code something in JS a la the [in]famous fizz buzz problem.

View more solutions