
Why you should refuse to participate in coding interviews - rmason
https://www.quora.com/Im-a-software-engineer-with-20-years-experience-but-I-cant-think-fast-enough-in-coding-interview-What-should-I-do/answer/Sean-Corfield?srid=4in&amp;share=1
======
steego
I give coding interviews and I try to take the original concern (Questioner
can't think fast enough or freezes) into account, but I can't really say with
any certainty if I'm successful or not.

About 10 years ago, I gave a woman a coding interview question and her hands
were literally shaking. She got through it, but I felt terrible because
clearly she was the type of person who gets really nervous when under that
type of pressure. She was very experienced and my discussions with her really
seemed to indicate she learns quickly and would probably be a decent fit. The
only reason we didn't hire her was I found another woman who was a better fit.

Since then, I've tried a lot of things. Lately, I've been putting the emphasis
that we allocate some time to pair program. We simply get in a room to make
something together and we may take turns with the keyboard. I actually go out
of my way to tell people this is not a coding test, but rather a play date. I
emphasize I don't expect them to know everything and I even half-joke I deduct
points for not asking questions.

Some people have told me they really like this approach, the others haven't
commented one way or the other, but I'm still skeptical about my method. Most
seem to relax well enough, but there are always people who may be more than
competent who simply don't manage to relax in a realtime environment.

Some people work like tortoises. They may appear slow, but the culminated
effect of their very deliberate and careful decisions accumulates far better
than a hare. I'm pretty sure my current process doesn't work in their favor,
but I'm at a loss for better alternatives at this time.

I'd love to know what HN readers think. Do your interview processes penalize
tortoises or other people who don't simply fit a mold? Do you have a good
system that takes into account the diversity of people's talents?

~~~
ryandvm
I think the test that is the least stressful as well as most closely simulates
the work they'll actually be doing is to give interviewees some "homework"
that they should be able to knock out in a few hours before their interview.
Maybe write a few API endpoints or whatever.

This allows them to tackle the exercise at their own pace and do it at a level
of quality that they're comfortable with.

If you're concerned they'll cheat and have their friends do it for them - you
needn't be. As long as the interviewer is knowledgeable enough to ask good
questions (e.g. "Why did you use that auth strategy?" or "What performance
problems do you anticipate?") you'll quickly be able to tell if they fully
understand the problem space. That's a much more useful test than asking
someone to implement a red/black tree.

~~~
CodeWriter23
I would reject that as well, it indicates the company thinks nothing of giving
me a half day of work to do for free.

~~~
ryandvm
Oh I don't think it should be free. They should definitely compensate you at a
reasonable market rate for a couple hours of effort.

------
g9yuayon
Coding interviews make sense for great companies like FB and Google. Such
companies receive probably tens of thousands of applications every week, and
all the candidates who can get an onsite interview have impressive resumes.
How do they pick the best and brightest from the best and brightest? Code
interview at least sets a higher bar for minimum requirements for two types of
candidates: \- If a candidate is a genius, the candidate can solve those
interview questions easily \- If a candidate is not a genius but is truly
passionate about CS, the candidate should have read or practiced enough to
solve the interview questions too.

Either way, the candidates who pass coding interviews meet the minimum hiring
bar.

And don't forget the historical context when Microsoft popularized brain
teasers and algorithmic puzzles in its haydays. In the 80s and 90s, there were
few interview prep books. There was no leetcode or any other pre site. Those
so called teasers are cleverly disguised math puzzles. Remember the questions
about pirates dividing up gold coins? Classic math problem. Remember the one
that asks how many unfaithful husbands there are in an island? Putnam question
solvable by mathematical induction. Similarly, the so-called algorithmic
puzzles came from classic CS books or from real projects. Those who can solve
the puzzles are either super smart or super geeky. Either way, they were
likely to be great hires for Microsoft.

------
marssaxman
I really don't understand where this meme has come from. How else are you
supposed to assess a candidate's ability to do the job, if not to pose them a
problem and watch them work?

~~~
mathgeek
> How else are you supposed to assess a candidate's ability to do the job, if
> not to pose them a problem and watch them work?

Unless the job is responding to problems and being watched while you work, the
argument here is that you're not actually assessing anything that's very
useful.

Most engineers/developers, for example, spend a lot of time thinking about a
problem or trying out their ideas (many of which quickly get thrown out). If
you do this in most programming interviews, you're going to fail them.

------
davidbanham
I think the answer to this problem is take-home coding tests. They do the best
job of simulating actual working conditions and minimising associated stress
and anxiety. I've had this confirmed by multiple candidates I've used this
approach with.

I'm actually launching a product to streamline the process if anyone is
interested.

[https://takehome.io](https://takehome.io)

~~~
geebee
Do read this bit about take home tests, though.

[http://www.gayle.com/blog/2013/09/18/companies-who-give-
cand...](http://www.gayle.com/blog/2013/09/18/companies-who-give-candidates-
homework-assignments-knock-it-off)

No real need for me to summarize it, it's all pretty well expressed in this
blog post.

~~~
davidbanham
That's exactly why I set a hard, verifiable time limit on my exercises. A few
hours is vastly too long. I limit mine to 20-40 minutes.

------
aanm1988
> The big companies that use them have started to finally admit this

I didn't get as much whiteboard coding as I thought in my recent interview
with a big company. Last 2 actually.

But of course facebook and google was still all coding. Google is still
obsessed with their overwrought process, and still try to sell a poor false
positive rate as a feature.

I still haven't really heard a better idea. Some of them sound incredibly
hostile to the applicant (e.g. lets try it for X days). Do this work, bring it
in and discuss is a pretty decent idea.

I'd like to see more of "here's what we want, lets code it on this computer
however you want.". Lets talk about while we work.

or just talk about what you have done.

------
qudat
I think blanket statements aren't going to work in a diverse field such as
software development. Certain jobs require strict skills and those skills need
to be measured by all potential employees.

On my team we aren't doing anything particularly crazy beyond a large crud
application. We feel confident enough in our development process that we can
hire interns and make them productive. We are more interested in knowing they
want to learn and are able to learn our application. Culture fitnisnlore
important to us.

As a result, having a conversation with the applicants is much more valuable
than a coding challenge. It works for us.

------
jstewartmobile
My experience is that knowing who's a good programmer is like knowing what's
art: you know one when you see one. That's why I don't get the coding
interview.

Just an everyday conversation with a coder will give you a better idea whether
he's any good or not, and it will do this without stressing him out or
impugning his integrity (which is exactly what you're doing when you ask
someone a bunch of trick questions on a subject they've already claimed expert
knowledge on in their resume).

~~~
steego
I'm skeptical.

There's always a set of programmers who sound erudite because they are
erudite. It's typically not that easy to fake being erudite, so it naturally
follows that programmers who sound and behave like they're competent are
usually competent.

A simple strategy would to always select from that pool. It might even be a
relatively optimal strategy too if you account the time and effort to
interview people.

However, my experience has show me that assumption has been wrong on a number
of occasions. People have both surprised me and disappointed me. I wish I
could say it's been the rare case, but it's happened a lot more than I would
have liked.

I've considered I'm not the best judge of people, but I can't help but notice
a lot of my colleagues aren't the best either. Some are and I envy their
talents to notice some set of heuristics I haven't picked up yet.

~~~
koverstreet
It's not about being erudite, or knowing lots of things.

What you pick up on when you're having a conversation with another programmer
about writing code is whether or not they give a crap about their craft and
doing it well, and what kinds of things they think about and worry about in
their code and the code they work with.

The really good programmers are the ones who want to make the world of
software a better place, without concern for ego or who wrote what.

~~~
jstewartmobile
Thank you koverstreet for putting it into words better than I could.

------
nunez
I don't know how else one can prove that they can code without having _some_
kind of a coding exercise during the interview. It doesn't have to be trivia-
without-the-beer coding hour; it could be pair programming, a take-home, etc.
But not coding at all? Doesn't make sense.

------
jkchu
While I fully agree with the author that coding interview questions are not
great, I think something important to keep in mind is that "fixing"
programming interviews it is an incredibly difficult problem to solve.

I think the best way to gauge a candidates programming ability is to work on a
small project with them, similar to Automattic's approach [1]. Unfortunately,
this method is extremely expensive, to both the candidate and the company.

Maybe company's are "lazy" for sticking with archaic methods that are not
always fair to the candidate, but when the author claims that companies are
simply "too lazy to figure out how to interview people effectively", I feel he
is trivializing a very difficult problem to solve.

[1]: [http://davemart.in/remote-hiring/](http://davemart.in/remote-hiring/)

~~~
RandomOpinion
I think there's a business opportunity here. Imagine something like ETS's
system for administering the GRE: Come into a location in your city at a
particular date/time, sit down at a computer pre-loaded with various editors /
IDEs for common languages, and run through an 4-hour coding exercise specified
by the hiring organization, and, at the end, your code is provided to the
hiring organization for examination. Internet access is freely permitted but
it is fully logged and reviewable by the hiring organization. A proctor is
present to keep an eye out for cheating and to resolve any technical
difficulties. This reduces the pressure to something not much higher than
working in a regular office.

Bear in mind that this is for the coding part, which people seem to have the
most difficulty doing on a whiteboard under pressure. There would still need
to be a conventional behavioral interview as well.

Somebody want to run the idea past YC? ;)

~~~
caleblloyd
Honestly this sounds terrible. I would never take a proctored test for an
interview. Might as well just send the company a copy of your grades from some
computer tech class in school, because that is basically what you're
proposing.

I will happily spend a few hours preparing an open source project and
presenting what I've created as part of a final interview.

Relying on testing alone is going to get you good test takers. A great team
needs a mix of of skills- technical experts, business minded folks, and
motivated leaders. I don't have the magic answer but I'm sure that proctored
testing is the wrong answer.

~~~
RandomOpinion
> _I would never take a proctored test for an interview. ... Relying on
> testing alone is going to get you good test takers._

A conventional interview is basically a set of tests already. A conventional
whiteboard coding interview segment is a proctored test, with the interviewer
serving double duty as the proctor.

This proposal aims to reduce the stress by having an impartial proctor instead
of an interviewer looking over one's shoulder as you code.

------
TP4Cornholio
I think take home tests are the best way to go.

