Interviewing for front-end development

Mon 25 January 2010

Interviewing people can be one of the most aggravating things in this industry. Just about everybody who walks through your door could be some run of the mill engineer who's set in their ways.

Now, I should be fair here - I probably see this more often, due to the position I'm in. As a front-end developer, I can't begin to count the number of times I've had somebody come in for an interview, expecting their database skills and server-setup capabilities to translate into web skills. It's maddening, at points, and a real problem in the industry - we're only now beginning to get out of the era where front-end development is treated as a necessary evil.

Front-end development carries its own unique set of problems. Nobody who's been doing database optimizations for the past five years is going to be able to hit the ground running on UI work; the playing field for this stuff is constantly changing. To that end, I've started trying to come up with different interview questions that can help show how someone attacks the kind of work we routinely face.

Seeing as how I've been in Javascript-land for the past four months, the most recent one I came up with is this:

The problem is simple: figure out what arguments need to be passed to "t.b()" for it to display the proper message.

I feel like this is a great problem to have someone solve, as it illustrates a few things right off the bat. Are they scared away by encoded characters? Do they even know how to decode those characters? Can they tell, based off the arguments work being done, what types of objects need to be passed?

It helps to draw a clear line between someone who just manages to get by with Javascript, and someone who can really dive in and tear things apart if need be. The code is just ugly enough to make some people roll their eyes back into their head, but it's deceivingly simple when you get down to it, and that's why it succeeds at the job.