Testing HTML/CSS/Javascript skills when hiring [closed]

Answer 1

An understanding of how browsers are different is also key. Especially IE. If they have only ever coded for IE beware! Vica Versa too, if they've never tested their stuff in IE6/7 they have no idea how horribly it is failing.

If they can name 3 things that fail, or need workarounds for in IE, then they're likely on the ball. If they can't, they haven't had enough cross browser experience yet.

Answer 2

I know this isn't a great answer, but one of the first things I do is expose the formatting of their Word resume. If they've made use of the indents and styles that Word offers and it's not tab, tab, tab, space, space, space, space then they go top of the pile.

Answer 3

I don't have any experience with hiring, but I've attended a number of Web Developer interviews and can relate my experiences.

Out of all my interviews one method really stuck out as the best way of discovering true talent. I'll admit that I'm no expert, and this is probably why I didn't get the job, but this was a fantastic way of weeding out those that were capable and those that were great.

We were asked a couple of questions about DOM, Object-Orientation, Closures, XML Namespaces and general Web Design, then we were taken into a quiet office with a nice view across the nearby river and asked to write a few examples to show our ability. We were left alone, but were told that the source code and our browser history would be viewed after, if we needed to use a browser. We were asked to make a company intranet using the following:

• A simple three column layout
• A good-looking table using CSS
• A usable but good-looking Navigation Bar.
• Dynamic loading using XML and JavaScript

Given a small amount of time to do this, you get to see people that can really do this stuff. Whilst perhaps their example could always be better or more suited to different applications it just goes to show that the best way to show the skill of a developer is to get them to make something! If you know your stuff and they know their stuff their code will be good.

Answer 4

We used to either set up a small brief for them to work within a certain timeframe, or in some cases contract a job to them and see how they went.

I was never that worried about making someone sit down at a laptop in an interview room and bang out a solution, because that kind of environment is not (you'd hope) very much like the normal working conditions.

The exact nature of the brief will depend a lot on the skillset you are looking for. In some shops, the front end developers will have to take on a certain amount of filling the gaps in design, and/or performing "brand police" duties as they implement the design "vibe".
In those cases, leaving some holes in the brief regarding some of the finer points of the typography and other small details can give you some hints as to their abilities in those respects.
Let them choose the javascript framework, did they choose the one best for the job, or the one that they knew. (subjective question, yes. But pulling in dojo for the sake of a datepicker and some menu animations might be overkill)

I would look for someone who can implement css based layouts, but can in fact work on table based layouts if needed when dealing with legacy projects. Maligned as they are, some of the finer details of hacky table layouts weren't always easy.

The main thing in this sort of task is the attention to detail, have they added a set of style rules for printing, used appropriate image sizing and formats, produced clean and valid code, have they gone for gold because they really want the job, and are prepared to stretch themselves a little to get it.

Because you give them some extra time, it is fair to expect that they try to impress, rather than the stress laden scenario of putting them at a strange desk and telling them to go for it. So, whilst being realistic and not expecting obsessively perfect work every day on every task, in this situation I'm looking for gold, or at least evidence that gold was the target.

Throw in a curve ball of something they haven't done before... see how well they can pick it up in a hurry. Experience is good, but the ability to learn fast is probably more important in an area that changes so fast.

Answer 5

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.

Answer 6

I wouldn't put too much weight on it, as proper HTML/CSS is so simple that anyone can learn it in a week.

That said, you might want to review their portfolio to help you make a decision on their current skill level.