
This is why you never end up hiring good developers - jpkenobi
http://qz.com/258066/this-is-why-you-dont-hire-good-developers/
======
zxcvgm
If you found this article familiar, that's because the same article was posted
here 3 days ago.

Previous link:
[http://seldo.com/weblog/2014/08/26/you_suck_at_technical_int...](http://seldo.com/weblog/2014/08/26/you_suck_at_technical_interviews)

Previous discussion:
[https://news.ycombinator.com/item?id=8232746](https://news.ycombinator.com/item?id=8232746)

~~~
cranium
I thought so. At least it's claimed by the same author.

~~~
nawitus
I've also noticed that the title has been changed _twice_. First it was "You
suck at technical interviews", then it was changed to "People suck at
technical interviews", then to "This is why you never end up hiring good
developers".

------
fennecfoxen
Fizzbizz? Naah. What you want to do is something more like Minesweep. You go,
"Mr. or Mrs. Candidate-Person, we're designing a Minesweep game. You've
probably played it before. Here are the rules if you need clarifications. I'm
handling the front-end, you write something for the backend."

It doesn't matter the programming language they go for or the precise
implementation they choose to any one of a number of issues. The question is
whether they can build something coherent that actually does what they intend
it to. There are basically two main types of candidates: the candidate who
approaches the problem and says "I need to loop over every cell in sequence
and assign a mine or not based on a random probability! Wait, what do you
mean, I need to get a specific number of mines on the board? I'm not sure I
can make that happen" ... and the candidate who's worth hiring.

That said, I have seen interviewers use this premise to try and push for one
particular algorithm as The Answer (the one where you shuffle the coordinates
and take N) under the premise that "pick random coordinates, check, and retry"
could be slower on ultra-dense gameboards -- but hey, dude, nobody plays
99%-full minesweeps because they're not fun. Meh.

~~~
parennoob
"There are basically two main types of candidates: the candidate who
approaches the problem and says "I need to loop over every cell in sequence
and assign a mine or not based on a random probability! Wait, what do you
mean, I need to get a specific number of mines on the board? I'm not sure I
can make that happen" ... and the candidate who's worth hiring."

Since this interviewer seems to have made up their mind already with pre-
conceptions of which candidate is worth hiring, what is the "correct" answer
to this question? "Pick random co-ordinates, check, and retry?". I'd like to
know, so I can give that as my first answer if I come up before such a person
in the interview.

This right here is why everyone tries to game the system and come out with the
"worth hiring" answer as if they had thought it out themselves. We are not
even given an opportunity to ask questions, maybe come up with an answer, say
"That's not optimal", and work towards a good answer -- which is the flow you
would use for working at your day-to-day job. And, for the record, I started
playing Minesweeper last year, and hadn't even touched it back in the day.

~~~
fennecfoxen
Any answer that gets the job done works. Looping through the mines in one pass
with appropriate adjustment of probability (never seen it). Pick random spot
and retry. Take all coordinates, shuffle, take N. Something I've never heard
of? Sure, if you apply it and it works.

The preconception is that someone who isn't capable of coming up with a way to
distributing X values into a data structure representing a M*N playing field
isn't worth hiring. It's a stupidly simple task, light on the algorithms (much
like the day-to-day programming tasks) and heavier on the "come up with
something coherent and quasi-organized to accomplish a very simple goal" in a
program.

As for the rules of Minesweeper, if you're rusty, I have a printout. :b

------
sAuronas
Funny because companies are still doing these things: just been asked to
fizz/buzz...code with someone watching my screen, etc (as someone who was told
he was inferior to whites by a HS teacher before a test, the anxiety is
terrifying). Another (YC) company did the "culture" thing to me - I believe -
because they just stopped calling me after telling me I would be moving on the
"the lunch with the team" interview. Didn't return my emails either... This
might be 2014 but it still strikes me as lacking taste to use the words
"culture" and "fit" to a minority [sic] candidate.

------
johan_larson
Hiring the right people is a hard problem. The standard approaches, hiring
software developers on the basis of code scribbled on white-boards or a series
of narrow technical questions, are bad. Instead, I favor three different
approaches, depending on the level of the position:

We should hire new grads based on internship performance.

We should hire senior developers based of their records of design,
implementation, and leadership.

We should hire mid-tier developers based on code review, typically based on
open-source code.

More here: [http://short-sharp.blogspot.ca/2013/04/stop-white-board-
codi...](http://short-sharp.blogspot.ca/2013/04/stop-white-board-coding.html)

~~~
fnbr
How do you hire interns?

~~~
johan_larson
Code review, if possible. Students of computer science write a lot of code for
assignments and projects; I want to see some of it. Obviously, it makes sense
to judge the students more leniently than I would judge finished
professionals. Grades in relevant courses are also a useful signal.

If a student insists that he has no code suitable for review, fall back to
coding problems, since coding under unrealistic conditions is better than no
coding at all. But in such cases I have to wonder what the heck the student
has been submitting for assignments and projects, so that's definitely a
minus.

~~~
forsaken
A reminder not to refer to programmers as "he" by default. A bit more here:
[http://alexgaynor.net/2013/nov/30/gender-neutral-language-
fa...](http://alexgaynor.net/2013/nov/30/gender-neutral-language-faq/)

------
Thiz
I can't answer a single question in an interview without getting sweatily
nervous. I suffer from telephobia so I screw dearly all phone interviews. I
dress awkwardly and they know it, having to shave for the interview is a total
emotional pain. I can't code without having google always open in a tab. So
why should I go to an interview that doesn't allow me to google the answers?

~~~
powertower
Next time, set a mind-frame of doing the interview for the experience of the
moment, to realize that it's okay - that the universe is still here and
nothing has changed, rather than for getting the job.

As a matter of the course, know full well that you are not getting the job.
Even if you don't fumble it, know that you'll refuse their offer.

 _The point is that interview does not matter at all to you._

Go in fully knowing that you are not seeking anything, nor trying to prove
anything, nor trying to make some statement about it all. Put this all in your
mind, and everything else out.

If done and practiced, this should take you out of your obsessive
introspective... To the point of laughing about it all when you walk out -
after not being able to answer a single question because it was all over your
head and experience level!

Later on, you'll be able to go even further by putting yourself into a buyers
inner perceptive (you're shopping for the right employer), rather than a
sellers inner perspective (you're selling yourself to an employer).

* As always, this is easier said than done, and will require at least a few minutes of meditation every day.

~~~
fillskills
My uncle once told me something that has helped me be way less nervous at
interviews. He said "Don't go in thinking you need them, go in the interview
thinking they need you". Just before an interview I repeat this sentence once,
seems to take pressure off my chest.

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

False.

The fizzbuzz test asks, "Can you algorithmically about a problem? Can you
understand variables? _Can you program?_ " And it's the quickest, simplest way
to find out.

How do you separate the people who "can do this job" from those who "can talk
about doing this job"? There are many more of the latter than you may think.

~~~
Dolimiter
fizzbuzz is very useful as a pre-interview screening technique. But as the
author says, it's 20 minutes of wasted time in an actual interview.

------
andy_ppp
Okay so the article is fairly standard stuff if you've read the Joel essays.

When I interview now I get the candidate to break down a problem with me and
answer it in sudo code. I'll ask questions and guide the candidate about how
it could be done better, asking if there are there any edge cases we have
missed and generally just build something out (a plan if you like).

The best candidates tell you you are wrong (politely) and come up with a
better way of building whatever it is that you've tasked them (I expect the
people I hire to be a lot better than me!). You also have a vague idea of what
it would be like to work with them. Weak candidates (even after you explain to
them) just do not get that it's a discussion and don't ask questions or for
help, they just get frustrated.

Use of the Internet is fine and you'll soon see if you can work with their
brain or not.

~~~
pyre
> sudo code

Hopefully this is for a security-related position! ;-)

~~~
andy_ppp
Haha :-D

~~~
BerislavLopac
What is "sudo code" actually?

~~~
forsaken
"psuedo"

~~~
jnbiche
Ach.. "Pseudo"!

------
frostmatthew
As someone who recently interviewed at a number of Boston area tech companies
I disagree with #2 from a candidate's perspective. I agree that interview
coding is "far removed from the real practice of writing code" \- but that's
okay.

If done correctly it can give the interviewer insight into the applicant's
thought process - and for the applicant it can be one of the best filters for
who you would actually want to work for.

Companies/interviewers that asked very specific questions that tested only my
memorization of a particular language's syntax were a huge turnoff. More open-
ended ones along the line of "how would you solve this problem" and allowed me
to whiteboard in the language of my choice and/or psuedocode made the company
much more attractive.

------
oretoz
There are so many different approaches to interviewing that come in and out
fashion every few years. This is only natural but the common theme in a lot of
discussions on HN is how people feel these approaches were not good for their
particular case.

Wouldn't it be better if flip the whole thing and ask the candidates under
what situation would they feel most comfortable and then conduct the interview
that way? Surely, we want to get the best out of people while making them
comfortable?

Yes, even this approach is not suitable for those interviewees who don't know
what is the best for them but atleast the interviewer will show they they
genuinely care.

------
AndrewKemendo
My approach is basically a mix between a conversation and a mini-work
experience.

At any point we have dozens of problems we need fixed or new features
implemented. So after some pleasantries the question is, so we have X problem
how would you go about fixing it? We want to implement Y feature, where would
you look for implementations we can integrate or would you build from scratch
and why?

etc...

I also have people play this game and see how they work through the
challenges:

[http://armorgames.com/play/4309/this-is-the-only-
level](http://armorgames.com/play/4309/this-is-the-only-level)

------
pan69
Most often people like to hire people who are like themselves. If the
interviewer has a fancy degree then he/she will be looking for someone else
with a fancy degree. If the interview is self-made then he/she will be be
looking for self-made.

There is a certain level of experience and insight required to rise above this
as an interviewer. Having a good understanding of the direction of the company
and the actual skills you're looking for. I've only seen a few people who
actually got this but most of them were looking for clones.

------
deedubaya
Interview questions often have less to do with the candidate than they have to
do with the interviewer.

Meaning: It's either a superiority thing, a desire to impress, or just plainly
covering up for lack of real interview skills.

Gauge a candidate's skill set by asking open ended general overview questions
like "Tell me about SCM branching and what advantages they provide" or "Tell
me about a time you might have encountered a race condition". What the answer
is isn't nearly as important as _how_ they answer it.

~~~
sethammons
I've interviewed candidates who can talk an amazing game but can't seem to
code. Starting a couple of years ago at our organization, it has been required
that candidates produce _something_ that can run (or come real close to it).

~~~
bartonfink
I had a friend blow a job interview on something very similar. The company
gave a description of an app and asked that he code something up over the
weekend and host it on github for them to see. He wrote up a pretty basic app
that did what they wanted, but the poor guy completely lost his head and
couldn't remember `git init`, so they passed. Whether that's fair or not is
another ? (I think it was, given he was interviewing for a senior role), but
it's important to keep in mind that even though you may have been a productive
maintenance engineer, working within an established codebase, basic
infrastructure-level stuff that comes up once a project can still bite you.

------
thegenius
In the best interview I had, the interviewer started by saying, "Just talk"
with a friendly smile. I was taken aback, and it eased the tension I was
feeling. I started talking about my experience, and he took an active interest
and branched off his questions based on the things I had done. He asked
intelligent questions that made _his_ compentency clear. I was able to volly
back and forth with him until my competency became clear to him.

Don't grill people with a technical interview about things you care about.
Have a technical conversation and try to find common interests. You get to
witness the interviewee's chops, see if they're an asshole, and prove that
you're not one all at the same time.

~~~
grimman
That might work for you, which is great when it happens, but I personally
can't do that... I can't just sit and talk.

~~~
coldtea
Why, what's the problem?

~~~
nitrogen
I'm not the OP, but I'd guess that they might need some starting point, a seed
crystal, before they can crystallize them into a conversation.

To the OP, I would suggest using the context of the interview to start (e.g. I
am here because....).

~~~
nthj
“Tell me about the coolest thing you ever built.”

