51 KiB
How I Hire Programmers (Aaron Swartz's Raw Thought)
Raw Thought
by Aaron Swartz
How I Hire Programmers
There are three questions you have when you’re hiring a programmer (or anyone, for that matter): Are they smart? Can they get stuff done? Can you work with them? Someone who’s smart but doesn’t get stuff done should be your friend, not your employee. You can talk your problems over with them while they procrastinate on their actual job. Someone who gets stuff done but isn’t smart is inefficient: non-smart people get stuff done by doing it the hard way and working with them is slow and frustrating. Someone you can’t work with, you can’t work with.
The traditional programmer hiring process consists of: a) reading a resume, b) asking some hard questions on the phone, and c) giving them a programming problem in person. I think this is a terrible system for hiring people. You learn very little from a resume and people get real nervous when you ask them tough questions in an interview. Programming isn’t typically a job done under pressure, so seeing how people perform when nervous is pretty useless. And the interview questions usually asked seem chosen just to be cruel. I think I’m a pretty good programmer, but I’ve never passed one of these interviews and I doubt I ever could.
So when I hire people, I just try to answer the three questions. To find out if they can get stuff done, I just ask what they’ve done. If someone can actually get stuff done they should have done so by now. It’s hard to be a good programmer without some previous experience and these days anyone can get some experience by starting or contributing to a free software project. So I just request a code sample and a demo and see whether it looks good. You learn an enormous amount really quickly, because you’re not watching them answer a contrived interview question, you’re seeing their actual production code. Is it concise? clear? elegant? usable? Is it something you’d want in your product?
To find out whether someone’s smart, I just have a casual conversation with them. I do everything I can to take off any pressure off: I meet at a cafe, I make it clear it’s not an interview, I do my best to be casual and friendly. Under no circumstances do I ask them any standard “interview questions” — I just chat with them like I would with someone I met at a party. (If you ask people at parties to name their greatest strengths and weaknesses or to estimate the number of piano tuners in Chicago, you’ve got bigger problems.) I think it’s pretty easy to tell whether someone’s smart in casual conversation. I constantly make judgments about whether people I meet are smart, just like I constantly make judgments about whether people I see are attractive.
But if I had to write down what it is that makes someone seem smart, I’d emphasize three things. First, do they know stuff? Ask them what they’ve been thinking about and probe them about it. Do they seem to understand it in detail? Can they explain it clearly? (Clear explanations are a sign of genuine understanding.) Do they know stuff about the subject that you don’t?
Second, are they curious? Do they reciprocate by asking questions about you? Are they genuinely interested or just being polite? Do they ask follow-up questions about what you’re saying? Do their questions make you think?
Third, do they learn? At some point in the conversation, you’ll probably be explaining something to them. Do they actually understand it or do they just nod and smile? There are people who know stuff about some small area but aren’t curious about others. And there are people who are curious but don’t learn, they ask lots of questions but don’t really listen. You want someone who does all three.
Finally, I figure out whether I can work with someone just by hanging out with them for a bit. Many brilliant people can seem delightful in a one-hour conversation, but their eccentricities become grating after a couple hours. So after you’re done chatting, invite them along for a meal with the rest of the team or a game at the office. Again, keep things as casual as possible. The point is just to see whether they get on your nerves.
If all that looks good and I’m ready to hire someone, there’s a final sanity check to make sure I haven’t been fooled somehow: I ask them to do part of the job. Usually this means picking some fairly separable piece we need and asking them to write it. (If you really insist on seeing someone working under pressure, give them a deadline.) If necessary, you can offer to pay them for the work, but I find most programmers don’t mind being given a small task like this as long as they can open source the work when they’re done. This test doesn’t work on its own, but if someone’s passed the first three parts, it should be enough to prove they didn’t trick you, they can actually do the work.
(I’ve known some people who say “OK, well why don’t we try hiring you for a month and see how it goes.” This doesn’t seem to work. If you can’t make up your mind after a small project you also can’t make it up after a month and you end up hiring people who aren’t good enough. Better to just say no and err on the side of getting better people.)
I’m fairly happy with this method. When I’ve skipped parts, I’ve ended up with bad hires who eventually had to be let go. But when I’ve followed it, I’ve ended up with people I like so much so that I actually feel bad I don’t get to work with them anymore. I’m amazed that so many companies use such silly hiring methods instead.
You should follow me on twitter here.
November 29, 2009
Comments
Yup.
posted by Russell L. Carter on November 29, 2009 #
Thanks for writing this. I’ve always wondered why tech hiring is so screwed up. For an industry that thinks a lot about a lot of things, hiring is one thing that doesn’t seem to have changed much over the years. Scaling this method of hiring might be tricky though. Another idea worth trying is to hire everyone as an “intern” initially and then, make a decision after a month of actually working with them.
posted by Abi Raja on November 29, 2009 #
+1. Totally agree.
However, for a different point of view check out this StackOverflow question:
posted by Ramin on November 29, 2009 #
Exception programmers are also creative - nothing was mentioned of that. They can see beyond the smaller details of a task and problem. They can put themselves outside of themselves, into the user space.
posted by Mark Rushing on November 29, 2009 #
The problem with asking about what a person has done, is almost uniformly, people will answer with what ‘their team’ has done, couched as if they did it. They are familiar enough with what the team has done, to talk about it semi-intelligently.
Sorry, i want them to answer something in front of me. It doesn’t have to be real hard, but it has to be real, and they should ace it.
posted by MeBigFatGuy on November 29, 2009 #
“Someone who gets stuff done but isn't smart is inefficient: non-smart people get stuff done by doing it the hard way and working with them is slow and frustrating. “
I couldn’t read anything passed that stubborn remark.
posted by on November 29, 2009 #
I really like your idea for figuring out if people are smart, especially the bit about asking what they’ve been thinking about, and continually probing (in a non threatening way) to see what level they understand something.
Very good ideas that I’ll be stealing from next time.
What I didn’t get though, was how you determine if someone actually gets something done. I’ve met a few smart people who have extreme understanding of a variety of complex subjects, but just don’t produce an awful lot.
Perhaps theres no way to tell for that particular case. There have also been times, though the exception, when I had talked to someone for an hour, been confident they were smart, and have them utterly fail the most simple programming test (fizbuzz, recursive method, etc.)
I wonder if your method would have ‘screened’ out those candidates that appeared smart in the hour I chatted with them…
posted by Vincent on November 29, 2009 #
The problem with a code sample is that it can be the product of other people. Even if the entire thing might not be the product of someone else, it could of been reviewed by many other people.
And if they can’t code under pressure how are they going to fix a bug that needs to be dealt with immediately. No one performs excellent under pressure, but a substantial amount of their programming abilities shouldn’t dissipate because of it.
posted by Kyle on November 29, 2009 #
The comments here and on Hacker News reminded me I left out a step. I’ve added it:
If all that looks good and I’m ready to hire someone, there’s a final sanity check to make sure I haven’t been fooled somehow: I ask them to do part of the job. Usually this means picking some fairly separable piece we need and asking them to write it. (If you really insist on seeing someone working under pressure, give them a deadline.) If necessary, you can offer to pay them for the work, but I find most programmers don’t mind being given a small task like this as long as they can open source the work when they’re done. This test doesn’t work on its own, but if someone’s passed the first three parts, it should be enough to prove they didn’t trick you, they can actually do the work.
(I’ve known some people who say “OK, well why don’t we try hiring you for a month and see how it goes.” This doesn’t seem to work. If you can’t make up your mind after a small project you also can’t make it up after a month and you end up hiring people who aren’t good enough. Better to just say no and err on the side of getting better people.)
posted by Aaron Swartz on November 29, 2009 #
great post. i loved it. it can be applied to so many other jobs besides programming.
posted by winzoAL on November 29, 2009 #
I am looking to be hired… it is a great post
posted by avanzaweb on November 29, 2009 #
This seems like a good approach, but the one part I disagree with is having to provide a code sample. I don’t program outside of work, apart from the odd script or php debug. All my code samples would be from uni, and while some of them are pretty good, most are of the oh-god-five-hours-to-deadline-quick-finish-it! level of quality. This might be because I’ve only just finished uni, but only two of the 40+ people on my course have done any sort of extra-cirricular programming.
I’d like to think I’m a pretty decent programmer, but have never written (production-level) code in my free time (I prefer to do things not related to my day job). Sure you’ll be getting the cream of programmers if you request a code sample, but you’ll be missing out a lot of decent ones at the same time.
posted by Fin on November 29, 2009 #
That’s an interesting way to hire somebody, though I’m not sure that completely removing the “interview” part is a good thing. I mean, if I’m hiring a programmer for working over giant datasets at the very least I’d ask for how a binary search works and when it makes sense to use it or how he’d process a 4Tb file. Besides, I agree that this part should be reduced to a minimum, so we can at least know that the applicant knows the required theory. Then looking at source code he has written is much more interesting than asking him to write down a working quicksort.
posted by Ivan on November 29, 2009 #
“Can they explain it clearly? (Clear explanations are a sign of genuine understanding.)”
Great post but the above is not always true, in my opinion. What if you’re interviewing a top programmer who happens to be a foreigner? If he’s speaking to you in his second language he may not necessarily always be as articulate as you expected, yet he may certainly still have a “genuine understanding” and be a top programmer.
posted by Peter on November 29, 2009 #
I’m surprised not to see a nod to Joel Spolsky here.
posted by on November 29, 2009 #
Aaron’s approach to hiring seems intuitively spot on.
Here’s what I find lacking in this approach: - By no means is this an universal approach. Rather, it’s much more suitable for startups and companies with relatively small tightly-knit teams. Bigger teams are probably far too heterogeneous to employ anyone who’s not a smart stand-up comedian with solid coding skills. On the other hand, big companies are most probably messed up already so there’s no one-size-fits-all solution for them. - Sufficient interaction with their potential coworkers is lacking. Even though the most competent person in the company should eventually decide, feedback from future coworkers should be taken into account. Could this rectified by having them work on a little piece of your project in the same environment as others? If the environment is virtual then virtual it is, if not, shouldn’t be the test take place? - In more interesting job positions there are several problem domains that one needs to excel in. For such cases you definitely need a person from each such problem domain repeat the entire “soft interview” cycle. Is it feasible? If it’s possible for you - then I think it is.
Cheers! Shonzilla
posted by Shonzilla on November 29, 2009 #
I’m sure that process works well for you, but I’m concerned it may not be entirely legal.
The “external” interview is constructed in a way that makes it much more difficult for certain people. Some mild mental illnesses and personality disorders could make a candidate completely non-functional in such a setting. The same candidate could be extremely engaging and lucid in an office setting talking about Work Stuff.
Under equal opportunity employment rules, it’s important that you do not subject a candidate to any tests that are not directly relevant to job performance. I think this interview— especially when you somewhat deceitfully tell the candidate that it’s NOT an interview— meets that criteria of not being directly relevant.
Of course, the content of the conversation is important, too. In a more “relaxed” setting, there may be more likelihood of the interviewer or candidate accidentally discussing topics which are not legally permissible in the hiring process.
The bottom line is, I would recommend that you and your readers speak to a lawyer before using this process again.
posted by el_gregorio on November 29, 2009 #
How do you get this process to scale? Especially in an institution like Microsoft or Google..
posted by Cherian on November 29, 2009 #
I’d given up interviewing because it seemed like people performing the interviews were employing the very techniques Mr. Swartz criticizes, it is a pleasant and welcomed surprise to see that someone from the hiring side thinks like I do.
That said, I’m still in dismay for if a prospective employer said something like “I make it clear it's not an interview” that’s a warning sign that the speaker is not being genuine or truthful and at that point, I’d conclude the interview indicating I do not see a good match.
Bottom line: I stay where I am because I really really like my boss (I feel I should be paid more) and at the end of the day, if I’m not happy with the people I work with, I’m not going to produce the kind of work that my employer is paying for.
posted by Anonymous on November 29, 2009 #
I agree with this post completely. It makes me think of Moneyball. Most companies are like the sports GMs who look for players with certain body types and who perform well at certain athletic tests in individual workouts — rather than concerning themselves with how the player will play (and has played in the past) in the actual games.
posted by Greg on November 29, 2009 #
My background is a professional programmer for 4 years, including conducting 20-30 phone interviews and about a dozen or so in person interviews. I’m no expert, but thought I’d share a few comments.
I like the holistic approach - is this a smart guy? But I’m not sure this interview approach is appropriate for programmers:
- Plenty of excellent coders are social introverts, and would not do well in such a casual setting. These people tend to prefer formality and the work environment, and are articulate and engaging w/ coworkers in a work setting. They may fail miserably in your interview process.
- Very tech lite interview. Like another poster, I’ve encountered plenty of guys that seemed really smart in a conversation, but couldn’t do the most basic programming tasks (omg recursion!?!). I think asking some screener questions before wasting time in person is a good idea (which is what most companies do).
I think the concepts borrowed from Joel Spolsky (get things done, smart) are definitely something that should be part of the hiring process. And a code sample is super important - although I prefer to give an offline code question and see the results (due to typical problems with previous pieces of code, i.e. did they write it? is it legal for them to show me another company’s code?)
But the other stuff, sitting down with them in a cafe, working with the group for a day… I’m not sure it’s much of an improvement.
posted by Anonymous on November 29, 2009 #
@Greg, speaking of “Moneyball” a lot of programmers now have public work records, much like college athletes have stats that pro scouts can examine.
On the subject of getting things done — hiring managers do seem to be looking at open source contributions, and have been for a while. But with “git log” and “git blame” and the equivalents, a hiring manager who knows a little bit about using a DVCS could get a very detailed look at an individual’s work within a project. Anyone seeing this happening?
posted by Don Marti on November 29, 2009 #
Hey thanks for this, it’s a helpful discussion for me. I often have to wear the businessman hat, but I feel like an idiot when it comes to all things business.
This process of course assumes that interviewer is smart enough to discern whether the interviewee is smart ;). Three cheers for small companies with direct hiring processes, and for dumb people sticking together!
posted by Jon on November 29, 2009 #
Great post. As someone who has gone through a lot of hiring processes (I’m an independent developer/consultant), I wish more organizations would take this approach. As someone who has occasionally been involved in hiring, I try to use a similar approach as much as possible. My mantra is to hire primarily based on “attitude and aptitude”, which more or less boils down to what you are talking about. I hope to be in a position of influencing more hiring processes in the future and I will remember your thoughts. Thanks!
posted by Shea Phillips on November 29, 2009 #
I don’t enjoy small-talks and chitchats. At most parties I feel pretty bored. I suspect many techie types have this trait, and we will not leave a good impression during the cafe interview.
posted by BY on November 29, 2009 #
Wow. I really like this method. I was thinking to myself the other day when building business relationships you also are technically just networking with people and making friends. When you are genuinely interested in conversation with another person you can get a better feeling on whether the person is more geared as a potential person to work with, or just a friend, or neither, depending if they pass the steps :)
posted by Vinnie T on November 29, 2009 #
I wish more interviews where that way. Seems like almost large company rather ask to build a binary tree parser over the phone or some other question like that. 1) One it’s very hard to do over the phone. 2) Who remembers that sort of school stuffs years after learning it. 3) A good programmer will know how to find that kind of info online and use it, and doesn’t need to memorize it, especially since it changes so fast in this field.
Programming is about logic, quick thinking and perseverance not memorizing !
posted by Thibaut Colar on November 29, 2009 #
Aaron, you are overcomplicating. All you need to know is if they care.
If they care about it, they’ll do whatever it takes to aquire expertise and get smart at it. It will be a means to a clear end and no time will be wasted on distractions.
If they care about it, they’ll get it done without caring for if they’re getting things done. Even getting things efficiently is crushing to someone who does not care for what they do.
If they care about it, and you care enough about it, then you’ll both get on just fine. Most relationships are built on the basis of 2 people having a common interest. If this interest is in something you work on all day, all the better.
posted by Gaurav Sharma on November 29, 2009 #
Funny, I’ve used a similar process when interviewing potential students for my alma mater to provide an alumnus recommendation. I don’t ask specific things, but find out if he or she has a passion about something (anything!) that will help drive them through having a meaningful college experience. (True at my a.m. as well as any.)
It’s often remarkable to me to meet prospectives who seem to have spent their entire lives avoiding feeling very strongly about anything. I’ve also met incredible kids with world-changing amounts of energy and intelligence.
I should use my college interview techniques (which are parts 2 & 3 of your above notions) for future job candidates.
posted by Glenn Fleishman on November 29, 2009 #
@Fin: “I don't program outside of work, apart from the odd script or php debug.” Honestly, that alone is a problem. Good programmers write code; the ones who only do it at work are just doing it because it’s a job.
Code written for work is often written under conditions guaranteeing it’s compromised in some way and probably isn’t representative of the best work you’re capable of. The code you write for yourself is going to be your best stuff.
On another topic, I’m bothered by the fact that this process is slanted in favor of social extroverts. You’re probably missing good people who just don’t do well in the kind of situation you’re creating, which many people find more stressful than a formal interview.
posted by Jeremy on November 29, 2009 #
Surely no one comes to your casual meeting over drinks or whatever thinking that it is NOT an interview in disguise.
How do you get away without being sued for discrimination?
posted by John Corbin on November 29, 2009 #
You have to be a little careful of this approach with regards to anti-discrimination laws. When you don’t have any sort of firm metrics by which to judge candidates, it’s easy for someone to say they didn’t get the job because you don’t get along with black/white/latino/asian people.
posted by Sam on November 29, 2009 #
A lot of this is obvious. Is the person likable? Do they seem smart and do their answers make sense? Are they “learners”? Will this person drive me crazy after a month?
Other things like working on small projects for me or temporary evaluation assignments don’t scale well - at least not any large company that I’ve ever worked for.
posted by Bill B on November 29, 2009 #
If I was a programmer and looking to be hired this is the process I would like to go through. It is applicable to many (but not all) hiring scenarios for a small team. The lack of scalability is why Google and Microsoft won’t benefit from it, and why it is a legal quagmire for all but the smallest and smartest. That it works is attested by the second last sentence, “I actually feel bad when I don’t geet to work with them any more”
posted by Jim Harvie on November 29, 2009 #
I was with you up till the part about asking someone to write code for free. That would immediately turn me off and I would decline. I have nothing against doing work for free but I wouldn’t give away my work to anyone just to be hired.
Ask me about some freeware that I’ve done. Ask to see code. Those are fine. But remember, I don’t know you or your company just like you don’t know me. There is a huge warning sign when someone wants some work for free instead of hiring a programmer. You may have nothing but the best intentions but I don’t know that.
posted by James Bailey on November 29, 2009 #
I’ve added a few thoughts of my own on my blog, but overall this resonates deeply with me. If you don’t hire a smart person, then you won’t be getting a good employee…
posted by Joshua Jabbour on November 29, 2009 #
"Someone who gets stuff done but isn't smart is inefficient: non-smart people get stuff done by doing it the hard way and working with them is slow and frustrating. " I couldn't read anything passed that stubborn remark.
That’s because you fall into the non-smart category. Otherwise you would have used “past.” Sorry, you don’t get the job.
posted by SSteve on November 29, 2009 #
Let me get this straight…If they can’t converse with you, then they are not smart.
posted by Mike on November 29, 2009 #
Inviting the candidate to a team function (like a game or lunch) sounds like a bad idea, to be frank. First of all, it puts your entire team on the defensive so as not to leak confidential information, opinions of the candidate up to that point, etc.
Secondly, it sends mixed signals to the candidate. If someone I was interviewing with said, “Hey let’s play a game of fuzbol with the team” or something, I’d interpret that as essentially having the job in the bag.
Like it or not, interviews are professional situations and should be approached professionally. Inviting a candidate in the middle of an interview out for a casual meal or coffee for some chit-chat and then saying it’s not an interview is also disingenuous. Especially now that you’ve posted this technique in a blog post entitled “How I Hire Programmers”. If you use it to determine whether the candidate is smart, it’s part of the interview, period. It’s going to influence your decision.
This is why interactions with candidates during the interview process should be and are kept strictly professional, because any interaction you have with a candidate is going to influence your judgment. By making it more casual, you’re opening yourself up to a claim that you decided to hire or not hire someone based on factors not relevant to the position.
posted by Damien Sorresso on November 29, 2009 #
This article is the first I have seen showing someone being smart about the hiring process.
The concern that this is not scalable is a legitimate one but the way things are done today seems like a game show IMO. You can argue that hey if you’re smart then win the game. To me the accepted mainstream way for getting hired is about putting up a facade.
I was watching a video on interviewing techniques and the HR person said “This how you should answer question X, it is the ONLY way.” Wtf? My conclusion is clearly this person is a closed minded idiot.
Personally I don’t know every data structure and every algorithm and quite frankly with a modern programming languages and APIs where you don’t implement a linked list everyday it seems reasonable that it’s not at your fingertips. However, if I have good reason or hobby time to dive deeper I sure would because it’s fun knowledge and I’ll most likely know more after such an experience.
Maybe I have the wrong attitude but I too have given up on interviewing, call it quitting if you want, but no job and nothing to do but code and read books just makes me know more everyday than I did the day before.
posted by John D on November 30, 2009 #
You have to be careful about being [too] social but if the people that are going to work for you are going to be in a comfortable environment then so should the interview process. Yes it is profession but I thought the goal was to learn about the person, seems like the goal is about passing some test. Then again what do I know, seems like the “scalable” way is to standardize the process, but I’ve always thought that people that use standardized tests to get a feel for how smart someone truly is are idiots.
posted by Stewie on November 30, 2009 #
@Jeremy: Regarding your reply to Fin:
@Fin: "I don't program outside of work, apart from the odd
script or php debug." Honestly, that alone is a problem.
Good programmers write code; the ones who only do it at
work are just doing it because it's a job.
I don’t see not doing programming outside of work as a problem. There are issues of life/work balance to consider and even if you really love programming and are great at it, that doesn’t mean that you have any time or energy to do much programming aside from what you do for your job. In fact that could mean that you don’t consider your job just at job and you’re giving it all your development and programming energy.
Code written for work is often written under conditions
guaranteeing it's compromised in some way and probably
isn't representative of the best work you're capable of.
The code you write for yourself is going to be your best
stuff.
Yes, code written for work usually involves compromises: dealing with existing systems, objectives and design decisions didn’t all go your way, schedule is too short, etc. But that doesn’t mean that your code for that project is compromised. Knowing how a developer works under those conditions and the quality of their code under those conditions is something most hiring mangers would dearly love to know.
Also, I’m sure you didn’t mean it this way, but your second paragraph above would make me as a hiring manager wonder if you’re saving your best for yourself and if you have trouble working with others. Is the code you write for yourself more clear, concise, efficient, etc? If so why aren’t you striving to do the same things for your code at work even in the face of compromises and other work pressures? My concern would also be that your definition of best included a large amount of: “Everything is exactly the way I want it to be.”
Sorry if I’ve misinterpreted what you were trying to say, but I thought another perspective might be useful.
posted by David Ballenger on November 30, 2009 #
I don’t belive that hiring developers are that different from hiring in many other fields. You have the same basic questions, just like you described, and there are a fantastic amount of bad hires in most organizations. Unfortunatly a sizeable portion of all humans doesn’t seem all that employable really.
The quirky hiring processes are more than likely the long evolution of inept people hiring others. Being scared of screwing up (btw, people who are afraid to screw up more than often so screw up because of their fear) and being “clever” by devising tests.
posted by Flekkzo on November 30, 2009 #
Anything I’ve written worth a damn is owned by my employer. If you are looking for people just starting out, asking for a sample is fine. But as someone else said, I have too many other interests to go home and do the same thing I’ve been doing all day. Otherwise yes, the only reason I’d ever ask someone to swap variables without using a temp is to hear them explain why that’s a terrible (and useless) idea.
posted by Dave on November 30, 2009 #
el_gregorio, are you by any chance a lawyer who doesn’t have enough work to do?
posted by John C. Randolph on November 30, 2009 #
@David Ballenger:
I would be deeply suspicious of a “programmer” who never writes his own code. Have you really never solved a problem of your own by writing code to do it? How is that even possible? I use my own code just to make my own computer work the way I want, let alone things like running a website or whatever. Did you just learn it in school as a job? My experience is that really good programmers aren’t those people.
What I meant about your own code being better is simply that, when you’re writing code for work, you are usually severely restricted by working within someone else’s design; working with a large, existing codebase; working with other programmers; conforming to badly-thought-out coding guidelines; etc. Looking at someone’s code written under those conditions without knowing about them will probably result in being less impressed than you might be. “Why did you do this in this convoluted way?” “Because I had to.” If you fully understood the restrictions it might even be more impressive, but you can’t.
posted by Jeremy on November 30, 2009 #
Congratulations, you’ve just selected for likability over smarts.
posted by Xofis on November 30, 2009 #
Ah, I’ve missed the getting to know them bit by going out to lunch. That is just up my alley, and if I find myself back in that position, I’ll definitely utilize that.
Thanks for sharing.
posted by Ben on November 30, 2009 #
You might find “First, Break All the Rules: What’s the World’s Greatest Managers Do Differently” by Marcus Buckingham.
From Amazon — no affiliate link: http://www.amazon.com/exec/obidos/ASIN/0684852861/managementcon-20/102-3775167-1472903
posted by Bill Quinn on November 30, 2009 #
Any interview method that does not focus on revealing the passion the programmer brings to a project is a waste. I know great programmers that don’t care enough about their projects to write any decent code, and I know fair programmers that have risen to the challenge to create creative and surprising answers to tough programming problems.
Find the passion and you will find the programmer.
posted by js on November 30, 2009 #
@Jeremy
Sure I write code to do things and solve problems on my own systems. I never said never. But that code is not representative of the types of stuff I’ve done at “work” where I’ve worked on compilers, operating systems components and utilities, and large scale distributed systems. And while I like to think that the code I’ve written at home is well written I don’t feel that it is a a scope to show what I do on the job.
I also have other interests that I like to spend time on as well, plus spend time with family and friends, so the amount of time that I have to code on my own compared with work is much more limited.
Maybe I’ve been lucky in that the projects that I’ve worked on were rarely “just a job”. They were projects with interesting problems to solve and new things to learn and do. And I had the chance to work with some great software engineers and programmers who also didn’t look at what we we’re doing as just a job. The great ones were passionate about the projects they were working on. Probably a lot of us were still thinking about the project “after work” whenever that was. Those types of “jobs” take up a lot of technical focus and energy. While you might do some of your own programming after work, it helps to have other interests that will let your mind recharge for the next day.
posted by David Ballenger on November 30, 2009 #
@js: “I know great programmers that don't care enough about their projects to write any decent code”
I wouldn’t call those great programmers. They might have great knowledge and maybe skills, but if they don’t apply those skills, they aren’t great programmers.
posted by on November 30, 2009 #
When I interview with a company for a position, it’s is as much about whether they are an acceptable employer as whether I am an acceptable employee.
If you want samples of my code, be prepared to pay for them. I am a professional; code is my product. The best code I’ve written is either only shared under NDA or client-proprietary. Some of it requires a security clearance.
If you insist that we have a conversation about non-job related topics, it’s likely that a you have criteria for employment that violate the law, and that could get you into a real mess.
If you say “this isn’t an interview,” you’ve just lied to me. I don’t work for people I can’t trust.
posted by Jim Nicholson on November 30, 2009 #
Great article - Most of these comments can apply to non-programmer hiring as well! It’s all about working together as a team with smart people!
posted by Chris Hedley on November 30, 2009 #
Awesome article! I posted a “response” to it on my blog relating it to Web Developers. http://jrtashjian.com/blog/be-a-better-programmer/
posted by JR Tashjian on November 30, 2009 #
How about vetting lots of interviews?
posted by sensei on November 30, 2009 #
Interesting way to interview for a small business, but when you have a larger business with an HR department that has to hire anyone from programmers to sales people to accountants to shippers, the HR are limited in understanding what you, the boss, wants, and people that would probably be what the boss want might not necessarily make it past the HR department due to some missing magic keyword or some odd spelling error.
Sometimes the HR departments use interesting cookie cutter paste-n-copy such as 5 years experience with CPU X (which has only existed 3 months).
Overall, it is an interesting blog and I could see this method of interview being used by a small creative team where the boss is the one that hires (and not a 3rd party like an HR department).
posted by Joe on November 30, 2009 #
I guarantee EVERY “engineer” from India would fail your test. They are money suckers and code leeches.
posted by Indian on November 30, 2009 #
This validates my own process - thank you. On the two occassions I have failed to stick to such principles, things have fallen apart. If an engineer (or anyone else for that matter) oversells themselves or pressures you, that is a red flag moment. Summary: Remain 100% inside your mutual comfort zone - for as long as the relationship lasts.
posted by Oflife on November 30, 2009 #
To know if they are any good at work it usually boils down to the fact if they know the answer to life , the universe and everything.
If they don’t you can order the bill.
Jolly
posted by Patrick aka Jolly on November 30, 2009 #
“Programming isnt typically a job done under pressure”
Really? I have never worked anywhere where there is not a significant amount of pressure.
posted by Devmentia on November 30, 2009 #
One problem, though. It takes a smart person to recognize another smart person. There’s been research to back this. So your advice falls flat on its back when applied by a not-so-smart interviewer.
posted by icyclectic on November 30, 2009 #
Aaron,
You should probably take this article down right now.
Every single candidate that you interviewed with this process over the past years and that you ended up not hiring can sue you and your company for discrimination, and with this article as supporting evidence, they will most likely prevail in court.
posted by Harold on November 30, 2009 #
That last sanity check is important… we are hiring a new programmer and we have seen people make it through the interview with flying colors… only to crash and burn during the sanity check.
posted by Daniel Sellers on November 30, 2009 #
Would someone mind telling me what you’re hiring for? What business/startup do you (Aaron) run?
posted by Brendan on November 30, 2009 #
@Joe:
In a large company it doesn’t have to be just HR involved in hiring.
I worked for a reasonably large firm (offices in 10 countries) with a pretty big IT department. For IT hires the interview process included someone from HR but also the line manager and the team leader of the team they would be working in. Sometimes senior developers would be involved as well. The HR person was only there to cover the bureaucratic stuff. The line manager and team lead were there for the technical stuff, and to see if the prospective hire would fit in. Worked well.
posted by SimonTewbi on December 1, 2009 #
I couldn’t agree more. This method has worked extremely well for me.
posted by Twylo on December 1, 2009 #
So… the bottom line is, you only hire stupid and naive programmers who don’t mind being deceived, lied to and manipulated?
Well, I’m sure the result is mutually satisfying. Like an S&M relationship.
posted by Rick on December 1, 2009 #
I couldn’t agree more.
good article.
posted by Veera on December 1, 2009 #
Wish everyone hired like you. You seem to treat each person as an individual instead of a process.
posted by Rodger on December 1, 2009 #
You should have some written test, just in case someone would sue you for discrimination. Written test can prove this very easily.
posted by Bubak on December 1, 2009 #
Thanks for your honesty, now it makes me feel much better :)
“I'm a pretty good programmer, but I've never passed one of these interviews and I doubt I ever could.”
Failed Google (5 times), failed Amazon, failed Facebook, failed FriendFeed, failed YouTube, failed Ning … anytime there was an interview I have failed.
Aaron, may I ask you how you got a job at Google?
Alex K
posted by Alex K on December 1, 2009 #
Why dont’ you have a sleep over as well?
posted by Bill on December 1, 2009 #
OK, here are some gross generalizations:
- Bad and ambititous programmers become managers
- Hiring decisions are usually made by the managers
posted by J on December 1, 2009 #
Thanks for your honest writing. It’s not often that you hear someone boldly state his opinion when it questions common practices and norms. The more valuable it gets then.
I share your opinion. Asking tricky questions and conducting psychological tests is pointless, you end up with wrong people for the job.
More to it, if you see a company do these things, you can raise a red flag. Because you can pretty much guess what kind of colleagues you’re going to get there.
Personality, attitude and willingness to learn is what matters. Not knowing answers to tricky questions or remembering some weird algorithms from university you graduated from over ten years ago.
Write more good stuff!
posted by Developer Art on December 2, 2009 #
I had the misfortune of being the lead developer for a company where the ‘boss’ did the hiring. I was only allowed to scan the resume’s and have one talk with the applicant. Every single programmer I picked where labeled too nerdy, too alternative, too smelly looking (for real!) etc. Every bloody time they hired people they ‘liked’. The result was programmers who couldn’t program but were ‘too nice’ to fire. This article comes pretty close to how I would like to be hired and how I’d like to hire people myself.
posted by Marsk on December 2, 2009 #
I would also read their blog if they have one. Amazing how much you can tell about a person from their blog
posted by rrtucci on December 3, 2009 #
Are they under 25? Do they ride a motorbike?
Anyone asking for a specific language (c, java haskell etc) should not be hiring programmers, they should only book hotels, meetings and talk on the phone all day
You can give them the (test) problems upfront, well in advance of the interview
Only those with a full motorcyle licence and motorbike who are under 26 will recive an invite
Your method looks like somekind of sexual selection, which may not be an invalid way of judging inteligence given it has evolved to be sexualy stimulating (or is it the otherway round chicken egg kind of thing)
Yeah, two interviewers, male/female and if you both like them thats a sure sign
I once lost a job by tucking into the free beer provided, that says a lot
posted by mike panero on December 3, 2009 #
I read this article, and I thought about how I would do in that process, and it seems to me that I’d do dismally. Except that I’m a successful programmer who gets stuff done, and that’s what your process is supposed to identify.
First off, I have a life outside of programming. Programming is something I do because I’m reasonably good at it and it pays me well enough to pursue the things I really love. If you ask me what I’ve accomplished in the past few years, you have two options: you can hear about what my team has accomplished, or you can hear about the things I do in my free time that are completely unrelated to programming. I’m happy to explain the technical details of knitting or 16th century music to you; that won’t tell you anything about my particular Perl skills.
And I’m a task-focused introvert. To be honest, until I get to know you, I’m really not interested in you — so I’m not going to ask questions about you and be genuinely interested. If you’re working on something that interests me - either because it’s related to one of the non-technical things I’m interested in, or because it’s something I think will be useful in programming, I’m interested; but otherwise, I’m happy to fake interest, but I can’t fake genuine interest.
Second, I’m an introvert. Your casual, unstructured café conversation sounds like torture to me: I don’t know enough about you to have a casual conversation with you, and despite your assurances that it’s not an interview, you’re considering hiring me, and if I know that, there’s no way I can believe that it’s not an interview. You aren’t going to get a good read of me in such a casual environment, and I’ll be miserable about it. We aren’t going to talk like we would at a party, because I don’t go to parties, because I find them abjectly miserable experiences.
And that goes double for a large group of people. A group dinner where I have to deal with the rest of the team, and I know I’m being evaluated for fit? An hour of that, and I’ll be prepared to confess to the JFK assassination just to make it end.
Your approach seems like it is excellently suited to finding people who are extroverts and who have programming as the primary interest in their life. If that’s the kind of people you’re looking for, more power to you. Maybe you want people who eat, sleep, and breathe software, and it’s good that you’d pass right by me, because I’m not that person.
You say you want someone who is smart, gets things done, and can work well with a team, and it seems like your process will do that without producing many false positives. But it’s also likely to produce a high number of false negatives, too.
posted by CW on December 4, 2009 #
You can also send comments by email.
| ----- |
| Name | |
| Site | |
| (only used for direct replies) | |
|---|---|
| Comments may be edited for length and content. |