Any reason to not ask an interviewee to write code?

Question

Many people, Joel included suggest that a person who wants a job as a developer is asked to write code right in the interview.

I think it is perfectly reasonable. If employed he will have to write lots of code and therefore the interviewer would want to check that interviewee really can write code and has not just listed all the words he knew in his resume. Plus seeing just-written code helps evaluate the level of the interviewee's expertice.

Now are there any valid reasons to not ask a person who is interviewed for a position requiring regularly writing code to write code right in the interview?

Answer 1

If you're not a developer you shouldn't ask someone who is interviewing for a development position to write code, since you can't evaluate it.

Other than that, no.

Answer 2

If the code is non-trivial, you might give the candidate five or ten minutes on his own with a piece of paper (or a laptop), and go have a coffee... I find it really hard to concentrate on writing code when someone is watching me, waiting for me to finish.

Answer 3

Maybe if the person is an apprentice/ trainee and therefore the intention is to learn to code on the job.

However, No. You have to interview people on what they will be doing in the job. If that's coding then ask them to code!

Answer 4

Depends on how the code writing is carried out. Many developers complain today if they have to write code on paper, as they are really comfortable doing it only in Eclipse. In particular, they never learned the full names of methods and classes by heart, but rely on code completion to tell them. To properly address that, they would need to write the code on a computer in the interview also.

Answer 5

It's very common for developer's to want people to write code in an interview. I'd say it's up to you. I personally prefer intelligent discourse. I can learn a lot more about a person through normal conversation than I can by giving him a test. A lot of programming tests for an interview tend to be one of the following:

• Too simple - don't demonstrate any real knowledge
• Too complex - easy to make a mistake on, especially given the stress of the interview
• Irrelevant to their duties
• Implement some arbitrary algorithm from Sophomore CS
• Only pen and paper

The important thing is that the interviewee has domain knowledge and can answer questions intelligently.

I would hire a person who failed a programming test yet demonstrated intelligence, creativity, and the desire and ability to learn over someone who passed with flying colors yet had demonstrated many of the personality traits (flaws) common among developers.

Cheaters Prosper

Another thing I'd like to add. If I gave written tests, I would be much more impressed by the person who "cheats" (google, stackoverflow, IRC, manuals, asking a buddy) to get the answer over the person who knew it already. The ability to be resourceful is a wonderful trait.

Hall of Shame

If you do decide to have your interviewees write code. You MUST share the code of any failed ones with the rest of the team. Hell, make a wall of shame. It'll make for good laughs, we love to make fun of other developers :) (Please preserve the anonymity of the poor soul though)

Attack of the Clones

Another issue that occurs is that the test is often written by the management (if technical) or one or more of the current development team. They will obviously write questions that they know the answers to, and consider challenging. This will lead you to have a team full of developers who can implement a quicksort algorithm in 15 lines of C yet not a one who can write a unit test or profile properly.

Answer 6

In theory, none....

However, you've got to think carefully about the type of problem you ask them to solve. These days people have become more dependent on things like Intellisense and integrated help, so often they're only use to working with these aids available. If you're asking them to write the code on a whiteboard then you may want to cut them a bit of slack.

I worked in a place where they use to get candidates in to sit a GUI and multithreading test at a PC which lasted about an hour. The problem was they were also willing to interview people without much multithreading knowledge but wouldn't change the test to cater for this. Putting someone in this situation is unreasonable and they would have people complain or (in one case) walk out!

Answer 7

For senior positions, I think it's a total waste of time. It should be clear from the conversion during the interview if a candidate is fit for the job or not.

If a developer has more than 15 years of software development experience, it's silly to have to write code, because it says little about the skills of the candidate. If the candidate has 10 years more experience than the person doing the interview, it can get downright embarrassing.

Answer 8

The only valid argument against writing code in an interview is if the candidate isn't strong in whatever language you use, and you aren't strong in whatever language the candidate prefers. Even then, you can always give the candidate the choice of language and just verify that it works correctly.

That's not to say that writing code is always the best way to spend time in an interview, but for a programming position, it's always justified.

Answer 9

I've been asked to do this once. And it was actually a good way of doing it.

The customer had given a short assignment and said the program shall be in Perl. That's all there was, really.

I made the initial version in Lua and ensured it worked; then rewrote everything in Perl (this is because I had never used Perl before) and sent it to them for review. I got the job.

So what I'd suggest is giving the assignment not in-situ but as an email before the actual meeting. This gives the interviewee time to think about the case and properly test the results. Most results you get will have bugs, which in itself tells a lot about the person.

You may also ask how long it took to make the code.

If wanting to have people code in-situ, one should give them their favorite editor and -say- 30 minutes time all by themselves. And Internet. And any known reference books they normally use. So... it might not be worth it?

Answer 10

In principle, none if you take it with a pinch of salt and consider stress and how unrealistic the situation is (you don't actually work like that, but who gives the interviewee access to stackoverflow, google and a poile of o'reilly books in the interview?)

However I think it's a serious flaw to ask questions which depend on knowledge of specific parts of a framework or syntax that everyone intellisenses say. I find it much more reasonable for someone to ask me to code out a generic factory pattern say, or work through how I would define objects X,Y,Z then to ask for an example of asp:foo control in action.

In short: coding is fine, but don't put them in an unrealistic scenario and expect realistic results.

Answer 11

If and only if you are the last interviewer of the day, and the three peers of yours who already interviewed him on his programming strengths say either of the following:

1. "This interview candidate is a complete dud. There's no way he can work here." In which case, your job is to wrap up the interview while making him feel good about himself. You don't want him leaving the interview thinking your company is a buch of pricks that ask insanely tough questions. Because, he might have friends that you would want to hire.

2. "The interview candidate is a rock star programmer. We'd be insane to not hire him." In which case, your peers probably already grilled him enough on technical aptitude, but they probably forgot the soft stuff, like actually explaining what your company or product team does. Give the candidate a demo of the product. Tell him about the roles of different team members. Ask him what his career aspirations are, etc... then sell the hell out of your open position to him.

Answer 12

I think the best way to do this is to have the candidate write in a 'psuedo-code' style. So for example, instead of ACTUALLY writing, say, C# code to do X task, they would just write fairly low level psuedo code to demonstrate that they know the steps involved, how the thing should be implemented etc. Speaking from experience, the mind can go horribly blank when trying to remember real classes / methods etc. If you ask them to write in a specific language, even if they know it in and out, you're still putting them in a position of stress, where in any normal job they'll have all kinds of resources available to refresh their memory.

I think in principle it's a good idea - anyone can ream of a list of buzzwords and sound confident in an interview, so it makes sense to challenge them.

For my current job, I had to write a program overnight, bring the source code and working binary, take two interviews, give a presentation on RPC / RMI, AND do a little test, including this kind of challenge. All told it was pretty stressful :/

Answer 13

Depending on the experience and skill level of the person begin interviewed it may be better to provide some sample code and asking them on how could it be refactored or written better. You’ll find far more out about someone by asking them to evaluate code rather than write some code.

Answer 14

I see no reason not to ask him to write code. Leave him alone for a certain amount of time. You might want to tell him on the phone so he knows in advance he will have to write some code...

If the position requires a certain programming language, he will for sure have to write the code in that language.

Maybe you should discuss his result with him afterwards so he can explain you why he has done certain parts the way he did it.

Answer 15

1. Programs are never Written, they are coded.
2. You are selecting a candidate for his coding approach,knowledge. Having him write something on paper is simply a waste of time for questions you could have asked him orally. It gives an impression of you being a "nit-picking" person.
3. Writing code is confusing, there could be spelling mistakes (that the IDE always handles) there could be simple things that you forget to write eg initialisations, etc (also warned by IDE)
4. Asking a person to modify written code is again stupid. Its not digital text that you can suddenly add variables at the top, add new methods to the class.
5. Besides, the most practical reason is that programmers are so used to coding, that they seldom write stuff.

So when you think of making someone to write code, ask yourself the following questions: 1. When was the last time you used a pen to write a program ? 2. Did you like it ? 3. Do you want to do it again ?

Answer 16

Getting the prospective interview to write code takes time, and time is what most interviewers don't have, especially if you've been unlucky enough to only get your shortlist down to 6 or 8 folk, which would mean a full day devoted to it. I've interviewed over 80 people, programmers, analysts, software engineers, pm's, architects, business analysts, the lot, and it was a bone crushing tedious exercise for the most part and getting them to sit for another 20 mins just wasted more time and adds to the tedium.

10 minutes of intelligent conversation, and a few probing technical questions will tell you right away if the interviewee know their stuff, and i'm not talking about asking vocational quetions like the difference between abstract and interface, more akin to design questions, of global and local in nature.

Answer 17

Anyone who is a developer, manages development or is going to have input into technical decisions being made should be asked coding questions in an interview. I ask different types of questions depending on how much code the person will produce on a day to day basis. I tend to ask algorithmic questions and I am not concerned as much with exact syntax for library functions. However if you are knowledgeable about your tools you should have a good idea what is in there.

Some examples:

1. For individuals who list distributed computing on their resume I ask them to code a distributed hash sort. Developers who have worked on real large scale distributed computing projects should know what this is.
2. For individuals who list Hadoop and or Map/Reduce I ask them to explain map reduce from beginning to end and then to code PageRank in Map/Reduce
3. I tend to also ask threading questions. For instance something I will ask is to implement a ReaderWriterLock with a Monitor

Why do I think asking hard questions in an interview is important even for dev managers? Bad technical decisions are often very expensive. A manager is going to be a resource and mentor younger developers and train them to make good decisions. Little things often pile up to make software slower or faster. Is there a more performent heap for your workload? What's the best way to build a parser for maintainability and speed? How do you measure L1 Cache misses and why is this important?

As the scale of the software increases the importance of understanding thorny technical details increases. While reducing CPU utilization 10% may not make difference in a desktop app, in a large scale service the same reduction can have hundreds of thousands of dollars.

If someone cannot explain and demonstrate important technical concepts in an interview it is likely (although not certain) that the will be unable to understand and properly apply them to their job.