This is a planned follow-on to my first post on hiring.  In my first post, I talked about the general process I like to go through when hiring a new programmer.  Of course, you can bet that this is continually evolving based on what works and what doesn’t.  So far, this is working very well.

When hiring, you obviously want to ask all kinds of questions, but I have to admit, I agree with a popular mantra that many speak about, including Joel Spolsky:  “Smart people who get things done.”  Smarts isn’t everything.  Take me, for example.  I know so many people who are smarter than me, hands down, but I make up for it with drive and persistence. 🙂   “Getting things done” isn’t everything either, because I’ve known my fair share of those people as well.  Sure, the system works (now), but with the “smart” in there, it could be a big jumbled mess that’s a maintenance nightmare.  I believe the two go together.

How the heck do I determine if the candidate is a good mix of the two?  Ha ha.  No easy answer there either.  I have to use my own experience to weight everything the candidate has to offer.  Some reference checks can help to determine the mix.  Some phone screen questions can contribute as well.  For me, I think the coding assignment can help determining the “smart” part.  I’m not fond of assignments like “create a Roman number converter” because that mostly tests procedural programming skills.  While there is value in that as well, I’ve preferred to ask them to do a little something with a technology that they have no experience in.  I leave it open-ended.  Using every available resource, this is downright easy for a smart person, and it should be because I need to respect their time.  It has the potential, though, of saving an interview for a candidate we wouldn’t hire.

Getting things done:  I think questions can bring this out.  It seems like it almost a mentality of getting things done as opposed to talking about getting things done.  Stories of past projects can help with this factor.

What else is pertinent in a candidate I’m looking for?  Ignorance of something!  What?  Did I read that correctly?  Yes.  If there is something the candidate doesn’t know, he is human.  If the candidate is so well-versed in everything, then he’s kidding himself.  Very few people are like that, and they certainly don’t have to interview.  Real people don’t know things.  Real people are constantly learning.  Someone who is slow to admit ignorance might be hard to work with.  From personal experience, the more I learn the more I realize how much I have to learn.  Does that scare anyone else but me?  I hope so, but it’s real.  Remember the teenager syndrome?  Teenagers know everything!  In fact, they know little, but are foolish enough to think they know everything.  Wise folks reject this notion as time progresses.  I’m impressed with someone who can talk about the things he doesn’t know.  This shows me that he can recognize gaps in knowledge that need to be filled.

Continual learning is another biggie for me.  Someone who is constantly learning impresses me.  I ask what technical things the candidate is reading/studying.  Answers that include books, magazines, etc are all good.  Nowadays, podcasts are in that boat too.  If a candidate struggles and finally comes up with an article they ran across “last week”, I get suspicious and follow up on the topic.

There are so many different techniques to find good people, and there is no way I can know them all, but I continue to learn. 🙂

[tags: hiring, technical, candidates, recruiting, interview, interviewing, managing, programmer]

With unemployment at essentially ZERO these days, it’s hard finding the best people, especially skilled knowledge workers like programmers.  Every company needs programmers, so the good ones who happen to be looking are few and far between.  By contrast, the mediocre to poor programmers are abundant and available.  Wading through the duds to find the right guy can be a daunting task. 

In-person interviewing is the most expensive part of searching for new employees.  It requires real time from the people in the department.  Each time a candidate is turned away because of an interview, the company has lost time and money.  The trick is to keep the bad candidate from making it to the in-person interview.  I’ve recently employed a few techniques to minimize time spent by my team on interviews.  My goal was to bring a candidate to interview only if I felt we would be making an offer.  Here are the things to do to weed out the folks who are unlikely to make it to the offer stage:

• Do a technical phone screen on every candidate.  Ask basic questions about levels of experience on required technologies and 3rd party libraries.  For instance, if your team uses 3rd party tools like CruiseControl.Net, Resharper, NAnt, NUnit, SVN, NHibernate, Rhino Mocks, etc, then it’s a plus if a candidate has used some of them.  This phone call should also ensure that you aren’t wasting each others’ time.  Make sure the candidate is interested in the kind of team you are running.
• Given them a “take home test”.  Make the questions appropriate for the technology (no insulting trivia).  Good questions are ones that a good programmer could answer easily.  The duds will fail the test, and you will have saved some time.
• Ask for a sample of code including code and SQL.  What they give you is a good indication of the types of things they have worked on and are confident in. 
• Give a coding assignment.  Call it an audition if you wish.  This can be any small coding task, but make it a prerequisite to the interview.  The interview is the most expensive part of the recruiting process.  I like to find a technology the candidate is not familiar with and ask them to produce something with it.  This ensures that the candidate can pick up new things and produce quickly.

I fully recognize that recruiting is not a science.  The worse thing to do, however, is to just talk in the recruiting process.  I’m going to ask my programmer to write complex software, and talking about it is little indication of that aptitude.  I prefer to see some example of the professed ability.  When a candidate easily progresses through all the above steps, it’s pretty certain that the in-person interview will be a “getting to know you” gate that opens easily to an employment offer right away.

[tags: hiring, technical, candidates, recruiting, interview, interviewing, managing, programmer]