

Interviewing for the anxious programmer - bendmorris
http://aneccodeal.blogspot.com/2014/02/interviewing-for-anxious-programmer.html

======
GuiA
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.

~~~
philangist
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.

~~~
mal-2
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.

------
rdtsc
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?

~~~
DontWasteTime
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.

~~~
rdtsc
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.

------
daphneokeefe
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.

~~~
jliptzin
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.

~~~
jared314
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.

[1] [http://benpowell.org/i-dont-hire-unlucky-
people/](http://benpowell.org/i-dont-hire-unlucky-people/)

------
cdoxsey
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](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.

------
jwingy
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.

------
adriand
> 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.

~~~
UncleOxidant
(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.

~~~
jfb
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.

~~~
jared314
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.

~~~
pacaro
This

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.

~~~
jared314
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).

------
fredophile
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.

------
philbo
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.

------
DontWasteTime
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.

~~~
UncleOxidant
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.

~~~
DontWasteTime
"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?

------
b0rsuk
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.

------
nickthemagicman
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.

