
F*** You, I Quit – Hiring Is Broken - lolptdr
https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-broken-bb8f3a48d324#.2hi5s1kd9
======
dang
Comments moved to
[https://news.ycombinator.com/item?id=11579757](https://news.ycombinator.com/item?id=11579757).

~~~
mixmastamyk
Hmm, I think the title change loses the feeling of frustration.

~~~
dang
It does do that, but long experience has taught us that HN is better when
titles don't vent feelings of frustration.

That doesn't mean that we don't share the feeling. I've felt the same way
about tech job interviews for years, and one of my life goals is never to
endure one again, at either end.

------
Gratsby
Software developers are not dancing monkeys and should not be treated as such.

Do software sales reps get told to "sell me this shampoo" during an interview?
Do they have to whiteboard the structure of an e-mail campaign? No. Because
it's no indication of whether or not they can identify and build a
relationship with a person at an enterprise that has purchasing power.

If you are putting someone through a coding exercise, it should be simply to
query the basics - does this person write readable code. Does this person make
comments or use logging?

Anything beyond that and you are looking for good candidates to fail,
especially if you are trying to make them do it on the spot in front of an
audience.

"Read this file, reverse the strings, and output the results to another file"
\- people can go months without reading/writing files in a given language and
how many times in your professional life did you ever have to reverse a
string?

"Explain the difference between a quick sort and a merge sort?" Who cares
except when you are reviewing existing code and you look it up to see if
there's an optimization to be made for your particular use case?

Being a good software developer takes a lot more than can be determined from a
white boarding or code writing exercise. It takes good critical thinking. It
takes the ability to work on a detail item while maintaining a view of the big
picture pragmatically. It takes the ability to teach and communicate across
technical boundaries. It takes the ability to identify, estimate LOE of, and
prioritize tasks. It takes so much more than you can glean from an exercise
flawed at the outset.

Look at the code bases for just about any existing software project public or
private and you'll see code that was written by someone who would have done
things differently if given a chance. Even when given autonomy over a project
and an endless timeline we don't do things perfectly. Why should anybody be
expected to write something perfect during an interview?

Developer interviews should be friendly and curious. You have to get along
with the new hire, and that developer will have to succeed in your
environment. Find the best person who meets those two basic requirements and
who knows about the specific area where your existing shortcomings are, and
you have a winner.

~~~
sghi
I do agree with you on all the rest of the points, but just to say I started
out in software and IT sales (but now much happier in a very different field)
and I have absolutely been asked to both sell interviewers pens and random
products and to have lots of imaginary phone conversations.

Funnily enough, anywhere that asked me to do that turned out to be a pretty
rubbish place to work...

------
bradp
Previous discussion is here:
[https://news.ycombinator.com/item?id=11579757](https://news.ycombinator.com/item?id=11579757)

------
shoyer
BFS may not feel very relevant for front end development, but second time the
author encountered it in an interview should have been a clue that it's worth
learning.

The world is full of not-entirely-relevant systems that you need to master to
succeed. Tech interviewing is just another one of them. The good news is that
once you know what they're looking for (and yes, there are books) it can be
studied in a straightforward way.

Think of it as a standardized test, with all the associated virtues
(consistency) and faults (dehumanization).

~~~
pmiller2
> Think of it as a standardized test, with all the associated virtues
> (consistency) and faults (dehumanization).

Except that it's not standardized _at all_.

~~~
shoyer
Obviously, your mileage may vary. But at least at large companies (e.g.,
Google) the CS fundamentals you need to know to pass a coding interview are
indeed pretty standard, and well described in books such as "Cracking the
Coding Interview".

BFS is absolutely on that list. Yes, I had to relearn it in preparation for my
Google interview, but it was something I was ready for when it came up. And I
would claim I'm a better software engineer for it -- graph search and data
structures are topics that come up in lots of different contexts and for which
understanding the basics can indeed make a big impact on your code.

The list of these fundamentals is not that long, and the fact that it exists
is a big part of the reason why coding bootcamps have been so successful.

------
samfisher83
So we have all these posts saying how it is so hard to find developers, and
half the posts saying hiring is broken.

Maybe the best time to do one of these interviews is right after taking your
algorithms final. I think I got 120 on that thing, but I would have a hard
time recalling what BFS and DFS did without reviewing it.

~~~
pklausler
Seriously? You can't figure out what Depth-First Search and Breadth-First
Search do just from hearing their _names_?

~~~
pklausler
You're given a starting node in a linked data structure and you want to visit,
collect, or search all of the nodes that it can reach, and do so without
duplication. If you can solve that problem correctly, you've just used or re-
invented one of DFS or BFS, and could come up with the other one after a
moment of thought about the order in which you visit the nodes. These are not
magic spells that you have to go to Hogwarts to memorize; they're the two
obvious approaches to solving a really straight-forward problem statement.

------
patrick_99
I understand the author's frustration but this sounds like sour grapes. Sure,
the interview questions that Google, Facebook, Amazon, Microsoft and pretty
much every big tech company asks are hard and abstract. But it shouldn't be a
surprise. As the author mentions, there's numerous books on programming
interview questions. Every software engineer I know will spend a lot of time
studying common interview questions like maze solving before interviewing for
jobs.

You can argue the process is flawed, but what's the point of applying to these
jobs without preparing and just hoping you would get a different outcome? The
flip side is that these hard interviews makes programmers that can pass them
scarce, which drives up salaries.

------
good_sir_ant
I dunno... it's frustrating, but really, you can learn some valuable stuff
during those few hours.

I have had some interviews that certainly haven't been positive, but they have
been instructive or rewarding in some way. Not necessarily even relating to
code. It teaches you something about them, the industry, and more importantly,
about yourself.

------
ask5
the interviewers (software engineers) just make sure that relevant people
don't get hired. It's just a job security gimmick I guess.

------
pklausler
Hiring is broken? The hiring process seems to have worked successfully in this
case by preventing a bunch of companies from getting into a bad match.

------
known
Tell the Interviewer

Quiz != Interview

