How to Hire a Hacker

Not knowing a framework well doesn't imply someone's not a good hacker, but the reverse is generally true; the people you want to hire are the people who will have learnt the obscure cases, and who are good at explaining what they know.<p>I'm very sceptical of the ability to do a good, fair "culture" interview; I've never seen a cultural line that divides good hackers from bad, and it's easy to use "didn't fit the culture" as a cover for discrimination.<p>Project experience you often can't tell about, and passion is a red herring - the best developer I ever worked with was the guy who'd rock up at 11, hung over more often than not, slump in his chair and give every impression of not giving a damn about anything. He still got more done than anyone else, in higher quality, and teaching the rest of the team as he went.

This should be titled "How to hire a programmer with years of experience using multiple languages" simply because the advice doesn't apply to anyone outside that demographic. It won't apply to recent graduates and it won't apply to someone who has spent the last 10 years using .NET (for example) exclusively.<p>Sure, if your loose definition of a hacker is someone with diverse language experience then it applies, otherwise it's nonsense.

I disagree with this in so many ways; nearly all the excellent coders/hackers I know are heavily biased towards certain languages and frameworks. They have pet projects, are idealistic and often fussy about what they work with.<p>To hire a great hacker you need to have a problem they WANT to work on: something that hits right in their area of interest. And then you need to give them the freedom to do it in whatever way they want (cause they know best).

Perhaps the title should be: "how to hire a hacker, assuming that there are tons of them to choose from."<p>Your premise is that there's a compromise required. If I'm a Ruby shop, then ideally I'd want to hire someone who loves Ruby, loves what I'm doing, loves my team, and lives where I live. But I don't often get all four, so I should sacrifice the language preference for the fit stuff. This makes sense, but I'd take it a step further and say that oftentimes (at least in this day and age) you get one, maybe two of the four and the required compromise is much deeper. Of course if you plan for it (make training available, remote work possible, etc.) then things can still work out.<p>I think the post is missing a key element though. How do you find these people in the first place?

There's a sizable number of hackers who wouldn't be caught dead using 'that crafty old java thing' or 'what? perl?!'. There is also a sizable number of hackers who would never touch anything high level - C code or nothing!<p>So obviously if you're hiring someone and your code base is all Ruby, you should at the very least mention it somewhere, even if you don't look for Ruby coders in particular. I don't think I need to point this out though, I'm not sure I've actually seen any job adverts that didn't mention programming language. Obviously most people get this.

&#62; <i>A good developer will be able to deliver value regardless of the language they’ve used before.</i><p>This is true, but more in the long term. If I hire a brilliant and experienced .NET guy for my python team, sure he'll pick it up quickly and achieve some sort of productivity until he's up to par on PEP8 and idiomatic python. But I feel there are many cases where companies are looking for someone with experience in a specific language/framework in order to 'hit the ball running' aside from the usual getting-their-feet-wet with the codebase, learning the business, and other mythical man month issues.<p>[Edited for clarity.]

<i>&#62;At the company I’m with, our very first interview is a culture interview. We decide if you’ll be able to fit into our environment and be productive with the team we currenly have before we even consider your technical ability.</i><p>Anyone know any specific advice or discussion on how to do a culture interview? This is a big topic lately, but it seems many times the details are assumed to be understood. In terms of culture, what are the bullet points you're looking for, and what are the disqualifiers, and how do you surface them in an interview?

Lots of truth here, but I'd point out that the one thing you don't want is someone who only knows one language well. They haven't had practice thinking in different headspaces and they see things interacting from only one perspective.<p>Unless you have someone managing them who can see from all the perspectives you need and ensure that the developer doesn't break compatibility, you're better off finding someone who isn't a one-trick pony.

I feel that the author is both right and wrong at the same time.<p>I'd have no problem hiring someone without C# background to write C# if they already know Java, but my gut feeling is to think twice before hiring someone to write C++ who has no previous C++ experience. Maybe it's because some languages are more unforgiving than others, I don't know.

While I agree in general, you shouldn't be too coy about what tools the developer will have in their hands from day to day.<p>Programming languages are syntax and patterns, but sometimes they're inextricably linked with productivity tools, libraries and testing frameworks, a set of best practices, a compiler tool chain, and even an execution platform.<p>As programmers work with these things all day every day, many of us have preferences - or at least I do. I'm happy to switch between languages that have good tools available - but if you use VB6 or PL/SQL you might as well tell me up front so we don't both waste our time.

Disagree with this article. I think the no 1 way to hire a great hacker is to see them code (either in real life through pair coding or through a coding test or through seeing what they have personally achieved).<p>Cultural fit is important also but it's a very vague notion. It's so easy to say that someone is a good cultural fit if you like them. That does not make them a great developer. That makes them likeable. Not denying that this is important, but it's down the list, it's not the number one factor to consider when hiring someone.

I am tired of seeing the word hacker being abused like this, seriously in this article it refers more to a developer or coder than a hacker, sadly the word has lost a lot of its old meaning. Now everyone who writes code with some competence calls himself a hacker, IMHO it should be earned not self assigned.<p>Downvote me to hell if you want, but I had to get that out of my chest.

I mostly agree.<p>Especially consider dropping lines like "5 years in X required." - you're just filtering out the fast learners.

Or...<p>...give the potential developer a box of Lego. If s/he does a Quagmire-esque "giggidy!", hire them.

Regarding culture: I once had an interview where one of the co-founders slash CEO (who had the last word on my hire) decided to interview me and showed me some code on part of their - at the time - current production systems. I wanted to test their so called culture, so my answer was basically "This is retarded. I'd like to meet whomever wrote this and give him/her a kick in the teeth for such an ugly implementation of X and Y. I would have done Z..." The CEO answered in turn "That would be me and you're hired. I don't like people that suck up to me, and I want to be told when I'm being an idiot. And I will do the same. Can you live with that?" -"I'm sold!"

"Hire for fit, not code completion" is a great quote.

The problem with these countless articles telling you the "super-über-top-secrets" how to a "hacker/guru" is that the small companies who would heed such advice have much better ways of finding great people available to them - while the (big) companies desperately needing this type of advice are far from being able to implement it any way because they have way too much process to struggle with.<p>How to hire a "hacker" or at least a great fit for your team? Make sure you offer a great place to work, make sure your people are happy and pay and treat them well - word of mouth from "hacker" to "hacker" will be ten times more valuable than anything some nameless derp wrote on their blog and it will ultimately work very well towards building a team that fits and sticks together.