13 ms·

How to Hire a Programmer

250 points by cruise02 15y ago

stch 15y ago
So hows the audition project work? Do you guys just hire the person on as a consultant for a week, or what? I'm curious, because I've never heard of this before.
invalidOrTaken 15y ago
Also worth reading: http://www.deserettechnology.com/journal/writing-a-good-job-ad-for-a-programmer http://www.deserettechnology.com/journal/writing-a-good-job-..., by HN's very own cookiecaper.
lachyg 15y ago
One thing I've really struggled with since coming to San Francisco is that every company seems happy to take extensive time out of a programmer for an interview, including an audition project. Yet if you ask this of a designer, you get shot down immediately for soliciting spec work.
- kgrin 15y ago
  Jeff's suggestion - perhaps not followed by everyone who does an "audition project" - is that the project be paid. (Spec work, of course, isn't guaranteed to be).
  - lachyg 15y ago
    I understand, and applaud Jeff for that, but most companies don't pay for their interview process, many of which can be multiple full day affairs. I can't imagine a company not getting backlash holding a design competition to 'interview' designers.
- Melyan 15y ago
  Programmers seem to work for free on Linux and other projects, while designers seem to be more eager to get paid. Given these common memes, people may think that programmers are eager to do any kind of work for fun.
- dustineichler 15y ago
  The audition project is pretty unheard of. It's time consuming on both ends especially if it's a week or more. What's more common is the 4 hour assignment, which annoys me to no end anyways.
- notJim 15y ago
  I think part of this may be that since programmers typically make more money and tend to be more valued, the upside for them of doing spec work is much higher. Even if salaries for developers and designers are comparable in startups, this is in-general not true from what I've seen, so designers as a community have banded together to stigmatize doing spec work. I'm explaining this situation, and how I think we might have gotten into it. To paraphrase a W3C spec: this comment is not normative.
- lrobb 15y ago
  The design profession is light years ahead of programming in that regard... Probably because of its print history. I'm reminded of this great presentation by the mule design guy (NSFW) F*ck you, pay me: http://vimeo.com/22053820 http://vimeo.com/22053820
jamesli 15y ago
Interview is a two-way process. The company must know who are their good interviewers and who are not. A not-so-good interviewer may not only give false-positive feedbacks but also contributes to pass really good candidates. To be worse, a lousy interviewer may produce a negative image to the company and actually drive a good candidate away. I think many people may have the experience that an interviewer was so rude and arrogant that no way would you join the company and work with the interviewer.
johnx123-up 15y ago
My personal favorite: How to interview a candidate/programmer http://rajeshanbiah.blogspot.com/2009/01/how-to-interview-candidate.html http://rajeshanbiah.blogspot.com/2009/01/how-to-interview-ca...
mirsadm 15y ago
Once you work at a few places and go through this process many times you get sick of it and create your own startup :P
mbenjaminsmith 15y ago
I was about to scream about #5 until I saw this: "This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement." I interviewed with a YC company about a year ago and was asked to do #5 except without pay. It's a long story, but in short I let my guard down because it was a YC company only to find myself having wasted a week. The part that really pissed me off is that they came back _months_ later and pretended that no time had passed at all (obviously their hire didn't work out) and asked me to jump through more interviewing hoops. When I rightfully just told them to put money where mouth is they actually insulted me and the free work I had done (written in an email no less). The point I'm making is that if you need this many hoops for a candidate to jump through you shouldn't be the one hiring. Find someone else with a business-tuned intuition and ability to judge character. If you act like you're the world's greatest company which people will waste hours and even days trying to impress you're going to miss the best people out there. Also #2: "Show me a Stack Overflow profile where I can see what kind of communicator and problem solver you are. Link me to an open-source code repository of your stuff." Kinda cheesy for Jeff to say the first part. I absolutely agree with supporting both info sharing sites and open source. But as a self-taught programmer that ships products and does very well financially, I can tell you that there are effective people out there that don't rely on SO to get things done and therefore probably don't contribute to it. I do absolutely support open source software but I also don't have a lot of free time. I've written a raster to vector conversion library that I'd love to clean up a bit and open source. But I literally don't have time to do so. Does that make me a second class programmer? Having hired many people over the years I know that I would look very seriously at someone who has shipped a lot of products but doesn't follow programmer community trends like SO. I guess it could mean they're truly horrible programmers with no knowledge to share. It could also mean they're too busy meeting their own (or some company's) targets. It could also mean they like to unplug once in a while and lead a normal life. I understand why companies like Google take a hardline approach to hiring. They just deal with too many people. But if you're reading Jeff's essay on hiring you're not running Google. If you're a small company you need to look at the outliers first since that where you're likely to find overlooked talent. That's where you're going to find the people who don't jump through hoops but who actually get shit done on a daily basis.
- 15y ago
dpdp_ 15y ago
Why do an audition project when you can fire candidates who do not work out within the first three months? My advice is to trust yourself and hire people you like. Take a leap of faith. If things do not work out - be quick to pull the trigger.
- pagekalisedown 15y ago
  Why not? Sadly, because we live in a litigious society.
  - dpdp_ 15y ago
    General Counsel gets a fat paycheck to take care of that. Avoiding litigations is simple too - do not hire dicks; ever. If you hired a decent person in the first place, and after two months things are clearly not working out, you can part ways in a civil fashion.
    - karamazov 15y ago
      It's not always that simple. What if that person quit their last job to come work here? Quit and moved across the country? Gave up other promising opportunities? I'm not saying you can't fire people, but unless a trial period is explicitly agreed upon beforehand, there's an expectation that a job will last more than a couple of months if the new employee is putting in real effort. I don't know where to draw the line, but even an employee who isn't a dick might sue if they rearranged their life only to be let go two months later; I'd argue that they also deserve to win.
      - dpdp_ 15y ago
        I absolutely agree, the trial period should be discussed up front. Full disclosure. There will always be special cases.
- mtviewdave 15y ago
  >Why do an audition project when you can fire candidates who do not work out within the first three months? Because then good people won't come work for you. I would not interview at a company that had a reputation of firing a significant portion of its employees within 3 months. Not just because of the obvious career and financial risk. But because a company that treats its employees as disposable is likely not to be a good place to work in general. And I doubt I'm the only one who feels this way.
btilly 15y ago
Good luck hiring someone who is merely unhappy in their current job. If someone is in a full-time job, it is hard enough to find time to go to interview. Good luck finding a free week to do a side project for you. They will self-select out of your selection pool, yet they are very valuable possibilities. Ditto for a probation period, why would someone with a job go work for 3 months for the possibility of maybe getting a different job? Yet that said, I don't think this is bad advice. A company will see many candidates that could have worked out, the challenge is making sure you don't wind up with a promising looking dud. A high rate of false negatives are OK, so long as you don't get a false positive. But it also isn't the only good way to do it.
- dustingetz 15y ago
  the challenges you describe are, i think, why networking is really the only viable way to find the best talent - self-selection can work in your favor, if you're doing it right. One of the leaders here in the Philadelphia tech community, Kyle Burton, talks about networking on HN here[1] - he is running a Clojure startup and has had little difficulty hiring due to the time he spent cultivating the local community. he hosts his own clojure meetup which it appears he can hire from at will. edit: i just emailed him to belatedly ask permission to quote him, maybe he will chime in here. "I was actively recruited to the team. I personally believe that this was because I made a conscious effort in the fall of 2008 to start being much more active in the community at large. I started doing more visibile things on the internet: a blog, putting up a sandbox on github. I also started speaking at local user groups (god bless them for listening to my first talks and my horrible, horrendous presentation skills). ... "By 'recruited into' I mean that not in the sense that either side used a recruiter. I mean I was approached through my network because of the effort I put into building the netowrk and the effort I put into building a personal brand (as slimy as that sounds, it is working). ... "Actively working at networking has been wonderful. I can't recommend it enough. I was involved in starting a "tech breakfast" meeting that takes place 1x a month. The local groups (esp volunteering to speak), the breakfast sessions, and buying people lunch (an hour of interesting conversation is totally worth the $10, and every time it has come back to me) has gone a long way to building a local network." [1] http://news.ycombinator.com/item?id=2832571 http://news.ycombinator.com/item?id=2832571
dustingetz 15y ago
John D Cook has a lot to say about this: [1] "One of the marks of a professional programmer is knowing how to organize software so that the complexity remains manageable as the size increases. Even among professionals there are large differences in ability. The programmers who can effectively manage 100,000-line projects are in a different league than those who can manage 10,000-line projects. ... Writing large buggy programs is hard. ... Writing large correct programs is much harder." Jeff Atwood's metrics will help you filter out engineers whose complexity ceiling is <1k lines -- StackOverflow answers, whoopee -- but that's not a terribly hard thing to interview for. Much harder to interview for the very best, the mythical 10x productivity programmers[2], those who can handle 100k LOC, 1M, or more. Perhaps this is the difference between an experienced non-expert and a real expert[3]. In my experience not a lot of employers care about this, perhaps because their challenges aren't those of complexity-in-scale, or perhaps because complexity hasn't bit them hard enough yet, or perhaps because they are "unconsciously incompetent"[4]. About the only hiring signal I've identified for this is interest in functional programming -- languages like Clojure and Scala exist precisely to raise the ceiling of complexity a human can handle[6] -- and as such I'm trying to learn this stuff and trying to find people via the community who care to hire engineers with these skills. Unfortunately my own bias may be blinding me, you never know which side of Dunning-Kruger[5] you're on until it's too late. If you care about these things: I'd love to know who you are and what you're working on, email me. [1] http://www.johndcook.com/blog/2008/09/19/writes-large-correct-programs/ http://www.johndcook.com/blog/2008/09/19/writes-large-correc... [2] I am not one of these, but I strive to be one someday. [3] http://www.dustingetz.com/how-to-become-an-expert-swegr http://www.dustingetz.com/how-to-become-an-expert-swegr [4] http://en.wikipedia.org/wiki/Four_stages_of_competence http://en.wikipedia.org/wiki/Four_stages_of_competence [5] http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect [6] Clojure creator Rich Hickey talking about complexity: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy edit: man, this got 2 downvotes in 2 minutes, cmon guys i put a lot of thought into this!
- jacquesm 15y ago
  > man, this got 2 downvotes in 2 minutes, cmon guys i put a lot of thought into this! That really sucks because there is some very good stuff in here. One thing that I find strange is to assume that those that are really good at this would have the time to maintain a stackoverflow profile. Likely they're too busy raking in the $. On the other hand start-ups likely can't afford those guys anyway. Until they drown in a 150K loc tangle that makes spaghetti look structured.
cyanbane 15y ago
Totally agree with judging people based on their portfolio, however a lack of StackOverflow achievement currency or github commits doesn't signal much.
einhverfr 15y ago
Actually this is entirely how I would expect to go about it. I recently looked into the way my alma mater hires IT folks and they give you a set of around 6 essay questions. Things like "Please tell me about two projects which best define your ability in terms of X." X might be network engineer, web developer, etc. For grins and giggles (and to help me figure out my hiring process) I went ahead and filled it out. The result was essentially the sort of portfolio that they were asking about. I do agree that you want to see someone's work but I don't think it needs to be an audition project. Even a properly done portfolio takes a bit of time to put together.
robomartin 15y ago
Sounds good...if you are hiring 15-year olds. If someone asked me to write a "Hello world" program in an interview I'd get up and leave (or hang up the phone). It's an insult. This would be very clear sign that I was talking to the wrong people. A lot has to happen before a formal interview takes place. If you have to ask a guy (or gal) to write a "hello world" program it probably means that you have absolutely no clue who you are talking to and have done zero homework pre-interview. You know what I want to see? Bring your laptop to the interview. Let's connect it to a projector and take me through some code that you've written. Inside of 30 minutes I should know what kind of a programmer you are. In 60 minutes I probably have enough data to decode your DNA and tell you what you are going to die from. What the hell are you going to learn from printf("Hello world")?
- robomartin 15y ago
  I'll add to that. I am far more interested in how a programmer thinks and how they might attack and evolve a problem. For example, let's say that they wrote some GA code. Show me the first version. Explain it. Then show me the evolution of the code and how (and why) you optimized it and what results you got. Tell me where you made mistakes and why. Tell me what you'd do differently next time. That sort of thing would tell me a lot more about someone than the procedure delineated in the article.
- nkassis 15y ago
  I have to disagree with you. This isn't supposed to insult you and it can be prior to the in person interview. I did an interview once and asked them to interchange the value of two variables in any language they wanted. In the end maybe 2 out of the 20 applicants that past our HR dept checks got through this. This one only one question, I there was much harder questions on my test but none that I or another person on the team couldn't answer in less than 1 minute. It was a disaster and I ended getting forced to hire someone from that pool anyway. That hire didn't mesh well at all.
  - robomartin 15y ago
    I guess my point is that there has to be something wrong with the hiring process if 2 out of 20 applicants can't swap the values of two variables. Either that or there's something very seriously wrong with CS programs. How can someone walk into an interview with a degree and fail something like that? If the quality of candidates is that bad, then, OK, maybe I'm wrong about the "hello world" test. In my reality someone wouldn't even get an interview without evidence of prior non-trivial work. Hence my rejection of the "hello world" test. I also recognize that if you are hiring massive numbers of people you need to mechanize things a bit. I couldn't see sitting down with someone, their laptop and a projector for an hour under those circumstances. Thankfully that is not my world...at the moment.
cletus 15y ago
As much as people like to deride #1 (here and elsewhere) it's one of the most useful filters (in terms of filter value for effort spent). It's not a positive filter (in that a candidate who passes won't necessarily be a great programmer) but it is a great negative filter (a candidate who fails almost certainly isn't). #2 I have mixed feelings about. A lot of people work on things where the source code (even the product) isn't visible. Having an SO profile is semi-useful but lack of one doesn't really mean anything. Github only makes sense if you work on open source (and frankly I'm tired of the incredibly naive "Github is the new CV" postings that pop up every few weeks). #5 is what I really object to. At least in this case you've gone through the initial filters. Some companies use an audition project as an initial filter before you've ever spoken to anyone (you know, to see if you'd be a cultural fit and so on). I have zero time for this. The problem with an audition project is that anyone truly good won't have to jump through those kinds of hoops. They'll have their pick of offers as is. Job seeking through a traditional (non-network) route is relatively low percentage such that there's only so much time worth investing in any particular position. I'm happy to prove to you know I have a solid enough foundation in data structures and algorithms, I can program my way out of a paper bag and I can problem solve and communicate effectively but as soon as you ask me to spend a week--even a day--on some audition project, forget it. Honestly, hiring isn't that hard. You just need people who are good at hiring to do it. I've done 10 or so "lunch interviews" at Google this year. This isn't an interview per se. It's simply taking someone to lunch in between their onsite interviews. It's a chance for the candidate to unwind, ask some questions, etc. But there is no feedback element to the process. Of the 10 after 10 minutes I predicted 8 wouldn't get hired, 1 would and 1 I wasn't sure about. Turns out the "yes" declined an offer and the "maybe" didn't get one and I was otherwise right. And this is simply from going to lunch with them. My formula is: 1. Filter early. "Hello world" and other simple programming tests; 2. Establish technical foundation and problem-solving ability (with one algorithm-related question that should be coded); and 3. Otherwise ascertaining personality/cultural fit. This you should get just from talking to someone for 10-15 minutes. It's really not that hard. You just need someone who can actually do it to do it.
- deleted 15y ago
  [deleted]
- deleted 15y ago
angrycoder 15y ago
They always tell you when you are interviewing you should never bitch or gossip about your old job. Articles like this are the inverse of that, the employeer is subtly bitching about every bad hire they've ever made. This is a giant red flag that whoever is doing the hiring sucks at their job. I've had a few interview process that have included some or all of these 6 steps, and I've turned down every one of their offers at the end. Not because I don't have the time to work on a sample project,or because I can't cobble together and isolate some sample code for them to take a look at, and not because I don't know how to play the interview game. It is because your interview process takes too damn long. One or more phone screens, one or more in person interviews, then a request for a sample project or source code, then a request for references, then a meeting with team, etc. That takes months, with weeks of down time in between. If you can't figure out if a person is a good fit socially and is a competent programmer in less time that, you suck at hiring and shouldn't be doing it.
- deleted 15y ago
  [deleted]
- amcintyre 15y ago
  I've started flatly turning down offers from one large company in particular because of this. It didn't help that they only wanted to conduct their two or more 1+ hour phone screens during banker's hours.
  - gaius 15y ago
    7sm - 9pm?
    - dangrossman 15y ago
      9AM-4PM, give or take an hour either way. In other words, guaranteed to be during your working day at your current employer.
    - amcintyre 15y ago
      I wish; that would have been easy to accommodate. dangrossman has the right range: they wouldn't even go as late as 4pm, or as early as 9am, which suggests to me they're only looking for people that are out of work or otherwise desperate enough to take what they can get.
radagaisus 15y ago
Just a minor point about hiring young developers. I was first employee in a start up before I even finished high school. A real start up, with backing from a top VC and an amazing founding team. On the interview I looked eager to start getting shit done. I was super enthusiastic, asked hard questions, trash talked technologies - I looked like I actually knew what I was doing! Then I went home and started to learn all those three letter acronyms they talked about. You have to check that people can actually code. I'm not talking about algorithms, I'm talking about string truncation, url shortening service, time_ago_in_words - some programmers do know how to oversell themselves.
jiggy2011 15y ago
The problem with stack overflow is that I ask for more questions than I answer. There's a few reasons for this. 1) Finding time, although I can easily justify asking questions on SO at work it doesn't seem quite right using my employers time to answer somebodies (probably coursework) question and it's something I'd have a hard time justifying to the MBA types when there is other work that I could be doing. So my only option would be to go back home and specifically go on to answer questions. 2) Finding good questions to answer can be difficult since I only use a relatively small toolbox of software that is not particularly popular and I usually have more luck discussing it on google groups than on SO. So that only leaves me with the easy lowest common denominator questions that have either already been answered or don't look terribly impressive to answer just as a way to earn points. I would rather write a case study of developing something and problems that I solved along the way and publish this on a blog, of course I would have to be careful doing this about work things as well.
shioyama 15y ago
As someone who has not yet worked professionally as a programmer (nor hired one), I might not be the best person to comment on this article (so take what I write with a grain of salt). But as someone aspiring to do so, I find this article and others like it on HN frustrating. For one thing, as mbenjaminsmith noted, for small (and I'd argue medium-sized) companies, setting up so many hoops for a programmer to jump through doesn't strike me as a very smart strategy -- you'll likely end up with very few candidates. But more importantly, the "hoops" listed in the article mostly filter for a particular type of candidate. In fact, the whole "jump through hoops" approach to hiring itself frustrates me -- not because I don't think I could jump through them, but because of the place I would end up in if I did. I come to programming with (what I consider to be) a fairly diverse background. One of the things that I immediately sense in recently having crossed over (in my free time, currently) into coding and into the profession of coding is how homogeneous the community tends to be: on the surface (for example) almost exclusively male and dominated by a relatively narrow demographic, but deeper down also lacking in a diversity of life experiences. I would argue that the process described in this article is partly responsible for maintaining this lack of diversity, by the simple fact that it encourages the "hoops" mentality. Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny? I have no idea. Can I find the largest int in an array? Sure, but why in the world are you asking me this? And FizzBuzz (linked in #1): yes I get it, it's easy and it filters out 199 out of 200 candidates, but what about those 199 other candidates? Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons? People have such a diversity of skills and experiences. Sure, a portfolio can express some of this. Selecting from your community (#3) also strikes me as very sensible. But to find the outlier candidates who have broader potential and knowledge of problems outside the "canon" of standard programming practice, I think you have to take a more open-ended approach. In the end, I guess maybe the problem for me is that the whole "How to Hire a Programmer" idea itself strikes me as somewhat misguided. A guide to "hiring a <fill_in_the_blank>" is only ever going to filter for cookie-cutter representations of <fill_in_the_blank>, whatever that profession may be.
- jbri 15y ago
Mizza 15y ago
It's funny to see a similar blog do exactly the kind of SEO targeting I've been doing: http://gun.io/blog/how-to-hire-a-programmer/ http://gun.io/blog/how-to-hire-a-programmer/ Same title and everything. Hooray Google Keyword Tool! (The content is different, this is about full time employees and not freelancers.) I'm glad to see that he recommends _actually paying_ the programmer doing the trial period! I see this kind of article a lot, the advice is always the same, but often they suggest the trial be unpaid.
rickmb 15y ago
Oh goodie, yet another checklist for people who don't know how to hire. Not that I claim to be awesome at it, but hiring and interviewing people is a skill, just like programming. It's not something you can get right by just having a checklist. Despite all the cute anecdotes we like to tell about clueless HR people, it is actually a real profession, one we could learn a lot from if we weren't so busy circlejerking about coding tests and whatnot.
dinkumthinkum 15y ago
I don't really agree with this, as usual. If you follow these directions, you might end up ok but you can definitely miss a lot of good people, and yes I'm aware of the meme about being happy to miss Knuth in order to avoid any blubs. I also think it's not practical for a lot of companies. As well, I know around these parts it is almost sacrosanct that one should have a Github, possibly blog, etc but there are many great programmers that do not have such a portfolio. I mean, many of these programmers are very good, deeply technical, and work on quite serious things. As far as #5, you will definitely miss out on people there. Many people with real talent actually have bills to pay and companies willing to pay them without some trial project. I understand the reasoning here, I mean, wouldn't it be great if we could go a step further and get someone to work for free for a year before we start paying them, just to make sure they are in it for the "long haul." #6, I have no problems with; it's quite reasonable. Honestly, I have followed Atwood for years, how many of these things would he actually pass, besides the thing about being very public? - no ad hominem, purely tangential.
- codinghorror 15y ago
  I'd probably be at most risk of not passing the phone screen, depending on how anal the interviewer is (read: whether they are a hard-core C programmer type). E.g. particularly if they asked coding questions about pointers and so forth. I've always hated C, ever since I tried to learn it in high school back in 1986 or so. The big picture stuff about bits and bytes and data structures I think I'd do OK on.
trustfundbaby 15y ago
You missed one Jeff ... treat them with respect. I've interviewed at a lot of places, and some of the things these companies do is breathtaking ... that's when they're interested in you. They try to schedule you into 3-4 hour interviews like you don't have a job to do that day. They send you coding assignments that take 4-8 hours to do. Interviewers get your resume 15 minutes before they walk into the room with you, then ask you to rehash your entire background (because ... you know ... that shit isn't in the resume in front of you already). Then there's the default position some of them take that 90% of the people they interview are idiots, so they're just going to treat you as such until you prove them wrong. I had one firm set me up for an interview, and then cancel it without actually telling me, until I emailed about 2 hours to the time of the interview wondering what was up etc etc But that's just the half of it, as soon as some of them decide you're that worthless programmer who didn't pass their pet brainteaser/trick question, they won't even do you the courtesy of telling you that you're out of the running. The recruiter who was all so chummy with you and positive about your prospects goes AWOL and you get that dreaded automatically generated rejection email. If you felt good enough about me to actually talk to me on the phone to get me to interview, why can't you even email me to cut me? Just man up and do it like the movie Moneyball. "Sorry x, you didn't make the cut. Good luck in your search". I'm a professional, I can take it. Its all rather exasperating, because we both want the same thing in the end.
suresk 15y ago
These seem like mostly good ideas. I do see some problems with things like GitHub and SO rep becoming so important in the filtering/hiring process - it gives a huge advantage to those who work at companies with good open source policies. Open source contributions and contributions to community resources like SO can be useful, but I hope the lack of them doesn't cost too many people shots at interviews - there are a lot of good developers with no presence on SO or GitHub. I do, however, have a bigger problem with #5. It seems fine at first glance, provided the company is being honest about it, but from the perspective of the potential employee, it is hard to know if performing well on the 'audition' is really all that is standing between you and the job. About 8 years or so ago, I was applying for a new job. The interviews all went pretty well, and I was given an audition project that was aligned with this companies product very tightly. I spent several evenings (probably ~8 hours total) working on it and submitted what I thought was a pretty good project. After I followed up with them a while later, I was told that while my submission was the best one they'd seen, they weren't going to be extending me an offer. I sort of wondered if they were using applicants to build their product, but it seems like it was a lot of overhead on their part. Either way, I wasn't pleased that I'd been given a project to work on even though I apparently wasn't going to get hired anyway.
kamaal 15y ago
Frankly speaking I interviewed for a bigMegaCorp last year which is pretty famous. Can't give out the name of the company for obvious reasons. They first had a telephonic round and checked around my skills. They talked of my last projects and make me write some code. It went well. Then they invited me to have some onsite interviews. It was the most pathetic interview experience any body could ever have. They gave me a laptop and made me code. Which I did. The first day they had three 1.5 hours session coding session based interviews. Of which I missed only on one question. They went pretty fine. They told two days later I need to go through more interviews, It was a another two coding sessions plus a database and common design pattern based interview which I also did well. But they called in a week later and said I needed to come again. Frankly speaking my patience had ran out. But nevertheless I still went. Only to find I had to go through another three rounds. This time the experience was pathetic. Its was full of puzzles and memorizing arcane facts of various bits and pieces of software which I bet no productive programmer will ever have time for. It was puzzles and fact quizzing galore like I had never seen before. Coupled by one Algorithm interview and I bet they asked mathematics I had never heard of before. Another week later they told me I was rejected. Now this is what I have a problem with. You want somebody who can build quality software, who knows his trade. Programming languages, Databases, Tools, design patterns, Quality and other daily stuff. How the hell does it matter the guy doesn't know facts and puzzles? Frankly speaking I can learn that too! If I spend 30 mins a day reading the career cup ebook and other internet puzzle forums I can very well game the algorithm and puzzle rounds. But what will this every say about my skills as a programmer? All this 'Github as a resume' , and 'Stackoverflow profile as a resume' work fine only in forums like these. Otherwise every interview has a puzzle and algorithm quiz round which has absolutely no relevance to the daily work of a programmer. Honestly all big web companies claiming to hire the best are definitely hiring the most knowledgeable person. But none of them are hiring outliers, passionate and productive people who can do miracles. This also perfectly explains, why most of their innovation and growth happens through acquisitions and not in house innovations. Because most companies have people who know a lot, but not necessarily who can do a lot.
hef19898 15y ago
In any technical domain, it's hard to identify the right people, even you base your hiring process on recommondation letters as it is done over here in Germany. These letters, and CVs and degrees as far as that is concerned, only get you so far. After thinking about it (and deleting my first comment), I see it as some good basic advice for first time employers. What I don't really get is the point with the trial project... Do start-ups and highly qualified experts (supposed you actually want experts) really have that much time to waste? I don't think so. One important point mentioned in the comments was culture, and yes it is paramount. Especially in disruptive, small companies where you cannot afford to have the average well-adopted worker drone around you usually get from HR in bigger companies, ideally the founders are around to communicate the culture themselves. Ouliers actually are a good place to start looking if don't already know your candidates. Personally, I like interviews whith people who actually have a say in the hiring, only HR usually sucks. Added benfit: people knowing their job usually can tell after professional discussions (and some tests that can be done in a couple of minutes to identify the liers) if the prospective employee knows his job or not. Disclaimer: Non-american non-programmer commenting, so please be kind :-) p.s.: Treat them with respect, because if you don't you'll only get the desperate and they tend to be desperate for a reason.
boskonovitch 15y ago
#2 in addition to seeing their portfolio they should also give you a code review and explain what the code does.This avoids code plagiarism.
singular 15y ago
Though I'm not saying there aren't good points here, there are many, I think it's interesting to consider the usual impact of discussions on this subject - typically a great deal of insecurity/defensiveness (I feel it too), which I don't mean to say in a negative light, in fact I think it's quite natural. It's worth quoting Steve Yegge's fantastic 'get that job at google' [1]:- 'Me: blah blah blah, I like asking question X in interviews, blah blah blah... You: Question X? Oh man, I haven't heard about X since college! I've never needed it for my job! He asks that in interviews? But that means someone out there thinks it's important to know, and, and... I don't know it! If they detect my ignorance, not only will I be summarily fired for incompetence without so much as a thank-you, I will also be unemployable by people who ask question X! If people listen to Stevey, that will be everyone! I will become homeless and destitute! For not knowing something I've never needed before! This is horrible! I would attack X itself, except that I do not want to pick up a book and figure enough out about it to discredit it. Clearly I must yell a lot about how stupid Stevey is so that nobody will listen to him!' [1]:http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...
CodeMage 15y ago
Okay, to get this out of the way first: I completely agree with Jeff that hiring programmers is hard and that the way a lot of companies go about doing it is about as effective as Russian Roulette. I've seen it and felt some of the dismal consequences. As a matter of fact, I still have to work with lots of those people that should have been filtered out in step 1. So yeah, I agree with the idea. Having said that, his process, taken together, is ridiculously one-sided. The message it sends comes across as "Of course you want to work for us, regardless of all the hassle we're putting you through, who wouldn't? Only someone out of their mind, that's who! And we don't want people like that here." Think about it, Jeff. You are asking for someone who: 1) is highly skilled 2) has an attractive portfolio 3) is mature enough to communicate well A lot of people like that already have jobs. If you want them to do #5 -- which might be something they're forbidden by their current employment contract, by the way -- and you also want them to prepare a presentation for #6, you must be the sexiest employer on the Earth. In short, what do you propose to balance things out?
- pavel_lishin 15y ago
  I'd wager that someone who is highly skilled can afford to take several days off work.
  - CodeMage 15y ago
    This is simply unreasonable. Those days off work come from somewhere, usually paid or unpaid vacation time. In other words, you're either cutting into the time reserved for your family/social life or you're paying out of your pocket. To put it simply: your approach doesn't scale.
ap22213 15y ago
Why doesn't short-term contract to hire work? Seems like it would save a lot of time, with very little risk.
- bryanlarsen 15y ago
  That strategy works great in a down economy when jobs are hard to find. But most good programmers have jobs, and are not going to leave a full-time job for a short-term contract.
- chollida1 15y ago
  To generalize, most good employee's already have jobs. It's going to be hard to get them to quit inorder to do short term contract work in the hopes that they might get hired by you.
- chrisbennet 15y ago
  If you don't already have a job, there is little risk. However, if you have to quit your job to "try out" another job, you most likely want a little more assurance that you'll still have a job in a few months.
SanjayUttam 15y ago
I see posts like this regularly on HN (lists of stuff you should do to hire that top 1% of talent). What I don't recall seeing, though, is a post more along the lines of employment branding. I understand how for very small start-ups that may just be a waste of time but when you get to a certain point it seems like you're going to want to do something. That might just be having a labs.yourCompany.com blog, or releasing an open-source project once in a while. I think that great devs want to work places where they know the work is interesting/fun/whatever. It's a lot easier for you to get the word out via say a blog, rather than have a 1-1 conversation with someone over the phone to communicate the cool stuff you're doing. Just my 2 cents.
trefn 15y ago
These 5 phone screen questions are lifted almost directly from Steve Yegge's "Five essential phone screen questions" post - https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho... 1) Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java. 2) OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem. 3) Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages. 4) Data structures. The candidate has to demonstrate basic knowledge of the most common data structures. 5) Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers. They even use the same regex example. He attributes other things to Steve, so maybe this is just an oversight, but I'd like to see another link.
lhnz 15y ago
I can see all sorts of ways that this will give you false negatives. This is what I would recommend: 1. Via an online test: check if they can code something very very simple. (This is your threshold that simply exists to not waste so much time.) 2. In their CV: Look for public-facing indicators of skill: github account, stackoverflow account, blog posts, etc. (Bias towards candidates with these indicators, but do not discriminate against those without. These are indicators of true positives and not true negatives.) 3. In a phone interview: ask about and then assess their breadth of knowledge. Find out their passion. 4. In a phone interview: test the depth of their knowledge in a relevant category of knowledge. If they are struggling then attempt a question in something they're passionate about. (This is the point where you detect true negatives.) 5. In the interview room: give them a choice of hard problems -- the sort you would want them to work on if they joined. (This is where you detect true positives.) 6. In the interview room: find out whether they're the right cultural fit for your company. (This is where you filter out any true negatives that remain.)
NDizzle 15y ago
I always see these kind of hiring practices put into place and enforced AFTER I'm already hired and working. (no, I don't conjure up hiring practices like these.) Simply put - I wouldn't have gotten my own job if I had to conform to these standards.
tobiasSoftware 15y ago
I have issues with both #2 and #5, having just gone through the getting hired process myself. I think a portfolio is good, but I can't stand this "let's look at Github and Stack Overflow" attitude. To my interviews I brought four projects that I plan to sell one day and one project that I worked on but wasn't mine, so these projects are not open source and I don't like this trend of employers expecting all this open source code. I have real working programs in my portfolio, that should be good enough, if I show you the code you would just nitpick on it anyways. Give them an audition project: Just no. The suggestions in the article definitely help, but audition projects as I've seen them are horrible, and even with the suggestions, you still need tons of time that you probably don't have unless you are unemployed. Maybe if it's an hour test-like thing, I had a good test project with a company that was an hour long, it tested me on a programming language I had never used, I guess it was more similar to a hello world programming example than anything else. However my other experience with audition projects was the week type. It was two questions, given BEFORE the first interview as a pre-screen. The first was a 2 page single spaced paper on an economic question. This was about 10% the length of the major research paper I had to do around the same time, all I could think of was how much better my time would be spent doing that. The coding question was far worse, something about triangulating a trapped miner using his cell phone records. There were so many things not explained that I would need, like the API of the cell phone records or how the data was stored that I felt like either I would have to ask the guy for more information than he would give or that it would be totally fake. Oh, and on top of all that, they gave me a deadline of the work week, not even a weekend. I was in school at that time and only had a few hours on weekday nights. From my personal experience (which very well may be colored by the one example above), I would have to say that projects as part of a hiring process are for desperate candidates. It will screen out the dumb or lazy ones, but it will also screen out the skilled ones because they will figure it's not worth their time trying to do tons of work for a company that very well may not give them a job, and that the time would be better spent doing something REAL (and not unpaid work for the company either), maybe even a project to put in a portfolio and show off to all companies they are interviewing for.
dspeyer 15y ago
> Instead, I have my own theory about how we should interview programmers: have the candidate give a 15 minute presentation on their area of expertise. ... The one thing every programmer should know, per Steve Yegge, is how to market yourself, your code, and your project. I wholeheartedly agree. Now pitch me! Yikes! This really looks like an anti-test. I'd rather work with people who don't know how to market themselves -- that marketing skill would distort every technical discussion I had with them. Even if that is a skill you want, a programmer who's really bad will almost certainly know how to bluff for 15 minutes -- they've been practicing their entire career! -- whereas a good programmer hit with that will probably wobble a bit looking for a topic. Even if you have a extraordinary bullshit detector, it's still a poor signal. It won't tell you what the candidate is weak at -- and that's often the most important thing to determine.

250 points by cruise02 15y ago

stch 15y ago

So hows the audition project work? Do you guys just hire the person on as a consultant for a week, or what? I'm curious, because I've never heard of this before.

invalidOrTaken 15y ago

Also worth reading: http://www.deserettechnology.com/journal/writing-a-good-job-ad-for-a-programmer http://www.deserettechnology.com/journal/writing-a-good-job-..., by HN's very own cookiecaper.

lachyg 15y ago

One thing I've really struggled with since coming to San Francisco is that every company seems happy to take extensive time out of a programmer for an interview, including an audition project. Yet if you ask this of a designer, you get shot down immediately for soliciting spec work.

kgrin 15y ago
Jeff's suggestion - perhaps not followed by everyone who does an "audition project" - is that the project be paid. (Spec work, of course, isn't guaranteed to be).
- lachyg 15y ago
  I understand, and applaud Jeff for that, but most companies don't pay for their interview process, many of which can be multiple full day affairs. I can't imagine a company not getting backlash holding a design competition to 'interview' designers.
Melyan 15y ago
Programmers seem to work for free on Linux and other projects, while designers seem to be more eager to get paid. Given these common memes, people may think that programmers are eager to do any kind of work for fun.
dustineichler 15y ago
The audition project is pretty unheard of. It's time consuming on both ends especially if it's a week or more. What's more common is the 4 hour assignment, which annoys me to no end anyways.
notJim 15y ago
I think part of this may be that since programmers typically make more money and tend to be more valued, the upside for them of doing spec work is much higher. Even if salaries for developers and designers are comparable in startups, this is in-general not true from what I've seen, so designers as a community have banded together to stigmatize doing spec work. I'm explaining this situation, and how I think we might have gotten into it. To paraphrase a W3C spec: this comment is not normative.
lrobb 15y ago
The design profession is light years ahead of programming in that regard... Probably because of its print history. I'm reminded of this great presentation by the mule design guy (NSFW) F*ck you, pay me: http://vimeo.com/22053820 http://vimeo.com/22053820

jamesli 15y ago

Interview is a two-way process. The company must know who are their good interviewers and who are not. A not-so-good interviewer may not only give false-positive feedbacks but also contributes to pass really good candidates. To be worse, a lousy interviewer may produce a negative image to the company and actually drive a good candidate away. I think many people may have the experience that an interviewer was so rude and arrogant that no way would you join the company and work with the interviewer.

johnx123-up 15y ago

My personal favorite: How to interview a candidate/programmer http://rajeshanbiah.blogspot.com/2009/01/how-to-interview-candidate.html http://rajeshanbiah.blogspot.com/2009/01/how-to-interview-ca...

mirsadm 15y ago

Once you work at a few places and go through this process many times you get sick of it and create your own startup :P

mbenjaminsmith 15y ago

I was about to scream about #5 until I saw this: "This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement." I interviewed with a YC company about a year ago and was asked to do #5 except without pay. It's a long story, but in short I let my guard down because it was a YC company only to find myself having wasted a week. The part that really pissed me off is that they came back _months_ later and pretended that no time had passed at all (obviously their hire didn't work out) and asked me to jump through more interviewing hoops. When I rightfully just told them to put money where mouth is they actually insulted me and the free work I had done (written in an email no less). The point I'm making is that if you need this many hoops for a candidate to jump through you shouldn't be the one hiring. Find someone else with a business-tuned intuition and ability to judge character. If you act like you're the world's greatest company which people will waste hours and even days trying to impress you're going to miss the best people out there. Also #2: "Show me a Stack Overflow profile where I can see what kind of communicator and problem solver you are. Link me to an open-source code repository of your stuff." Kinda cheesy for Jeff to say the first part. I absolutely agree with supporting both info sharing sites and open source. But as a self-taught programmer that ships products and does very well financially, I can tell you that there are effective people out there that don't rely on SO to get things done and therefore probably don't contribute to it. I do absolutely support open source software but I also don't have a lot of free time. I've written a raster to vector conversion library that I'd love to clean up a bit and open source. But I literally don't have time to do so. Does that make me a second class programmer? Having hired many people over the years I know that I would look very seriously at someone who has shipped a lot of products but doesn't follow programmer community trends like SO. I guess it could mean they're truly horrible programmers with no knowledge to share. It could also mean they're too busy meeting their own (or some company's) targets. It could also mean they like to unplug once in a while and lead a normal life. I understand why companies like Google take a hardline approach to hiring. They just deal with too many people. But if you're reading Jeff's essay on hiring you're not running Google. If you're a small company you need to look at the outliers first since that where you're likely to find overlooked talent. That's where you're going to find the people who don't jump through hoops but who actually get shit done on a daily basis.

15y ago

dpdp_ 15y ago

Why do an audition project when you can fire candidates who do not work out within the first three months? My advice is to trust yourself and hire people you like. Take a leap of faith. If things do not work out - be quick to pull the trigger.

pagekalisedown 15y ago
Why not? Sadly, because we live in a litigious society.
- dpdp_ 15y ago
  General Counsel gets a fat paycheck to take care of that. Avoiding litigations is simple too - do not hire dicks; ever. If you hired a decent person in the first place, and after two months things are clearly not working out, you can part ways in a civil fashion.
  - karamazov 15y ago
    It's not always that simple. What if that person quit their last job to come work here? Quit and moved across the country? Gave up other promising opportunities? I'm not saying you can't fire people, but unless a trial period is explicitly agreed upon beforehand, there's an expectation that a job will last more than a couple of months if the new employee is putting in real effort. I don't know where to draw the line, but even an employee who isn't a dick might sue if they rearranged their life only to be let go two months later; I'd argue that they also deserve to win.
    - dpdp_ 15y ago
      I absolutely agree, the trial period should be discussed up front. Full disclosure. There will always be special cases.
mtviewdave 15y ago
>Why do an audition project when you can fire candidates who do not work out within the first three months? Because then good people won't come work for you. I would not interview at a company that had a reputation of firing a significant portion of its employees within 3 months. Not just because of the obvious career and financial risk. But because a company that treats its employees as disposable is likely not to be a good place to work in general. And I doubt I'm the only one who feels this way.

btilly 15y ago

Good luck hiring someone who is merely unhappy in their current job. If someone is in a full-time job, it is hard enough to find time to go to interview. Good luck finding a free week to do a side project for you. They will self-select out of your selection pool, yet they are very valuable possibilities. Ditto for a probation period, why would someone with a job go work for 3 months for the possibility of maybe getting a different job? Yet that said, I don't think this is bad advice. A company will see many candidates that could have worked out, the challenge is making sure you don't wind up with a promising looking dud. A high rate of false negatives are OK, so long as you don't get a false positive. But it also isn't the only good way to do it.

dustingetz 15y ago
the challenges you describe are, i think, why networking is really the only viable way to find the best talent - self-selection can work in your favor, if you're doing it right. One of the leaders here in the Philadelphia tech community, Kyle Burton, talks about networking on HN here[1] - he is running a Clojure startup and has had little difficulty hiring due to the time he spent cultivating the local community. he hosts his own clojure meetup which it appears he can hire from at will. edit: i just emailed him to belatedly ask permission to quote him, maybe he will chime in here. "I was actively recruited to the team. I personally believe that this was because I made a conscious effort in the fall of 2008 to start being much more active in the community at large. I started doing more visibile things on the internet: a blog, putting up a sandbox on github. I also started speaking at local user groups (god bless them for listening to my first talks and my horrible, horrendous presentation skills). ... "By 'recruited into' I mean that not in the sense that either side used a recruiter. I mean I was approached through my network because of the effort I put into building the netowrk and the effort I put into building a personal brand (as slimy as that sounds, it is working). ... "Actively working at networking has been wonderful. I can't recommend it enough. I was involved in starting a "tech breakfast" meeting that takes place 1x a month. The local groups (esp volunteering to speak), the breakfast sessions, and buying people lunch (an hour of interesting conversation is totally worth the $10, and every time it has come back to me) has gone a long way to building a local network." [1] http://news.ycombinator.com/item?id=2832571 http://news.ycombinator.com/item?id=2832571

dustingetz 15y ago

John D Cook has a lot to say about this: [1] "One of the marks of a professional programmer is knowing how to organize software so that the complexity remains manageable as the size increases. Even among professionals there are large differences in ability. The programmers who can effectively manage 100,000-line projects are in a different league than those who can manage 10,000-line projects. ... Writing large buggy programs is hard. ... Writing large correct programs is much harder." Jeff Atwood's metrics will help you filter out engineers whose complexity ceiling is <1k lines -- StackOverflow answers, whoopee -- but that's not a terribly hard thing to interview for. Much harder to interview for the very best, the mythical 10x productivity programmers[2], those who can handle 100k LOC, 1M, or more. Perhaps this is the difference between an experienced non-expert and a real expert[3]. In my experience not a lot of employers care about this, perhaps because their challenges aren't those of complexity-in-scale, or perhaps because complexity hasn't bit them hard enough yet, or perhaps because they are "unconsciously incompetent"[4]. About the only hiring signal I've identified for this is interest in functional programming -- languages like Clojure and Scala exist precisely to raise the ceiling of complexity a human can handle[6] -- and as such I'm trying to learn this stuff and trying to find people via the community who care to hire engineers with these skills. Unfortunately my own bias may be blinding me, you never know which side of Dunning-Kruger[5] you're on until it's too late. If you care about these things: I'd love to know who you are and what you're working on, email me. [1] http://www.johndcook.com/blog/2008/09/19/writes-large-correct-programs/ http://www.johndcook.com/blog/2008/09/19/writes-large-correc... [2] I am not one of these, but I strive to be one someday. [3] http://www.dustingetz.com/how-to-become-an-expert-swegr http://www.dustingetz.com/how-to-become-an-expert-swegr [4] http://en.wikipedia.org/wiki/Four_stages_of_competence http://en.wikipedia.org/wiki/Four_stages_of_competence [5] http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect [6] Clojure creator Rich Hickey talking about complexity: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy edit: man, this got 2 downvotes in 2 minutes, cmon guys i put a lot of thought into this!

jacquesm 15y ago
> man, this got 2 downvotes in 2 minutes, cmon guys i put a lot of thought into this! That really sucks because there is some very good stuff in here. One thing that I find strange is to assume that those that are really good at this would have the time to maintain a stackoverflow profile. Likely they're too busy raking in the $. On the other hand start-ups likely can't afford those guys anyway. Until they drown in a 150K loc tangle that makes spaghetti look structured.

cyanbane 15y ago

Totally agree with judging people based on their portfolio, however a lack of StackOverflow achievement currency or github commits doesn't signal much.

einhverfr 15y ago

Actually this is entirely how I would expect to go about it. I recently looked into the way my alma mater hires IT folks and they give you a set of around 6 essay questions. Things like "Please tell me about two projects which best define your ability in terms of X." X might be network engineer, web developer, etc. For grins and giggles (and to help me figure out my hiring process) I went ahead and filled it out. The result was essentially the sort of portfolio that they were asking about. I do agree that you want to see someone's work but I don't think it needs to be an audition project. Even a properly done portfolio takes a bit of time to put together.

robomartin 15y ago

Sounds good...if you are hiring 15-year olds. If someone asked me to write a "Hello world" program in an interview I'd get up and leave (or hang up the phone). It's an insult. This would be very clear sign that I was talking to the wrong people. A lot has to happen before a formal interview takes place. If you have to ask a guy (or gal) to write a "hello world" program it probably means that you have absolutely no clue who you are talking to and have done zero homework pre-interview. You know what I want to see? Bring your laptop to the interview. Let's connect it to a projector and take me through some code that you've written. Inside of 30 minutes I should know what kind of a programmer you are. In 60 minutes I probably have enough data to decode your DNA and tell you what you are going to die from. What the hell are you going to learn from printf("Hello world")?

robomartin 15y ago
I'll add to that. I am far more interested in how a programmer thinks and how they might attack and evolve a problem. For example, let's say that they wrote some GA code. Show me the first version. Explain it. Then show me the evolution of the code and how (and why) you optimized it and what results you got. Tell me where you made mistakes and why. Tell me what you'd do differently next time. That sort of thing would tell me a lot more about someone than the procedure delineated in the article.
nkassis 15y ago
I have to disagree with you. This isn't supposed to insult you and it can be prior to the in person interview. I did an interview once and asked them to interchange the value of two variables in any language they wanted. In the end maybe 2 out of the 20 applicants that past our HR dept checks got through this. This one only one question, I there was much harder questions on my test but none that I or another person on the team couldn't answer in less than 1 minute. It was a disaster and I ended getting forced to hire someone from that pool anyway. That hire didn't mesh well at all.
- robomartin 15y ago
  I guess my point is that there has to be something wrong with the hiring process if 2 out of 20 applicants can't swap the values of two variables. Either that or there's something very seriously wrong with CS programs. How can someone walk into an interview with a degree and fail something like that? If the quality of candidates is that bad, then, OK, maybe I'm wrong about the "hello world" test. In my reality someone wouldn't even get an interview without evidence of prior non-trivial work. Hence my rejection of the "hello world" test. I also recognize that if you are hiring massive numbers of people you need to mechanize things a bit. I couldn't see sitting down with someone, their laptop and a projector for an hour under those circumstances. Thankfully that is not my world...at the moment.

cletus 15y ago

As much as people like to deride #1 (here and elsewhere) it's one of the most useful filters (in terms of filter value for effort spent). It's not a positive filter (in that a candidate who passes won't necessarily be a great programmer) but it is a great negative filter (a candidate who fails almost certainly isn't). #2 I have mixed feelings about. A lot of people work on things where the source code (even the product) isn't visible. Having an SO profile is semi-useful but lack of one doesn't really mean anything. Github only makes sense if you work on open source (and frankly I'm tired of the incredibly naive "Github is the new CV" postings that pop up every few weeks). #5 is what I really object to. At least in this case you've gone through the initial filters. Some companies use an audition project as an initial filter before you've ever spoken to anyone (you know, to see if you'd be a cultural fit and so on). I have zero time for this. The problem with an audition project is that anyone truly good won't have to jump through those kinds of hoops. They'll have their pick of offers as is. Job seeking through a traditional (non-network) route is relatively low percentage such that there's only so much time worth investing in any particular position. I'm happy to prove to you know I have a solid enough foundation in data structures and algorithms, I can program my way out of a paper bag and I can problem solve and communicate effectively but as soon as you ask me to spend a week--even a day--on some audition project, forget it. Honestly, hiring isn't that hard. You just need people who are good at hiring to do it. I've done 10 or so "lunch interviews" at Google this year. This isn't an interview per se. It's simply taking someone to lunch in between their onsite interviews. It's a chance for the candidate to unwind, ask some questions, etc. But there is no feedback element to the process. Of the 10 after 10 minutes I predicted 8 wouldn't get hired, 1 would and 1 I wasn't sure about. Turns out the "yes" declined an offer and the "maybe" didn't get one and I was otherwise right. And this is simply from going to lunch with them. My formula is: 1. Filter early. "Hello world" and other simple programming tests; 2. Establish technical foundation and problem-solving ability (with one algorithm-related question that should be coded); and 3. Otherwise ascertaining personality/cultural fit. This you should get just from talking to someone for 10-15 minutes. It's really not that hard. You just need someone who can actually do it to do it.

deleted 15y ago
[deleted]
deleted 15y ago

angrycoder 15y ago

They always tell you when you are interviewing you should never bitch or gossip about your old job. Articles like this are the inverse of that, the employeer is subtly bitching about every bad hire they've ever made. This is a giant red flag that whoever is doing the hiring sucks at their job. I've had a few interview process that have included some or all of these 6 steps, and I've turned down every one of their offers at the end. Not because I don't have the time to work on a sample project,or because I can't cobble together and isolate some sample code for them to take a look at, and not because I don't know how to play the interview game. It is because your interview process takes too damn long. One or more phone screens, one or more in person interviews, then a request for a sample project or source code, then a request for references, then a meeting with team, etc. That takes months, with weeks of down time in between. If you can't figure out if a person is a good fit socially and is a competent programmer in less time that, you suck at hiring and shouldn't be doing it.

deleted 15y ago
[deleted]
amcintyre 15y ago
I've started flatly turning down offers from one large company in particular because of this. It didn't help that they only wanted to conduct their two or more 1+ hour phone screens during banker's hours.
- gaius 15y ago
  7sm - 9pm?
  - dangrossman 15y ago
    9AM-4PM, give or take an hour either way. In other words, guaranteed to be during your working day at your current employer.
  - amcintyre 15y ago
    I wish; that would have been easy to accommodate. dangrossman has the right range: they wouldn't even go as late as 4pm, or as early as 9am, which suggests to me they're only looking for people that are out of work or otherwise desperate enough to take what they can get.

radagaisus 15y ago

Just a minor point about hiring young developers. I was first employee in a start up before I even finished high school. A real start up, with backing from a top VC and an amazing founding team. On the interview I looked eager to start getting shit done. I was super enthusiastic, asked hard questions, trash talked technologies - I looked like I actually knew what I was doing! Then I went home and started to learn all those three letter acronyms they talked about. You have to check that people can actually code. I'm not talking about algorithms, I'm talking about string truncation, url shortening service, time_ago_in_words - some programmers do know how to oversell themselves.

jiggy2011 15y ago

The problem with stack overflow is that I ask for more questions than I answer. There's a few reasons for this. 1) Finding time, although I can easily justify asking questions on SO at work it doesn't seem quite right using my employers time to answer somebodies (probably coursework) question and it's something I'd have a hard time justifying to the MBA types when there is other work that I could be doing. So my only option would be to go back home and specifically go on to answer questions. 2) Finding good questions to answer can be difficult since I only use a relatively small toolbox of software that is not particularly popular and I usually have more luck discussing it on google groups than on SO. So that only leaves me with the easy lowest common denominator questions that have either already been answered or don't look terribly impressive to answer just as a way to earn points. I would rather write a case study of developing something and problems that I solved along the way and publish this on a blog, of course I would have to be careful doing this about work things as well.

shioyama 15y ago

As someone who has not yet worked professionally as a programmer (nor hired one), I might not be the best person to comment on this article (so take what I write with a grain of salt). But as someone aspiring to do so, I find this article and others like it on HN frustrating. For one thing, as mbenjaminsmith noted, for small (and I'd argue medium-sized) companies, setting up so many hoops for a programmer to jump through doesn't strike me as a very smart strategy -- you'll likely end up with very few candidates. But more importantly, the "hoops" listed in the article mostly filter for a particular type of candidate. In fact, the whole "jump through hoops" approach to hiring itself frustrates me -- not because I don't think I could jump through them, but because of the place I would end up in if I did. I come to programming with (what I consider to be) a fairly diverse background. One of the things that I immediately sense in recently having crossed over (in my free time, currently) into coding and into the profession of coding is how homogeneous the community tends to be: on the surface (for example) almost exclusively male and dominated by a relatively narrow demographic, but deeper down also lacking in a diversity of life experiences. I would argue that the process described in this article is partly responsible for maintaining this lack of diversity, by the simple fact that it encourages the "hoops" mentality. Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny? I have no idea. Can I find the largest int in an array? Sure, but why in the world are you asking me this? And FizzBuzz (linked in #1): yes I get it, it's easy and it filters out 199 out of 200 candidates, but what about those 199 other candidates? Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons? People have such a diversity of skills and experiences. Sure, a portfolio can express some of this. Selecting from your community (#3) also strikes me as very sensible. But to find the outlier candidates who have broader potential and knowledge of problems outside the "canon" of standard programming practice, I think you have to take a more open-ended approach. In the end, I guess maybe the problem for me is that the whole "How to Hire a Programmer" idea itself strikes me as somewhat misguided. A guide to "hiring a <fill_in_the_blank>" is only ever going to filter for cookie-cutter representations of <fill_in_the_blank>, whatever that profession may be.

jbri 15y ago

Mizza 15y ago

It's funny to see a similar blog do exactly the kind of SEO targeting I've been doing: http://gun.io/blog/how-to-hire-a-programmer/ http://gun.io/blog/how-to-hire-a-programmer/ Same title and everything. Hooray Google Keyword Tool! (The content is different, this is about full time employees and not freelancers.) I'm glad to see that he recommends _actually paying_ the programmer doing the trial period! I see this kind of article a lot, the advice is always the same, but often they suggest the trial be unpaid.

rickmb 15y ago

Oh goodie, yet another checklist for people who don't know how to hire. Not that I claim to be awesome at it, but hiring and interviewing people is a skill, just like programming. It's not something you can get right by just having a checklist. Despite all the cute anecdotes we like to tell about clueless HR people, it is actually a real profession, one we could learn a lot from if we weren't so busy circlejerking about coding tests and whatnot.

dinkumthinkum 15y ago

I don't really agree with this, as usual. If you follow these directions, you might end up ok but you can definitely miss a lot of good people, and yes I'm aware of the meme about being happy to miss Knuth in order to avoid any blubs. I also think it's not practical for a lot of companies. As well, I know around these parts it is almost sacrosanct that one should have a Github, possibly blog, etc but there are many great programmers that do not have such a portfolio. I mean, many of these programmers are very good, deeply technical, and work on quite serious things. As far as #5, you will definitely miss out on people there. Many people with real talent actually have bills to pay and companies willing to pay them without some trial project. I understand the reasoning here, I mean, wouldn't it be great if we could go a step further and get someone to work for free for a year before we start paying them, just to make sure they are in it for the "long haul." #6, I have no problems with; it's quite reasonable. Honestly, I have followed Atwood for years, how many of these things would he actually pass, besides the thing about being very public? - no ad hominem, purely tangential.

codinghorror 15y ago
I'd probably be at most risk of not passing the phone screen, depending on how anal the interviewer is (read: whether they are a hard-core C programmer type). E.g. particularly if they asked coding questions about pointers and so forth. I've always hated C, ever since I tried to learn it in high school back in 1986 or so. The big picture stuff about bits and bytes and data structures I think I'd do OK on.

trustfundbaby 15y ago

You missed one Jeff ... treat them with respect. I've interviewed at a lot of places, and some of the things these companies do is breathtaking ... that's when they're interested in you. They try to schedule you into 3-4 hour interviews like you don't have a job to do that day. They send you coding assignments that take 4-8 hours to do. Interviewers get your resume 15 minutes before they walk into the room with you, then ask you to rehash your entire background (because ... you know ... that shit isn't in the resume in front of you already). Then there's the default position some of them take that 90% of the people they interview are idiots, so they're just going to treat you as such until you prove them wrong. I had one firm set me up for an interview, and then cancel it without actually telling me, until I emailed about 2 hours to the time of the interview wondering what was up etc etc But that's just the half of it, as soon as some of them decide you're that worthless programmer who didn't pass their pet brainteaser/trick question, they won't even do you the courtesy of telling you that you're out of the running. The recruiter who was all so chummy with you and positive about your prospects goes AWOL and you get that dreaded automatically generated rejection email. If you felt good enough about me to actually talk to me on the phone to get me to interview, why can't you even email me to cut me? Just man up and do it like the movie Moneyball. "Sorry x, you didn't make the cut. Good luck in your search". I'm a professional, I can take it. Its all rather exasperating, because we both want the same thing in the end.

suresk 15y ago

These seem like mostly good ideas. I do see some problems with things like GitHub and SO rep becoming so important in the filtering/hiring process - it gives a huge advantage to those who work at companies with good open source policies. Open source contributions and contributions to community resources like SO can be useful, but I hope the lack of them doesn't cost too many people shots at interviews - there are a lot of good developers with no presence on SO or GitHub. I do, however, have a bigger problem with #5. It seems fine at first glance, provided the company is being honest about it, but from the perspective of the potential employee, it is hard to know if performing well on the 'audition' is really all that is standing between you and the job. About 8 years or so ago, I was applying for a new job. The interviews all went pretty well, and I was given an audition project that was aligned with this companies product very tightly. I spent several evenings (probably ~8 hours total) working on it and submitted what I thought was a pretty good project. After I followed up with them a while later, I was told that while my submission was the best one they'd seen, they weren't going to be extending me an offer. I sort of wondered if they were using applicants to build their product, but it seems like it was a lot of overhead on their part. Either way, I wasn't pleased that I'd been given a project to work on even though I apparently wasn't going to get hired anyway.

kamaal 15y ago

Frankly speaking I interviewed for a bigMegaCorp last year which is pretty famous. Can't give out the name of the company for obvious reasons. They first had a telephonic round and checked around my skills. They talked of my last projects and make me write some code. It went well. Then they invited me to have some onsite interviews. It was the most pathetic interview experience any body could ever have. They gave me a laptop and made me code. Which I did. The first day they had three 1.5 hours session coding session based interviews. Of which I missed only on one question. They went pretty fine. They told two days later I need to go through more interviews, It was a another two coding sessions plus a database and common design pattern based interview which I also did well. But they called in a week later and said I needed to come again. Frankly speaking my patience had ran out. But nevertheless I still went. Only to find I had to go through another three rounds. This time the experience was pathetic. Its was full of puzzles and memorizing arcane facts of various bits and pieces of software which I bet no productive programmer will ever have time for. It was puzzles and fact quizzing galore like I had never seen before. Coupled by one Algorithm interview and I bet they asked mathematics I had never heard of before. Another week later they told me I was rejected. Now this is what I have a problem with. You want somebody who can build quality software, who knows his trade. Programming languages, Databases, Tools, design patterns, Quality and other daily stuff. How the hell does it matter the guy doesn't know facts and puzzles? Frankly speaking I can learn that too! If I spend 30 mins a day reading the career cup ebook and other internet puzzle forums I can very well game the algorithm and puzzle rounds. But what will this every say about my skills as a programmer? All this 'Github as a resume' , and 'Stackoverflow profile as a resume' work fine only in forums like these. Otherwise every interview has a puzzle and algorithm quiz round which has absolutely no relevance to the daily work of a programmer. Honestly all big web companies claiming to hire the best are definitely hiring the most knowledgeable person. But none of them are hiring outliers, passionate and productive people who can do miracles. This also perfectly explains, why most of their innovation and growth happens through acquisitions and not in house innovations. Because most companies have people who know a lot, but not necessarily who can do a lot.

hef19898 15y ago

In any technical domain, it's hard to identify the right people, even you base your hiring process on recommondation letters as it is done over here in Germany. These letters, and CVs and degrees as far as that is concerned, only get you so far. After thinking about it (and deleting my first comment), I see it as some good basic advice for first time employers. What I don't really get is the point with the trial project... Do start-ups and highly qualified experts (supposed you actually want experts) really have that much time to waste? I don't think so. One important point mentioned in the comments was culture, and yes it is paramount. Especially in disruptive, small companies where you cannot afford to have the average well-adopted worker drone around you usually get from HR in bigger companies, ideally the founders are around to communicate the culture themselves. Ouliers actually are a good place to start looking if don't already know your candidates. Personally, I like interviews whith people who actually have a say in the hiring, only HR usually sucks. Added benfit: people knowing their job usually can tell after professional discussions (and some tests that can be done in a couple of minutes to identify the liers) if the prospective employee knows his job or not. Disclaimer: Non-american non-programmer commenting, so please be kind :-) p.s.: Treat them with respect, because if you don't you'll only get the desperate and they tend to be desperate for a reason.

boskonovitch 15y ago

#2 in addition to seeing their portfolio they should also give you a code review and explain what the code does.This avoids code plagiarism.

singular 15y ago

Though I'm not saying there aren't good points here, there are many, I think it's interesting to consider the usual impact of discussions on this subject - typically a great deal of insecurity/defensiveness (I feel it too), which I don't mean to say in a negative light, in fact I think it's quite natural. It's worth quoting Steve Yegge's fantastic 'get that job at google' [1]:- 'Me: blah blah blah, I like asking question X in interviews, blah blah blah... You: Question X? Oh man, I haven't heard about X since college! I've never needed it for my job! He asks that in interviews? But that means someone out there thinks it's important to know, and, and... I don't know it! If they detect my ignorance, not only will I be summarily fired for incompetence without so much as a thank-you, I will also be unemployable by people who ask question X! If people listen to Stevey, that will be everyone! I will become homeless and destitute! For not knowing something I've never needed before! This is horrible! I would attack X itself, except that I do not want to pick up a book and figure enough out about it to discredit it. Clearly I must yell a lot about how stupid Stevey is so that nobody will listen to him!' [1]:http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

CodeMage 15y ago

Okay, to get this out of the way first: I completely agree with Jeff that hiring programmers is hard and that the way a lot of companies go about doing it is about as effective as Russian Roulette. I've seen it and felt some of the dismal consequences. As a matter of fact, I still have to work with lots of those people that should have been filtered out in step 1. So yeah, I agree with the idea. Having said that, his process, taken together, is ridiculously one-sided. The message it sends comes across as "Of course you want to work for us, regardless of all the hassle we're putting you through, who wouldn't? Only someone out of their mind, that's who! And we don't want people like that here." Think about it, Jeff. You are asking for someone who: 1) is highly skilled 2) has an attractive portfolio 3) is mature enough to communicate well A lot of people like that already have jobs. If you want them to do #5 -- which might be something they're forbidden by their current employment contract, by the way -- and you also want them to prepare a presentation for #6, you must be the sexiest employer on the Earth. In short, what do you propose to balance things out?

pavel_lishin 15y ago
I'd wager that someone who is highly skilled can afford to take several days off work.
- CodeMage 15y ago
  This is simply unreasonable. Those days off work come from somewhere, usually paid or unpaid vacation time. In other words, you're either cutting into the time reserved for your family/social life or you're paying out of your pocket. To put it simply: your approach doesn't scale.

ap22213 15y ago

Why doesn't short-term contract to hire work? Seems like it would save a lot of time, with very little risk.

bryanlarsen 15y ago
That strategy works great in a down economy when jobs are hard to find. But most good programmers have jobs, and are not going to leave a full-time job for a short-term contract.
chollida1 15y ago
To generalize, most good employee's already have jobs. It's going to be hard to get them to quit inorder to do short term contract work in the hopes that they might get hired by you.
chrisbennet 15y ago
If you don't already have a job, there is little risk. However, if you have to quit your job to "try out" another job, you most likely want a little more assurance that you'll still have a job in a few months.

SanjayUttam 15y ago

I see posts like this regularly on HN (lists of stuff you should do to hire that top 1% of talent). What I don't recall seeing, though, is a post more along the lines of employment branding. I understand how for very small start-ups that may just be a waste of time but when you get to a certain point it seems like you're going to want to do something. That might just be having a labs.yourCompany.com blog, or releasing an open-source project once in a while. I think that great devs want to work places where they know the work is interesting/fun/whatever. It's a lot easier for you to get the word out via say a blog, rather than have a 1-1 conversation with someone over the phone to communicate the cool stuff you're doing. Just my 2 cents.

trefn 15y ago

These 5 phone screen questions are lifted almost directly from Steve Yegge's "Five essential phone screen questions" post - https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho... 1) Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java. 2) OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem. 3) Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages. 4) Data structures. The candidate has to demonstrate basic knowledge of the most common data structures. 5) Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers. They even use the same regex example. He attributes other things to Steve, so maybe this is just an oversight, but I'd like to see another link.

lhnz 15y ago

I can see all sorts of ways that this will give you false negatives. This is what I would recommend: 1. Via an online test: check if they can code something very very simple. (This is your threshold that simply exists to not waste so much time.) 2. In their CV: Look for public-facing indicators of skill: github account, stackoverflow account, blog posts, etc. (Bias towards candidates with these indicators, but do not discriminate against those without. These are indicators of true positives and not true negatives.) 3. In a phone interview: ask about and then assess their breadth of knowledge. Find out their passion. 4. In a phone interview: test the depth of their knowledge in a relevant category of knowledge. If they are struggling then attempt a question in something they're passionate about. (This is the point where you detect true negatives.) 5. In the interview room: give them a choice of hard problems -- the sort you would want them to work on if they joined. (This is where you detect true positives.) 6. In the interview room: find out whether they're the right cultural fit for your company. (This is where you filter out any true negatives that remain.)

NDizzle 15y ago

I always see these kind of hiring practices put into place and enforced AFTER I'm already hired and working. (no, I don't conjure up hiring practices like these.) Simply put - I wouldn't have gotten my own job if I had to conform to these standards.

tobiasSoftware 15y ago

I have issues with both #2 and #5, having just gone through the getting hired process myself. I think a portfolio is good, but I can't stand this "let's look at Github and Stack Overflow" attitude. To my interviews I brought four projects that I plan to sell one day and one project that I worked on but wasn't mine, so these projects are not open source and I don't like this trend of employers expecting all this open source code. I have real working programs in my portfolio, that should be good enough, if I show you the code you would just nitpick on it anyways. Give them an audition project: Just no. The suggestions in the article definitely help, but audition projects as I've seen them are horrible, and even with the suggestions, you still need tons of time that you probably don't have unless you are unemployed. Maybe if it's an hour test-like thing, I had a good test project with a company that was an hour long, it tested me on a programming language I had never used, I guess it was more similar to a hello world programming example than anything else. However my other experience with audition projects was the week type. It was two questions, given BEFORE the first interview as a pre-screen. The first was a 2 page single spaced paper on an economic question. This was about 10% the length of the major research paper I had to do around the same time, all I could think of was how much better my time would be spent doing that. The coding question was far worse, something about triangulating a trapped miner using his cell phone records. There were so many things not explained that I would need, like the API of the cell phone records or how the data was stored that I felt like either I would have to ask the guy for more information than he would give or that it would be totally fake. Oh, and on top of all that, they gave me a deadline of the work week, not even a weekend. I was in school at that time and only had a few hours on weekday nights. From my personal experience (which very well may be colored by the one example above), I would have to say that projects as part of a hiring process are for desperate candidates. It will screen out the dumb or lazy ones, but it will also screen out the skilled ones because they will figure it's not worth their time trying to do tons of work for a company that very well may not give them a job, and that the time would be better spent doing something REAL (and not unpaid work for the company either), maybe even a project to put in a portfolio and show off to all companies they are interviewing for.

dspeyer 15y ago

> Instead, I have my own theory about how we should interview programmers: have the candidate give a 15 minute presentation on their area of expertise. ... The one thing every programmer should know, per Steve Yegge, is how to market yourself, your code, and your project. I wholeheartedly agree. Now pitch me! Yikes! This really looks like an anti-test. I'd rather work with people who don't know how to market themselves -- that marketing skill would distort every technical discussion I had with them. Even if that is a skill you want, a programmer who's really bad will almost certainly know how to bluff for 15 minutes -- they've been practicing their entire career! -- whereas a good programmer hit with that will probably wobble a bit looking for a topic. Even if you have a extraordinary bullshit detector, it's still a poor signal. It won't tell you what the candidate is weak at -- and that's often the most important thing to determine.