
How to Hire a Programmer - cruise02
http://www.codinghorror.com/blog/2012/03/how-to-hire-a-programmer.html
======
angrycoder
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.

~~~
scott_w
It's probably a bit extreme to say he's "bitching".

This sort of thing is quite useful to those of us who have an involvement in
hiring, but don't have a lot of experience.

I've been involved in hiring a couple of people, though the process I go
through usually involves:

a) Read a code sample, if available. b) Face-to-face interview (telephone if
face-to-face is difficult). c) Hire/No-Hire

The interview usually involves talking about our company and the interviewee
talking about their previous experience. The hiring decision is usually based
on "I like the feel of this guy", with some weighing up of their skill set,
the job role, and also how interested they would be in working for us.

I've found this works for the company I work for. We don't hire large numbers
of people, so I don't think this approach could scale - as an example, the
largest block of CVs for a position that I've seen is about 10. I don't know
how it would work if we got 100 CVs.

~~~
ChristianMarks
He's saying negative things about former employees. So much for symmetry.
Interesting that employees cannot prudently make negative remarks about former
employers even in general terms, but employers can make negative remarks about
former employees. If a negative remark would lead a prospective employer to
wonder if a candidate would eventually say the same things about him, why
wouldn't a prospective employee think that a prospective employer who made
remarks about bad hires would not eventually say the same things about him?

~~~
hippee-lee
I think it depends when and where you discuss a negative experience. Sure, not
a good idea in an interview.

But what about doing a personal reflection, say a blog post or something on
your own time about the observations and lessons learned with regards to
things like culture or development philosophy directly related to that
company? As long as you do it in a way that doesn't break any non-disclosure
agreements why should you be punished for it and do you really want to work
for someone who would look negatively on you for expressing what you have
learned from a bad experience? Even more important - perhaps the employer
doen't know how bad the culture is inside or worse they do know and rely on
you not ever saying anything to continue recruiting others similar to you?

Then, during the interview you can find a way to bring a summary of the
negative experience into the conversation without it looking like you want to
trash or burn your former employer or manager. There are many opportunities
for this, a common question one gets asked is to describe what you have
learned from mistakes on the job. This is open and general and one could
easily work programming specific or soft skill lessons learned into the
discussion that do not paint your former employer in a positive light. And if
your former employer has not earned the right to a positive reference you
should not be required to give it to them just because you want to continue
working.

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

------
dustingetz
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-
correc...](http://www.johndcook.com/blog/2008/09/19/writes-large-correct-
programs/) [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> [4]
<http://en.wikipedia.org/wiki/Four_stages_of_competence> [5]
<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>

edit: man, this got 2 downvotes in 2 minutes, cmon guys i put a lot of thought
into this!

~~~
jamesli
Have to show some support for this post.

Engineering is a combination of technology and art. Therefore, it is
impossible to have a simple process for interviewing engineers that magically
works. Otherwise, such posts would not have been brought up so many times in
HN.

Also, some people are good at people evaluation, some are not. An excellent
engineer could be a lousy interviewer. On the other hand, a mediocre engineer
is lack of the ability to evaluate a top engineer within an hour. Therefore,
the employer must first know who are his/her best interviewers. If s/he can't
identify her/his own people, I highly doubt s/he is able to identify good
candidates.

The hiring signals I pay attention to are one's curiosity and one's depth in
understanding in at least one programming language or one computer science
topic, no matter if that topic or programming language has any relevance to
the position to be filled. Here is the rationale. To be a very good engineer,
one needs both internal motivation and intelligence. Both of the two signals
speak for internal motivation. A deep understanding on any topic shows the
candidate is sufficiently intelligent. Such a candidate, even if s/he knows
little about the languages and/or the frameworks the position requires, s/he
would learn it very fast and would be very good at it. To be realistic, it is
really not hard to learn a programming language and a framework.

~~~
kamaal
Good thoughts!

I think software has a lot of reusable principles/concepts. And these days
syntax is really skin. Programming languages get used a lot because their
ecosystem.

You are definitely very correct to demand perfection in at least one walk of
our profession. Because those concepts get reused nearly everywhere.

Another thing that I don't understand is rejecting people merely because they
don't know answers to some questions from the algorithm and data structures
text book. Software engineering today is so much about so many things.

Above all I would say productivity and passion is the only factors I would use
to judge people today. Because those factors decide nearly every other factor.

------
btilly
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
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>

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

~~~
brazzy
_as soon as you ask me to spend a week--even a day--on some audition project,
forget it._

Note that he proposes the audition project to be "a regular consulting gig
with an hourly rate", spent on-site doing real work.

You don't have time to earn money doing real work? Then why are you applying?

And even for a "truly good" professional who has his pick of a dozen offers, I
could see this as a good idea, since they have just as much reason to be
interested in the company's "real" work environment than the company has to be
interested in their "real" work performance.

~~~
CodeMage
_You don't have time to earn money doing real work? Then why are you
applying?_

False dichotomy. I'm already earning money doing real work. I'm not applying
so that you can cut into my family time. I'm applying because I want work
that's more interesting or more money or who knows what. If you really want to
know, ask, instead of assuming ;)

EDIT: Clarifying the "more interesting work" expression.

~~~
brazzy
_I'm applying because I want work that's more interesting or more money or who
knows what._

Apart from the money, such a "audition project" could help you a great deal in
deciding whether this company actually meets your expectations.

You're of course right in that it will be difficult to do it like that for
someone who already has a fulltime job.

------
robomartin
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")?

~~~
nkassis
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
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.

~~~
nkassis
I posit that some of it is just people lying. I had someone send in a huge
perl script he claimed to be his own work yet failed that variable swapping
test. Basically our setup was HR gets a bunch of resumes and scans for minimum
requirements (degree, prior experience) then we get them. You get really good
looking resumes that you need to prove somehow. That's where that basic litmus
test comes in.

Things like Github improve this a bit although I'm not even a huge user of
public github repos (something I'm working on fixing since I realize my online
profile is a bit sparse at the moment). I don't it's perfect either as a lot
of very good candidates don't have time or are shy to show they work in
public. Heck I love working on my professional project in my spare time and
can't show that code publicly most of the time.

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

~~~
wccrawford
#5 is still a bad rule. It eliminates anyone who currently has a job. That
leaves you with people who don't have a job (for whatever reason) or are
working as a freelancer.

Freelancers really don't want to work at a company, and in my experience, it
doesn't work out. I'm thinking of one person in particular who was an amazing
coder, got along great with everyone, and all that... But he wasn't happy
there. He quit before his 3 months review came.

Last time I interviewed, 1 of the companies asked me to write a sample app
that was useless, but would show I knew what I was doing. I had 48 hours to do
it. So yeah, I lost a weekend (well, 16 hours of it) but they were able to
know I was capable without a lot of craziness. I actually ended up taking a
job somewhere else before my interview with them, though. I had found a better
paying job at another company that didn't do any of that stuff. It was just a
1-on-1 interview and discussion of my past work. I'm still here a year later.

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

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

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

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

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

------
CodeMage
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
I'd wager that someone who is highly skilled can afford to take several days
off work.

~~~
CodeMage
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.

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

~~~
mtviewdave
>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.

~~~
dpdp_
Well, if you end up firing a lot of people, give recruiting to someone who's a
better judge of character.

Firing when things do not work out is an honest act. What does it have to do
with disposability? Both parties will be better off moving in separate
directions.

Also, I don't see how an audition will improve anything.

Life changes are the biggest risk to employees performance. No matter what you
do, you are not going to predict life changes during the interview.

~~~
mtviewdave
>Well, if you end up firing a lot of people, give recruiting to someone who's
a better judge of character.

It's not just about judging character. It's about the amount of effort an
employer puts into the interviewing and hiring process. Interviewing people
well takes effort. But if you're willing to fire someone easily, well, why put
in the effort?

In my experience, this feeds back on itself. The more comfortable the employer
gets with firing, the sloppier the hiring process gets. Soon good people start
avoiding the company, which means mediocre people get interviewed. So the
interview standards need to drop further, otherwise no one would get hired at
all (and besides, you can just fire them if it doesn't work out, so what's the
harm?). Pretty soon you're one of those companies with constant churn, where
no one seems to last longer than a year.

>Firing when things do not work out is an honest act. What does it have to do
with disposability?

It's not about honesty, it's about empathy. A good employer empathizes enough
with the employee enough so that they find firing to be painful, even if the
firing is justified. But an employer who cannot, or will not, empathize with
their employee basically treats their employee as a thing. And if they treat
employees as things when it comes to firing, they'll treat them as things all
the time. Which is an excellent way to create a terrible work environment.

~~~
dpdp_
But how an audition will improve anything? The marginal improvement in the new
hire quality that you get from doing an audition is not worth the time and
money spent on auditions plus the cost of lost candidates who took offers that
did not require auditions.

~~~
mtviewdave
Actually, I'm not advocating auditions. I'm also really not a fan of the
StackOverflow/GitHub/you-shouldn't-have-a-life-outside-of-coding approach
either. But just because that approach is overkill doesn't mean that
interviews should be be treated lightly (and I think treating interviews
lightly is unavoidable if an employer considers firing to be a routine tool).

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

------
mirsadm
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

------
singular
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-
goog...](http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html)

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

------
trefn
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-
pho...](https://sites.google.com/site/steveyegge2/five-essential-phone-screen-
questions)

    
    
      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.

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

~~~
nandemo
> 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?

The first question is silly. It's probably intended as a shibboleth, but it's
a pretty useless one: people who can answer it probably understand what is
octal/decimal/hex, but lots of people who do know octal/decimal/hex have never
heard of that silly joke.

The second question is very easy and it's good as a first filter: if you can't
answer it then it's very very likely you cannot code. They're asking it
because there are indeed people who interview for that position yet cannot
answer it.

> 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?

I think the 1/200 ratio is rather hyperbolic and not based on any actual data.
In my experience interviewing candidates for a not very well-known company (so
we didn't have 1000s of candidates for every position, more like dozens), more
than 2/3 of the candidates would pass the really easy questions.

But yes, if the candidate fails Fizzbuzz then it's probably pointless to
continue the interview. Of course the candidate might have other skills, but
we're talking about interviewing for a programmer position.

~~~
shioyama
Thanks for the context.

> But yes, if the candidate fails Fizzbuzz then it's probably pointless to
> continue the interview.

I didn't really mean to imply that basic programming skills are not a
prerequisite for a programming job, which I guess is what the second quote of
mine above seems to imply. What I'm saying is that testing itself shapes the
type of candidates you'll get, not just in the way that testing is meant to
(i.e. screening out the ones that are not qualified) but also in other,
unintended ways.

If the first thing you do in your interview is check if I can pass FizzBuzz,
what does that say to me about your company? Tests like fizzbuzz are so
uninspiring and uncreative. Aside from the fact that some strong candidates
may just blank on them even though they can program fine, the deeper issue is
that testing in this way says to me as an interviewee that you see candidates
in terms of black-and-white "testable" skills.

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

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

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

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

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

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

------
Mizza
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/> 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.

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

------
boskonovitch
#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.

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

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

~~~
chrisbennet
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.

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

------
johnx123-up
My personal favorite: How to interview a candidate/programmer
[http://rajeshanbiah.blogspot.com/2009/01/how-to-interview-
ca...](http://rajeshanbiah.blogspot.com/2009/01/how-to-interview-
candidate.html)

