Julio's Blog — Hiring front-end developers

I’ve been getting a handful of emails offering me front-end jobs recently. Probably about time I admit that I like spending most of my time doing that, even though I ♥ my Rubies and I still believe developers who specialise end up worse off.

So I’ve decided to put down in words some thoughts that I had as I read through the job ads. This isn’t another post on how to hire developers in general (much), but on how to hire front-end developers specifically, and at the same time, get you to understand what sort of statements you’re putting out there when you say certain things in a job ad.

1) Figure out what you want to do with your hire beforehand.

This is pretty much like telling you that to beat poverty, you need to win the lotto first. But yeah, it’s valid, and the reason is because you can’t go out there and advertise that you’re looking for a front-end developer and then list 3+ back-end languages as experience required.

For instance:

> Requirements:> - Experience with Python, Ruby, Perl, Java, C++.

It tells me:

> If shit hits the fan, we’ll get this guy to cover for one of our back-end developers.

And no, saying any of those isn’t cool either, and the reason is because I want you to tell me why you need me to know a language in particular.

This is way better:

> We use mostly Ruby for our back-end, so it would be sweet if you’re acquainted with it as we might need you to help out every now and then.

Now you’re being clear. Should I like the idea of working with Ruby sometimes, I might take the job on the grounds that you’re being specific about what language, and how much chance there is I might be using it.

2) Don’t ask me to know XHTML/HTML4.1/HTML5

Markup is being consolidated into just HTML. Unless you happen to rely on your markup being parsable by a XML parser for any reason, asking me to know XHTML for instance says.

> I’m spamming buzzwords to ensure we get the right guy.

Better way to say it:

> We expect you to know HTML, use tags efficiently, and have a good grasp of the semantics behind each tag.

Protip: don’t let someone fool you saying they know HTML5 if all they know how to use is the doctype.

3) Asking for 3+ different JavaScript frameworks.

I often get this:

> Experience with jQuery, Prototype, Ext.js, and Mootools.

JavaScript frameworks aren’t something you throw around like it’s nothing. If you’re saying I need to know Ext.JS for instance, this role means something entirely different than if you ask me to know jQuery. Instead, if I’m to work on an existing project, tell me which framework you’re using in it:

> The project you’ll join uses Prototype (kinda sucks, we know), so we expect you to be familiar with the framework.

Excused if you do happen to have other projects that I might be working on that use other stuff:

> We use jQuery for other projects, so you’d be working with it too at some stage.

Final on this subject, learn how precious it is to get the hell out of the developer’s way if you’re developing something from the ground up:

> You’ll be working on a greenfield project. Any tool you use is fine as long as you know it REALLY well. Except of course for Ext.js. There’s just no excuse for using it ever.

Make sure you include the last two parts of the sentence.

4) Asking for JavaScript frameworks but not for JavaScript.

A framework developer is the kind of developer who, outside of a framework such as jQuery, is incapable of building anything useful. That’s as bad as hiring a “Rails developer” instead of a Ruby developer, or the equivalent for any other language.

A good JavaScript developer will know how to use frameworks. But not only that: he will know when to do it, and I’d argue that’s as important as the former. Chances he will also know a bunch of important stuff you don’t even know you should be asking about: code portability, degradation/enhancement, and performance.

5) Not disclosing what exactly I’ll be working on.

We’re getting into any job ad territory here, I know. Fact is so few people do disclose that I thought I’d mention it: selling a gig based solely on the technologies a developer will be able to use will net you the kind of nerd who cares way too much about that sort of thing to have any vision of the product itself, or desperate people who need a job. I’m guessing you don’t want either of those.

Any developer worth his salt will embrace a good idea. That’s important because it translates into productivity. I can’t embrace an idea that you won’t tell me in the first place. Also, not saying what you’re up to that carries this statement (potentially):

> I’m not quite sure what I want to do, but I heard a lot of people became millionaires in this startup game, so I thought I’d give it a go.

6) Asking trick questions in an interview.

The inconvenient truth of web development is that we’re surrounded by hacks. And I’m not talking about getting things to work on IE. I mean the lot of web technologies are basically the scaled up versions of ideas that someone had many years ago. Because of that, there are lots of little JavaScript, CSS, and HTML quirks which are corner cases, or sometimes outright bad ideas that were kept around.

Some developers memorise that sort of thing so they can spring onto other people with questions, find out they don’t know the answer, and then feel proud on the inside. That’s stupid. It doesn’t mean you can get things done, or that your work is creative, or better in any way really.

If you get your senior developer in the interview, and he pulls that on me, this is what you’re telling me:

> I’m gonna have to work with this dick and hear him say he wants to make sweet love to the ECMA spec all day long as if that translates into building something people will like better.

I’m not advocating ignorance, but making that a part of the interview process is too much. Leave it. I’ll know that sort of thing when I need to know it by googling.

That’s it!

Best of luck hiring!