How do you feel about being asked to code during an interview?

You do not have to be "in the zone" to be able to write a small program in front of - or even with - your future superior. To be a truly excellent programmer, you do not only have to be able to program, but also to communicate with others. Your ideas, your intentions, and all the other things that code doesn't indicate. Consider "interview programming" a test of whether you will be able to function in a "peer programming" environment.

In my experience, it's very common to be asked to write code during an interview, although it's code on a whiteboard and not actually working on an IDE to compile and run code. Almost every job I've had I was required to whiteboard some code during the interview. I've also been on the other side of the fence, being part of interview panel. Whiteboarding code is very valuable - it shows that the candidate: can understand the problem as stated, and break it down in a way to solve it knows the basics of the programming language (although he wouldn't be penalised for incorrect syntax, since it's only a whiteboard exercise - but if he used lots of Java-isms in a Python exercise then that starts alarm bells ringing!) understands concepts such as hashtables, network sockets, threads... whatever subjects the interviewer needs to test the candidate on understands the programming language's libraries, such as how to use those concepts in practice While it's possible you could just use non-coding questions and answers to find out if the candidate knows all these things, it would be a longer process. By using code, the interviewer can go deeper, faster, into finding out what the candidate knows. And in the end, to be blunt, the interviewer is hiring someone to write code. It's reasonable for your interviewer to ask the candidate to do in an interview what he would be doing in his job. If you have difficulty writing code during an interview, then I suggest you make the interviewer aware of this, and have code from other projects prepared for the interviewer to see. But be particularly careful to ensure that the code you show is relevant for the job you are going for - for example, if the company's product makes extensive use of threading, you need to show that you have that knowledge.

I feel ok about it. It seems reasonable to me to demonstrate a skill I am supposed to have in an interview for a job that requires that skill. My last two major interviews required this of me. I wasn't surprised. I considered it a good sign. In my current job I was asked to code up something I considered unbelievably simple - print out all the primes between 1 and 100. I asked the interviewer: "do you want something efficient or something that just works"? Something that worked was good enough. I asked if we could assume I knew how to print out a number to the console using printf. As I asked I wrote printf("%d\n", n) on the white board. "No" So, no need to write a complete program. This reduced the problem to writing a function to determine if a given integer is prime. I wrote the most brain dead function that was obviously correct. And the interviewer was happy with that. For the interviewer this question was about determining if I, or my CV, was full of it; to see if I had ever written any code. The other thing to note was that I asked questions of my interviewer. I engaged in a dialogue, one in which I showed that I understood certain aspects (albeit simple ones) of programming. Once I got that job I spent quite a bit of time doing interviewing too and I was amazed at how bad many interviewees are at even the simplest of programming tasks in an interview situation. You need to be able to show that you can walk-the-talk these days. I do not see that changing nor do I wish to.

I've been involved on both sides of the table - as a potential employee being asked to write code "on the spot" in an interview, and as part of an interview panel trying to assess the skills of an applicant. Your situation seems similar to that of an experienced singer. Any good singer will do warm up exercises before a performance - without getting "in the zone", warming up and focussing on the performance, the quality of the singing is not going to be their very best. But, they will be expected to sing during the interview - and the interviewers will be aware that it's not going to be the best he/she can do. Similarly, the actual code written during an "in interview" programming exercise is much less important than seeing how the applicant processes the problem and approaches the solution. Since coding during interviews isn't going away any time soon - in fact, it's becoming more and more common, in my experience - I suggest you could work to improve the way you come across in the interview. Some ideas ... Practice "stream of conciousness" descriptions of what you're doing. Rather than going quiet for 5 minutes while you work on the problem, describe to the interview (team) what you're thinking about and why. Don't make assumptions - ask questions. For example, instead of assuming that you need to write a highly performance solution, ask if performance is an issue. If they give you an answer with wiggle room (such as the classic "you choose") then state your assumptions, both verbally and on the whiteboard or as a code comment. If there is something you don't know, admit it up front - and state how you would find the answer yourself. Make sure you describe a number of different techniques. You could bomb out pretty badly with the code itself during the interview - but if you can show that you would have solved the problem under normal working conditions, you might still get the position.

To be honest I don't like it. I think coding should be planned in advance. I like to prepare myself. If they want to see my code, I can give them examples of previous projects that I've done.

I always ask coding questions. Stupid little puzzles like reversing a linked list or whatever. The usual. However, I hate this approach more and more. I find that it doesn't say much about the person I'm hiring. Only that they can write convincing code on the whiteboard for how to reverse a list (for example). So what? If they need to reverse a list in real life would they really do it on the whiteboard, and whiteboard alone? Probably not. Other things the interview didn't tell me: How do they go about testing? How approachable are they when other engineers need clarification. Do they ask good and timely questions when they're in trouble? How passionate are they? How much do they care about clean code? Performance? Do they use tabs or spaces (hey, I care about it! =) Can I pair with this guy? At this point all I know is that if I ever need pseudo-code for reversing a linked list, I found the guy (or gal) who can do it. Maybe slightly better would be have them code with a real text editor. At least I'll start forming an image in my mind of how they are as programmers. Still doesn't answer much, but it's a little better. Someone mentioned that a truck driver would have to prove they can drive a truck. I actually don't think they would have to show how to drive a truck by drawing things on a whiteboard as proof of their skill. In fact, I imagine they don't even drive a real truck to show off their abilities. They probably just show they have the proper driver's license and the rest of the interview revolves around other stuff. That being said, I enjoy interviewing people almost as much as I enjoy being interviewed, which is not much. So I'll probably keep asking how to find the medium node on a linked list and continue being in denial about how answering this question somehow correlates with being a good asset for the company/project.

My personal feeling is that it's ok as long as the interviewer is clear what he wants and the program/piece of code is not long. Most of the times, the code is not actually about coding, but showing to the interviewer your reasoning process. So you just have to demonstrate that you handle the edge cases, use appropriate data structures etc. For writing upto 50 LoC, I don't think you need much preparation. Of course, there are some interviewers who want code with perfect syntax that compiles on the first run. I don't like interviews like that.

If I was interviewing a person for a job as a bus driver, I wouldn't hold it against them if they didn't know how to attach horses to a wagon. Who does that anymore? In the same vein, there are many programming jobs and tasks where people don't do things like hex, pointer arithmetic, reversing strings or recursion. There are also many programmers these days who were never math or puzzle geeks. These people are not going to do well on surprise coding tasks during a job interview. They just haven't spent time with those things. That doesn't mean that they aren't intelligent or that they are not good with their technology. Judging them on those things is a bit like interviewing someone for a job as an Italian interpretor, talking to them in Italian during the interview about Italian opera and concluding that they would suck as an interpretor because they didn't know much about Italian opera. Coding during interviews is a fact of life. I accept that. I'm open to improving myself at doing random puzzle type of things. That is what brought me here. I may never use these skills at my job, but I don't program in my blue interview suit either. I enjoy putting on that suit once in a while and I think there is some good in doing "code katas" too. Some of the comments in this thread have seemed to be judgmental. I would like to apologize in advance if my comments have seemed like that. If that is the case, it is not about my intent, just my lack of skill in expressing myself. I have no desire to offend anyone. Have a good weekend everyone.

When I interview for a company and they don't make me write some code I become apprehensive as to whether I want to work there. It's a potential danger sign that the place is full of complacent mediocre developers where I will have to pull everyone's weight. Consider that when the company is interviewing you, you are also interviewing them. If the interview is hard, then you know that the minimum standard for your future colleagues is also higher. Do you want to get hired for a new job where the other four guys on the team are duds and you are going to be doing all of their work? Or would you rather be working with people from whom you can learn? I always pick the latter. So please, bring on the coding during interviews.