How to hire a programmer

I'm always a little amazed when I hear of an employer who doesn't give a written test when hiring someone. I know it might take more time and I've often heard how some people don't work well under interview-pressure – but that's just tough luck. I swear to god, we have higher standards when it comes to hiring a juggler for a kid's birthday than when it comes to hiring programmers – I blame talentless managers.

That mini-rant aside, my favorite way to perform interview tests is to write a very basic feature description go over it with the person and ask them to actually code it on a COMPUTER with all the tools you're used to using (specifically, google/the internet, VS.NET, SQL Management Studio, …). I never remember what an SQL Server connection string looks like, and I'm not going to expect someone else to remember.

The type of "feature" I normally ask for is a *very* simple user-management tool where you see a list of users and can edit/add/delete their information (maybe a name, email address and password or something). I'll typically mention that the feature would be part of a larger enterprise application where maintenance is key. The goal is to get to see how they write their code. I'm specifically interested in seeing if they use any N-Tier or OOP concepts and how their codebehind/aspx are done.

I like to give them about 1 hour to work on this and will let them have up to 30 minutes of "do you want a bit more time?" Hopefully we can all agree that 1.5 hours is more than enough.

The first time I used this system we interviewed 7 people who did miserable. My manager (the owner of the company) told me the test was obviously too hard and I needed to adjust it. Luckily, before I had time to do so, we interviewed an 8th person who wrote it in 30 minutes and did better than people who worked on it for 2 hours. We hired him and it was well worth it.

Here are some general recommendations if you do give exams (or want to start) during interviews:

1. Don't make the exam too hard or too long
2. Write it yourself, have other coders on your team do it too, and adjust it accordingly to how well you did
3. ALWAYS let the person know they'll be writing a test prior to the interview and let the person know how long it should take
4. Don't bother giving the exam unless you think the person is a good fit in all the other important categories
5. To expand on point 4, consider doing it as part of a follow up
6. Tell them to fill in any auxiliary parts (like logging) with comments if they want to, and that other comments aren't really necessary
7. Give them full access to all the tools you use, create a blank database for them and give them a username and password that has full access to that database – for security purposes, you might have to adjust your network a bit
8. Let them use the internet and any books you have (you might want to mention to them that they can bring any books they like to the interview for the exam)
9. Treat them like any other employee: don't look at them code more than normal, sit them with your team (if possible)
10. If you use stored procedures, mention that you'd prefer they used stored procedures if possible. If you don't say anything, don't hold it against them for whatever they use.
11. At least 2 or 3 times ask them how it's going, what part they are on and if they are having any difficulty. GIVE THEM the answer to any questions they ask. If you don't know the answer, either tell them they are looking at it wrong or help them look it up. Don't be afraid to sit down and type A BIT for them.
12. Let them know that their time is up and ask if they'd want to spend more time finishing stuff up or reviewing it.

I'm not going to tell you what you should look for or not (since it'll depend on your own personal prefences), but there are some real tell-tell signs as far as I'm concerned:

• Datasets and SqlDataSource are very bad (update: the dataset thing didn't go over too well in the comments ;) )
  
• Data access shouldn't be in the aspx or codebehind
• Objects should be properly disposed of (using either try/finally or usings)
• Check how exceptions are handled: I don't expect anything in the global.asax Application_Error but exception swallowing is also very bad
• Naming convention might not be a big deal, but I hate Hungarian notation
• No hard-coded connection string (or at least a //todo, move to config)
• Caching!
• Parameterized queries for either sprocs or in-line