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
This entry was posted in Grab a coffee before reading. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

24 Responses to How to hire a programmer

  1. Michael says:

    I’d have to agree with Christopher… testing your recruit’s problem-solving skills by giving them a smelly sample code and see how they do with it, but is that really what separates great programmers or software development companies from the rest? I’d say, there should definitely be problem solvers in the team, people who get new ideas into the team, new technologies, inspire, and make a project more fun than work, but there’s so much more to it that ultimately will determine success of your project… Afterall, let’s face it… Who here can honestly say that all the programmers on your team are perfect? I’ve been managing software development projects for over 10 years now and I’ve outsourced most of the development work quite successfully… Whether it’s a simple website or a complex software application, there are many items to consider: from methodologies, to team structure, resource alignment, proper planning and prototyping, testing and quality assurance processes, etc., etc., etc. I’d say in this day and age go by public opinion – go to guru.com for example and find a top ranking developer in a category of your interest – for example, I went to guru’s Web Design and Internet Marketing category – #1 vendor on guru is Zallas Technologies, http://www.zallas.com, 15 five-star reviews, excellent portfolio, Google them just in case :) and you’re good to go.

  2. James McKay says:

    I agree that DataSets are bad. However, I don’t think you should necessarily hold it against a candidate for using them in an interview. Having said that, it’s always a good idea to ask them why they’re using them, what the pitfalls are, and what alternatives they might consider.

    Hungarian notation is similar — it’s very much a matter of taste, and it’s a good idea to ask your candidates why they are using the specific conventions that they have chosen. A good candidate will be able to tell you the difference between Apps Hungarian and Systems Hungarian, or even point you to Joel Spolsky’s essay “Making Wrong Code Look Wrong” where he explains how to form Hungarian conventions to help you write secure code. (http://www.joelonsoftware.com/articles/Wrong.html)

  3. Shan says:

    Well I agree to the exam pattern recommened except for giving the whole MSDN to start with …. If hiring a Programmer how bout start with a Little Logic exercise ..offcourse all of them and us also know it but sometimes given a situation it helps if the person has coded or went through the Syntax atleast …then talk bout Adding data to a dataset ……. cuz many of the guys dun pas the if then else …..

  4. I read this article recently, and ironically enough had an interview very similar to this earlier today. I got the job…I owe you a virtual beer (kinda ;-) ).

  5. karl says:

    Well said Mathias. I agree.

    We had to pull out some data from a database and dump it all to a table recently. This was a 1 time operation. Of course we used a DataTable with a DataGrid, but otherwise I’ve managed to avoid them for the better part of 2 years :)

  6. Mathias says:

    DataSets really are very evil for anything that has to do with performance and code quality. Here are just some of the drawbacks that you can’t work around in my experience:
    - Allocates massive amount of objects on the heap, which puts a LOT of pressure on the GC in any high usage scenario. Time in GC % exceeding 20 % is not uncommon in server applications that use DataSets extensively (When GC runs, all other threads are suspended, effectively choaking your application throughput…). Just doing a ‘new’ on a reasonable sized dataset class can allocate several hundreds of Kb (I have seen 400+ kB and hundreds of objects allocated from a single ‘new MyDataSet()’ several times).
    - DataSets serialize bloatedly. Since the DataSet object model is massive, a serialized dataset is very large.
    - DataSets as a part of any web service interface makes integration with other platforms very hard, which rules it out in any mixed architecture (DataSet serialization is memory intensive, formated rudely and a pain in general).
    - DataSets do “too much”. Most of the times you only need some of the features, but you always have to pay for all of them. For instance, the event model is very rich which means that it is not uncommon that ds.AcceptChanges() consumes 95 % of your CPU resources in highly compute bound applications (actual result when profiling server application) – even when you are not sinking a single event. Since you can’t turn off these features you are powerless unless you stop using DataSets.
    - DataSets encourage working with data in a relational, set oriented way instead of instance of types, which works agains the OO nature of .NET. To elaborate:
    - DataSets forces a separation of data and behavior which firmly pushes the coding style towards being very procedural (OOP becomes unnatural). This leads to several bad things. Some examples are no data encapsulation, fragile client code, massive amounts of fan-out-dependencies in client code and the same maintenance problems that plagued structured programming, etc.

    To be honest, DataSets as a general purpose data access mechanism for large application is just a bad choice. I would only use it for small, in-house apps or maybe, maybe, very specific scenarios involving zero performance requirements and multiple data sources.

  7. dr. job, swear to me you won’t push me to use typed datasets again ;). Now Im almost done cleansing some my modules that initially uses typeddatasets. I know its bit OFF topic to the original post but I take it from my experiences with TD. Its a failure to me, its very difficult, its pain. Got to always bring Subversion with you so you can always Revert onces things messed up.

    I had something to say here, http://community.devpinoy.org/blogs/dehranph/archive/2006/09/26/.NET_3A00_-10-TypedDatasets-Pitfalls.aspx

    And I have lots of negative experiences with TD. My friends who comments might be corrct that maybe I’m just a newbie to TD, but I dont want to take chances and compromise my project again.

    So dr. job, swear to me lols ;)

  8. karl says:

    AsbjornM:
    In my code example, I said that was the kinda of code i wanted to AVOID. So yes, I’ve violating EVERYTHING…which is exactly what I don’t want to see :)

    I don’t want to see untyped datasets (yes, typed are better) and I don’t want to see dataaccess in codebehing :)

  9. AsbjornM says:

    Ok, so “DataSets” are Evil, but Custom classes are ok?, So, if you use Typed DataSets, then you are closer to Custom classes, right?, and then less evil? :)

    Well, I use TypedDatasets, and that works very well.
    The code-example you provided in you last comment here is violating everything, one thing is that you use an generic dataset, another thing is that you bind directly to the dataset itself, not giving anyone any clue about what you want out on the form, third, you are doing dataccess in code-behind…
    So, that was not an good way of telling datasets is evil, Or?

  10. Great post. Since a great deal of a developer’s work is usuallly fixing/maintaining legacy code, what about giving the candidate some smelly code (with unit tests) and asking them to refactor it. Billy McCafferty has contest going on where’s he doing this (http://devlicio.us/blogs/billy_mccafferty/), but I think it would be a good for interviews as well.

  11. karl says:

    Matt:
    Personally I like to sit them at a desk and let them work on their own. I keep an eye on them though, and like I said, pop over 2-3 times to ask how they are doing. A L shape configuration is nice, so you can just take a quick peak over your shoulder.

  12. Matt says:

    Barend: How on earth would you NOT notice the candidate copying a previous solution? Do you leave the candidate alone during the interview? If so, what’s the point of giving them a programming exercise at all. The point of the interview is to find out how they work and whether they will be able to work in your team. If you’re not there while they’re working how will you find that out?

  13. karl says:

    Sorry everyone…I’ve always had a thing against datasets…I could see past it for this particular example (it’s true that they are particularly well suited). The only justification that I have is that I did state it would be part of a larger enterprise application.

    I would like to see a hint of an actual business layer and some type of representation of a “User” class (especially since it’s basically 4 properties). If the actual data-access behind the scenes uses DataSets that would be totally cool. What I’m specifically trying to avoid is the..

    Page_Load
    if (!IsPostBack)
    {
    SqlConnection connection = ….
    da.Fill(ds);
    Grid.DataSource = ds;
    Grid.DataBind();
    }

    AS a couple people mentioned..there are some other things worthy of taking into consideration..namely how they setup their DB and whether localization fits in at all (especially since I live in a VERY bilingual town).

    As for caching…I just think it’s underused…you’re all right that if I expect it to be there I should specify it. It’s not like it’s a NO SOUP FOR YOU kinda deal, always just nice to see :)

  14. camera says:

    “Datasets…are very bad” and “Caching!”

    Could you please elaborate? I’m guessing that you don’t want to see a 0-tier solution. Meaning, you don’t want to see DataSets populated from SQL and then widgets populated by directly iterating through the DataSet object. You’d prefer to see Employee objects defined and then populated from the Datasets returned from the SQL call. You’re looking for separation of data access and data presentation. Right?

    And I certainly would not implement caching unless explicitly instructed to do so.

  15. Foxedup says:

    I would also like to add my weight to the “data sets aren’t that bad” argument. I agree that they are not suitable for every application, but they do have a place.

    If you gave me a spec in which you said it was “very simple” and only gave me an hour to write a solution, I would use datasets and I believe I could defend my approach.

    I would also not attempt to write a caching solution for something like this.

    You have to remember the that over complexity is BAD!

  16. Take into account that in an interview, I don’t know a lot of people who would be able to make use of a good framework in that timeframe.

    Given a computer and access to the net, it would take about an hour just to set up the env so I can start working.

    There is also the issue about what people will think if they can’t understand what I am doing. I was in interviews where I literally had written a piece of code in 10 minutes, and spend 30 trying to explain how / why it worked.

    * Datasets and SqlDataSource are very bad

    XXDataSource – Bad, DataSet not so much for this particular case.

    * Data access shouldn’t be in the aspx or codebehind
    * Objects should be properly disposed of (using either try/finally or usings)

    Agree! to both.

    * Check how exceptions are handled: I don’t expect anything in the global.asax Application_Error but exception swallowing is also very bad

    In general, I tend to not handle exceptions in asp.net, and leave it to final production, by sticking an error page.
    some stuff (db down, for instnace) you just can’t do anything about, and it is useless to try.

    * Naming convention might not be a big deal, but I hate Hungarian notation

    I really don’t care about what they use. As long as they are internally consistent, that is fine.
    If they aren’t, that is a problem

    * No hard-coded connection string (or at least a //todo, move to config)
    * Parameterized queries for either sprocs or in-line

    Agree!

    * Caching!

    Not something I would do in a task like this, to tell you the truth.

  17. Matt says:

    Even better is to pair program with them on the real production codebase. A canned coding test is never as good in my experience.

  18. Michal says:

    Very good article, Karl. Lot’s of good points. I’m just curious to hear why you think DataSets are so bad? We use them all the time in our ASP.NET 2.0 web projects to pass data from the Data Access layer up to the GUI layer. I know they are not perfect but it’s a lot quicker and simpler than writing custom objects.

  19. Barend says:

    Also make sure you clean out the machine they’ll be working on, I had one person copy code from a previous candidate, and call it his own. One problem, he copied the files with a create date of 6 months before he did the test, if he copied the code with notepad into his own project we would not have picked this up.

  20. Bryan says:

    My company administers a test to each of our candidates, and most of them are astonished and hint that they’ve never done this during an interview. I agree with most of this post, with the exception of the inclusion of Google (other web access).

    We had a candidate that was admittedly an inexperienced developer, but since we were (and are) tight for people, we decided to give him a shot at the test, expecting him to ask questions and do as much as he was capable. Several hours later, we had a freshly Google’d application which met most of the criteria. The only reason we even caught it was because he had trouble integrating all the requirements in the time allotted. After a few searches we found the identical source code ourselves. Had he just a little more experience, we would have been stuck with a near-novice, plus the cost in terms of time getting him up to speed only to later learn that he was incapable of the performing the job.

    I believe it is sufficient to supply the candidate with the full MSDN documentation (which contains structures of things like connection strings :) ) and let them figure it out.

  21. Liam says:

    I agree with Baz, Datasets are great for setting up parent child relations when doing reporting with nested repeaters on the web. Other than that I don’t use them for anything else.

  22. hello karl, can you spare me a plane ticket to Canada so I can give your exam a try. hehe ;). Nice one.

    You might also look if its localized, db properly normalized, uses side-by-side assemblies, multiple projects instead of app_codes, this is extreme lols…

  23. Jay says:

    Datasets aren’t always bad… that said, there is a very limited place they should be used. Usually in winforms.

  24. Baz L says:

    Wow,

    I would fail soooo bad….

    Then again I’ve only just begun doing stuff in C#. So obviously I love DataSets. lol
    Sorry.

    But these did make very good points.