

Ask HN:  Advice for interviewing/first time hiring - benologist

We finally reached a stage where we can start bringing on developers.  Anyone got some awesome advice or cautions for hiring?
======
mathattack
Some thoughts:

1) In addition to technical skills, look for values and fit. Is this someone
you want representing your firm? Is this someone you want to share 2000+ hours
a year with for the next few years?

2) Do your best to have each hire bring something unique that nobody
(especially you!) else is good at.

3) Look for trajectory in addition to location. For example: If there are two
people of the same ability, and it took one person 7 years to get there, and
the other 3, the junior person is learning faster. You don't want to hire
people who have already peaked, as your organization and it's needs will grow.

4) No matter how busy you are, it's always ok to wait if you haven't found the
right person. The cost of a bad hire is enormous, and it's a large market.
It's ok missing three good hires if the process allows you to miss one bad
hire.

5) For more tips, go to www.joelonsoftware.com and page down to the section
listing his posts for recruiters. You don't have to follow 100% of what he
says, but investing a few hours will help a lot.

------
ecaroth
1) Make sure your personalities meld - I hired people multiple times for their
coding chops when we didn't necessarily 'jive' and it made working with them
over a long period pretty painful, especially when brainstorming or doing
stuff like critique

2) Make a test with problems unique to your space - aka if you write
scheduling software, have the test use some date/time functions or if you
write a search engine have them write a simple DOM tree parser. Nothing crazy
complicated, but enough to give you an idea of what they are made of. Let them
take the test home to complete, then give them feedback about their answers
after they return it and see if/what changes they make in response to your
feedback. This gives you a good idea if they are willing to adapt and learn in
your problem space, and if they can take constructive feedback.

------
neiljohnson
In addition to the good advice elsewhere on this thread you might find the
following links to be of use.

[http://www.startuplessonslearned.com/2009/01/lean-hiring-
tip...](http://www.startuplessonslearned.com/2009/01/lean-hiring-tips.html)
[http://joelonsoftware.com/articles/FindingGreatDevelopers.ht...](http://joelonsoftware.com/articles/FindingGreatDevelopers.html)
[http://sites.google.com/site/steveyegge2/five-essential-
phon...](http://sites.google.com/site/steveyegge2/five-essential-phone-screen-
questions)

You might also find this link to be useful, but I wrote it myself so ymmv
[http://fragile.org.uk/2010/03/anatomy-of-a-technical-
intervi...](http://fragile.org.uk/2010/03/anatomy-of-a-technical-interview/)

------
bo_Olean
My 2 cents:

1.Do not hire devs without taking a test.

2.Hire developers for their "skills" and not for your affiliations with them.

3.Hire someone who is self learning and knows type of product/platform you are
working on.

Why you may ask:

1\. Test measures the work speed and efficiency

2\. Respect people for their skills not for your relationship with them (eg.
friend, relative etc..)

3\. So that you won't waste time giving them keywords to Google.

~~~
jarrettcoggin
In regards to #2, you can't simply just take the people with the best skills.
You have to be able to get along with them at the same time. Otherwise, you
may have a rockstar developer that's an absolute nightmare to work with.

------
abbasmehdi
Hire as a contractor, then make an offer in 3 months or so based on
performance.

