
How We Hire Developers at Treehouse - johnjlocke
http://wellbredgrapefruit.com/blog/2013/06/01/how-we-hire-developers-at-treehouse/
======
mfonda
Summary: first interview the candidate to check for culture fit, then pay them
to complete a 10-20 hour project. If the culture fit is good and project
successful, hire.

As a developer I don't like the idea of having to do a 10-20 hour project as
part of an interview, but at least they are compensated for it. I would love
to hear thoughts from developers who have done a "project as an interview".
Positive or negative experience?

~~~
dougk16
I've done two projects-as-interviews for two different jobs, one paid, one
not, both a week deadline if I recall, and around 20 hours. These were both in
the midst of applying to a bunch of jobs, getting the interview based on
portfolio/resume, and then, due to anxiety, completely bombing out when the
technical questions started, or when they sent the do-these-problems-in-an-
hour test.

I got both the jobs where I did the week-long projects. They took a while, but
it was completely stress free, and allowed me to show what I can do under more
realistic circumstances. I realize that some "rockstar" programmers might
scoff at someone daring to take up so much of their free time, but these are
the people who probably do well at the classical interview, so more power to
them.

Overall, I enjoyed the project-as-interview process. Two things though: (1) I
was a youngin at the time without much responsibility. Ask me to do the same
thing now, with a family, and it can't be longer than a few hours spread over
a week or two, or I just don't have the time. (2) As an interviewer and fellow
human being, I'm very respectful of people's time. I'm uncomfortable asking
someone to commit so much of it, even though for me personally it was OK.

------
nawitus
As long as there's no empirical data on recruitment, these "we think our
process works well, here's how we do it" blog posts are not of much value.

One problem with step 3 is that it filters out engineers who are busy with
their jobs and life, and cannot easily afford doing 20h extra work (even if
it's paid work). Especially if compensation etc. are not negotiated
beforehand.

------
nader
Your hiring process sounds great from a company perspective. I just wonder how
it really works out and if you find enough people this way. I've experienced
that when you take too much time to screen devs, put too much test-effort on
them, evaluate for a longer period of time ... they might just as well go to
work somewhere else.

------
revelation
I guess if you've put your whole life into a company, a question like

 _Why do you want to work at Treehouse?_

makes perfect sense to you. An applicant, however, didn't know your company 15
minutes ago, and his main motivation is either money or finding a job that
fulfills his desires.

~~~
weisser
As an employer, shouldn't you seek to hire team members that have a strong
passion for your company's mission? I understand many people want jobs for the
pay but I think this is a very important question.

"Why do you want to dedicate the next few years of your life working on this
instead of something else?" If the answer is just because it pays more or the
company is in a better location I think most employers would want to keep
looking for someone that has different motivations.

~~~
hexasquid
"Why do you want ME to work at your company?"

~~~
johnjlocke
No.

------
tptacek
Please don't take this the wrong way, because I think a lot of very smart
people disagree with my take on this, but: I hate pretty much every part of
your hiring process, and could as a result use it as a springboard to talk
about how we're trying to design ours.††

My problems:

1\. Makes demands of the candidate before selling the role (in fact,
explicitly!)

I recommend you don't do this. Instead, make a point of going out of your way
to sell your company and your role to your candidates before you do _anything_
to screen them.

This serves three purposes: (1) sure, it makes it marginally more likely that
you'll keep high-value candidates engaged who'd otherwise fall out of your
pipeline at/after "stage 1"; (2) more importantly, it helps disarm the
interview process, both by establishing that _you, the employer_ are going to
put the effort and initiative into keeping the process running and
establishing that tone for the whole process, and, even more importantly, by
making the candidate actually want the job so they'll perform better during
the process; and, (3) it's both the right thing to do and a noticeable
difference from most firms' terrible hiring processes, which is good for
marketing.

2\. Is extremely subjective

Right out of the gate you're asking the candidate questions you can't possibly
be benchmarking. "Code you're proud of"? What if the code the candidate is
most proud of is something simple that been super useful on lots of projects?
What if the candidate cherry-picked it from their code to demonstrate the most
complicated stuff they've worked with? How will you compare it to every other
code sample you get across the lifetime of your company? You're doing that,
right? Keeping track of how well your hiring process predicts performance?

2a. Culture fit

Beware culture fit questions. You state it outright later in your process when
you say (paraphrased) "you can train technology but personality mismatches are
impossible". That's a recipe for hiring the same 10 dudes who like roughly the
same X360 games. I know that sounds hyperbolic, but look around you at other
companies and tell me that isn't a real concern.

Two other problems with culture fit questions: (a) they mask irrational
responses from interviewers, which happen _all the time_. Some of your best
performers do badly on interviews, because they just don't interview well.
Some of those people (ironically, it seems to be those people in particular)
will be hard on candidates who have the same problem. Why are you setting the
expectation with your team that they should ding candidates for intangible,
irrational, or subjective concerns?

In neither (2) or (2a) am I arguing that you should only be hiring based on
measured defect density or ability to correctly estimate how much time feature
X would take† or typing speed. If there are specific personality traits you
need to select for, that's fine: just select for them deliberately, and train
your team how to select for them, and track how you're doing.

3\. The tryout project

This is going to make me sound like a jerk for at least 2 reasons I can
immediately think of, but, to sacrifice (a lot of) tact for (a little)
clarity:

I think less of teams that propose short contracting projects to candidates to
try them out, because I would never agree to interview on those terms.

Here are the problems I have with this approach: (a) it invites/provokes an
argument during your hiring process about what a good daily rate is, (b) it
asks the candidate to negotiate an hourly rate in a situation where their
leverage is egregiously compromised, which is unethical, (c) job searches are
full-time jobs by themselves, and your best candidates are _almost invariably
already employed_ , so how could it be reasonable to demand they take a temp
job with you as part of that search, (d) it requires you to demand the
candidate produce billable work and assign the resulting IP before the
candidate is sure they're going to accept the offer they might get from you,
(e) the tryout project is deceptively low-information.

On that last point: I guess I've hired a person or two in my career that ended
up not working out almost immediately. But usually, the dealbreaker problems
I've had with coworkers or employees took months to surface. Lots of people
can be productive for a short, high-stakes sprint. But virtually no dev team
is hiring for that; they're hiring for the ability to be reliably productive,
to exercise good judgement in design and estimation, and be compatible with
the decision making process the team uses.

Yes, the tryout project proves the candidate can produce code you might deploy
on your website. I hope I'm not the first to tell you that that is a very low
bar; lots of high school students can do the same.

Please please please take this comment in the spirit I intended it. I expect
lots of smart people will disagree with some or all of it, and would be happy
to learn from them. I'm pretty convinced though that the conventional
interview system that some of the smartest teams use is fatally flawed in a
bunch of ways, and this hiring process is an opportunity for me to start
talking about why.

%. One last point because I am on a tear about this lately

I would like to start establishing a meme: Job Interviews Are Hostile For
Candidates.

Normal people don't enjoy interviewing for jobs. Normal people find the
experience off-putting. They're nervous. They're dealing with a procession of
people each of whose stated position is to judge them. Normal people don't
like being judged by strangers. They sit there and read tea leaves from
behavioral cues about whether they're coming across well. In my experience,
this happens even in phone interviews, which (can we also establish this
meme?) _are the worst_.

I am not saying don't interview people. I'm just saying when you do it, assume
all the signals and readings you're getting from your candidate are janky as
hell, because they are. Lots of strong performers can't do their best thinking
and judging when they're conflicted and anxious. Compensate.

Whoah, long comment.

† _BTW: my favorite dev interview question_

†† _There is a better way to write this paragraph but I'm pretty depleted
right now so please excuse the clunky, combatitive tone._

~~~
shrikant
> 3\. The tryout project

The example in the post actually sounds quite relaxed (environment of
candidate's choosing) compared to what I went through in a recent interview
for something akin to a data analyst position.

I was given an Excel sheet with a mass of sales data in it and asked to come
up with whatever 'insights' I could in 15 minutes. On a Spanish version of
Windows/Office, running on a laptop with a Spanish localised keyboard layout
(which meant none of the symbols were where I would expect them to be on a US
or UK keyboard). I must've spent about 5ish minutes of the allotted time just
figuring out how to get the required symbols to show up :(

~~~
CaveTech
Your task was also 15minutes long. When I was interviewing, several companies
have no taken this "project" approach, requiring 10-25 hours per project.

Sorry, but there's no way I'm going to do a 25 hour project for your company
in the context of an _interview_ , because I'm wasting time that I could use
to interview for another 10 companies - which will most likely give a much
larger likelihood of a job.

If you give exact requirements and give promise of a job if those requirements
are met, I would consider doing the project. Anyone who does otherwise is
foolish and objectively desperate.

------
posharma
And all this to cure hunger, cure diseases, cure patients, etc. Great going!
Very motivated to go through the entire process to write a web application.

------
el_fuser
This is better than a lot of the processes I've seen.

But.

Developers that do interviews seem to want a step by step algorithm for doing
an interview... Or worse yet just want to throw them a topcoder style
algorithm question so they can "spend" an hour on the interview and come up
with an easy yes/no answer.

I've been conducting interviews for about 5 years and started out doing the
same. I came to realize however, that we were rejecting perfectly fine
candidates.

Several devs would either knock our take home puzzle out of the park or show
us a great portfolio, but then would flub or stumble when the (mostly JR) devs
would ask them to implement something akin to a topcoder challenge.

Now, much like we expect devs to tailor their resumes to us, I tailor my
interview to the person being interviewed.

If you're relatively new, you might get asked some data structures / algorithm
questions.. If you're senior expect to go into great detail about your past
projects and design decisions.

There is no process or formula. Interviewing is an art.

------
pablasso
Assuming those interviews with the team don't include these sorting coding
problems that are so hyped this is the best process I've heard about.

I think any coder will be more comfortable doing real job instead of studying
college stuff that you haven't done in years.

------
pyre
Off-Topic, but you know you're spending too much time one HackerNews when you
see "THE VENTURE BROS" in a sidebar and immediately think that it's some
venture capital group (for 'brogrammers' or something) before reality sets in.

------
asperous
Can we please get researchers to research:

(1) Different hiring practices and their long term success rates

(2) Different procedures (agile, scrum, cubes or no cubes) and whether they
impact working efficiency

I just feel like everyone and their mom has these grand ideas about how they
can do things differently than everyone else but I never get to find out
objectively if they work.

------
prakster
You lost me at your opening question. It's YOUR job to tell me about your
company first and get me excited about foregoing the potential of the stuff I
am working on. Only then should you ask me why I want to work for you.

I doubt you will get great developers that way.

------
joyeuse6701
The trial run is a cool idea, I could see it being hard to replicate for some
businesses, either no project in the pipeline/difficult to scale past a
certain size. Seems pretty solid though and much better than the academic
coding questions.

------
nayefc
First:

> I’ve filtered through resumes and listened to coworkers...

and then...

> ... which is why we don’t ask for resumes.

I am confused.

------
freework
Like all other interviewing "processes", this is too much overhead.

I can tell after talking with someone for 5 minutes whether have the right
stuff or not. You can tell by how they choose their words and express their
opinions.

The best interview process:

1\. Candidate sends company a resume.

2\. Company reviews resume and likes what they see

3\. Company calls candidate for a quick 5-10 minute call.

4\. Questions asked are "What are you currently working on/thinking of
starting" (referring to any kind of extra-work projects the candidate might
have), "what is your favorite language and why", "what is your favorite
library/framework and why", etc. Like I said before, its usually pretty
obvious who comes from experience and who is novice. For instance if someone
said they prefer PHP over C# because "PHP is faster", you can assume that
person isn't the most experienced... The other day I sat in an interview where
the candidate was an older guy (grey haired who graduated in the early 90s).
Not even 25 seconds into the interview and I knew immediately that he was the
read deal. It was something about how his stories seemed to have the right
details. The problem is that it takes experience to judge experience. When I
was 22 years old (which is the average age of most startup founders these days
it seems), I would have been more likely to dismiss him as an old grey haired
coot whose skills are outdated.

5\. Company decided candidate is experienced and invites the candidate to a
face to face. This may include travel expenses if the candidate is not local.
At this point the company pretty much makes the decision to hire the person.

6\. During the face to face, the objective is to give the candidate a clear
description of what the company expects in terms of work hours, salary and
benefits, etc. Also, what kind of problems they are working on, what kind of
technology they use, company culture, etc.

7\. Candidate and company negotiate, and then eventually agree on terms of
employment. Candidate starts whenever possible.

The problem is that it takes a good developer to know another good developer.
If you are a non-technical person, or a low-experience developer, you don't
have much intuition to go off of. Instead you have to resort to making
candidates jump through hoops by making them do things like FizzBuzz.

Another thing I should say. Interviewers should focus less on judging the
candidate based on personality. The way I see it, as long as you're passionate
about the right things, I don't mind if the person is prone to jerk like
behavior every now and again. All brilliant people in the history of mankind
have been described as "jerk" at one point or another. In my experience, the
truly talented will always set aside their sometimes giant egos in the end for
the benefit of the project. Its kind of like Justin Bieber. Despite him
getting into controversy all the time, he still manages to get out there every
night to put on a show that makes the fans keep coming back for more. The day
his promoters stop putting up with his crap, is the day he fails to draw
ticket sales.

In other words, more companies need to stop basing their hiring practices on
repelling people prone to "Beiber behavior", and need to start basing it on
bringing in people capable to drawing "Bieber crowds".

~~~
protomyth
> where the candidate was an older guy (grey haired who graduated in the early
> 90s)

Uhm, I graduated in 91 and am 42. If that's considered an older guy, then I
can see why there are so many hiring problems.

~~~
pyre
His post is suffering from a year-1900 bug. The guy graduated in the early
1890s. /s

Nothing says how old the guy was when he graduated, or how far he went in
academia (i.e. Masters? PhD?). It's also possible for people to have greying
hair in their 40s, which may lend to someone looking older than they are.

~~~
protomyth
Ok, I guess I'm a little touchy about old guys being in their 40's. Maybe it's
because I have been mistaken for my 3 year younger brother's father a couple
too many times. He finds it amusing, myself not so much.

------
EternalFury
That's the best hiring process I have heard of. Good job.

------
qqg3
Treehosue?

------
targusman
You misspelled treehouse.

