Hiring - finding out what you're really looking for

I've spoken to a few people recently about hiring. They were in an initial stage where they've said to me that they needed to find someone for a tech position. And in each case when I've asked for detail about the profile needed, it turned out that the person was not that clear on what they exactly needed. Everyone who has done hiring has been in this situation. You know you need someone and think you know what you need, but as soon as you start looking, you start to realize that you're really not sure.

Obviously it would be best to know before you start talking to candidates. For many hiring managers, though, it seems that they start by browsing ads posted by other companies to make a profile. And then the process of interviewing people is the way that they figure out what they are actually looking for.

One easy and obvious way to get a handle on this is to do the job yourself for a little while. Of course this depends on the job and company, but if you can, you'll clearly get the best sense of what's needed. This of course happens naturally in small, growing companies, but isn't always an option.

Another thing to do is focus on creating a good practical test for the job. For technical positions this is a necessity. And I believe that the best practical test simulates real work as opposed to theoretical problems or logic puzzles. So when you put together the test for what the candidate needs to know, you should be reviewing real work problems and tasks.

These are two things that have worked well for me. I also try to keep in mind that when you don't really know what you're looking for, not only can you make negative impressions on candidates, but - worst of all - you may not realize it when you find the right person.

Using Logic Puzzles in Interviews

I have never been a fan of using logic puzzles in the hiring process. The practice apparently originated at Microsoft. The idea for using them is based in the fact that technology is always changing. And so you don't want to test anyone on a current technology, but rather on their general logic abilities which will let you know whether they will continue to be useful to the company in the future when it has to adopt new technologies. This line of reasoning is compelling and it seems like a lot of tech companies have accepted it.

Personally, I don't buy the argument. For one thing I don't see why the puzzle necessarily tests someone's logic abilities better than a programming test, which gives someone a formal way to reason - the programming language. It also does not necessarily follow that someone who can solve logic puzzles well is going to be any good at programming which has all kinds of constraints and doesn't rely on clever tricks. I think it's far better to give someone a real programming problem that you have at work and see how they go about solving it. As it's a real work problem, you should be familiar with the details and some of the approaches to solving it. From this familiarity with the problem you should be able to tell more about someone's ability to reason and think logically, then from a puzzle which has no context.

As for whether a potential programmer will be able to move on to other technologies or languages, it makes more sense to me to see how they understand the concepts behind what they are doing and also to get a sense of what kind of person they are. When it comes to learning a new technology, what you need more than some general logical abilities is good curiosity and motivation.

Tech Hiring Process

Having a well-defined hiring process for technical employees is the essential first step in having a great development organization. I don't think this is anything really new or surprising to say, but what exactly that process looks like may not be so obvious, especially for people new to hiring for technical positions.

Here is a basic structure that you can use to make your own process:

1. Initial screen email
2. Phone screen
3. Written test
4. Interviews

The initial screen email is just to cover real basic issues like whether the person can legally work in the US, whether they are really looking for full-time work, whether they need to relocate, and other such issues. You'd be surprised how many people send out their resumes without really reading certain details about the position. And be sure to ask about salary expectations or last salary earned, if you don't put a range for the position on the initial ad. I think you need to know where someone is with salary before even talking to them because you really do not want to be surprised later on. It can also be a bad sign if someone does not want to answer a question about salary or just says that it is negotiable. In this situation, you are more than likely dealing with someone who is not that serious. Good people know what they want and aren't bashful about saying where they are with pay.

The phone screen should be short, about 20 minutes. There should be 4-5 technical questions that cover basic knowledge required for the position. You should ask the same questions of everyone so you can hear the differences. You should also ask a question about what they're working on to get a sense of how they communicate. This should weed out a lot of candidates.

The written test should make the candidate do something that they would be faced with on the job. There are some differences in opinion here, but I believe that trying to simulate real work problems that come up in the position is the way to go, even to the extent of giving them a recent problem or issue faced by your team. When the candidate finishes the test, you can go over it with them and get an understanding of how they tackle problems. I think this gives you the clearest picture of what the person would be like if they came to work because, really, you gave them a little work to do.

The final interviews are with team members and I think it's a good idea to prep them with questions. They can ask what they want to, but make sure they have access to questions so they don't have to worry about it. Personally, I don't like the brain teasers.