Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I have seen a lot of comments about good interview questions and puzzles to require potential developers to solve during the interview process.

I have personally had several interviews in which the interviewer has asked me to write some piece of code or solve a problem during the interview, and I have always performed very poorly in these "tests".

The reason is simple, as a developer who spends my days talking to computers, I find I have to prepare myself and "switch gears" to be in "interview mode". I prepare myself to make a good impression.

When I'm programming, I'm very focused and am totally different from when I'm being "interpersonal". I just can't get into "the zone" when I'm also having to be a charming and witty potential employee.

I feel that by asking a developer to prove his skills during an interview, all you're doing is finding out if they can code under pressure, and at the drop of a hat. It has almost no ability to determine how you would perform in a "real life" development situation.

Maybe, if you're looking for someone that can code and chat at the same time, i can see how that would be beneficial. But I think you overlook potential candidates that simply do not perform well in such an artificial environment.

While I appreciate that a potential employer wants to see what I can do, I don't think an interview is the place for such a test. I mean, suppose a job for an over the road trucker required that you drive while being interviewed. How does that really end well?

So I'm curious as to what others think about such situations. Have you failed interviews because you were not in the right frame of mind? Have you failed to make a good interpersonal impression because you were too distracted trying to solve the problem?

If you're a hiring manager, or someone that gives interviews, do you even think about such things? Is it really important that someone perform well in an interview?


To clarify, I'm not against testing applicants. My concern is about testing during an interview.

See also: What are the pros and cons for the employer of code questions during an interview? looking at this from the interviewer's point of view.

share|improve this question

closed as not constructive by gnat, Walter, GlenH7, Robert Harvey, Jesse C. Slicer Nov 29 '12 at 16:33

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

I would expect that an interview for a trucker would require that they prove they can drive. Thus I expect a program to be able to prove that they can code. I would suggest you just learn how to cope. Writing code at an interview is not going away anytime soon. Note: It is not just your coding skill we are testing be asking you to write code (somebody that can only code is not very useful in a team and to write major applications you need a team). –  Loki Astari Apr 2 '11 at 11:05
I think it is a big problem if you are putting on a 'face' for the interview so much that it takes up all your energy. They might hire you based on this 'mask' and you end up not fitting into the team at all. It will suck for YOU and the team. –  c_maker Apr 2 '11 at 12:45
Bad analogy...A trucker merely has to produce his CDL license to prove he can drive... he doesn't have to take the driving test over again. –  red-dirt May 27 '11 at 0:52
I like the distinction between coding -during- the interview vs. coding a "take home" problem. Solving problems at home seems more natural to me, and you can't really fake it when you walk through your solution during the interview... –  Al Biglan May 27 '11 at 4:16
I have interviewed people who said they were a '10' in (insert language here). When I asked them to write 'hello world' in that language, they couldn't do it. (Any of it, not even the first few import/include lines, or a print statement, nothing) –  KevinDTimm May 27 '11 at 9:13

18 Answers 18

"I just can't get into "the zone" when i'm also having to be a charming and witty potential employee."

As Tommy Lee Jones tells Harrison Ford in The Fugitive when Ford proclaims "I'm innocent!": "I don't care!"

The sad truth is that as a hiring manager, my task is not to accurately assess your skills, my task is to hire someone that can do the job, and to avoid hiring people who can't. If I do it right, having candidates write code during the interview helps me avoid the folks who really can't write code. If it incorrectly eliminates some candidates who are good coders but who "can't get into the zone" during an interview, that's too bad for them, but not a problem for me. I've got ten more interviews to do this week. It's a competitive market, and there are plenty of programers who can write decent code even when they're nervous, and "not in the zone". Yes, I may miss a good employee now and then, but I also miss out on a lot of disasters. We can't adjust our product schedules to wait for you to get in the zone.

My apologies if that comes across as unduly harsh. I'm really just trying to convey the fact that the goals of the job applicant and of the hiring manager often differ. You can rail against how unfair it is, but you are better off just practicing interviews so they don't put you off your stride so much.

share|improve this answer
So what you're saying then, is that you would rather hire a mediocre developer that can jump through your artificial and arbitrary hoops, rather than a highly skilled developer who would actually help your company to be profitable. That sounds like you're more concerned about how much effort you have to expend to do your job, than how well you do your job. As a hiring manager, you should be concerned about hiring the best candidate, not merely the one that makes your job easier. I know, i know.. reality is harsh. –  Erik Funkenbusch Apr 2 '11 at 9:27
You are setting up a false choice. I really don't have to choose between a mediocre developer who can code during the interview, and a highly skilled developer who can't. I can assure you that there are plenty of highly skilled developers who are also whizzes at coding during interviews, and some are even charming to boot! Some people have to work harder than others to pick it up, but I assure you, interviewing is an acquired skill. –  Charles E. Grant Apr 2 '11 at 9:34
@Mystere: no, he he will choose from those other ten highly skilled develoers who compete with you and don't need to get into any obscure "zone" to get their job done. –  thorsten müller Apr 2 '11 at 9:40
@Mystere, you will never know when or if you've hired the best candidate. I'm not even convinced a "best" candidate necessarily exists. People aren't whole numbers that you can assign a strict ordering to. Every interview technique you can imagine will have false positives and false negatives. The people trying to get hired will worry about the false negatives, and the people doing the hiring will worry about the false positives. In my experience, being able to write code during an interview is positively correlated with folks who have ended up doing a good job. –  Charles E. Grant Apr 2 '11 at 10:06
@Mystere man, how can you be the best candidate if others can do the interview better than you? –  user1249 May 27 '11 at 14:28

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.

share|improve this answer
I disagree on several details. First, you don't know how I think, and I don't know how you think. Second, most of the examples of "tests" i've seen involve being VERY creative at the drop of a hat. Third, there is a difference between programming with your peers, and programming while trying to impress a future employer. Your peers aren't evaluating your performance and making a decision about whether you will be hired or not. These are fundamentally different environments. There is a difference between "communicating" and "interviewing". –  Erik Funkenbusch Apr 2 '11 at 8:44
Your question title explicitly said "programming", not "tests". Can you respond to "write a program on the white-board for me that calculates the ten first primes" in an interview setting? –  user1249 Apr 2 '11 at 8:51
I agree that programming is hard, and require mental effort. But do you consider ANY programming problem so hard that you cannot even attempt it in an interview session? –  user1249 Apr 2 '11 at 9:12
This entire discussion has been one side telling the other "you can improve some of your skills to perform better in such interviews" and the other saying "no, I can't". If you can't, that's a bigger problem than not being able to code during interviews. –  Rein Henrichs May 26 '11 at 21:41
@Mystere man, reread your answer. Do you sincerely mean that your answer to "Can you respond to "write a program on the white-board for me that calculates the ten first primes" in an interview setting?" is no? –  user1249 May 27 '11 at 14:29

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.

share|improve this answer

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.


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.

share|improve this answer
Never offer the efficient version first. Brute force first time. That gives the interviewer the opportunity to ask "can you improve that" (after they have asked you the big O complexity). Then you can go "Why yes I can". –  Loki Astari Apr 2 '11 at 11:37
@Martin: also if you do the best version first the interviewer will be like "Hm...he answered fast but probably he just memorized the solution from some book." –  Kevin May 26 '11 at 21:37

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.

share|improve this answer

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.

share|improve this answer
Providing samples is not necessarily good either, as you could be providing samples of someone elses code. And most code people write belongs to former employers, so providing code would be illegal. I'm not against testing an applicant, just doing so during the interview. –  Erik Funkenbusch Apr 2 '11 at 8:49
But suppose you're working on some problem and you discover you need, for instance, to write some 15-line algorithmic function. Do you have to stop and prepare and write it tomorrow? Or do you just write it? I think better programmers will normally do the latter - though, obviously they may choose to make tea or take a break first. –  poolie Sep 9 '11 at 8:34

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.

share|improve this answer

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.

share|improve this answer
A good whiteboard coding exercise should be able to answer several of the points on your list. Pretend you don't understand part of their code and ask them for clarification. Think up bigger examples and ask how they would organise it (clean code). Use an exercise where there's potentially varying performance characteristics - then ask them about the performance of their chosen solution and explore how to change it to improve performance. For the rest of your points - for example, testing, just ask them! The point is a coding exercise is not the ONLY part of the interview. –  Richard Downer Apr 3 '11 at 8:19
A code question isn't meant to be the only question you ask. Ask them separate questions about how they'd test something, how they'd solve a performance problem, how they indent their code (sheesh, the correct answer is "the same as the rest of the team"), how they solved an interesting problem with someone else. Passion you can judge from whether they actually get interested in these questions. –  poolie Sep 9 '11 at 8:07

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.

share|improve this answer

On the hiring side of things, I completely agree with Charles E. Grant. If you can't do it, somebody else just as good can.

On the interviewee side, I'm not sure I'd take a job if they didn't have me code during the interview. It's the quickest and easiest method I've seen to judge a person's coding ability, and if they don't do it, I'm skeptical about the whole thing. It's like, "How competent can these people be if they're hiring me for a job, and they didn't even check how well I can do it?"

And, while there's certainly a mindset and focus required to sit down and churn out code for a few hours straight, that's not what's being asked for during an interview. Any competent programmer should be able to write some code snippets without "getting in the zone."

I'm even half tempted to say that most places have so many interruptions and distractions, filtering out people who need to "zone out" to get anything done might be a benefit. "Oops, got an email, there goes my productivity for the next hour."

And FWIW, I'm pretty sure truck drivers ARE required to drive during their interviews. At the very least they need a driver's license, and they definitely have to take a driving test to get that.

share|improve this answer

It depends on the circumstances. I don't mind walking through some code (on a whiteboard, for instance) with the interviewer so I can see their thought process (and they can see mine). However, I dislike "puzzle" or "math problem" types of questions that just show either obscure knowledge, or are something simple that anyone can Google or has a built-in implementation (e.g. "How would you sort x" the answer is I would use my programming language's Sort feature)

share|improve this answer

I do screening and interviewing for my 20 person software company. I want to see candidates write code. Lately I've invited candidates to bring in a laptop with a programming environment if they have one, otherwise we just use the whiteboard.

We are look for good C++ programers, they are few and far between. IMHO the good ones can code on a whiteboard. All the good ones.

I'll cut an entry level candidate some slack, but a candidate who claims years of C++ experience ought to be able to code in an interview.

share|improve this answer

A lot of this depends on the skill of the interviewer.

I've gone on interviews where the environment was very much hostile, and their purpose was to flesh out your limits and see where your breaking point was. Solve the 8 queens problem in your language of choice... Given an array of numbers, write a time efficient algorithm to find the longest increasing subsequence... Write an algorithm to determine if a given graph is acyclic. All while being challenged on your thought process and code.

Very much a pressure-cooker situation.

On the other hand, I've gone on interviews with very skilled interviewers where at the end of an hour I've felt like I've just finished talking about my career/projects in-depth with a CompSci buddy I haven't seen since college. Then proceed to the whiteboard and it's very care-free and relaxed, no pressure.

A couple of hours go by and I feel like I've been tricked into an interview! (I see what you did there).

Unfortunately the guys that actually study and perfect the art of interviewing are exceedingly rare, and most tech interviews end up being self-indulgent ego-stroking for the hiring manager.

share|improve this answer
The problem with these questions is that they're not testing your intelligence, just your knowledge. Yes I've once had to solve the 8 queen problem and I remember that you can solve it with backtracking a tree. That does not prove I can think, just that I can remember well. –  Carra May 27 '11 at 13:53

Writing code during the interviews is fine, but there should be a limit on cyclomatic complexity of the functions the interviewee is expected to produce on paper. Furthermore, I don't know about you, but I don't write non-trivial code linearly, I need to change something here and there, sometimes rewrite some portions of the code, insert something before existing code, rewrite/simplify conditions and all this is only feasible if you are using an editor. This is further compounded by the fact that I only write when filling out some forms or signing papers. That's about 2-3k characters a year. I type more dally on the average.

Now, regarding the problems we are asked to solve during the interviews. Basic linked list operations (insert/delete/find/reverse) are fine, so are tree traversals and related stuff. Primes are ok too, maybe the Fibonacci sequence too, if you remind the interviewee the formula.

However finding a loop in a linked list? in linear time and constant memory usage??? There are few named algorithms dealing with this problem, the most popular being the "Floyd's cycle-finding algorithm" and I seriously doubt Robert W. Floyd came up with that solution during an interview or in a similar setting. So these questions with well known solutions don't really test anything. They only prove a candidate prepared well for a typical CS BS interview and nothing more.

A similar question would be: find the largest sum of contiguous integers in the array

share|improve this answer

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.

share|improve this answer

I don't like doing coding on job interviews either. That point is moot, as Charles E Grant wrote in this thread it is going to happen and you have to adapt.

I think a point some of the people in this thread are overlooking is that is that someone can be a good programmer, but have no experience with the type of problem being solved. I think this quote from an earlier post illustrates this very well:

Can you respond to "write a program on the white-board for me that calculates the ten first primes" in an interview setting?

The last time I had to think about prime numbers was in junior high school. I had to look up what a prime number was on wikipedia. I have never had to calculate a prime number. I don't know how.

Those kind of "puzzle things" are just not the kind of problems I am regularly exposed to, so on a job interview those things would catch me cold, even though I have done good work as a programmer.

Like I wrote, I'm not complaining. Coding on interviews if a fact of life. Period.

I'm just explaining why I don't like it and why I don't think it is always a good test of someone's ability to program.

share|improve this answer
I am surprised that a "programmer" does not know what a prime number is. I am surprised and appalled that after looking it up you could not figure out how to create at least a brute force algorithm to solve the problem. –  AttackingHobo May 26 '11 at 23:02
I simply haven't been called upon to figure how to calculate prime numbers or do things like hex arithmetic to solve the programming problems ( even large and complex ones ) I have had. I think that is true of the daily lives of many programmers for a number of years. What you are not exposed to atrophies. I feel like you negatively judging me, but I don't feel negatively towards you. Peace. –  user26340 May 27 '11 at 0:26

If you are interviewing for a website company, you are gonna have downtime "situations". In these cases, the pressure is not only from your immediate manager, it will be the whole stack of people right from your VP/CEO watching over you. Same in the case of offline development companies which are faced with an issue like SQL Injection worms and have to release a patch.

So working under scrutiny and coping with pressure comes with the job, I suggest you work on it.

share|improve this answer

It's a reasonable request but becomes unreasonable when it becomes clear the guy making the request could never handle the problem himself in the 2 minutes he's asking you to sort through it if he hadn't looked up his interview questions on Google. Keep 'em brief.

And look, I'll write some code, but FFS knock it off with damned whiteboards already. I've been typing since I was 12. Asking me to put my chicken scratch on display is like asking me write code while juggling hyaenas. Hand me a laptop already..

Ultimately interview processes are a two way street. People who think strong devs are easy to find are coming from a place of mediocrity or arrogance, IMO.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.