
Embarrassing code I wrote under stress at a job interview - lkrubner
http://www.smashcompany.com/technology/embarrassing-code-i-wrote-under-stress-at-a-job-interview
======
intelliot
> Interviews are weird: the pressure of time, and not being able to look
> things up, distorts the code.

In the interviews I do, I tell the candidate that:

1\. There is no time pressure. Work at a normal pace, as if you were working
here. This is not a speed test. I don't expect you to finish. I mainly want to
know how you think.

2\. You should look things up. Behave the same way you would when coding at
home. Use Google, Stack Overflow, documentation, etc.

This probably works better for the interviews I give because the problem is
not implementing an existing algorithm. It's a realistic task, something that
we've actually built on-the-job.

~~~
serve_yay
I don't think that's good enough. It's unfair to ask candidates to write code
on the spot.

~~~
dataminer
I have had my share of bad interviews but I don't agree with this sentiment,
why is it unfair? Haven't you ever been in a situation where you have to
create a hot fix and deploy it as fast as you can. Haven't you ever gone
through a crunch period where the deadline is closing in and and you have to
fix that elusive bug. There is limited time for everything, the sooner we
realize that the better.

Having control over your nerves when s __* hits the fan is a valuable quality,
which we should all strive for.

Most of these interviews are tests to see your approach to solving a problem.
The best practice is to come up with a strategy before you hit the first key,
ask as many questions as you can and find as many corner cases as you can. All
the sane interviewers will appreciate that even if you don't end up with the
best solution. And please treat all interviews as a learning experience, you
will be much better off.

~~~
learc83
I must've been working in a much different environment than you. I've _never_
had to solve a difficult problem in 15 minutes while someone who knew the
solution watched over my shoulder and did their best to answer my questions
without answering them too well. Ohh yeah and the results of my performance
had potentially life changing consequences.

The adversarial and extreme time boxed nature of a coding interview is
something that is truly outside the day to day experience of the vast majority
of programmers.

>Having control over your nerves when s* hits the fan is a valuable quality,
which we should all strive for.

That may be true, but think about that for a minute. Go back to college and
think of how many people in the class were comfortable going up to the board
and solving problems in front of everyone.

When I was taking Automata, we could get an extra point on our final grade by
going to the board and correctly working out a problem that we hadn't seen
before. Only myself and 2 other people ever did it--in a class of 60.

Do you think that your company is solving problems so hard and paying so well
that you can can only consider 3 out of every 60 developers (or whatever the
real ratio is) who are otherwise qualified who have also mastered control of
their nerves far beyond what is required 99% of the time on the job? Maybe if
you're Google, for the rest of us we need to find a better solution.

By the way, even though I was able to solve problems at the board, I hated
every minute of it, and I refuse to work for companies that require this kind
of interview.

~~~
nilkn
> I've never had to solve a difficult problem in 15 minutes while someone who
> knew the solution watched over my shoulder and did their best to answer my
> questions without answering them too well. Ohh yeah and the results of my
> performance had potentially life changing consequences.

So you've never taken an exam in your entire life?

I don't mean to be snarky. I just don't understand this extreme disdain for
coding interviews, even when they're very forgiving and flexible. Yes, exams
aren't fun, but they're necessary.

Even if you can look up whatever you want, use whatever language you want,
take as long as you want, do it right on a real desktop (not a whiteboard),
and if you're asked a reasonable, real-world problem, not an algorithmic
brainteaser, you'll still have people say it's a horrible process and it's
unfair. And that's already way more forgiving than any exam I ever took in
school.

I mean, are programmers expected to not be able to do anything at all in an
interview setting? Like you can't be expected to produce any code of any kind,
as if you don't know how to program at all? I think it _is_ a bad sign if
someone who is a talented programmer utterly buckles under a little bit of
pressure. To me, that means they either really aren't nearly as talented as
they think they are, or they won't be able to deal with the pressure of the
job anyway.

So what, if I hire you and at some point need you to hotfix something in, is
that unfair? Maybe I do know how to do it myself but don't have time because
I'm busy with something else. That situation doesn't seem all that different
from the interview, except it would actually be higher pressure because
there's a _real_ problem, not a fake one.

~~~
learc83
>So you've never taken an exam in your entire life?

You missed the context where we're talking about a professional setting.

>And that's already way more forgiving than any exam I ever took in school.

You took exams in school were the professor was looking at what you were
writing the entire time? Your exams were in front of several people on a
whiteboard?

>To me, that means they either really aren't nearly as talented as they think
they are, or they won't be able to deal with the pressure of the job anyway.

And you'd be wrong. I've worked with very talented programmers who are
absolutely terrible at interviewing. The problem is you're biased by your
experience. You are probably good at this kind of interview and you are
probably a good programmer, so you assume that any good programmer must be a
good interviewer.

I know for a fact that these 2 processes are orthogonal. Books like cracking
the coding interview exist because it is possible to practice and game the
system. I've met just as many people who are good at interview questions, but
are terrible software engineers, as I have people who are bad at interviews
and are excellent software engineers.

The fact is that our current hiring processes are broken. Other professions
don't conduct interviews like this. Go talk to some mechanical engineers
who've been working for 10 years and ask them if they interview like this.
Newspaper writers work on deadlines, but they don't have to write an article
on the spot while someone watches them type.

Studies have constantly shown that work sample tests are really the only form
of interview that shows real predictive power (that and general intelligence
tests). The closer you can make the work sample to real work, the better.
Finding the nth item of some arbitrary sequence in 15 minutes while someone
watches your every move is _not_ close enough to real work to have much
predictive power.

>So what, if I hire you and at some point need you to hotfix something in, is
that unfair?

If you're regularly giving me life or death tasks that I have 15 minutes to
solve, I don't want to work there. I'm also probably very familiar with the
domain, and it's not some artificial problem that I may have never seen
before. But more than that, why don't you see the difference between a hotfix
and an artificial situation where someone who already knows the answer is
standing there watching your every keystroke, and judging your value as a
programmer?

There are better ways to interview programmers. Here is one:

Pair the candidate with an interviewing engineer, give them an hour or two to
solve a problem as a team. The interviewer isn't an adversary; their job is to
assist the candidate like they would if they were working on a real problem.

Repeat this process if necessary.

Get everyone together and talk about past projects the candidate has worked
on. Have the interviewers evaluate the candidate, and make your decision.

You know whether the candidate can code, and you've removed the adversarial
nature and unnecessary stress from the interview process. Most importantly,
you got to see them work in a much less artificial environment that's closer
to what they'll be doing day to day.

~~~
Fargren
Going on a tangent, but:

>You took exams in school were the professor was looking at what you were
writing the entire time? Your exams were in front of several people on a
whiteboard?

Yes. Is this not common? I've had a number of teachers who, as a graded form
of evaluation, would ask us to present a topic to the class, and/or ask
questions about it. This was extremely common on high school, and happened
once or twice in the more advanced courses in my college. I also had to defend
my thesis to graduate, which was _basically_ a more lengthy version of this.

I live in Argentina. Maybe it's a cultural thing.

~~~
learc83
Were you asked to actually solve new problems you hadn't seen before in front
of the class?

> would ask us to present a topic to the class, and/or ask questions about it.

This is common in the US as well, but presenting on a prepared topic and
solving novel problems are 2 completely different things.

~~~
Fargren
I've had to do both, but presenting on a prepared topic was much more common.
I don´t recall ever being graded on a novel exercise presented to the class,
but I certainly have had to solve them.

~~~
learc83
I've had professors that like to require writing on the board as well. But as
in your case the key difference is, they weren't graded.

That being said, a professor student relationship isn't analogous to an
employer employee relationship. Hopefully an employer wants to make the
interview process as enjoyable as possible to attract as many qualified
applicants as possible.

~~~
Fargren
I agree, the relationship is not analogous at all. That's why I said I was
going on a tangent: I was more interested in learning about the evaluation
system in the US than it's possible parallels with job interviewing,

------
rcthompson
This is a sentiment I hear expressed a lot:

> But I wanted to appear smart, so I didn’t express any confusion.

And I don't get it. When I ask questions, if anything, I get told that I seem
smarter for it. Asking questions is a sign that you're paying attention and
actively trying to understand things. I don't think I've ever had anyone
question my intelligence for asking questions for clarification.

(I'm not trying to criticize the OP in particular for this. I've heard it from
a lot of places, and wanted to point out the fallacy.)

~~~
lotyrin
Yep. This has been the primary source of frustration for me in my
communicating with software developer peers. I'll explain the task I'm
delegating carefully: why it exists, the big picture of how it should be
implemented, what tradeoffs I feel like will need to be made, and what corner
cases are likely to exist and they'll nod like they understand to defend their
ego then go and implement roughly none of it.

~~~
jmilloy
It makes testing for this behavior important, and it sounds like the OP
exhibited just this behavior, doesn't realize it, and blames the interview
technique despite it ascertaining exactly what it needed to.

------
stevepike
This is a tricky problem. Here are some things I've found helpful on the other
side of the table:

\- Pick a real world task (e.g. text munging).

\- Suggest in advance that they bring a laptop with their preferred work
environment. Allow any reasonable language if you're willing to train them on
your stack.

\- Write the problem down ahead of time. Have someone else at your company
read it.

\- Do the problem yourself. Ballpark your estimate for a _great_ candidate at
3x the time it took you.

\- Tell them there is no penalty for using stack overflow over the language
docs.

\- After you give them the problem, give them a few minutes in peace (leave
the room) while they think it over. Talk about their approach out loud before
they begin working.

\- Ask them to spend 5-10 minutes re-factoring their code once it's working.

~~~
spectre256
That 3x to do it yourself time seems excessive, but we once did exactly the
same thing at a previous company. We chose problems we knew, worked with tools
we knew, in a comfortable environment.

Even if you aren't intentionally trying to do the opposite, which
unfortunately many interview techniques, like whiteboard coding effectively
do, conducting interviews where a candidate is comfortable and at their best
is ridiculously hard.

~~~
stevepike
Agreed, but it's worth trying to do well. You get a lot of information out of
how someone handles programming live vs. what you get in a homework
assignment.

------
tinco
Very nice write-up, I can just feel the stress.

Regarding the interview, there's this trick I learned that presenters do when
they come on the stage. Instead of focusing on the audience and their talk
immediately, they first drink a glass of water slowly. It lets you set your
own pace, and deal with the first high of adrenaline a little.

In this case, they asked you a question and you immediately fired up a repl
and started typing away as if it's a race. But if no one is holding a stop
watch it's not really a race. If you're going to have to do this kind of
interview more often, perhaps practice on your generic problem solving
strategy.

If it were me, I'd probably ask for a piece of paper, and then write down the
components of problem on the highest level, then drill down the details of
each component. At each level of detail check with the interviewer if the
requirements of the component match their intentions. When you're confident
you've got the algorithm down on paper, then you can start on working it out
in the REPL.

Also, I'm not a LISPy guy so no idea how you usually do this, but those first
three mistakes you made were horrible. Obviously you were nervous, but these
kinds of mistakes don't happen if you have a good IDE and disciplined code
style. You can't miss matching brackets if every opening bracket starts a new
line and a new indentation level. You can always clean up the new lines when
your algorithm is done.

Practice and preparation are the best countermeasure to stress.

Not that I agree with this interview style at all by the way. You are most
likely an excellent developer, and if they don't decide on hiring you they
probably are making a big mistake. If I was hiring Clojure people I'd be
surprised I'd get someone that would work a REPL like that without internet
reference at all.

------
gajomi
I feel compelled to point out, as a native English speaker familiar with this
sort of mathematics, that the phrasing to "go infinitely" doesn't make much
sense. Or, if it makes sense, it is at least ambiguous (with plenty of room
for the interpretation "diverges to infinity"). The clarification that the
author makes about looping (or even better, repeating) is much clearer.

~~~
rdtsc
As a non-native English speaker who also interviews candidates, I try make
sure to see if the candidate understood and always say it in another way --
For example after saying "go infinitely" (which is a silly way to phrase it) I
would also say "it basically loops around", "creates a cycle". Maybe even draw
out a little example on a whiteboard.

------
sergiosgc
Thanks for the great post. The author, even if he were a bad programmer, is a
great writer. The text grabs the reader and makes him sweat in the
interviewee's shoes.

Live programming interview tests are rubbish, because:

a) They produce a huge rate of false negatives. People who do not "interview
well" flounder in a programming task with someone peering over the shoulder.

b) They can only test "algorithmic" tasks (for lack of a better definition).
Most programming is not algorithmic, it's higher level: glueing already
written libraries, with very light data manipulation or validation.

~~~
nowarninglabel
I'm not sure I agree with you on this.

Live programming interviews should not be the sole quality of judging someone,
but if we've first given them a coding exercise to do on their own time and
they passed that, then it's useful to have them come in and do some coding to
show that they can walk through their code and add additions/fix bugs to it
without problem.

Which on that same note, I'm not sure why you would say they can only test
"algorithmic" when we can do like I just described and have them for instance
code a new feature in an existing code project of theirs.

That said, I agree with everyone else that they shouldn't be rushed, should
allow the interviewee any and all resources they care to look up, and should
shoot for "real-world" exercises over made-up scenarios.

~~~
sergiosgc
I was speaking about live programming, during the interview. I much prefer
asking candidates to write a task on their own time, and then use that code as
basis for conversation during the interview. You get all the insights on how
good a programmer he is, without the sweaty palms effect.

------
theVirginian
No matter how badly I was doing in the interview I would walk out when I saw
the engineer pull out his phone and start checking messages. How embarrassing
for the company to have someone that disrespectful conducting interviews. An
interview should be a conversation between potential peers and him pulling his
phone out is just as rude as if you had pulled out yours because you were
bored of hearing about the company.

~~~
jacquesm
I even do this IRL. If I come to visit you or you come to visit me then that
takes precedence over social media. If that's not the case I'll be more than
happy to walk.

It's rude beyond insult to do this during a job interview, whoever decided
that was ok to do is basically sending you a very large warning message that
even hiring is a job that does not require full attention.

~~~
alok-g
Counter opinion: I have done this in the past to signal the candidate that I
am _not_ watching over his shoulder, just to help the person relax as he
figures things out. I feel glad now that I have done this after explicitly
indicating this to the respective candidates.

~~~
jacquesm
Do you signal that in a verbal way as well or do you simply look away and
start working on your phone?

~~~
alok-g
Verbal way.

~~~
jacquesm
I think that's a key difference then.

------
learc83
The way I see it, you can master coding interviews by practicing solving small
problems quickly under pressure. But this kind of practice takes time--time
that is probably better spent mastering the skills you'll use day to day.

The studies that get brought out every time this comes up are very clear. The
best predictor of future success is a work sample test. Solving a bitesize
problem in 20 minutes while someone watches over your shoulder is not a work
sample test--it's about as far away from a work sample as you can get and
still call it programming.

At the _very least_ why not let the candidate work on the problem on their own
for 30 minutes and then check back in.

I've said it before, the best interview process I've ever heard of is this:

Pair the candidate with an interviewing engineer, give them an hour or two to
solve a problem as a team. The interviewer isn't an adversary; their job is to
assist the candidate like they would if they were working on a real problem.

Repeat this process if necessary.

Get everyone together and talk about past projects the candidate has worked
on. Have the interviewers evaluate the candidate, and make your decision.

You know whether the candidate can code, and you've removed the adversarial
nature and unnecessary stress from the interview process. Most importantly,
you got to see them work in a much less artificial environment that's closer
to what they'll be doing day to day.

------
jcadam
I am horrible at these kinds of interviews.

I remember once being so nervous that I completely blanked. I'd been asked to
reverse a linked list. A very simple task, one I'd even practiced a few times
in various languages prior to my interview and should have been able to breeze
through.

But I froze. My hands were visibly shaking as the interviewer stared at my
back... I shut my eyes tight, trying to think through the problem (I _knew_
this was a simple task, and I was frustrated that I somehow couldn't recall
the solution). At first I tried to write out a recursive solution to the
problem, but my anxiety-riddled brain just couldn't cope with recursion that
morning. So I erased the board and started over trying to find an iterative
solution. That went even worse.

"Um, I need to repeat this block of code, I think, maybe. There must be some
way, some kind of construct that causes a block of code to be executed several
times, almost as if one were _looping_ through the code." AGH! _Think!_

But I was coming up empty, I searched my memory, ready to seize on the first
seemingly helpful thing I could find. And so my mind wandered back to a time
when I was about 8 years old, learning to program for the first time on my
Apple II. I had just discovered the magic 'GOTO' command, which was the
perfect tool to cause uncomplimentary messages about my older sister's hygiene
to scroll down the green mono display for all eternity (or until someone hit
Ctrl-C).

So... I completed my solution on the whiteboard using a GOTO. The interviewer
put his face in his hands and began laughing. Eventually, he stopped and said
"Um, ever heard of a for loop?"

"Well.... yes."

------
jlcfly
This sort of interview is insulting. There are real problems to solve in
business and elegant solutions to the 'next number in sequence' isn't one of
them.

~~~
recursive
There's not really time in a 30 minute interview to pose a real business
problem, much less have any meaningful representative work done, by which to
judge the candidate.

~~~
rhizome
Why would you only allow 30min at the stage where the candidate is writing
code? 30min is for the phone screen, in-person is when you're serious.

~~~
ianstallings
Agreed. If I have you in the office I may talk to you for the rest of the day
and I schedule accordingly.

~~~
rhizome
And if you're LinkedIn you never communicate with them again.

------
chetanahuja
I have ranted before about the cargo-cult style used in hiring processes
across our industry. Most of the "write-code-on-whiteboard" and "how-many-
golf-balls-a-school-bus" style of bullshit has been handed down through
folklore from old Microsoft interview techniques from the 80's. Now that I'm
running a company, I've used the opportunity to define policies by basically
banning those practices from our engineering recruitment process. Instead, we
give a problem to the candidate (of the sort that we might be solving in day-
to-day work ... not "create this data structure and be sure to use recursion
horse-manure) and ask them to take the whole day or more if they want, in
their own environment (home, cafe, wherever they find focus), as if this is a
real problem they might be solving for work, and produce working code. Now I
know this is not perfect, but I'm convinced this is way better than the
traditional coding interview.

~~~
zak_mc_kracken
> I've used the opportunity to define policies by basically banning those
> practices from our engineering recruitment process.

Good for you but FYI, brain teasers have been banned in most companies in
Silicon Valley for a solid decade. The fact that they are no indicator of the
quality of an engineer candidate is a well known fact.

~~~
PopeOfNope
> Good for you but FYI, brain teasers have been banned in most companies in
> Silicon Valley for a solid decade.

I think you mean "specific, but highly visible companies" instead of "most
companies." Having recently gone through a round of interviews, I can tell you
the brain teaser is alive and well at quite a few hiring companies in SF and
SV. I think people know they don't work, but hiring is difficult and most
people are lazy, especially at companies where the interviewers would rather
be coding.

------
S4M
I think the OP made the mistake of trying to solve the problem directly, and
when he got errors, he got nervous which made him get more errors. Instead the
right strategy would be to think aloud "well, how do I get the digits of a
number? first, cast the number into a string then try to see if I can treat it
as a list. Ok, let's try (seq (str 10)) on the repl....". Having an instant
feedback and being able to no exactly if a small instruction works or not
would have helped him to focus better, and avoid nervousness.

~~~
shortly
that he did not take this approach makes me think the candidate is
inexperienced, and probably coming to clojure from an imperative mindset.

~~~
tonyarkles
Yeah, that's exactly what I look for in problems like that. How does this
person approach the problem? How do they decompose the problem?

For that specific problem, I'd probably be satisfied if they wrote a function
that took a number like 341 and returned [3, 4, 1], and then mumbled something
about a set or a hash (or a list even) for storing the already seen numbers.

------
seba_dos1
On my first job interview, despite having already quite a bit of experience
with personal and free software projects in various languages and frameworks,
I somehow managed to struggle with FizzBuzz. I didn't know that it's supposed
to work as a basic filter so I was looking for some catch thinking that it
cannot be as easy as it looks. As I couldn't find any I figured out I should
go with trying to write the prettiest, most elegant and clever way, started
fiddling with modulo division and managed to screw it up under nerves and the
fact that I was writing it on paper with no ability to run and check. Also,
despite of being told "use whatever language you want", for some irrational
reason I worried about correct syntax, which probably added up to my
nervousness.

Fortunately, they didn't stop there and I was able to do harder tasks better
later on ;)

I reacted pretty much in the same way on my driving exam. Both that interview
and that exam weren't telling you anything about how I actually program or how
I actually drive - even under extreme conditions. Being judged is just a
completely different experience that makes me behave in completely different
way.

~~~
XorNot
I had an interview a few days ago, and just punched the problem I was asked to
do in Python into iPython. Immediately did it a much simpler way, and also
spotted my logic error (if you want deciles you actually divide by 9, not 10,
since you have 9 columns with 10 edges).

Took me about 2 minutes to do. Whereas in the interview I wrote entirely the
wrong thing initially, then went "oh wait, that makes no sense".

------
mavidser
I remember that my first interview was kind of similar. Though it was a phone
interview on Hackerrank Codepair.

I was really nervous, and since it was a phone interview, I tried to speak my
thought process, which didn't quite work out due to me constantly stammering.
So I just took to typing all the time so that my interviewer wouldn't think I
was taking too long coming up with a language or copying answers. I started
making silly mistakes like using `int sum=0` in python. I took the input as a
number, converted it to a string, and then further converted it back to a
number, and did mathematical operations on it, trying to solve the problem.
Every time I thought I did it, it would get stuck in another case.

Ultimately, the interviewer deleted 50 lines out of my 60-line code, and just
added a print statement on a variable I was already using for storing things
temporarily, which turned out to be the correct answer.

Needless to say, I blew the interview. I haven't done an interview since, and
I'm gonna be up for it very soon. I'm not sure if I'd do better this time, but
I'd be ready with a glass of water, and try to be as relaxed as possible.

~~~
leovander
How long do you normally wait between interviews?

------
mockery
"I’m suddenly self-conscious about the prettiness of my code — it doesn’t
matter if I can solve the problem, since I’m also competing against candidates
who can solve the problem, so the real competition is probably about how
elegant and idiomatic our code is."

This is an incorrect assumption, at least when I interview people. A live
coding interview has (almost) nothing to do with the "quality" of your code,
and doesn't necessarily even demand complete correctness. It's about observing
your process, and trying to simulate what it would be like to work with you:

Do you approach a problem with caution until you're sure you understand it, or
jump in head first and start writing code you hope is correct? Can you
verbalize your thought process and communicate it to others? How good are you
at reasoning about the runtime behavior and correctness of your solution? Do
you consider edge cases and naturally want to test them? Things like that are
won't show up in a take-home coding test, and tell me a huge amount about what
kind of programmer you are, and whether I want to hire you.

See: [http://www.yacoset.com/Home/signs-that-you-re-a-bad-
programm...](http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer)
\- there's a lot of truth to this article, and many of these flaws will be
glaringly obvious in a live coding session.

And yes, of course some people interview poorly or are just having a bad day.
That's unfortunate, but I'm not about to give up a powerful interview tool
just because it can have false negatives. Until I find a divining rod that
will point out the best programmer in a room, asking a candidate to write some
code is the fastest way to learn what kind of programmer they actually are.
(And also immediately weed out people who can't actually write real code.)

~~~
MichaelDickens
> A live coding interview has (almost) nothing to do with the "quality" of
> your code, and doesn't necessarily even demand complete correctness. It's
> about observing your process, and trying to simulate what it would be like
> to work with you

I frequently hear people say things like this. Now maybe you do think this way
and I'm not saying you don't, but I think that makes you exceptional. In about
80% of interviews I've done where I successfully completed the problem, I got
an offer; and in 100% of interviews where I did not complete the problem, I
did not get an offer. That seems to indicate pretty strongly that solving the
problem is by far the most important thing for most interviewers.

~~~
yoklov
I didn't take what he said to mean that solving the problem wasn't important,
but that the quality of your solution (in terms of how 'elegant' or
'idiomatic' it is) wasn't important.

------
logicallee
Technical interviews always get your hopes up, and then you accept the job and
over the next six months not _once_ does an engineer come into your office and
ask you if you know what a Collatz number sequence is, then explain it to you
and ask you to write some functions that would allow him to find the longest
iterations through the Collatz sequence, given a set of starting numbers. It's
practically bait and switch.

( _EDIT: this was actually a joke..._ )

~~~
sdenton4
I recently had a good long discussion with a fellow engineer about the number
of sequences of coin flips with no streaks longer than length k. (turns out
the answer is a generalized Fibonacci number!) So it /can/ happen...

------
Jach
I have a dream I'll one day be asked to interview someone, and get to try out
my unconventional idea... (Or have it done to me one day.) I hate standard
coding exercises, and I expect the candidate to have already been vetted for
being able to code by either having some open source work or if none is
available being given a take-home fizzbuzz-ish problem. My idea is to pick a
problem off my own personal list of things I'd like to explore, things I'd
like to reinvent code for from high level descriptions if I had more
time/discipline (for example drawing voronoi diagrams), and do this alongside
the candidate, so together we can attack the problem with a whiteboard and a
shared computer or two for wikipedia/pseudo-code/real-code/etc. We may not get
very far in just an hour, we might not even get to code, but it will be good
information for both myself evaluating the candidate and the candidate
evaluating me about how we collaborate on a problem neither of us knows the
complete solution to in advance.

------
droopyEyelids
Part of this was nerves, part of it was insecurity, and part of it was two
people being bad at communicating with each other.

Bad situation, but I don't draw any conclusion from it. There are lots of
inherently hard things in life that get messed up if you are nervous, insecure
and can't communicate. That isn't _necessarily_ an argument against them.

~~~
arthurcolle
Sex immediately comes to mind too.

~~~
dllthomas
Regardless of the topic at hand.

------
zak_mc_kracken
My dislike of dynamically typed languages went through the roof reading
through this article.

~~~
slowmovintarget
Your dislike for an interview question that tests knowledge of number theory
instead of programming is what should have increased.

Writing Clojure functions under pressure is like gardening at 55 MPH. You're
trying to make something still and beautiful and overdoing it (or missing
entirely) as you drive by.

~~~
zak_mc_kracken
> Your dislike for an interview question that tests knowledge of number theory

"Number theory" is a bit exaggerated. This is a warm up question to see if the
candidate is able to decompose number 530 into digits five, three and zero. If
you can't do this in a few minutes, you're probably out of the running from
the get go.

------
AndyD1st
Interesting article, but ironically the interviewee's solution is still
incorrect at the end of his post. You'll notice that he only squares the first
digit, and then adds the second digit rather than squaring it.

E.g. when he calls (happy 97) it prints 88. However, that's 9^2 + 7, when in
fact the answer is 9^2 + 7^2 = 130.

------
d0m
2 things that I think would make your life so much easier..

1) Agree with the interviewer before starting to code on the algorithm and
problem. I.e. You could say I need function X that would be used like such,
and function Y that would loop through such and such. Even better is drawing a
high-level example on the board. That way, the interviewer knows that you
understood the problem and can be systematic about it. (If you don't have a
whiteboard, just write in comment at the top, whatever)

2) Once you start coding, start small.. especially in the REPL. I.e. instead
of starting with the whole function, start with the string, then separate it
in digits, then sum it up, then work from there. That way, if something
doesn't compile, it's perfectly clear what step it was and once you have your
function, you're 100% sure it works. TDD style.

------
ricardobeat
Going on a tangent, but that Clojure code looks incredibly convoluted. Compare
to this:

    
    
        next = (n) -> "#{n}".split('').reduce ((p,c) -> p + c*c), 0
            
        happy = (n, set = []) ->
            return false if n in set
            return true  if n is 1
            happy next(n), set.concat(n)
    
        console.log(n, happy n) for n in [1..100]
    

That complexity certainly makes it harder to solve the problem under pressure.
This is really an example of an interview process that focuses on specific
language skills and not actual programming abilities.

~~~
QuercusMax
What language is this?

~~~
nadaviv
CoffeeScript.

------
zyxley
This kind of thing is why the best "code interview" I ever had involved being
given a problem (in this case, a small message sending/receiving library) and
told to work on it over the weekend.

~~~
nothrabannosir
This type of work-intensive interview gets old real fast when the umpteenth
company declines. I fully understand the pros of looking at a more
comprehensive, realistic body of work. But if that's what you're looking for;
I got a whole Github profile full of stuff to discuss. Spending every weekend
on yet another throwaway application until you get hired; I'd rather not.

EDIT: removed some bitterness. :)

~~~
yason
I would assume that a longer programming task would only take place in the
very final rounds of interviews, where it's clear that the candidate is a
potential hire and the company just wants to be sure that the candidate can do
non-trivial work, walk through his code, have it reviewed and discuss the
problems found.

Starting with a programming problem that takes hours is simply being lazy from
the company's part. It's easy to hand out and review but a lot of work for the
candidate.

~~~
personx
that's the dream but there are some companies which send out their pre-baked
"weekend projects" after the initial hr screening and I'm talking about large
corporations (the new york times for example) which isn't terrible at first
but results in lots of trying to look up what practices the company in
question follows and prefers and what they are actually looking for

personally I really need human feedback rather then 8 hours at my desk
guessing and searching for what's being looked for

it's one of those situations where I see the value for the interviewer but as
the applicant it's completely sucks especially when you have 4 sample projects
to write at home while juggling phone interviews and you know having a
life/job

------
mpeg
I have very little love for code interviews of this kind. Here's an
alternative I would propose to hiring managers:

Give the candidate a research paper in PDF, then ask them to implement the
algorithm described there in code.

You get the same feedback on whether they can actually code, and what kind of
code they write, but it takes the pressure off having to think of what kind of
algorithm to use, what the big O complexity of it is, and a thousand other
factors that will probably never relate to what their day job will consist of.

~~~
celadon
For some companies/teams/hiring managers/interviews, having someone who can
reason about big-O complexity and design their own algorithms is important and
necessary. There won't always be problems that have a preexisting algorithmic
solution.

------
jmilloy
The important mistakes that the author here made were assuming the interviewer
wanted him to work quickly, without looking anything up, without asking for
clarification, and without collaboration. The author seems to still be making
this mistake by assessing his performance by the code he wrote, rather than
the (lack of) dialogue he had with the interviewer.

Consider that the interviewer has now seen that this person will choose to,
without clear understanding of either the goals of the task or the task
itself, work alone as though he must solve the problem in isolation in order
to prove himself.

The most important thing that a candidate needs to be able to do on the job is
discuss expectations; failing to do this in the interview is more egregious
than any compiler error. Another important thing is to understand the problems
they are working on; failing to even discuss the problem is more egregious
than any compiler error. Another is collaboration and humility; you can
demonstrate these skills in a coding interview as well.

This interview demonstrated many more important indicators of a poor fit than
typing ones. Just because you pose a coding problem doesn't mean you're unable
to assess candidates on the things that matter.

------
eranation
Awesome post. You have some really good memory! I wish I would see more post
interview analysis in this depth here in HN. Great read.

P.s. You are not a bad programmer... Pressure can mess your mind. My secret to
finding great developers that everyone else misses is by making them feel calm
(giving them an easy problem and giving them encouragement so interview stress
becomes less a factor, best way to find good developers who just are bad at
interviews)

~~~
leovander
Not OP, but I have going through a string of interviews. Hopefully I can post
a couple soonish.(In the middle of studying for another one)

------
dba7dba
I took 2 different tests for 2 different companies.

One was a very simple task, setting up a server as a customer would at an ISP
using WebMin type tool. Really simple stuff. Guess what. I couldn't figure it
out in time. Maybe because I had been consciously staying away with gui stuff
to stay sharp with cli. Or maybe the proprietary tool the ISP was using was
very unintuitive. Maybe the suit and tie I put on for the first time in 2
years got to me. Either way, had I NOT been in an interview setting, I
would've figured it out. But with this interview, I couldn't figure it out.

In the 2nd company, I was giving an online test using
[https://trueability.com/](https://trueability.com/), to complete from home.
Set amount of time to complete some test scenarios. Far more difficult stuff
than setting up a small web server at an ISP. And I would say it was a far
more realistic test of my skills.

IMHO, interview should really only focus on compatibility, not actual tech
skills. If your company is really spending time on tech skill test DURING
interview (especially onsite), you are doing it wrong. just my 2 cents.

~~~
Decade
I hate TrueAbility. It gives you so little time to do the test, and for
example the Linux skills test is really about your intimacy with the dark
corners of an outdated version of CentOS instead of anything current. Then, if
you bomb a test, it doesn't allow you to try again.

~~~
dba7dba
I love TrueAbility. You are not expected to finish 100% or even 80% of the
given tasks completed during the test. I read online somewhere that he/she got
barely 50% done but still got an interview. The recruiter giving out the test
on TrueAbility is looking for how you solve the problem, not how much of it
you solve.

Also, the way I understand it, you can keep a personal profile on TrueAbility
and point recruiters to it for them to review your tech skill level.

------
seanwilson
I'd be more comfortable coding something more concrete and familiar than
Collatz and Happy number sequences personally.

~~~
jacquesm
You're liable to see Collatz sequences and such in interviews because the
interviewers can look up the answers to project Euler problems online to see
how your solution compares to those coded up by others.

------
quantumtremor
I realize that the interviewee was in time pressure, but really should've made
smaller helper functions - probably would have helped ease the stress a lot.
Possibly also unfamiliar with Clojure/functional programming as someone
mentioned, given that his "happy" function uses loop unnecessarily. Here's my
solution.

    
    
         (defn int-to-digits [n] 
           (map #(Character/getNumericValue %) (str n)))
    

(I had to Google Character/getNumericValue - doubt anyone expects you to
memorize that).

    
    
        (defn next-happy [n]
          (reduce + 
            (map #(* % %) (int-to-digits n))))
    
        (defn happy? [n] 
          (loop [n n seen #{}] 
            (if (contains? seen n)
              (== n 1)
              (recur (next-happy n) (conj seen n)))))
    

A lot simpler to reason about, even if the initial implementation did have
bugs.

~~~
dllthomas
_" really should've made smaller helper functions"_

I couldn't agree more. Especially when you're under pressure, bite off smaller
pieces. Not only is it possibly better practice in general, but in a time of
diminished cognitive capacity (such as when much of your bandwidth is being
eaten up wondering how you're coming off) they will be easier to get right,
and small successes will help ease your stress as much as they help solve the
problem.

------
bkcooper
I related to this a lot. Having somebody watching over my shoulder (especially
in a judgmental capacity) means that when I inevitably make some stupid minor
mistake, instead of just laughing it off as I normally would, I get anxious.
This then increases the chances that I will make another mistake, and so on.

------
nadaviv
CoffeeScript solution: (sorry, couldn't resist trying!)

    
    
        happy = (n) ->
          sum = 0
          while (sum += Math.pow n%10, 2 ; n = 0|n/10) then
          sum
        
        happyness = (n, s=[]) ->
          (n is 1) or (n not in s) and (happyness (happy n), [ s..., n ])
        
        console.log n for n in [1..100] when happyness n
    

Edit: and a JavaScript one:

    
    
        function happy(n) {
          for (var sum = 0; n; sum += Math.pow(n%10,2), n = 0|n/10);
          return sum
        }
    
        function happyness(n, s){
          s || (s=[])
          return n==1 || !~s.indexOf(n) && happyness(happy(n), s.concat(n))
        }
    

Edit 2: And the golf version:

    
    
        function h(n,s){for(s=0;n;s+=Math.pow(n%10,2),n=0|n/10);return s}
        function H(n,S){return n==1||!~(S=S||[]).indexOf(n)&&H(h(n),S.concat(n))}

------
detrino
I think the author may be missing the point of this exercise. Solving this
problem requires the following things:

1) Decompose a number into digits. Less experienced candidates will likely
convert the number into a string and then the characters back into numbers
while more experienced candidates will tend towards a small loop using div and
mod.

2) Use some kind of library to insert and test membership in a set data-
structure. Less experienced candidates may not be able to do this without
stackoverflow, big red flag.

3) Some basic flow control wrapping it all together. Less experienced
candidates may fail here similar to fizzbuzz.

The interviewer likely thinks these things are a good proxy for the quality of
a candidate. For example, the author would have failed #1 even without
miscommunication/stress/time constraints.

------
istvan__
An interview that forces you to do something that is otherwise not part of
your daily routine and measures how good you are based on that is bad. I
understand that you need to get insight into the skill of the candidate but
forcing her to work on an editor she does not know, giving limited time etc.
is probably not the best way to get that. I used to interview software
engineers for a big company and we usually gave them a problem that they could
solve in 48 hours using anything they want (internet, library etc.) and we
just asked them to explain their solution in person during the final round of
interviews. You are interested in how good the candidate is not how fast she
can fail a synthetic test that has nothing to do with the actual work you are
doing.

------
sopooneo
It's weird. I have the opposite experience. I do not have a CS degree. I do
not know formal algorithms or data structures. But I have technical aptitude
and significant _stage time_ , including in front of drunk audiences from
another life that didn't exactly lead to stardom. So I _enjoy_ technical
interviews because what limited knowledge I have is instantly accessible and I
thrive in front on an audience.

So it seems here is a an instance of where life was not fair... in my favor.
But now I'm in a position to hire other people. So I don't want to judge them
in the same way I was. I want to find out who's got the chops completely apart
from who can dance on cue.

------
personx
I don't fully understand the direction you were going with some of the
solutions, something like this would work no?

(defn digits [num] (let [ x (map str (str num)) s (map read-string x)] (apply
+ (map #(* % %) s))))

I do think the interviewer should have pointed you in the right direction or
offer some sort of hint to gain an understanding of how comfortable you are
with the language rather then just having you fumble around but depending on
the role they were hiring for these questions and this practice don't seem bad
to me

------
solve
Looks like more of an advertisement against Clojure than anything else.

~~~
Matthias247
At least like an advertisement against coding anything directly in a REPL.

Typing in an editor (probably with Send-to-repl functionality) would have
caught a lot of errors. But yes - doing it with a proper IDE or even a
statically typed language would really had helped to focus in the problem and
not on getting-it-to-run.

------
cxseven
Out of curiosity, what's the best solution to this? One thing I noticed is
that every loop will pass through an entry less than 100, so you only need to
remember the last 99 numbers below 100 when checking what's been seen-so-far.

You could also precalculate or cache the answer for 1 through 100 to save
rerun time.

But maybe a little bit more math would reveal much better optimizations.

------
PublicEnemy111
I once had to implement a simple API during an interview. I'd done it many
times, but the stress of having an interviewer breathing over my shoulder made
it a painful experience and I completely flopped. Not to mention there was
another interview trainee in the room.

I can write white board code with ease as those are almost always two way
conversations

------
MrGando
Hey man, I get terribly nervous too. I've gotten just a bit better with time,
if you ever want to talk about it let me know :)

Skype n_goles

------
benwaffle
In scala:

    
    
        def happy(n: Int) = n.toString.map(_.asDigit).map(Math.pow(_, 2)).sum.toInt
    
        def find_happiness(n: Int, seen: List[Int]): Boolean = {
            if (happy(n) == 1) true
            else if (seen.contains(happy(n))) false
            else find_happiness(happy(n), seen :+ happy(n))
        }
    

I think OP's answer is wrong

------
bra-ket
that's why the top topcoder coders use java under pressure

------
jiaweihli
Are there any good IDEs for Clojure? If so, most of the stumbling could have
been avoided. Coding without one tends to fall into the "ball-of-mud" problem
where wrong code is built on top of other wrong code. Or alternatively, is
there any way to continuously compile Clojure?

~~~
wging
Emacs is good for this. A buffer of clojure code in cider-mode can be
(re-)compiled easily when you're jacked into a running session (as he does
above).

Of course, some of the issues the author faced can't be solved by Clojure's
compilation step. When his code fails at runtime in the repl, it compiles
successfully.

------
sukilot
A lot of the trouble here comes from Clojure's cryptic function names and non-
static-typing making it hard to get work done. The only real mistake I see a
unprofessional choice of language. The mistakes and successful debugging are
totally fine.

------
sudeepj
I won't put a candidate in a situation which I myself won't want to be in.

While interviewing, I tell the candidate the problem and then leave the room.
He is alone and comfortable (I hope). I check back after 30 min. If not done I
still give him more time.

~~~
Decade
Pay me a fair wage for my trouble, especially if I succeed at the problem, and
maybe I'll feel a lot better about the coding exercise.

------
spion
What helped me I think was going to meetups at the local hackerspace and
preparing presentations involving live coding without previous preparation.

The cost of screwing up there is small and yet its excellent exercise in
coding in front of an audience.

------
blakecaldwell
Another idea, if you really hate the pressure of interviewing, is to ask for a
medium-sized project that you'd hand in the next day. That's more real-world
scenario, anyway. Try it - I've done this!

------
learnstats2
I find the % operator (div and mod) essential - and not only in interview
questions.

As far as this interview question is "Do you %?", I like it as a test. For the
rest, I feel sorry for the author. Good luck next time :)

------
gcb0
once i interviewed at a company because my current employer was under
aggressive take over from Microsoft.

in the interview i fluked a question about js scope because the whiteboard
handwrite of the interviewer made it hard to see which variable was i and
which was j... but after he explained why i got wrong and i realized the
letter mistake i was too stressed and dumbfounded to make a case, so i just
left.

6 mo later, my current employer is still independent while that company is now
owned by Microsoft...

------
nbevans
It's quite clear that a lot of your pain was caused by Clojure's type system.
Those exception messages are something you'd not expect in the 21st century.

------
metaphorm
Your code isn't embarrassing (its just rushed/nervous). Their interview
technique is embarrassing.

------
pete23
Euler addicts.

Although some function decomposition of the problem would have been nice to
see!

------
mikekchar
When we do coding at our interviews we do ping-pong pair programming. One of
the things we want to see is if the person can deal with actually doing TDD.
Usually there are 2 of us and one candidate. We explain the problem to the
candidate and ask, "Do you want to write the first test, or shall we?". We've
done the problem hundreds of times so we know a very, very simple first test
that will lead forward. This allows the candidate to "warm up" a bit before
they have to start thinking hard about the problem. Sometimes they hit the
ground running and are keen to write the first test, which is also fine.

The idea is that we switch back and forth. One of us writes a failing test,
then the candidate writes the production code. The candidate then writes the
next failing test and one of us writes the production code and the next
failing test. If the candidate gets stuck, we usually try to talk through the
situation and if they are _really_ stuck, one of us will offer to take over.

The candidate is allowed to look things up on the internet and even ask
questions. Often we will suggest things. For instance, after the candidate
writes some production code, we might say, "That works well. But how about
refactoring it using inject," for example.

I often use a pomodoro timer set to 20 minutes. We'll do as much as we can in
the first set. After that first set we'll ask the candidate how they think it
is going. We'll offer some advice about technique and such. If it was an
absolute disaster (happened a couple of times), we'll just leave it there and
thank the person for their time. Otherwise we'll ask if they are up for
another round. Usually the first set is pretty bad because the person may
never have done real TDD before, or may find the ping-pong awkward at first,
or may be very nervous. Talking about how they are feeling at the break
usually helps and the second set is much, much better.

After the second set we'll ask the candidate how they think they did. I think
this is important because if the candidate says, "It went really well" and it
was actually awful, then we have a pretty good idea of their skill level. If
they say, "I wasn't really happy with my performance, but I enjoyed the style
of programming", then we will have to take into consideration a variety of
different factors to see if we believe that the person can do better. If the
person says, "I really didn't like working that way", then we can rule them
out as a candidate regardless of their skill level (also happened a few times
unfortunately).

The feedback we've gotten from candidates on the process seems to indicate
that they really enjoy this interview style. I think it removes a lot of the
spotlight from the person and allows them to relax a bit. Especially having us
come in and help out in sticky situations allows the candidate to get over
stupid blind spots (like the converting between string and integer in the
article). So far, I think it has helped us spot potential in a few people that
I'm sure we would have overlooked using a more standard, "Here, solve this
problem" approach.

On the downside, there is still considerable room for improvement. Language
lawyers (know every detail about the programming language but are still poor
programmers) can often look very, very good in this kind of test. Similarly,
inexperienced but very talented people can often be frustratingly mediocre
because the unfamiliar method of development can hamper their style. You need
to be very aware of the amount that the person improves during the interview.

One final comment about this approach. We have occasionally been in a
situation where we said, "I'm not sure how good this person is. They seem like
their skills are fine, but whether they will be really excellent, I don't
know. However, it was _really_ fun programming with them." In those cases we
have hired the person and never regretted it.

------
fsk
Also, the interviewer didn't even know his own question.

As I understand it, you are taking the sequence

n -> (sum of the squares of the digits of n)

First, the sequence never diverges to infinity. For example, 9999999999 ->
9*81.

Second, not all numbers converge to 1. There is a stable cycle that does not
include one.

Consider

4 -> 16 -> 37 -> 56 -> 61 -> 37 -> ...

So, any positive integer either

1\. Converges to 1

2\. Converges to the stable cycle I just mentioned above.

So the interviewer should be fired for not understanding the question he was
asking.

~~~
6d0debc071
Interviewer said it would converge either to one or infinitely:

 _' The next sentence of English is where the problem started. I _thought_ he
said:

“The sequence will either go to one or to infinity.”

but he actually said:

“The sequence will either go to one or infinite_ly_.”'_ [My emphasis]

(Firing's also a bit harsh for getting an interview question wrong)

~~~
fsk
That also is incorrect - the sequence either converges to one or a stable
cycle - not infinitely.

That's also a horrible question for illustrating functional programming style.
It would be much more efficient to have a simple loop caching the array
n->f(n) and then finding the ones that converge to 1.

