Should "inability to code under pressure" be a valid excuse when writing code in an interview?

Question

I've come up with what I believe are realistic problems to work on during an interview. Frequently I have candidates respond that they cannot code under the pressure of me watching them code (via Live Meeting or Locally). Is this a valid excuse for inability to complete the task (or taking too long) during the interview? If so, what can I do to decrease the pressure during the interview process?

It would seem that being unable to program under this kind of pressure could be problematic in typical employment because there are times when we as developers are fixing code when our manager is standing beside us, or during internal demos with product management. Additionally there is also the pressure that is typical with programming jobs that comes with deadlines (yes, we all hate them) and bug fixes.

Edit: I do my best to not "breathe down their necks" but I don't exactly abandon them during the process. Maybe I will take the "get the hell out of there" approach.

Answer 1

Are you literally over their shoulder as they code? That's a little off-putting imo. It's one thing to give someone an hour and a task and then review the code afterward. Quite another to hover over them while they declare each variable.

If you're talking about just whiteboarding an algorithm with pseudocode, that's a perfectly reasonable interview expectation.

Answer 2

Absolutely not. You want to see what a potential candidate can come up with without the aid/crutch of Google in front of them while coding. It seems like you've found a pretty good filtering mechanism as a matter of fact--assuming your coding problem isn't too off the wall, the fact that a candidate refuses to/can't perform under these conditions is a definite "NO HIRE" red flag.

To lower the pressure, perhaps just put them in a conference room with a laptop and an internet connection (if access to the net won't spoil the problem) and tell them to work out the problem as best they can in a set amount of time. This avoids the whole "over the shoulder" pressure some people may feel.

Answer 3

If a job were a completely stress-free or pressure free environment, then I'd say it would be a good excuse.

However, that isn't the case. Good programmers can program under pressure.

Answer 4

I would say that it depends really. How long are these interviews? How complicated are the problems? How realistic is it that you would expect the programmer to be able to come up with a solution in 30 minutes or less without having any idea what might be asked of them.

Sure in my current application I can have answers about what is going on (if not actual fixes) in less than an hour, sometimes 30 minutes. I am familiar with the code and it's behavior for the most part. I have been working with it for over a year now but 85% of the code was not written by me.

I think it might be unrealistic depending on the question asked, not in all cases, but at least for some.

How many "green" programmers are put in situations where they are likely to have to answer directly to "the boss"? I have always seen them paired with a more experienced programmer for a period to kind of help them and guide them.

Answer 5

I personally think that it should be (though my definition of pressure is that there is somebody watching), though I'm biased - I have the same problem.

I am an experienced programmer, and I have also done my share of programming under pressure (e.g., in academic environments such as solving a final exam as an undergrad or teaching as a grad) and believe I did it fairly well. However, I find that when I am writing code while somebody is watching my every tiny move, it is extremely distracting and I fail even the trivial stuff.

In my case, I try to figure out what the interviewer is thinking, and I keep looking for little tells. This is fine for Hold'em, where you have two cards to look at, but not so fine for programming.

Also, I personally tend to initially write with crappy syntax (on a whiteboard) and then fix little things, rather than do a clear line-by-line. Again, in an interview, that's a problem because I am worried that as soon as I don't close that brace or add the semicolon, I will look bad.

In addition, I often find "think aloud" to be distracting. This is acceptable in pair programming, but not in individual programming.

Furthermore, I have been in interviews where while I am writing, the two interviewers keep chatting between them on how they solve the same problem. Imagine that you are trying to code while two other people are reading each other's code aloud to the same problem. This is among the "scare the interviewee techniques".

Finally, some people don't do well with paper or with whiteboard. I am one of them. I like knowing that I can insert lines easily and type at the speed that I think. When I am confronted by a whiteboard or paper, it takes me ages to handwrite, and in my case I also can't really read my handwriting so everything is trickier. Give me a computer and I'll do fine.

So in a nutshell, my view is this: Wanting to make sure your interviewee perform under pressure is a very good idea. Time limits are also a very good idea. However, your prospective hire will never have to code with someone looking over his shoulder like that.

Therefore, give him the task, tell him you'll be back in 20 minutes, and then get the hell out of there!!!. Leave them alone. Give them a phone number for questions or for letting you know when they're done.

Note that I do agree with Drew that it's important to isolate the person from the aid of Google and code samples. I don't consider that pressure, though.

Answer 6

Yes, coding under pressure shouldn't be a problem, but interview pressure is a very different animal to deadline pressure. So I wouldn't be too quick to put them both together...

Answer 7

A deadline is one thing. Having someone breathing down your neck is another.

• Deadlines are useful in the sense that they set a goal for completion.

• Breathing down someone's neck is only useful if you want to irritate them and make them panic.

I would make sure they know the basic syntax of the language using some trivial problem. Then I would give them a significantly more complex problem and tell them to whiteboard a solution, without writing any code.

If they come up with a good solution on the whiteboard, tell them to take a laptop, go to a quiet empty office, implement the solution, and show it off in one hour. That is one way of giving some a deadline, without breathing down their neck.

If your company pays coders to design application while jumping out of airplanes, breath down their neck. I would not want to work for a company like that though.

Answer 8

I like the "leave him and come back later approach", but I also think you'll be missing much this way. I've been through some interviews like that, and they also gave me time to review my code, and point out what I think was wrong.

I think it all depends on what you want to see. If you want just to know how good the "end code" of a interviewee looks like, than the "leave him and come back" should be good enough. If the way he approaches the problem is also a big issue, then you should stay watching, or maybe use a screen recording approach (less pressure this way).

Another suggestion, is starting with some really easy problems, that should be solved in 5 min or less, and help him get more comfortable with this idea. Then you start adding some (but not much complexity)

Answer 9

If they're going to be in an environment dominated by pair programming, they better be able to code with someone watching over their shoulder. Even if not, if I had two equally qualified candidates, I'd rather have the one that can code under pressure.

Answer 10

Much depends on what the candidate will be expected to do if they're hired.

If they're going to be pair programming, or working in an environment where colleagues frequently peer review by working together, then this kind of pressure is perfectly justified and (as others have said) this is a good indicator of whether they should be a "no hire".

If they're going to sit in a room all day and program by themselves, then this isn't really a fair judge of what they shall do.

Answer 11

It's really the unforturnate reality of interviewing - not all good people can do well in an interview. I do think that great people will be so good at coding that they will be able to write some code even if they got two minutes of sleep the night before though.

That's just an interview... it's not a great way to decide on people, but if you don't have working experience with people, it's the only way you can do it.

Answer 12

I think being able to handle pressure is important, things go wrong in production systems and programmers sometimes need to think fast and clearly to solve or at least contain a problem.

However, I think the pressure of being in an interview is artificial and I would not rule someone out because they could not code a solution with me sitting across from them. If they can do it then great, if not I would look for some sort of compensation control such as walkthrough some of your code and having them explain how it might be refactored or whatever just to confirm they are literate in the language / frameworks you need.

Answer 13

In this case, I try and put them at ease, tell them they have as much time as they need, take deep breath and go forward. The reason I don't leave the room is that I want to see more than the end result. For example, if I leave the room, they could go on to SO, copy a Jon Skeet answer change some variables and present it as their own. Also, I am trying to evaluate what the skills of the person are. So, I want to see what they get stuck on, how they resolve the issues they come upon as well as how they interact with the IDE.

Answer 14

So I think the problem is that you can't exp-doo-do-do-do-do-do-do-dah
doo-do-do-do-do-do-do-dah
unda pressah!

...

Crap where was I?

Answer 15

Remember, when you're talking to a candidate it's a mutual interview, you talk to your candidates and they talk to you. You can quiz them but if you like but don't ask them to work for you. I don't believe it's the place for such things.

If you want them to code, use the probation period, give them a simple task and see how they perform.

We had some success just handing out some code to look at (real simple stuff) where we discussed pros/cons and what was going on in the code. You quickly realize which candidate you want to give a probation period.

Answer 16

I don't think there is a golden way. If you really have the feeling the person is acting, show him the door. If (s)he really is nervous, just take your time, and see if (s)he improves if the immediate pressure is away.

At one point you have to ask yourself what you want. Quality employees, or quick interviews.

Answer 17

You want a developer who can code under the pressure of x, where x can be any one of: tight deadlines, ever-fluctuating / fuzzy requirements, angry customers, broken code, insert the headache-of-the-week-here. But rarely is x = being observed.

Furthermore, think Heisenberg: you're going to change the outcome simply by observing.

You can have a developer who's fantastic working with ever-changing requirements, working with angry customers, working with extremely tight deadlines, and you want a person like this. But that developer might also have performance anxiety.

If performance anxiety is a dealbreaker for you, then you should watch your interviewees code. Otherwise, you should find ways to simulate the pressures you do care about, and let them solve your problems unobserved.

Answer 18

As a candidate, I prefer the whiteboard approach, where the interviewer allows me five or ten minutes to get started, then begins to ask what is my approach to the problem, why I used certain classes, asks if I overlooked a certain part of the problem statement, etc. and prods me in the right direction. This is a good test of:

1. Problem solving & analytic ability
2. Language syntax & memory
3. Software design (& trade-offs)
4. Handling criticism
5. Work under Pressure

The interviewer often changes the problem in mid course and asks how the candidate how they would adapt their program to handle the new requirements, what kinds of cases the algorithm would perform poorly on, etc.

But on the flip side, if you are looking for an integration coder, ability to find other people's solutions, internet examples, etc. in a hurry and work that into the project is important. The whiteboard approach is good at testing algorithmic ability, but not research acumen. Perhaps a different kind of interview task (like offering a laptop with a wireless connection) would be better to test that kind of ability.

Answer 19

Early in our interview process, we give the candidates an abstracted real problem from our application & give them a couple (two, maybe three) days to return it. We do want to see what they can do but have found that the during-the-interview situation it unrealistic. They have to return that & have it evaluated before we proceed.

If I'm on the interview team, they'll have to whiteboard a solution to a different problem, but no code. This is to evaluate their thinking, not their ability to output compilable code under pressure.

And besides, they're going to be able to look things up if they come work for us anyway...

Answer 20

I'm personally of the opinion that pop quizzes and programming questions have no place in the interview process. The interview is the chance we have for seeing an individual eye-to-eye and figuring out if they fit into the group or the company culture. It's a waste of time giving them kiddie quizzes under artificial circumstances. I like to find out more about the person, what makes them tick, what they like to work on, what was the most creative way they solved a problem, how interested they are in learning new stuff, how they communicate, stuff like that.

And if a manager hovers behind a programmer's seat while they're trying to think, that manager deserves a swift kick in the ass. Last thing you want is a programmer making an error because you're hovering back there making them nervous.

If you really want to find out how they code, have them print out a few pages of code they're most proud of. Or hire them under a no-fault 3 month probation. If by the end of that time it's proven that they can't produce code get rid of them.

But fer crying out loud, don't waste time with stupid dog tricks.

My $0.02 (and I speak from experience on both sides of that fence).

Answer 21

I have had a lot of experience giving interviews and creating coding tests for interviewees. A lot depends on how you stage the test. If you slam them with a hard question right off the bat, even smart and experienced people will have a brain fart and do badly. You don't want geniuses smacking their heads when they leave the building saying "oh yeah, duh! dumb mistake" and then going on to work somewhere else. Give them a super-simple, easy question first to let them warm up to the situation and get used to the fact that you're breathing down their neck while they code. I mean REALLY easy, like from an "intro to programming" course. Once they get some confidence answering an easy question, give them a harder one -- keep upping the ante until they crack. And of course, if they can't answer even the easy question, that tells you something about them as well (that they lied on their resume, for example...).

Other tips:

• don't distract them too much while they are coding, but make a joke once in a while to make them feel more comfortable.
• don't fuss about little syntax problems. Even good coders miss stuff that the compiler would catch.
• don't require them to know the names of API functions or other crap they can always look up if they want (e.g. what are the arguments and types of the fooBar function?). IMO this is a particularly silly thing to ask because it tells you nothing about the candidate except maybe what their job performance would be if the internet went down and all API references, help files, were to simultaneously be deleted from their machine. If I'm interviewing somewhere and someone asks me this it would just make me want to work somewhere else.
• (instead) give them problems that give you insight into their problem solving skills and knowledge of basic algorithms and concepts. You know, computer science stuff. You don't want code monkeys, you want engineers.
• give them fun problems too, because when you have a good candidate, the interview is also an enticement to come work there (in case they have other offers)

p.s. I forgot the most important thing. For crying out loud, take the time to give them a computer and notepad++ or the equivalent. Don't make them write it out with a pen, that's just cruel.

Answer 22

Inability to work under pressure doesn't make a person a bad programmer. But an excellent programmer who doesn't know Java is an inappropriate hire for a Java job. Likewise, an excellent programmer who can't work under pressure is an inappropriate hire for a job where the programmer needs to work under pressure. Given the description of the job, I think that the ability to work under pressure is necessary.

Answer 23

I haven't really done code writing in interviews, but many other funny things. And I can tell you this: it's not the pressure of being watched or getting the job, it is the perception of an ingenuine environment or in other words a play-situation. It is especially bad if you have psychos (ops, I meant psychologists) sitting there. I personally was never able to behave naturally knowing it was just a play.

The candidate's declared inability to write code under observation can be due to the critics he'is be getting from you on the very first line of code. If you are not criticizing but helping to create a friendly relaxed environment and it still does not work, then it might be a bad sign.

Anyway, only a test period will tell you whether a candidate has the qualities you are looking for.

---

There is one more thing to it. Work under pressure vs. work in loud environment. I am personally able to speed up my activities when there is little time or something has to be done urgently, but I am incapable of concentrating in a loud environment with talks, calls etc. I suppose these are two different qualities and you should consider them separately.

Answer 24

You could also quite possibly scare off a good developer. "Is everything I do going to be this scrutinized? Will I need a hall pass for the bathroom? What happens when my kids are sick and I need to work from home?" At that point its not about pressure but the idea of "Big Brother" always being there.

Answer 25

The mindset that allows us to produce excellent code is very different from the mindset of of an interviewee.

We can all kick ass when we're in "The Zone", but the mental concentration and focus required to get there won't be found during a nervous interview.

Answer 26

By this test I'd ask, are you penalizing a programmer because they want to eliminate distractions?

Personally, I think that coding is actually more art than science (at least it is to me), and problem solving skills are not the same as engineering talent.

Evaluating a coder for whether they can solve a problem quickly doesn't necessarily mean that they've been able to think things through well enough to solve it properly, or with an eye towards future problems, or even elegantly.

The crutch of Google and maybe stackoverflow ;) might be fair to eliminate, but I agree with an earlier answer that the best thing to do is leave them alone. I know I personally am most productive when I can focus on the problem, the solution and the technique without much distraction.

That doesn't always/ever happen naturally, but if you're trying to test a programmer in an ideal condition so you can evaluate their skill level, I'd say that leaving them alone is better. Ive yet to work in a team, where despite the pressures of management, the engineering team wasn't still able to put on headphones and tune out the world once they started writing code. In some cases, they wouldn't respond to IRC or IMs either until they solved their problem.

Answer 27

I have a problem with interviewing techniques like this.

• I think an important skill in programming is how not to be hasty, but to think clearly, consider alternatives, and not engage in guesswork.

• Another problem is that often people are asked about arcane language-specific "hoohaw", like when to make a "friend" class or the the working of virtual constructors, rather than how to analyze a problem.

Fortunately, for all the jobs I've had, my reputation was good enough - I haven't had to go through HR.

Answer 28

I think it's entirely reasonable to ask a candidate to demonstrate their jobs skills. The one thing I would be wary of, is make sure that you are actually testing their job skills and not just being a pain, or adding unnecessary pressure.

Answer 29

I perform technical interviews on a regular basis and have some coding samples prepared ahead of time. Honestly it's a mixed bag of responses. Some people plow through them in a minute and others freeze up under pressure.

Interviewing for a job is stressful. Some people can handle it and others cannot. Depending on the position I'd factor this in, but usually for a straight coding situation if they freeze up under pressure I'll just ask some additional code-specific questions to ensure they have the fundamentals necessary for the job.

Answer 30

I have done some of my best coding under pressure. So yes, sit accross the table and glare at them and see what happens. Of course I am also the world's worst debugger under pressure. I have solved so many bugs driving away from a job I wonder if I should bill for the time.

Eric Lippert had a blog about his interview style where he presents a problem (with many different ways to solve) and see's how the person goes about solving it. This would give a you a good idea of what they know, how they would tackle a problem, and cut through any manure someone attempts to serve

Answer 31

It's a lame excuse.

Imagine you're hiring a musician for an orchestra. Would you not ask them to play something? How about an excuse like "it's too much pressure playing alone, and when you're watching me so closely", "I need to sit in an orchestra pit, not here in a plain conference room", "How am I supposed to play properly without a tuxedo?"

A good musician will play any tune well, anywhere, anytime. A bad one will come with excuses.

Answer 32

So much is context dependent. For the exact reasons you discuss, I tend to focus in this priority order during interviews:
1) Have them speak their thought process out-loud as much as possible and evaluate their problem-solving approaches in general--right, wrong or otherwise.

2) As they go through their solution and thought process, how do they interact with me--ESPECIALLY WHEN THEY GET STUCK!

3) The merits of their particular solution, if they reach one.

I make the solutions VERY acheivable, but when people get stuck, I'm more concerned about their ability to try repeatedly try new approaches and then to work WITH ME as I prod them forward and ask them questions and throw out ideas.

We all get flustered sometimes and don't show our best abilities EVERY interview, so it there is a small amount of validity to it. However, some questions are very basic syntax/framework/OOAD type questions that they should just nail. In the other "interesting" questions, I evaluate primarily the interactions during the problem-solving process and the solutions a close second. This, to me, is a better gauge of my ability to work with them in the longer term, especially in crunch-time pressure situations in the "real world."

Answer 33

There are times when you need to know if a candidate actually has basic coding skills. How are you going to find out?

There are always going to be times when the interview is the only opportunity to figure out if the candidate can actually write code. I wouldn't consider "inability to code at an interview" a valid excuse for a candidate to avoid this. I'm not going to play ogre, and deliberately try to make things hard for them. I'll encourage them and tell them that I'm not going to fuss about syntactic details. I'll talk them through it, or leave the room, if I think it will help them. But at the end of the day, we need to hire people who can get the job done. If a candidate can't show us that they can do the job, we're not going to hire them.

Having said that, I'm certainly interested in other ways to get at this information. Sometimes there are obvious ways to learn more about a candidate, such as references. But that only works if the reference is somebody you know and trust.

I don't like having them bring sample code, since that's a problem for folks whose current (or former) employers own the code. And the fact that they have code doesn't tell you anything about how it was written. How long did it take to write? to debug? What kind of review and input did they get from others?

I like the idea of hiring somebody for a "no fault" probationary period. I'd be curious to know how this has worked for folks in practice. I can't imagine the typical HR department signing off on it. Also you have to be sure that you and your team will be ruthless enough to let them go if things don't work out. It's easy to say that, "We'll get rid of them if they turn out to be a bozo." But in my experience, the real problems aren't the bozos, but rather the second-tier programmers. The nice but mediocre programmer probably won't raise any red flags during their probationary period, but then spend the next few years delivering late, producing more than their share of bugs, and generally getting in the way.

Another technique is to ask the candidate to do some coding as part of the phone screen. This is where you really want to weed out the folks who can't code, so you don't waste lots of time interviewing them. I haven't tried this, but it would be nice to ask somebody for a 2 hour phone screen. Talk to them for an hour, then give them a simple coding problem and ask them to e-mail you their code in an hour. Obviously you'd want to pick something a bit off the beaten track, so they can't just google a solution.

Answer 34

I'm a not a big fan of writing code during an interview (or performing other tricks to ensure a proper reward of my resume's legitimacy); for many reasons that Uri already mentioned. Although I understand the purpose of this type of interview, I honestly wouldn't blame the candidate at all for failing over something that's already stressful to begin with.

Many "larger-software" recruiters I've talk to (still an undergrad here) volley on this fence. So, to really answer your question as one who might be taking this interview... make it light & enjoyable. There ARE better ways to distinguish a candidate then making him solve a puzzle for half an hour.

IMHO.

Answer 35

I have given over 100 interviews. Some have gone well, some not-so-well, and of the failed interviews, a few have gone poorly for reasons that have nothing to do with the candidate's ability to do the job. If I detect such a problem, I put in my writeup that I do not have confidence in the screen, and my score is discounted. If I do not detect it, but the committee sees that I reported a completely different experience than the other people who screened, then they dig deeper, often choosing to discount a score completely out of left field.

Part of my job as an interviewer is to correct for the whiteboard effect. Almost nobody codes well on one, but we have a very good baseline about the kinds of mistakes a whiteboard causes. Those that impact the job are important, but those resulting from someone not being able to hit control-space should just be ignored. After a while, every interviewer I know gets a feel for which mistakes matter.

You will find the odd interviewer that cares about syntax over substance, but again, the committees have read a great many summaries, and they know each interviewer's foibles. They comment back to us on interviewer failures. Among other things, I have had hiring committees tell me that they found a question not sufficiently useful as asked and answered, or that a question is now on major interview question web sites. In addition, we read each other's questions, and how they scored the result, and we do talk.

It is true that the one hour job interview does not match the experience of working for us. I do not think I have had to actually code a sorting algorithm in the last five years, but I have had to make judgements about a library's quality, and one way that I do that is to look at the sorting algorithms they chose, along with a host of other indicators of how much the implementors care, and how well they implemented. How a candidate approaches a problem tells me a great deal about whether they could make those judgements. How they implement that solution tells me even more.

Hint: the best answer, if given what is essentially a sorting question, is "I use the library implementation. In Java, the standard Collections.sort impl uses the (whatever) method for ordering to implement a (whatever) sort that behaves this way for fully sorted data, thusly for mostly-sorted data, and such-and-so for unsorted data." Then be ready to implement something. This gives me maximal data to make my call.

To be honest, the whiteboard also forces candidates to focus. The times we have let people bring in their laptop and favorite IDE, it has actually not gone that well. They tended to get lost in the details, and to not find a 'good enough' solution in the time they have.

Scott

Answer 36

The important thing when watching someone code is not to get wrapped up in small things. It's easy to feel a ton of pressure coding while someone watches. Don't be concerned if they can't remember how to do something very basic.

What you're looking for is the thought process. If they describe what they're trying to do and you can tell that their thought process is leading them the in the right direction, chances are good they wouldn't be making the same small mistakes when you're not watching.

For example, if someone can't remember how to setup junit for a test case, I'm not hugely concerned if they can tell me what a test case does and describe the correct strategy for testing the code in question.