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 very weird indeed. When I talk to people in other fields and tell them about what it's like to interview for a programming job they're really surprised. I tell them that I need to actually study for a few days before the interview because it's kind of like a final exam where you have absolutely no idea what's going to be asked.
I have difficulty when I feel I am being watched. Had difficulty even in school finals if a teacher would peer over my shoulder out of curiosity or just stand next to me. I am not quite sure it is anxiety, its as if there is a thread in my head that wont shut up saying "that guy is still over here", now if only I had a baseball bat to shut that guy up in my head it would all be fine. Finally, I just cannot think unless I am pacing.
I wish it was kosher to say this, "now if you will please excuse me and leave the room for 10 mins, then we can discuss, and hope you dont mind me taking your questions while I pace". Many have trouble with coding on the whiteboard, thats a lesser problem than these.
for me it's not really anxiety. in a way it's similar to what you describe.
for me for example it's similar things others consider impressive, i consider so trivial that when i was asked that question the last time. i just looked at them and said i dunno. there was a name for this that i can't remember, but it had something to do with underselling yourself.
another problem i noticed is that i think a bunch of problem solution, and scalability pairs in my head after getting asked an interview question. the guy who's looking at me doesn't know what's going on in my head the only thing he sees is some dude staring in the room. i heard that this is actually very common.
a friend of mine at facebook advised me to actually speak out what i'm thinking, as i try to solve the problem, but to me it almost seemed like i would insult the guy by saying a solution i know only works in certain corner cases.
in summary it's very rare that people don't get a really good impression of me after having worked with me. but exactly that is the problem. in open source you can work with anyone, but in the job world you might never even get the chance to.
> but to me it almost seemed like i would insult the guy by saying a solution i know only works in certain corner cases.
The point of the interview isn't about reaching a solution, but showing you can think and reason about the problem. You want to identify those corner cases, and reason about ways to fix your solution. Someone who can do that is a better candidate than the know-it-all who doesn't have those skills.
I feel like I'd be unable to code if I smoked a joint. I've never tried it though. I'd love to hear about people's experiences doing something like that though.
I haven't had the same experience as jaredmcateer. I often find myself more focused when I'm high - it's easier to achieve that flow state and to think creatively. Cannabis can be very helpful for seeing big ideas and thinking in modes that are different from your everyday way of thinking.
That being said, I've only been high for personal programming projects, I wouldn't be likely to smoke before an interview.
It's not like it is some foreign psychedelic experience, you're just slower and less focused. With experience that's probably mitigated as well. I suspect if weed didn't affect my motivation so much it would be fine but only thing I want to do when under its influence is sit down watch some comedy and eat junk food, until I fall asleep.
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?
1. RTFR (read the...resume) if you don't. The value of a resume is somewhat limited, but you can gain a lot of insight about a candidate by what is said, what isn't said and how his/her experience is presented. A lot of interviewers don't RTFR or skim it right before the interview.
2. Request code samples. A lot of companies ask for Github links but don't bother to take the time to review and discuss the candidate's code.
3. Ask for examples of work product (public facing if possible), and ask detailed questions about them. This is a great filter. A candidate should be excited to talk about his work and should be able to go into technical depth about what was involved.
4. Provide a practical programming task before the interview. This should reflect the type of work that the candidate will actually perform as an employee. Let the candidate complete the task when and where they like. Don't provide a task that would require more than 1-3 hours of the candidate's time as estimated by how long you think the task should take. Set the expectation with the candidate that you'll be reviewing the deliverable before he comes in for the interview and that you'll be discussing it with him when he comes in.
5. Ask practical technical questions. If the candidate is going to be asked to work on an app with a MySQL database, you don't need to ask many questions about basic stuff (like joins, foreign keys etc.) to get a sense of whether they are a poser. Focus on high level concepts, not on questions that pressure the candidate to make a decision on the spot that would be contemplated in a less intense environment in the real world.
If you cannot weed out unqualified candidates doing the above it suggests that you require a demonstration of competencies that will never realistically be obtained reliably in 1 or 3 interviews. If this is your situation you should consider requiring a trial or contract-to-hire arrangement.
Thank you, those are very good. I am always ecstatic to see code samples. Very few people have them from our candidate pool, so those that do stand out.
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.
It really is kind of silly. I naively started interviewing this way, basically copying big G and others who do these kinds of interviews. The problem was I was filtering for the type of programmer who enjoys these discrete, quirky, contrived puzzles, not real engineers who understand resource constraints, writing production quality scalable software, and fierce debugging. Now I find a candidate whose work impresses me, put him on a project for 2 weeks, and hire at that point if we're happy. So much better.
The important thing to remember about the big G or MS style is, they have a massive stream of extremely qualified potential hires, who want to work there far more than the company needs them. The company needs an assembly line just to handle the large numbers of applicants.
There is a classic anecdote about the manager who handled a large stack of resumes by randomly throwing half into the garbage, and remarking "I don't hire unlucky people"[1]. I can't find the original source, and it's probably not true, but it is closer to what they are doing than actually evaluating people for a job.
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.
(author of the article here) Probably you're right, but knowing people in the psych field and having read several books on the topic ("Monkey Brain" comes to mind) it's also a very hit-or-miss process. Often you can go to a therapist for years without much improvement.
One irony of mental health services is that the people who most need the help are often not in a position to use the services optimally; it is perfectly valid to break up with your therapist if they're not helpful. In fact, it should be encouraged, but doing so can be really stressful.
This is not to tar the professionals with some kind of pseudo-Scientology crackpottery; they exist somewhere in the n-dimensional space of competence, authority, ability, &c. as everybody else; but that there can be dissonance between the treater and the treated is not a reason to give up on the whole idea.
Another irony is, the act of seeking mental health services can, in some cases, be used against you in future medical, legal, and employment situations. This might also explain why so many people, while being supportive of professional mental health services, seek alternatives.
this is both ridiculous and, unfortunately, true. If it is a concern for you, you can ask that your therapist not take notes, then there is nothing physical to subpoena.
I have not heard that suggestion before. I have heard to not use your medical insurance, or credit cards, and avoid a formal diagnosis. I believe the service provider is required by law to keep records for their legal liability, but that will depend on the laws covering your area (e.g. state and federal laws for US).
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.
As the author, I feel like I have to actually defend the interviewers because they generally weren't as bad as you describe. It's not that they shouldn't ask questions or shouldn't even ask you to whiteboard an algorithm (though I think it would actually be better to give you a REPL and have you code with that), I think the issue is that some people (myself included) have developed certain phobias that make that sort of thing potentially difficult. It might be better to ask candidates to code something up prior to coming in and then go over the code together in the interview.
"It might be better to ask candidates to code something up prior to coming in and then go over the code together in the interview."
That is entirely reasonable and a lot of employers do this. So why bother with the ones who want you to demonstrate whiteboard chops that don't have any relevance to the daily work you'd be doing?
Remember... the interview isn't just for the employer. It's your only opportunity to determine if you're interested in working for the company. If the interview is a one way street and doesn't give you the opportunity to learn anything meaningful about the work you're really going to be doing, how would you feel good about joining the company even if you ace their inane whiteboarding exercises?
What companies have you worked for that have no real-time problem solving or programming in the hiring process? Since you want people to not waste time, do their hiring processes also not include any take-home problems?
Every single one. I have never worked for a company that treated an interview like the SATs.
Maybe I was lucky earlier in my career but now that I have been in the industry long enough and have a big enough collection of work I can reference I am comfortable avoiding companies that basically make the assumption that every candidate is either incompetent or lying about their experience. I mean if you can't sit down with me and engage in a real dialog that establishes I know what I say I know that's on you, not me.
I think take home tasks are fine so long as they don't require more than a few hours and are clearly relevant to the job. If you can't come up with a task that mirrors the type of thing I'm going to be doing on a daily basis and ask me to do something inane it tells me you're lazy or not focused on what's important.
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.
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.
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.
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.