How to Hire a Hacker(rtigger.com)
rtigger.com
How to Hire a Hacker
http://rtigger.com/blog/2013/01/15/how-to-hire-a-hacker/
44 comments
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.
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.
> what are the disqualifiers
I imagine that disqualifiers fit into two categories. 1. Subjective differences between you and the other people at the company. 2. Objective personality flaws.
There isn't much you can do about 1, and you shouldn't. If your personality doesn't fit in with a team, you should not try to alter your personality; it would get tiring and stressful, and you won't enjoy your job.
Things in the 2nd category (e.g., compulsive liar, arrogant douchebag, wet blanket) should be worked on in general, regardless of whether you're trying to find a job or not.
I imagine that disqualifiers fit into two categories. 1. Subjective differences between you and the other people at the company. 2. Objective personality flaws.
There isn't much you can do about 1, and you shouldn't. If your personality doesn't fit in with a team, you should not try to alter your personality; it would get tiring and stressful, and you won't enjoy your job.
Things in the 2nd category (e.g., compulsive liar, arrogant douchebag, wet blanket) should be worked on in general, regardless of whether you're trying to find a job or not.
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.
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.
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.
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.
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.
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.
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.
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.
Downvote me to hell if you want, but I had to get that out of my chest.
Downvote me to hell if you want, but I had to get that out of my chest.
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
I mostly agree.
Especially consider dropping lines like "5 years in X required." - you're just filtering out the fast learners.
Especially consider dropping lines like "5 years in X required." - you're just filtering out the fast learners.
Or...
...give the potential developer a box of Lego. If s/he does a Quagmire-esque "giggidy!", hire them.
...give the potential developer a box of Lego. If s/he does a Quagmire-esque "giggidy!", hire them.
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."
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).
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).
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.
We're kind of arguing the same point - I mostly meant there should be less of a focus on language experience and more of a focus on passion (pet projects). It goes without saying if you try to hire someone who doesn't want to work for you or your projects, it's not going to work.
I really like C#, and I prefer to do most of my projects with it, but learning new languages interests me (a problem I want to work on) and is a challenge that I'm passionate enough about to do in my spare time.
I really like C#, and I prefer to do most of my projects with it, but learning new languages interests me (a problem I want to work on) and is a challenge that I'm passionate enough about to do in my spare time.
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.
Sure, if your loose definition of a hacker is someone with diverse language experience then it applies, otherwise it's nonsense.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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...)
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".
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...)
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".
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. ;)
I for one would be interested in reading your proposed next blog post. ;)
Ask and ye shall receive! http://rtigger.com/blog/2013/01/17/how-to-find-a-hacker/
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.
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.
I agree. Perhaps rather than requirements like "5 years of Ruby experience", have requirements like "Be willing to work with Ruby".
> 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.]
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.]
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!
That being said, if you can find a great Python developer who is also passionate and a good fit, you've hit the jackpot!
the distance between knowing 0 Python and being proficient in Python shouldn't be more than 2 weeks, and the distance from 0 to "idiomatic" shouldn't be more than 3-4 weeks... and these are generous timeframes. most programming languages are very simple and i'd question whether even 1 month is going to make a difference, especially when i see companies having the same unfilled positions month after month
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.
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.
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!"
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.
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.
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
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
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
But on focusing on cultural fit, we certainly agree.
- another nameless derp
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.
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.
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 :)
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 :)
I get the impression you haven't read the article - it's about how to choose a developer, not how to attract one.
It's also funny to hear one nameless derp giving out advice while saying you shouldn't hear the other ;)
It's also funny to hear one nameless derp giving out advice while saying you shouldn't hear the other ;)
At least I am just rabbling anonymously for my own peace of mind and not to establish myself in any way or to polish my cv/application when the hr drones google me or for whatever other profit-oriented reason most blogs really are created in the first place.
The "choosing" part was included in my suggestion, you let your people recommend someone and you give that person a chance and it will become very apparent very quickly if they fit well or not.
The "choosing" part was included in my suggestion, you let your people recommend someone and you give that person a chance and it will become very apparent very quickly if they fit well or not.
I would've hoped the lack of advertising, missing link to my linked in profile or resume, or lack of any sort of "donate" button would've established that I'm just doing this because I have a personal interest in writing and software development. Hell, my real name isn't even on the site!
But yes, thank you for your critical feedback.
But yes, thank you for your critical feedback.
I realize I might have singled you out too much for what I personally generally dislike about the "blogosphere"; I am sorry for that. It was uncalled for. It is not a bad article and you obviously have all the right intentions, if anything I do find the topic a bit boring in the sense that it does pop up here at least weekly and I have no hope any of this will ever reach the typical HR drones who should actually learn something from this anyway.
"Hire for fit, not code completion" is a great quote.
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?