

How to Hire a Hacker - RTigger
http://rtigger.com/blog/2013/01/15/how-to-hire-a-hacker/

======
lmm
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.

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.

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.

~~~
RTigger
We don't do cultural interviews to determine if someone's a hacker, we do them
to determine if they're a good fit for a team and if they'll be able to work
in our company environment.

And passion comes in many forms - the fact that they were willing to teach the
team alone speaks volumes. If someone didn't care about programming, they
wouldn't want to spend the extra time teaching their peers about it.

~~~
xiaoma
I think what lmm is pointing out is that perhaps your "cultural interviews"
might illegally shut out certain groups of people. For example, has the
company ever hired a hacker over the age of 50?

The question is hypothetical, but lmm's comment is valid. A lot of companies
use 'cultural fit' as a cover for discrimination. Plausible deniability isn't
hard to find, but it's still an unfortunate practice.

~~~
pekk
The law can't actually do anything about discrimination as long as there is a
slight professional veneer to cover it. Don't want to hire old people? Want to
fire someone who doesn't like your ideas? There is a standard stock of phrases
like 'cultural fit' which are unimpeachable in almost any context, and once
hired, almost everyone is or can be construed to be in violation of some
regulation. As long as you use the right words, don't let slip any stupid
smoking-gun memos, there is nothing anyone can really do because it is
impossible to prove anything.

The best protection is to be able to change jobs, and to stick with
environments which do not contain toxic people who abuse their power or want
to hurt you.

If you are older and a company does not hire you due to 'cultural fit' then
you are probably dodging a bullet. Forcing them to hire you wouldn't make
things better even if it were possible.

------
Peroni
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.

Sure, if your loose definition of a hacker is someone with diverse language
experience then it applies, otherwise it's nonsense.

~~~
RTigger
I'd argue that (and I have) - a recent grad who went outside of their
coursework to learn about node.js (for example) and/or has maintained their
own personal website or projects is a passionate developer and can probably
learn anything you throw at them. In fact they can probably learn it better
than someone who's spent 10 years in a certain language because they've just
come out of a 4 year learning experience.

------
daurnimator
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.

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).

~~~
dorkrawk
I think that when you try lots of things and thinking critically about them as
you work with them, you're bound to form strong opinions about what you like
and what you don't like. That's why being able to intelligently discuss your
favorite language/framework/whatever is much more important that what that pet
technology is.

------
cliftonmckinney
Perhaps the title should be: "how to hire a hacker, assuming that there are
tons of them to choose from."

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.

I think the post is missing a key element though. How do you find these people
in the first place?

~~~
RTigger
I don't think it's as much as a compromise, just that we should focus less on
the language aspect of it. Technical details like implementation and syntax
are easily learned. Passion for development is more of a character trait that
can't easily be taught.

Out of your 4 criteria, I'd say (personally) that the important ones are
"Loves what you're doing" and "Loves your team". If you hire someone who is a
Ruby god but has no passion for the problem they're solving, or causes
problems with your existing company, culture, or team, you're probably going
to have a net loss. Working remotely is a different topic and can be done well
([http://blog.davidtate.org/2013/01/companies-that-support-
rem...](http://blog.davidtate.org/2013/01/companies-that-support-remote-
workers-win-against-those-that-dont/))

I did want to talk a bit about finding those passionate developers, but
thought it'd make for a separate blog post later on. One key quote I've heard
good recruiters say: "The good developers you want to hire aren't looking for
jobs, they already work somewhere".

~~~
cliftonmckinney
I take issue with that last point. While it's true that good developers aren't
currently unemployed--especially these days--that doesn't mean they're not
looking for something new, especially if what you have to offer (better fit
and something awesome to work on) is available to them.

I for one would be interested in reading your proposed next blog post. ;)

~~~
RTigger
Ask and ye shall receive! <http://rtigger.com/blog/2013/01/17/how-to-find-a-
hacker/>

------
RyanZAG
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!

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.

~~~
meric
I agree. Perhaps rather than requirements like "5 years of Ruby experience",
have requirements like "Be willing to work with Ruby".

------
felideon
> _A good developer will be able to deliver value regardless of the language
> they’ve used before._

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.

[Edited for clarity.]

~~~
RTigger
I'd argue the short and long term gains of this approach. If you hire someone
who's really good at Python, you're going to get good quality out of the gate
from them. But if they're not a good fit for your company or team and/or if
they're not passionate about what they do, you might be damaging progress or
performance in the long run. In that case I'd take a .NET developer willing to
become a good Python developer over a Python developer who's there to collect
a paycheque anyday.

That being said, if you can find a great Python developer who is also
passionate and a good fit, you've hit the jackpot!

------
SkyMarshal
_> 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._

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?

~~~
iuguy
We have two simple tests.

1\. Are they a cock? If they're a cock, or they exhibit signs of being a cock,
they fail the test. Signs of being a cock include:

\- Lying on the interview \- Being overly confrontational \- Irritating people
\- Being extremely fixed in their ways

Good signs include, but are not limited to:

\- Decent sense of humour that fits in with at least one other person and
doesn't irritate anyone. \- Positive attitude towards work and people in
general. \- Is able to tell us about things that interest them with some
energy and passion (but not to the point of boring us)

The other thing we do is we take people to the pub after the interview
finishes so they can meet everyone. It's almost technically part of the
interview but the main thing is for them to see as many of the people they'll
be working with as possible and vice versa. Even if someone passes our cock
test, we don't necessarily pass theirs and the important thing with hiring
that I've found is that the person is the right match for the company at the
time.

The day after the pub I'll generally ask what people thought of the candidate
in the pub, and afterwards I (or whomever's hiring) will give the candidate a
call and see what they thought of us.

------
codygman
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.

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.

------
10098
I feel that the author is both right and wrong at the same time.

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.

~~~
RTigger
I don't mean to exclude the value of language experience, rather point out
that just because someone doesn't know C++ doesn't mean they wouldn't be able
to contribute to your team. It's more an argument against companies who won't
even entertain the idea of hiring someone without X years of experience in a
particular language.

When it comes down to it, most programming languages are just syntax and
patterns. Most intelligent people can pick up on this. The people who are
going to contribute the most to your project and company in the long term are
those who love what they do and are passionate about doing a good job.

------
michaelt
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.

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.

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.

------
timedoctor
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).

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.

------
ristalk
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.

Downvote me to hell if you want, but I had to get that out of my chest.

~~~
RTigger
I consider myself one of the people trying to "take it back". See my article
on the subject: <http://rtigger.com/blog/2012/11/19/redefining-hacker>

------
readme
I mostly agree.

Especially consider dropping lines like "5 years in X required." - you're just
filtering out the fast learners.

------
beebs93
Or...

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

~~~
sergiotapia
Nah, I'm here to get shit done, get paid and get out. Keep your games for the
fresh graduates. I'm a professional, not a monkey that will work on Sundays
for you because "it's fun."

------
sp4rki
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!"

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

------
kahawe
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.

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.

~~~
RTigger
Aww, thanks for the constructive criticism!

Despite your comment, I think we're kind of getting at the same point - if you
have a great place to work and focus on building a team that works well
together, you're going to have more success as opposed to hiring someone with
X years of Ruby experience just because they know how to code. Focus on
cultural fit, the technical stuff can be taught.

Signed, nameless derp

~~~
kahawe
Constructive criticism: I am not sure yet another "how to hire a hacker"
article is really all that necessary because there is no shortage of similar
advice and I think all the characteristics typically listed in those articles
how to identify and pick that one über-hacker with pinpoint accuracy are not
really that much better than the pre-dotcom-bubble myth of selecting the one
with the geekiest tshirt, simply because there is too much you do not and
cannot know or predict or foresee in that situation. So common sense should
dictate you are much better off relying on qualified recommendations from your
people because they know more about the person they recommended, maybe they
have even worked or studied with them - this gives them much more insight than
you could possibly hope to get in your first encounter with that person, no
matter how smart and elaborate your "detection mechanism" is. And this saves
you a lot of time and money.

But on focusing on cultural fit, we certainly agree.

\- another nameless derp

~~~
RTigger
Fair enough - as someone else pointed out in the blog comments, there's not a
lot of "actionable" items in this post short of seeing if people work on side
projects, which in itself isn't an indication of someone you should hire.

Word of mouth however is a pretty reliable way of finding solid developers
provided you start with a good developer or two to begin with, and is a great
way to build your team and culture - odds are if your team is recommending
someone, they'll fit in with and extend the culture your company is going for.
We saw an example of this when we opened our Vancouver office - after a few
key hires we were able to attract a lot of talented developers who fit in
nicely.

~~~
tonyarkles
Kind of OT but... Are you still around Saskatchewan at all? We met many years
ago, I ran power for ArcticLan and TCU in maybe 2003-2004? Always interesting
to see other Canadian prairie folks around here :)

~~~
RTigger
Yep - had a two year stint in Vancouver but moved back last year. Good to hear
from you! Drop me a DM on twitter if you're around :)

