Interviewing for the anxious programmer

Thanks a lot for writing this.

I don't get full blown panic attacks, but I get extremely stressed out as well during tech interviews. I think I'm a pretty good coder/computer scientist - I've released tons of open source stuff, spoken at conferences, solved many Project Euler challenges, published papers, taught people how to code, etc - but my success rate is still abysmally slow in interviews because of that.

For me, it's a mix of the stress of feeling judged, having to "impress" someone in a very short timeframe solving a problem they know perfectly and that I have never seen before, the fact that I am naturally introverted and shy, etc.

A friend of mine who works at a large tech company in Seattle told me he took Xanax before his interviews. Another friend working for a big tech company in the valley told me he'd chug a couple beers before his. Yet another friend working for a fairly large "startup" in SF recommended that I smoke a joint before my interviews.

Our industry is weird.

Thank you for sharing. I usually sit on the other side of the table -- interviewing. And I also know how it feels. I have gotten a mild panic and completely blank mind during tests before. Something as simple arithmetic and my brain just spins in a tight loop "Hmm 45+13=... 45+13=..." stuff like that.

So things I do to help out with that. I try not to give quick or trickly puzzles as questions. I try not to make it adversarial (like "I am testing you") I try to make it collaborative "let's solve this problem". Often that is an actual problem being solved or solved in the past. No digging holes with 5 worker vs 4 workers (we are not a utilities company) or, no geometry of manhole covers (we don't maintain our own sewer system here, someone else does). I try to give hints or switch topics and talk about something else, not everyone is knowledgeable in all areas.

Not sure of those above would be helpful but would you or anyone else here want to advise an interviewer as to what would help? How would you interview yourself or what would you do to make it easier and less painful?

One of the issues I have is with this style of interviewing, period. This has no relation to the way I actually work. I don't write production-quality enterprise application software at a whiteboard in front of a group of judges. I don't hear the problem and immediately start writing code. Instead, I think the problem over, perhaps google around about it, perhaps discuss it with my colleagues. I spend more of my time as a developer planning, prototyping and designing solutions than writing code. If you think it through carefully first, you can write the code quickly in the end. Just not on a whiteboard in front of a group of critical judges.

I'm pretty terrible at interviews and probably bombed more than my fair share. It's frustrating but I forget sometimes that the person on the other side knows next to nothing about me, and all they'll learn is what I show them. Being the type to undersell and over-deliver it really ends up biting me in the end.

Those personality traits can't really be unlearned, but I think it helps if you go in with a nothing-to-lose attitude and explain as much as you can - maybe something you say will connect with the interviewer.

I think the other problem here is something I blogged about before: programming is (for me) a tacit skill (http://doxsey.net/blog/tacit-knowledge). I have no idea how I do it and I can't really explain it in the abstract. It'll look real rough in the start (like I have no idea what I'm doing), but 3 days later I'll probably have a solution.

In other words, I can probably do the job, but I can't really prove it in the interview.

I find it curious how people who are as smart and technical as programmers are, can come up with testing/interview methodologies that so clearly deviate from the actual day to day activities of what that position will probably require.

There's definitely value in asking a candidate questions face to face as there are times when problems need to be discussed, but clearly there's a non-trivial segment of the programmer population that has trouble performing under this type of atypical situation.

Why not also have a sort of "written test" portion of an interview where the candidate doesn't have to stress out about performing in front of people they don't know? It would certainly help reduce the flagging of false negatives.

EDIT: by "written test" I mean something like a test where the questions are on a piece of paper or text file, and the interviewee just answers it on there, without another human sitting there and staring at them. The interviewee can always be asked to explain his/her answers afterwards.

> By then I realized that these episodes were panic attacks. I read up on the topic and basically went through a lot of cognitive self-therapy and after a year or so I was able to drive without issues and life was good again.

My advice (not that you asked for it, but I feel strongly that you should consider it): seek help from a qualified professional, like a psychologist. You don't deserve to suffer like this and it is not something that you should be trying to solve on your own. You may not believe that someone like this could help you, but consider how much better you would feel if they did.

I've spent time on both sides of the interviewing table and I think there are some misconceptions in this thread. Generally an on site interview is the last in a series of steps for the candidate. They've already passed the early screening process and the company is investing serious resources in the recruiting process at this stage. Almost everything in an on site interview comes down to fit.

The point of whiteboard exercises isn't to see how pretty your writing is or to make you stumble on brainteasers. It's to see how you think. The real key is to think out loud as you go through the problem. How are you approaching it? Have you seen a similar problem before? Can you find an easier version of the problem and try to get some intuition (ex 2d vs 3d)? What do you do when you get stuck? Asking questions to clarify things is usually encouraged. If you're nervous I'd recommend practice with thinking out loud while you solve problems. There are plenty of books full of interview level problems. Grab one and work through them while saying everything you think. Once you're used to that do more with a friend pretending to be an interviewer. If you find yourself getting stuck a lot I'd recommend reading How to Solve It by Polya.

Sometimes you'll be asked to write code on a whiteboard. This is really unnatural. The interviewers also know that it's really unnatural. Unlike gcc whiteboard compiler is very forgiving. Usually people are looking for a couple of key things. Have you handled all of the corner cases? What about invalid inputs? Do you use reasonable variable names? Is your algorithm horribly inefficient?

There probably are companies that give brainteasers type questions too much weight. They heard places like Google and Facebook use them so they will too. I'd treat this as a red flag and not want to work there.

Unfortunately, there aren't a lot of better options for interviewing. Any problems given have to be relatively trivial due to time constraints. I've had interviews where you sit and write a test or code at the start and the next step goes over your answers. The problem with this is that you have to leave the candidate doing nothing for 30-60 minutes while someone goes over what they wrote. Tests you do on your own also have limited value. They're mostly useful as a low pass filter. They weed out the really bad candidates but can't tell you much more than that.

Amen.

Speaking as someone who has suffered in a similar way and subsequently gone on to interview developers myself, may I state: interview / test conditions will invalidate everything that you think you can discover about a candidate.

Live coding tests, logic problems, whiteboard exercises; all of those things will definitely rule out some genuinely great candidates. In an industry where jobs seem to outnumber competent applicants, I genuinely think softer, subtler interviews represent a much better approach.

This is painful to read. Not because of the poster's anxiety but because of his unwillingness to refuse these types of interviews completely.

If you have a reasonable amount of experience and a track record of actually delivering working software that people use in the real world you don't need to subject yourself to this nonsense. Sure refusing these types of interviews means you won't be considered for certain jobs at certain companies but do you really want to work for a company that is so foolish as to run candidates through a series of standardized tests and ask them to do a bunch of tasks under a microscope that are completely unrelated to the job you'd be performing? A lot of the companies that employ these ridiculous interview tactics are staffed by people who have deluded themselves into believing that their lightly used web app requires elite programmers.

There are plenty of good opportunities for half decent devs at companies not staffed by people who want you to spend 8 hours whiteboarding algorithms but won't take time out of their day to read your resume, review your code samples and ask you relevant questions about your experience.

In my case, just old-fashioned honest work and writing programs to show beforehand substantially reduces anxiety. I feel a lot more confident when I can honestly say "I wrote this and that" and talk about the solutions used.

If I was that guy, I'd try more general health solutions like exercise, bicycle, going for a walk regulary. Fresh air.

The thing that bothers me about it it not really the interviews...it's the fact that you're going to have to spent 8 hours a day everyday, for years with these people. Think about that.