When we're developing software, for our own products or for our clients, we have always been diligent about managing the version numbers of our compiled code. With reliable versioning we can better track when issues were discovered or introduced and at what point they were fixed, it provides a consistent model for applying labels in source control, allows us to monitor aging of bug reports, but I digress. I'm not here to discuss the virtues of version numbering, I'm here to share a tool we've been using that has made managing version numbers, particularly in large projects, much easier. 

We've been using a wonderful Visual Studio extension,  Automatic Versions by Precision Infinity. The tool allows us to control the rules for how version numbers are assigned, automate some parts of the version number while maintaining manual control of the incrementing of other parts of the version number. It helps is maintain consistency of versions across multiple projects with almost no effort. This has been a HUGE time savor for us.

Our new favorite extension for Visual Studio is the Visual Studio Spell Checker by Eric Woodruff. The plug in offers a word processor quality spell check utility to Visual Studio code for elements such as comments, string literals, and content (such as html). It knows not to try to spell check variables, html tags, scripts, etc. With spell check as you type and integration with Visual Studio's suggestions menu, embarrassing spelling errors in code comments, documentation, and content produced in Visual Studio are a thing of the past. Thank you, Eric, for releasing such a helpful tool.

I'll just come right out and say it: Asking a programmer to code during an interview is a bad idea.

I've seen many interviews in which the interviewer - usually one of the programmers on the team the interviewee is hoping to join - asks the interviewee to write some code, either on a piece of paper or on a whiteboard or sometimes on a computer ... though rarely. I'll even admin to being guilty of doing this when I was younger. I've watched my staff ask candidates to write code, I've watched my teams debate over what they should have a candidate code during the interview. Eventually I'll intervene and put a stop to it. Here is what I tell them.

Asking someone to write code during an interview does nothing to give you insight into their programming ability. 

A) No one writes code on paper or a white board ... not ever.
B) Modern programming tools are full of features such as auto-complete, immediate error checking, beautification, etc. None of which are available on a white board.
C) Programmers have always relied on looking up syntax, code snippets, and how-to's on the internet. If you aren't willing to let your candidate do the same during the interview, then you shouldn't be asking them to code.
D) Programmers will remember syntax, features, functions, and algorithms they use often, and will not remember syntax, features, functions and algorithms they use infrequently or not at all. Will you know in which of these categories your programming tasks fall?

I can hear the push-back now. "But if we stick to basic coding, they should be able do that."

To which I answer - if your coding task is that basic, it doesn't tell you anything

Again, I can hear the push-back. "It will help us weed out people that can't code."

To which I answer ... if a candidate for a programming position has made it to a face-to-face interview and they can't code then your candidate selection process leaves much to be desired. Perhaps fix that first.

There are other questions you can ask that will tell you about their programming capabilities, but it is important to let them draw from their own experience. Interviewing a programmer should be a discussion and if you ask the right questions, they can lead to meaningful discussions that will tell you more about your candidate than any coding assignment you throw at them.

Tell us about a particularly frustrating programming challenge you faced. A question like this allows the candidate to tell you about a real problem from their own experience, so it takes out any bias you introduce by choosing a problem for them to work on. It will open the door for you to ask how they solved the problem, to understand the nature of a challenge the candidate might struggle with, and dig into how creative they get when solving a problem.

What is the worst coding error you've ever seen? I haven't met programmer yet that hasn't seen some really bad code that is burned into their scull. The ability to explain the code and why it is particularly bad will tell you a lot about their own skills as a programmer. If they can't recall any bad code there is a good chance they aren't good enough to recognize bad code when they see it ... and in all likely hood are producing bad code.

What development environment (IDE) do you use? What is one thing that frustrates you about it. First, if they can't discuss their own development environment then they are a novice at best. Second, anyone that spends quality time hunkered down writing code will have something that frustrates them about that environment. Being able to articulate that will tell you a lot about their abilities and should lead to a discussion about programming topics and practices that the candidate is particularly passionate about.

Tell us about some coding conventions you or your team has. Again, anyone that doesn't know what a coding convention is probably doesn't have enough experience for you. This question shouldn't be used to judge the conventions themselves (programmers love to judge each other and each others teams, but now is not the time). The range of answers you get back will be huge. Anything from using Pascal case for variables to database access conventions to code performance analysis practices. Regardless of the complexity of the convention, the response should open the door for you to have further discussions such as the benefits or drawbacks of the convention, and offer opportunities for the candidate to demonstrate their knowledge and experience.

Questions such as these foster a dialog between  the candidate and the interviewer(s). That dialog is where you will get an understanding of their experience and abilities. Giving them a programming task is usually more of a test of their ability to memorize than anything else and memorization ability most definitely does not equate to programming skill.