Interviewing is hard and annoying

We've been interviewing on and off for the last couple of months. We've brought in 13 people, made roughly 4 offers (none of which were accepted), and have yet to see someone that I really felt we had to have.

I've identified two major reasons why we can't hire anyone good:

  • We can't pay premium salaries for really talented people
  • There's a lot of mandatory overtime.

Let's start with the first one. We're not a huge company so, on the surface, paying above-average salaries probably seems like a waste. What I can't get anyone to realize is that this is horribly wrong. Hiring one truly talented person and paying them what they're worth would bring more benefit to the company than the legions of kids-right-out-of-school or the out-of-work-and-desperate who get shuffled through our team.

Sadly the people who have the final say about how much money goes out don't really understand what it means to be a truly good programmer and consequently can't see the benefit of paying for one.

But let's say that I find someone to overcome the money obstacle. That leaves #2. The kind of person I really want to hire isn't going to stand for the sort of death marches that everyone here is accustomed too. This person is going to have the pick of jobs in this area, if they're even looking. It's going to take something a hell of lot more appealing than just money to woo them.

So that substantially shrinks our interviewing pool, in turn creating the next issue. It's hard to find competent people.

I'd thought all of this stuff had been pretty well covered by other people but some people still aren't listening. So here are few tips for you job-hunting programmers.

  1. Proofread your resume. Spellcheck it. Then get 2-3 other people to read it. Then spell check it again. Then give it to more people to read it. Writing "ect" instead of "etc", "firer" instead of "fire", mixing past & present tense, etc (See my little joke there?) will pretty much kill your chances with me from the beginning. This is such an easy one to get right and so many people blow it. I wish I lived in a world where you wouldn't actually get to come in for an interview but I'm not that lucky.
  2. Get your technologies right. Claiming to be an expert in "Java Script" or "My Sequel" is not going to impress me. Again, I'd like to say you won't even be considered for an interview but some people don't look as critically on those kinds of mistakes as I do.
  3. You get extra points if you bring code samples without being asked.
  4. Don't act surprised when I ask you to write code as part of the interview. It kills me how many people trying to get hired as programmers completely panic when they find out they have to write code.
  5. Don't put a skill on your resume if you don't really know anything about it. If it was something you studied in school 4 years ago and haven't used since, take it off because you're just going to look like a fool when I ask you questions you can't answer.
  6. Know something about our company. "I don't know why specifically I want to work here. I just want to stay in Louisville" is not going to give me warm-fuzzies when I ask why you want to work for us.

Now for the testing. I always ask people to write a very small amount code and I have a few different questions that I like to ask (most of them, I've cribbed from other people). I usually vary the questions depending on the person I'm interviewing and I give a lot of leeway on syntax since this is being done on paper and/or the whiteboard. I just want to know if you can think logically and if you know at least a little bit of the languages you claim to know.

  • Someone right out of school without much language specific experience might get a recursion problem (Fibonacci, multiplication, and so on).
  • I ask C programmers pointer questions (that I "borrowed" from [Joel Spolsky][]).
  • I ask Java & PHP people to come up with a data structure for storing a list of people and information about them, then sort it and print it out. I specifically ask people not to use a database and you fail if you ignore me and use a database anyway.
  • People with database experience get asked to draw some basic tables to store report information. There are some one-to-many relationships & some normalization-iisues to consider. Then they get asked to come up with SQL for certain queries.

And it kills me how many people claiming years of experience can't do these simple things. I know this has been discussed to death (Google "FizzBuzz") but it's still mind-boggling to me.

How did these people get jobs they claimed to have before? Were they lying? Are they just padding things to get the next job?

And, more importantly, how do I get the people who can do these tests (and aren't psychopaths) to work for us?