
What not to do when giving technical interviews (2014) - andrelaszlo
http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews
======
gjm11
There is at least one serious misconception in this article.

> _The famous fizzbuzz test simply asks "are you aware of the modulo
> operator?"_

Nope. The famous fizzbuzz test simply asks "can you actually write code at
all?", because it turns out that some people applying for software development
jobs basically can't. Even people with relevant-looking experience on their
CV/resume. Even people who talk convincingly about what they've done.

(If you don't know about your preferred language's modulo operator but can do
truncating integer division, you can do FizzBuzz that way instead. If you
don't know how to do division, you can do it by having counters that count up
mod 3 and mod 5, or one counter that counts up mod 15, and you don't need
"mod" in your vocabulary to do any of that.)

Now, whether a candidate can write code -- like whether they know their
language's modulo operator -- is also just one bit of information, but it's a
_really important_ bit of information that turns out to be tricky to get. This
is also one reason for the "code on a whiteboard" tasks that many interviews
use, which the author also doesn't like.

It may be that those are bad ways to get that one bit of information. But the
author doesn't seem to appreciate what problem those things he criticizes are
trying to solve.

~~~
bitL
OK, I'll write your desired fizzbuzz in Haskell in a way that you won't be
able to understand it for the next 30 years. You'll moreover piss me off and
get a placement on my blacklist of companies to never work for and me actively
spreading the news about your interview to anyone capable I know, hoping
nobody is going to waste time interviewing for your jobs. Happy now?

~~~
AnimalMuppet
No, not happy now. Your technical skills may be off the charts, and your
criticism of fizzbuzz may be completely valid, but I don't want people with
that kind of attitude anywhere near my team.

There's going to be stuff that isn't done the way you want, in the company
policies, in the code base, in the architecture, in the way the team works. If
you're going to respond in an I'm-above-this, salt-the-earth kind of way when
that happens, then no, I don't want to hire you. Go destroy some other
workplace.

As I said, this is orthogonal to whether your criticism of the use of fizzbuzz
is valid. Your response may make you feel better, but it's showing me a lot
about who you are, and it's not improving your hireability.

If I were asked fizzbuzz in an interview, I think I'd say something like "I'll
answer that. But I expect the rest of the interview to be at a considerably
deeper level."

~~~
bitL
You are making amazingly far-reaching decisions from very limited information,
a quality I definitely wouldn't want to see in my superior. A dislike of a
certain test must mean "to destroy some workplace". I am now wondering if all
the issues we see with politics lately are happening because people are
becoming single-dimensional, unable to even consider someone else's view if
the way it's presented slightly deviates from what they demand.

As somebody who was often interviewing other people fighting for jobs at top
companies I worked for, I would never ever offend them by throwing FizzBuzz in
their faces; I don't have such arrogance in me. I would rather try to figure
out what clicks with them and throw them something tasty where they can show
off, then increase pressure to see what needs more work, then explain/discuss
what could have been improved. I would respect their time and help them to
learn something on that single interview they had with me. Never throw into
their faces that they are frauds which is implied by employing FizzBuzz. One
doesn't have to be a super psychologist, just simple empathy is sufficient to
understand that people perform best when they are respected and treated as
adults.

~~~
AnimalMuppet
In the great-grandparent, you said:

> > > You'll moreover piss me off and get a placement on my blacklist of
> companies to never work for and me actively spreading the news about your
> interview to anyone capable I know, hoping nobody is going to waste time
> interviewing for your jobs.

Now you say:

> A dislike of a certain test must mean "to destroy some workplace".

That was a bit more than "a dislike of a certain test". If we hired you and
you reacted that way to something you didn't like, that would be in "destroy
the workplace" territory.

~~~
bitL
You mean me employing colored words, even if they nowadays became pretty much
colloquial without harsh emotional content? In that case I apologize, though
at that moment when I was writing it I wanted to emphasize that I viewed this
whole FizzBuzz charade insulting, basically treating interviewees as frauds. I
think sometimes for the sake of proper behavior reinforcement the use of those
words is vital and they fulfill their proper linguistic function when needed,
otherwise they wouldn't have existed. They likely made you feel bad, which is
exactly what I wanted to achieve whenever anything about FizzBuzz is
mentioned; I hope this feeling stays with you and just for the sake of feeling
good you would avoid FizzBuzz from now onwards.

~~~
AnimalMuppet
Your words made me feel bad about _you_ , not about myself or even about
FizzBuzz. If your intent was to emotionally manipulate me into not using
FizzBuzz, you utterly failed.

~~~
cmonnow
I have interviewed candidates for Senior DBA positions who didn't know to
write a simple JOIN statement.

Reading this thread only solidifies my desire to ask for FizzBuzz, so that I
weed out 2 types of candidates :

\- those who are too bad for it

\- those who are too good for it

~~~
bitL
I was specifically addressing the FizzBuzz problem as stated in the original
article a few years ago, not some random sanity checks for some positions. If
you read that article and used it in interviews, you'd have demonstrated to me
your disregard of experience, your lack of inventiveness, laziness, and far
reaching arrogance, qualities I wouldn't want to see in my superior, so it's
obvious it'd be better to avoid each other and maybe meet only on the golf
course or as competitors/suppliers.

------
mnd999
I’ve recently learned via a few interviews at tech companies that interviewing
for tech companies is a completely different skill to working at one. I’m
sticking to contracting for now I guess.

~~~
skizm
Do you not have to go through the same interviews for contract work, assuming
you are programming?

~~~
mnd999
Usually it’s a lot more straightforward. Contracts can be terminated at very
short notice if you’re not delivering so it’s not usually worth spending a lot
of time interviewing.

------
tictacttoe
Anecdoctal, but while we are discussing narrow scope interviews... I just
finished a physics PhD and applied to a finance firm. Before I get a chance to
speak with a human, they send me a 15 problem 20 min timed exam. Some of the
questions were easy and some required thought, unless you’ve been sitting
around practicing riddles and LSAT questions all day. I timed out halfway
through the exam. It wasn’t even clear a priori how to navigate the exam, or
if I could skip questions or how I would be graded. The company effectively
canceled my application based on the 50% score.

Now, I’ve probably taken 100+ math exams in my life and I’d be happy to
provide data from any one of them. Why trump all that data with 15 questions?
Viewing the application process as a pure machine learning problem, their
decision seems crazy.

------
acjohnson55
Totally agree. I hadn't seen this article until now, and I'm thankful for it
because I think this is a message that needs repeating from many points of
view. Engineering hiring is a farce through much of the industry.

I've written two articles along these same lines:

[https://m.huffpost.com/us/entry/us_7973484](https://m.huffpost.com/us/entry/us_7973484)

[https://acjay.com/2019/05/16/hiring-developers-is-
easy/](https://acjay.com/2019/05/16/hiring-developers-is-easy/)

------
hahamrfunnyguy
I can't say I agree with everything here. I've found live coding to be a
useful way to gauge how someone thinks. Prior to the in-person interview, a
10-15 minute phone screen has already been done as well as a easy programming
problem that takes most senior developers 5-10 minutes to solve it. So when we
bring them in, we think they should be able to "pass" the interview.

When they arrive on site, we give them a 90% completed program that needs 2-3
lines of code to finish. We tell them they can use the web to look up anything
they need to. We're mainly looking to see how the candidate thinks, and we
discuss what they're doing and why. We're more concerned about the why than
the what.

Once this is done (about 15-20 minutes in), we have a reasonable understanding
if someone would be able to do the work. Next we try to figure out how much
they would need to learn to be productive, and try to see if the candidate
would be a good fit culturally.

We had one candidate who a minute or two into the live coding exercise said
"Geez, I really don't think I can do this." I reminded him we weren't looking
for a correct answer and to just give it a try, and he wouldn't. I thanked him
for his time and ended the interview.

~~~
cableshaft
If this (finishing a program missing only a few lines of code) were all most
coding interviews were, I don't think there'd be anywhere near as many
complaints about them. That's very similar to what you'd actually be doing on
the job.

It's coming up with what you took in your data structures/algorithms class a
decade ago on the spot and write full functions about them, especially on a
whiteboard, that gets really annoying, and makes programmers feel like they
have to refresh their knowledge of an entire class (plus a bunch of other
trivia from across CS) every time they want to find a new job.

------
JoshTriplett
I agree entirely with the premise of the article.

One nit, though:

> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"

FizzBuzz also tests basic programming skill, and it's surprising how often
people fail _that_ part. FizzBuzz isn't necessarily the best test of that; I
know one interviewer who instead uses "write a function to swap two numbers".
But _some_ test of basic programming skill does help, albeit it should happen
_long_ before the in-person interview.

~~~
logicallee
How would you swap two numbers?

~~~
pjc50
std::swap<>? CMPXCHG? LDREX/STREX?

The XOR trick is cute but you shouldn't use it on anything larger or more
modern than a Cortex-M0. Just put it through a temporary variable and let
register renaming deal with it.

(Perhaps a more interesting question would be a multi-threaded examination of
swapping two numbers...)

~~~
verall
It's interesting because this is a real answer that will get you hired. It
demonstrates knowledge of: the "correct" way to do it, basic asm awareness,
programmer culture, and computer architecture. This probably checks off like 6
boxes for most technical interviewers in one answer.

Finally it implies it could have asked a better interview question ;)

~~~
pjc50
Thankyou. I try to strike a balance with these things - showing off is
mandatory in interviews, but needs to be done politely. You don't want to go
full "Hexing the Technical Interview": [https://aphyr.com/posts/341-hexing-
the-technical-interview](https://aphyr.com/posts/341-hexing-the-technical-
interview)

------
Lendal
Sometimes I do have time constraints fixing a bug. In fact most of the time
that constraint is imposed by me, because I have pride in my work. But at the
same time I hope my manager understands that staring over my shoulder for 45
minutes doesn't help. Hopefully in my next interview I can get these ideas
across respectfully.

~~~
perl4ever
There are different levels of distraction. Staring over my shoulder is one.
Having a conversation with me about what I need to fix is another.

For some reason, I find it impossible to figure things out when I am looking
over someone _else 's_ shoulder, or in a meeting, but when I am seated at my
desk, it is vastly easier.

------
ddelt
Thank you for posting this. Not sure how many times these same points need to
be repeated for it to sink in.

~~~
andrelaszlo
You're welcome. I'm not sure either. I think my main take-away from this
article is that hiring is a human activity first and a technical one second.

There seems to be an attitude of "I had to go through this, so I don't see why
new hires shouldn't" hidden under a thin layer of justifications but in fact
we're playing a game with very limited information. We probably don't even
have the tools to know if we're doing good or bad hires except in extreme
cases. We almost certainly don't know if we're rejecting the wrong people.
Still we pretend like it's working.

To me, it seems overly rigid, pattern-matching against a too-narrow idea of
what a good developer/employee/team member is. So much could be improved by
just adding some flexibility, but maybe we're afraid of losing the illusion of
having a _Process_ and _Objective Criteria_.

Maybe I'm naive, but aren't we looking for what people are _good at_ and what
they might bring to the table? Maybe someone likes programming puzzles and
whiteboards, let them do it, but don't insist if it freaks another person out.
Maybe someone else would rather do a take-home assignment, but don't insist on
it if someone else don't have the will to do several hours of unpaid work.
Others might prefer pair-programming in person, technical quizzes, Codility-
style problem solving online, actual paid work on a project basis.

~~~
perl4ever
One self-defeating pattern is having different parts of the interview process
filter out different types of people, so that neither one can make it through
the whole process.

Sometimes (well, maybe even typically) the beginning and ending of an
application process are with different groups, and types, of people.

------
yoz-y
I agree that it is best to hire people that will evolve as that is the crucial
part of being a good engineer, but you still need people that know how to
start, your company is not a school. The problem FizzBuzz test is trying to
solve is not to find the good candidate, but to weed out the vast majority of
applicants that can't code at all.

Depending on where you put your job postings you can get really swamped by
them.

~~~
perl4ever
"to weed out the vast majority of applicants that can't code at all."

I think one ought to consider the possibility that if the vast majority of
interviewees can't code at all, there is something wrong with the
company/process. I mean, I'm not saying it necessarily follows, but the
question is worth considering.

I have never been asked to implement FizzBuzz, so I can't buy the claim that
"everybody does it".

Rightly or wrongly, if I was asked tomorrow, I wouldn't have the preconception
that it was appropriate or necessary, and thus wouldn't necessarily choose to
continue if I thought it was indicative of culture. If other people react
similarly, it doesn't necessarily matter if it _is_ a reasonable standard of
competence; you're still skewing the pool in other ways than you intend.

~~~
yoz-y
I think FizzBuzz is an example, when I was interviewing I mostly got questions
in this vein during first or second telephone screen (some companies use an
online multiplayer notepad or some other method).

When I was doing interviews I was always mostly discussing motivation. Most of
the time the hires turned out very good, but I did happen to have one bad one
and it cost us quite some time.

~~~
perl4ever
I have had the experience of doing well on the programming test at the
beginning of the process and being rejected for other reasons. Maybe counter-
intuitively, that made me less interested in doing such tests, since in that
case it wasn't determinative. It's possible that many or most places feel that
to ensure someone doesn't cheat on a take-home, they must demonstrate their
ability in the in-person interview. Which is logical, but it also makes me
think that going through a process starting with a take-home is a waste of my
time, as long as it's not a universal requirement.

~~~
yoz-y
What you describe is normal. Assignments usually go from easy to hard because
usually it is faster to solve the easy problems and usually these questions
can be also asked by less technical people. Several companies I have
interviewed with had the first programming questions asked by recruiters (who
clearly had CS background, but most probably just shifted careers)

~~~
perl4ever
What I'm talking about had a much more involved test than Fizzbuzz at the
beginning, IIRC something like 5 small projects, but with your choice of
language, and a generous amount of time (days). During the interview, it was
simpler, but in an environment I'd never used before and a language which I
had disclosed up front I didn't have recent experience in. It seemed like they
were only interested in hiring new college grads at the end, but perversely
the process started by senior people referring me and screening me. While I
admit it sounds like sour grapes, I thought later that the organization
probably had communication/coordination problems that would've made it
unpleasant to work for.

In some organizations, they start by recruiting people they think have talent
in general, and then the interview is about finding where you fit in.

In others, they have a very specific need and they focus on winnowing down the
pool to get the (hopefully) best person for it.

The place I'm talking about seemed to have a split personality.

Also, I've had enough interviews, both successful and unsuccessful, to be
clear that there is no "normal". Every place is unique, as was this.

------
collyw
"No Assholes policy"

The golden question being "who gets to decide who is an asshole"

Ironically a paragraph down they say:

"You are NOT hiring for "team fit""

~~~
fogetti
Right? It's the same age old question as "Whose code is the worst?" Not
surprisingly it's always someone else's code.

------
pjc50
As pointed out in the article, fizzbuzz doesn't test "can you code at all", it
tests "can you code under interview conditions, including highly unnatural
ones like on a whiteboard".

On the other hand, "hiring for future potential" sounds great but is _really_
vulnerable to personal bias since it's inherently about the unknown future. If
you want to run a deterministic interview process you need to have a standard
set of questions and a rubric for assessing answers, written up in advance.

~~~
taneq
If you can't write fizzbuzz in a few minutes on a whiteboard, even in
pseudocode, then you _can 't_ code.

~~~
mikelevins
I can't write fizzbuzz in a few minutes on a whiteboard under interview
conditions, but I've shipped multiple products over three decades. Several of
them are from 50% to 100% code written by me.

The syllogism you're proposing overlooks some human variables.

Interpersonal interaction tends to completely occupy my cognitive capacity,
the moreso if the other person is a stranger, or if they are challenging me in
some way (such as, for example, posing puzzles and evaluating the quality of
my answers). I can't think about logical operations under those conditions. I
require peace and detachment from human concerns in order to think that way.

This is, of course, a personal quirk, or, if you prefer, disability, and
nobody should have to bear the burden of it but me. But I've been an actual
10X programmer on a shipping product, as verified by DVCS statistics. I submit
that as evidence that I can, in fact, code. I just can't do it in interview
conditions.

I also can't navigate while interacting with someone. I can drive just fine; I
can operate a vehicle safely. I just can't _navigate_. Everyone in my close
family is aware of this limitation. When my daughter was a teenager, she
exploited this quirk for laughs. I have to admit, I thought it was pretty
funny, too. In particular, I remember a pause in a conversation where I looked
around and realized that I was parked at a Safeway in Capitola, California,
and had no idea how I got there. My daughter and I both laughed when I
realized what had happened.

But if you want me to drive, and you want to reach a specific, predictable
destination, you have to leave me alone to navigate.

Similarly, if you want me to be a 10X programmer, or indeed any kind of
working programmer, you have to leave me alone to do it.

Maybe I'm not the only one.

I won't argue that you should accommodate me, or people like me. Maybe you
don't need us. That's okay. I've found other ways to get by--being hired by
people already familiar with my other work, for example, or making my own
products. It's maybe a less predictable career path than the usual, but it's
worked so far.

But for obvious reasons, I can't agree with your claim.

~~~
taneq
There's always an exception that proves the rule. I'm sure, though, if you
could provide an explanation like this and then provide and walk them through
some already-written code examples, that would also be acceptable?

I'd take someone who says "I can't live-code while talking about it, but
here's an example of my code and I can explain how it works" over someone who
tries to BS me.

~~~
mikelevins
Yep, I can do what you suggest, and I've done it before. It can go a little
sideways, though, depending on the questions you ask. If your question
requires me to do what I can't do in an interview setting, then neither you
nor I will be happy with the result.

Don't get me wrong; you as an interviewer are not under any obligation to
adapt your hiring process to my quirks.

On the other hand, I'm not under any obligation to participate in a hiring
process I don't like, either. I stopped participating in hiring processes I
don't like around two decades ago, and I've survived anyway.

------
invalidOrTaken
I think next time I interview someone I'll ask them to fizzbuzz:

\- if they are confident and fail, I'll pass on them

\- if they are nervous and we'll fail, we'll talk about it, and move on with
the interview

\- if they succeed, I'll move on w/the interview

\- if they refuse, I'll hire them immediately and recommend them for promotion

------
sexyflanders
You lost me at Joel Spolsky.

Hosting a tech Q&A site doesn't make you the canonical source of how to
structure interviews.

The live coding interview style was a toxic and negative contribution to the
tech industry as a whole, IMO.

~~~
xtracto
Sorry, but I strongly disagree with you. Reading the cited book (Smart and
gets thing done) was an absolute eye opener for me, and for every person that
I have recommended it to.

Really, you should read it (unless you were only trolling). It is a very fast
read and full of insight.

Also, "tech Q&A site " is a huge mischaracterization of Joel's blog. He has
really insightful articles like "Evidence based Scheduling", or the ones about
(not) rewriting-code.

