How much weight should the ability to write code in an interview carry?

Question

Possible Duplicate:
Any reason to not ask an interviewee to write code?

IMO, Syntax can be learnt. At the same time, it helps if a candidate knows how to use the language efficiently, and this would probably reflect in the resume if the candidate is experienced.

When looking at a candidate for a developer profile, I look first at logic, the ability to communicate, problem-solving skills. Then at targeted/mentioned technical skills in the candidate's experience.

• When/Why would you ask the candidate be asked to write code?
• How much weight should the ability to write code carry in an interview?

• Whether the code should be written on a whiteboard or in text editor (Visual Studio)? Text editors helps to deal with syntax, but it is usual environment for developers.

Answer 1

If the candidate claims experience in a language, they should be able to code in it. They may not know the details of every API, but they should know the basics.

I'd be very wary of someone who claimed years of experience in a language but couldn't actually write it in an interview. As a candidate, I've always preferred interviews where I am asked to write code - it means I can show that I can do it.

The exact weight is likely to vary by interview - you may want to have one problem-solving interview and one more code-based one. Alternatively you can combine them: talk about how to solve a problem, and then ask for an implementation - with some hand-waving if necessary. ("Assume we have a type which does [this bit] - now we can...")

Another question is whether you use whiteboards or laptops for such interviews. Laptops are good for giving someone a problem and leaving them to get on with it for half an hour - whiteboards are good for discussions, IMO.

Answer 2

It is a nice practice to ask the candidate to write code if the position is for a developer.

If its for a senior position it would be a waste of time to make the candidate write code.

Answer 3

From my opinion, at least 50%, if the position implies writing code. But not a particular language, necessarily. A good program has to understand the main principles, must have knowledge of basic algorithms, etc.

Syntax is not the most important thing, but if he claims that he knows a particular language, he should be able to code in it. Something basic, not rocket science, but anything you write in a CV must be backed up. And testing this at an interview seems only logical to me.

Answer 4

If someone claims development experience they should know how to code. If its someone moving from java to c# they know a lot of the language, they may just get caught by the libraries and where they live.

the coding test should can be done at any time. A well known consultancy make you do the coding test before they do any other interview process.

I wouldnt let the coding test change your opinion on them too much unless they make mistakes that are really bad. e.g. using a tsv in a list when they should be using a hashmap or dictionary

Answer 5

Candidates should of course always be able to write a code sample, but I don't think it is a very good measure of how competent programmers they are in that particular domain. A very large part of being a competent programmer is about the ability of reading and understanding other peoples code, asking them to analyse an existing piece of code is perhaps a better approach than letting them write code themselves.

Answer 6

I generally don't ask candidates to write lots of code ; what I generally want to know is if they have the background required for software development : do they understand anything about algorithms ? Are they able to think ? Do they know anything about modelisation ? Do they have good habits / practices ?

For instance, someone that uses Frameworks (even if not the one he will be using in the company I work for) is generally considered "better" than someone who always spend days re-inventing the wheel.
After, asking a couple of questions specific to the languages/frameworks/tools a candidate says he used is nice : it allows to see if they really used it enough to encounter some problems, and to know how they managed to solved those -- after all, developping software is also about solving problems!

Someone who spent time learning another language by himslef, even if one he won't use at work (particularly one he won't use at work) also has a nice point.

Something I really like is when candidates code in their spare time, and release code as Open Source : it is the best way to know what they can really do by themselves -- without having a boss who said "use this or that".

After all, if the candidate really lied about his abilities, in France, the company has 3 months (some kind of "trial period") to say "after all, we won't be keeping you" -- though I've not seen that happen often...

Answer 7

You can let applicants write some code to see if there are some basic skills or not, but you can't really give them such a complex task that it will actually show anything more than that. The demanding part of programming often takes place before the code writing starts.

Something that might give a bit more insight to a persons ability is reading code. You can present the applicants with a piece of code that has some deliberate errors in it, and see if they can understand the code and spot the problems.

Answer 8

I have quite a strong opinion here, I believe that if you are interviewing a programmer, you MUST ask him to do some code, would you hire a pianist without asking him to play the piano before? These are the three things I believe you must ask him:

What follows is extracted from an article I wrote on my blog 3 tips to know how good is the candidate you are interviewing

1.- Make the candidate draw a high level design. This activity will help you to know how good designer the candidate is.

Ask the candidate to explain in a board the architecture and design of some previous application he has developed. This will allow you to engage him in an open conversation, by the end of it you should be able to answer yourself the following questions:

How good was he explaining the design? One of the most important qualities of a programmer is his communication skills, is almost as important as the quality of the design, if the candidate is not able to explain it in a clear, concise and focused manner, then how is the rest of the team going to understand it? How good was the design? How good was he answering your questions? You want to make sure that the design he is explaining is his design, so ask him a few questions and see how he answers you, based on that you should be able to tell if he is really the author of the design.

2.- Make the candidate write some code. This activity will help you to know if the candidate is able to produce working code in a realistic time frame.

There is a very popular article from Joel Spolsky “12 steps to become a better code” where he states as point 11 “Do new candidates write code during their interview? “, well, I couldn’t agree more, that will give you an unique perspective on how the candidate really performs, there are still a few considerations.

Leave him alone in a room with a computer, just come back when the time is over. Make him code using the same tools he would use in the position he is applying for. Leave him enough time to complete the task

3.- Make the candidate review some working code. This activity will help you to see if the candidate has a good sense of what good code is and will help you to determine how good he is reading code.

By asking the candidate to write some code, you should have some idea on how clean his code is, but that could be a false impression as you will be judging based on a piece of code which has been written under quite pressure, that’s where this other activity will help you, hand him over some poor functional code written in the language he is applying for, and leave him alone with it for as much time as you think he will need to review it, then come back and ask him the following questions.

What is the purpose of the code? What do you think of the code, is it a clean code? What would you change from the code to convert it into clean code?

Answer 9

I think I can figure out pretty quickly if someone is capable of coding for a specific language, without letting him code. It all depends on the questions you ask.

More important is, does he/she fit in the team, can the candidate grow in your organisation, can he/she get things done, is there "more in the package" than is described in the CV, and does he/she understand pointers. (I hope everyone agrees that understanding pointers is not only required when writing C/C++).

But writing code in an interview is not bad, since it can also unveal other capabilities besides understanding the language. Things like problem-solving, understanding of algorithmics, speed and tidyness. You need to carefully choose what piece of code you let the candidate write. Maybe you could ask some questions first and then pick the code-assignment that best fits the candidate. Also, you need to think about how you are going to evaluate the results. Bad code or a non-working result does not always indicate a bad candidate. Maybe the assignment was not carefully picked. You might want to review the code together with the candidate, point out what, in your eyes, is wrong with the solution and watch how the candidate handles your suggestions. Maybe he/she convinces you that the solution is good after all!

But, for a position as developer, coding abilities are not the only required capabilities. Design decisions, understanding patterns, and a small hint of stubbornness are just as important.

Answer 10

I've found its very easy to sort the wheat from the chaff with a simple programming exercise. I've had some people who after an hour have managed 4 lines of code that won't compile, and others that have built a number of web controls and classes and implemented everything I asked for and more, even teaching me a few things in the process.

I would never hire a developer without getting them to write some code first.

Answer 11

It is extremely important that a candiate be able to write actual code in an interview. This is what they will presumably be doing once you hire them, so make sure they can actually do it. It's too easy to bluff one's way past an interview that doesn't require coding. If someone cannot code, you probably don't want to hire them. Even if they are super smart, you may want to think twice because it will be a long time horizon until they are productive.

How much weight? If the person cannot write code during the interview, it is an immediate blocker. This should carry 100% negative weight. On the other hand, if they can code, you need to move on to make sure they know how to design, fit the team, etc. Coding is just the first step, but it's a very important one.

A few notes:

• Coding != syntax. If a candidate makes small syntactical mistakes in his/her code, that's fine. The compiler will catch them.
• Language is not important. If the candidate can code in a similar language to what you need, you can teach the other syntax easily. Beware, however, of dropping to a lower-level language. If the candidate only knows PHP, beware hiring them to code C#.
• Candidates, if the company does not ask you to code, beware. They probably hired a bunch of people who can't code and you'll be stuck taking up the slack.

Answer 12

Based on the very high percentage of candidates I’ve interviewed that couldn’t write very basic code, I’d say the answer is a definite yes. It can be argued that this puts pressure on the candidate in an environment which is not consistent to what they’d normally be working in but there are a few fundamentals which an interviewee should be able to pull out at any time.

I’ve opted for the model of providing a very basic business requirement (with a couple of simple caveats), and given the candidate 30 minutes of alone time to complete on a machine with Visual Studio but no internet access. I believe this gives the right balance of not placing undue pressure yet requiring some degree of skills demonstration.

After the code test is done I always talk through it with the candidate and give them the chance to explain their thinking. If they get stuck somewherethen they have the opportunity to talk through their thought process which usually demonstrates whether it was momentary brain fade under pressure or they’re simply not up to scratch.

BTW, to put things in perspective, I’ve had the vast majority of candidates (in the .NET world) fail on syntax as simple as nullable types, generic collections and string builders. Gotta love the agency screening process!