
Bullshit Interviewers - jonthepirate
https://coderwall.com/p/yn9g2a
======
zainny
Just as with all the other such articles, there are probably going to be
comments on this one talking about how interviews like this are the exception.
That you just got crappy interviewers and as the article itself notes, you
probably didn't want to work there anywhere.

If you are the kind of person who would write this comment, stop now. The
truth is the _vast_ majority of technical interviews for developer positions
are conducted in this bullshit manner _today_. The only way to solve this is
to do what this article is doing and continue to draw attention to the fact
that the way people are hired for software developer positions is completely
and utterly broken. We need to make shitty technical interviews the exception,
not the norm.

I've been in interviews in the past where I've just wanted to scream at the
interviewer - Why, why aren't you asking about my portfolio? Look I've built
amazing things that people love. With my own hands. To a high quality. On
time. You can see and touch them. And it's exactly what you want me to do here
in this role. JUST LOOK.

 _Nope. Hey it would be great if you could please while standing on your head,
design a spice rack for a blind person (I 've seriously been asked this), with
one hand touching your nose. Oh and can you wear this red clown nose. This
shit's important._

~~~
michaelt
Would you say all data structures and complexity questions are bullshit?
Mrainteaser / estimation questions? Is all coding bullshit, or only on
whiteboards? Only coding algorithms from college? Is asking someone to code
'fizz buzz' bullshit? I'm interested to hear where you consider the boundaries
to lie.

Or have I misread your post, and you mean something else?

~~~
neumann
It depends on who you want to hire.

1\. Do you want a team member who can plan, investigate and research
unforeseen problems, brainstorm and contribute to the code? Then the one on
whiteboards is bullshit UNLESS it is a brainstorming question - with a laptop
next to it - and you are both working on the problem together - and ideally
neither of you know the answer.

2\. Or does you company have a clear knowledge of what lines of code are
needed to be written for the next 5 years. Then sure, go ahead and do the
whiteboard interview. Or just train a monkey, at least they are cute and
cheap.

A whiteboard interview typically just tests memory recall under a stressed
situation. It might be what you need if you require a hacker for a Die Hard
sequel where there is only 90seconds to figure out how to line up the
encrypted polycube nano-algorithm before nuclear meltdown is initiated. Or if
you require a monkey.

------
ngoel36
If I was giving that interview, I wouldn't give a shit if you found the
optimal solution or not. But if you could spend a high-energy hour with me
iterating over possible solutions, then that signals to me that you're smart,
have fortitude, and think outside the box. All qualities I would never hire a
candidate without.

At the end of the day, companies aren't looking for just PHP programmers or UI
designers. They're looking for problem solvers first. I've said this before in
other threads, but the fact that you cannot solve a given "puzzle" does not
mean that you're definitely a bad candidate, but the fact that you can sure as
hell signals that you might be a good one. And any company that's in-demand
can afford a few false negatives here and there.

A PHP programmer's ability to handle saving a company after being hit with a
SQL injection attack is surely going to be correlated with PHP coding tenure
and expertise. But that being held constant, it's absolutely going to be much
more heavily correlated with general problem solving ability, which - as much
as it sucks - tends to be correlated with ability to solve "bullshit interview
questions"...

~~~
seiji
_But if you could spend a high-energy hour with me iterating over possible
solutions, then that signals to me that you 're smart, have fortitude, and
think outside the box. All qualities I would never hire a candidate without._

Maybe that's the problem? If I'm in that situation, I get more annoyed than
excited about playing find-50-ways-to-solve-pedantic-imaginary-crap-from-
memory.

For me, it's instant deer in headlights because I'm uncomfortable making a lot
of dumb false starts that don't go anywhere then being judged negatively based
on the false starts you wouldn't see in a real world scenario anyway. (Some
interviewers understand draft-then-improve processes, others expect perfection
(and _fast_ perfection) out the gate.)

------
creature
The big problem with this approach (focusing on what a candidate's done
before) is that there's a surprising number of people out there with great CVs
who can't actually code. I've interviewed a number of people who looked
amazing on paper, and passed a phone screen¹. 7-10 years of experience.
Positions of responsibility. They knew how the internet works. They knew their
OOP. They could talk about how to troubleshoot performance problems. They
could explain MVC to a non-technical colleague.

But when it came to an in-person interview, they struggled with FizzBuzz. They
couldn't write the add() method for a linked list. Please understand: I want a
candidate to thrive in an interview. I don't say "Please write the add()
method for a linked list on the whiteboard," then sit back in silence with a
stony look. No: I ask them if they've heard of a linked list, then (regardless
of the answer) give them a refresher. I talk about what it is, and draw
diagrams of the data structure, and code an example of how it's used & a Node
struct they can use, and write a class skeleton for it. If they jump in then,
great. If not, I'll suggest they start with the empty list case, and keep
trying to be a friendly guide through the exercise. Even then, some candidates
can't do it. At all.

This isn't quite a bullshit brainteaser, but it's definitely not a real-world
problem. Nobody who got hired would be implementing their own collections. But
that's not what the question's about: it's about understanding how two simple
pieces of data interrelate, and being able to manipulate them. If a candidate
can't grasp that, then I'm not going to hire them no matter what their CV
says.

I don't think this is the best way of hiring people. I like the short term
contractor approach – candidates get a real-world project to complete that
should take 2-3 evenings, and their solutions are code reviewed & discussed.
But that's not always feasible for the business or the candidate. So I don't
think we'll see the death of this kind of interviewing for a while.

(¹ As a result of these experiences, my standard phone screen now contains
some basic programming.)

------
Matt_Mickiewicz
My experience at DeveloperAuction shows that _some_ companies actually view it
as a point of pride that they reject 19 out of 20 Engineers they interview and
that it's near-impossible to pass their rigours technical screening. It seems
almost seems like they are trying to "trick" people into failing by asking
obscure questions that have little relevance to the job at hand.

Of course, what they fail to account for, is the incredibly cost of hundreds
of hours spent talking to candidates & administering these silly challenges or
the fact that Google's interview data proves that such such logic questions
have little predictive value on future on-the-job performance.

I was actually really impressed recently by Stripe's technical interview
process - outlined on Quora: [http://www.quora.com/Stripe-company/What-is-the-
engineering-...](http://www.quora.com/Stripe-company/What-is-the-engineering-
interview-process-like-at-Stripe)

------
ern
The worst bullshit interview I experienced was one where I was asked all sorts
of questions about OO- design principles and concepts. I got the job, and was
very surprised that the system, written in an OO language, was in fact, almost
entirely procedural with large amounts of code duplication. I wrote a few code
generation templates to speed things up for myself, updated my résumé and left
after a few months.

Ironically, someone else who I knew, happened to interview for the same job,
and didn't know OO jargon as well as me, but was vastly more experienced and
very intelligent (he had math, not CS background). He would also have been a
great fit culturally and technically for the team, but was rejected.

I still haven't figured out if it was vanity, self-delusion or plain
dishonesty that led to those interview questions. But whatever led to that
interview format, it failed to choose the right candidate for the job.

------
justinhj
The article author comes across as bitter. He's clearly talented and
productive, but likely is not strong at the kind of skills you need to solve
puzzles in an interview setting.

A good interviewer will be able to spot that and evaluate his skills based on
his real experiences and previous successes.

That said, I don't think these kind of puzzles are that bad at evaluating what
it will be like to work with someone. If a problem comes up will they throw up
their hands and say I never thought I'd have to solve a problem like this?

------
web007
Because "Email us your answer to ZW5naW5lZXJpbmdAcm9ja3RoZXBvc3QuY29t" with no
context as to what that means - on a SQL problem - isn't bullshit?

~~~
localfugue
And "all horses run at constant pace"? People are reading too far along
skipping this thing - I mean, what's the point in finding the fastest one when
they all run at the same pace?

For context, here's the actual wording from the article:

    
    
      There are 25 horses and a single race track. The
       track has 5 lanes. Your job is to find the fastest 3 
       horses assuming you don't have a stopwatch and all 
       horses always run at a constant pace. What’s the 
       way to find the fastest 3 in the fewest uses of the 
       track.

~~~
dlgeek
That doesn't mean that all the horses run at the same speed - it just means
that an individual horse doesn't speed up or slow down while running - if its
average speed is 17.2 MPH, it runs at 17.2 MPH for the whole course.

~~~
localfugue
Yeah, I thought of that - but do people look at average speed when timing a
race? I was reading the whole sentence in "... you don't have a stopwatch and
all horses run at a constant pace." :-)

------
ballard
There's always a choice. Give feedback that you feel this is not the right way
to start off and that you hoped to work on solving a real problem. If this is
not going to happen, you feel it is a waste of both of your times to blindly
follow business theatrics that have been repeatedly proven to hold no value.

The other point is group dynamics do need some outlet for hazing to keep
things fun.

------
GuiA
>There are 25 horses and a single race track. The track has 5 lanes. Your job
is to find the fastest 3 horses assuming you don't have a stopwatch and all
horses always run at a constant pace. What’s the way to find the fastest 3 in
the fewest uses of the track.

It's not specified that one lane = one horse, so... release all horses at
once, pick the top 3 :)

~~~
ibudiallo
Wait to see which 3 finish the race first.

------
dougabug
Pretty easy puzzle, if they were looking to hire a puzzle solver instead of
say a PHP programmer. Some people hang their intellectual self esteem hat on
simple trick logic puzzles, a skill which doesn't require a great deal of
intelligence, so much as time and willingness to practice puzzles.

~~~
marcosdumay
That question is equivalent to "describe an optimum ordering algorithm".
What's so wrong with it?

~~~
dougabug
It's not an optimum ordering algorithm, it's a top-k problem. The overall
order is not requisite, nor is the order of the top-k elements. The problem is
that it provides no useful insight into whether the candidate will be a
capable PHP programmer. The most productive, capable PHP developers I've
worked with would not likely fair well on this kind of question, while some of
the most useless, hapless programmers I've known live for this kind of
question. I agree with the sentiment that these kinds of questions are largely
asked to make the interviewer feel smart.

------
general_failure
Heh, I was asked the same horse question for a linux driver development
position.

