
Hiring Is Broken – My interview experience in the tech industry - sahat
https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-broken-bb8f3a48d324#.yankhfx9h
======
sagichmal
Hiring isn't broken, dude. You just don't interview well, and you seem
antagonistic even to the idea that your cachet and skills, insofar as they
exist, aren't useful to the market. That's a problem -- for you.

Interviews exist because employers need a way to quantify and qualify your
ability. Typical computer science problems are a (flawed, but concrete) way of
doing that. No reasonable interviewer expects you to recollect breadth-first
search flawlessly, on demand, onto a whiteboard. But they do expect you to be
able to reason from a problem statement to something approximating a solution.
That's fundamentally what programmers _do_. You should have the chops to think
in this way, and you should be eager to try. Emoting "what the fuck?!" and
claiming you can't, or won't, because you're not a recent graduate is an
excuse and a cop-out.

A few popular open-source projects don't necessarily speak to your talent as a
programmer. A 960 day GitHub streak is trivia, not a signal of anything
useful. (If anything, it marks you as a target for burnout!) A few Hackathon
wins and a couple hundred GH stars are the artifacts of a successful hobbyist,
not a proxy for professional ability, or a gateway to employment.

~~~
emerongi
I don't think many software engineers deal with "computer science problems" in
their everyday jobs.

GitHub stars are worth much more IMO. It shows that other developers value
your work. That says a lot.

In the end, we have to realize that most developers are just average. Why go
through the ridiculous process of finding average developers who by luck (or
some homework) happen to solve the problems you throw at them perfectly?

~~~
unoti
> Why go through the ridiculous process of finding average developers who by
> luck (or some homework) happen to solve the problems you throw at them
> perfectly?

Never underestimate the value of hard work, preparation, and a can-do
attitude. It eclipses natural talent every time.

~~~
p4wnc6
The hardest workers with the most successful can-do attitudes will simply
reject your company if you ask them to do bullshit like algorithm trivia or
HackerRank tests.

Such trivia is the opposite of useful hard work; preparation for it truly
wastes time that could be better spent on other things; a can-do attitude
would imply rejecting or ignoring requests to do such things.

As a result, the people who actually do take the time to complete it will not
be completing it because of a good attitude or work ethic, yet you will
mistakenly believe they are.

~~~
serge2k
or they already learned it because they worked hard during school and they
work hard to keep themselves current.

I think the concerns people have about the efficacy of this interview style is
valid, but extending it to the point where you start to make claims about how
people who can pass them aren't as good is ridiculous.

~~~
p4wnc6
No, overfitting is a real thing. Overfitted learning algorithms are generally
worse at generalizing their ability to broader examples and new situations.

The types of candidates who spend the time necessary to memorize algorithm
trivia for the sake of passing these exams are exactly like overfitted
learning algorithms. What they happen to know is unlikely to generalize well.
Of course you could get lucky and hire someone like that who can generalize,
but that's rare. More often, since hiring is political, you pat yourself on
the back for how "good" the candidate is (based on some trivia) and make
excuses when their on-the-job performance isn't what you'd hoped, and find
ways to deflect attention from that so that you, as an inefficient hirer,
won't be called out on it.

Willingness to waste time overfitting yourself to algorithm trivia absolutely
predicts worse later-on performance than candidates with demonstrated
experience and pragmatism (e.g. I'm not wasting my time memorizing how to
solve tricky things that rarely matter. I will look them up / derive them /
figure them out when/if I need them).

If given the choice between hiring a math/programming olympiad winner vs. a
Macgyver/Edison-like tinkerer who may not be able to explain how to convert
between Thevenin and Norton circuit forms, but who took their family radio
apart and put it back together, Macgyver/Edison wins every time (unless you're
hiring for bullshit on-paper prestige, and of course many places are while
proclaiming loudly that they aren't).

~~~
consz
Totally disagree with the final sentence. Most math/programming olympiad
_winners_ are way more than capable of handling anything the Macgyver/Edison
type would be good at. At least in my industry, every olympiad winner has been
a consistently spectacular performer, and I have absolutely no qualms heavily
biasing myself towards that credential.

~~~
p4wnc6
Having worked with some such folks in a quant-focused field, I can say that
their performance was no better than average and in some cases worse. After a
few hires like this, my boss actually pulled me aside and asked me to take
over one of the main hiring projects because he and a few other managers were
unhappy with the way the emphasis on this type of paper credential had failed
to produce good enough analysts, and they wanted a process more focused on
probing someone's experience and ingenuity. I didn't enjoy it at the time, but
that 9-month project focused on that team's hiring needs (which took me away
from some of my technical projects for more time than I liked) ended up
teaching me a ton about what candidates in general look like (at least for
that type of firm).

But I grant this is reasoning just from the anecdata that I have. I can
believe that _winners_ perhaps represent a higher degree of skill, but then
we're talking about an extremely small number of people.

Generally you're facing a tradeoff where you have to choose between a sort of
rustic self-reliance skill set versus a bookworm skill set. People from either
group can learn the other over time, but you can't predict how well by testing
them solely on trivia that constitutes their current main group. My preference
is to hire for self-reliance and learn bookworm stuff later. I used to believe
the opposite (e.g. hire someone good at math because they can always learn to
be an effective programmer later) but my job experience made me believe the
opposite (e.g. actually it's pretty easy to teach people stochastic processes,
machine learning, or cryptography, but it's incredibly hard to teach people
how to be good at creative software design).

------
vdnkh
It took me a year to find a new job. I got rejected from on-sites 8 or 9
times, a few other rejections before that. I've been through everything the OP
has and more. I was once forgotten in an interview room while my interviewer
played foosball and then went home. I've managed to pass all rounds with
"positive feedback" only to get rejected three days later. I've swam through
rivers of aerated bullshit to find a new job and it sucked - but I never once
believed that I was a bad engineer. Hate the game all you want (and I really
do hate it), but you have no choice other than to play it or have an extremely
strong network.

I didn't even want to go to the interview which landed me my new job. In my
previous phone screen they were looking to hire a single person.The perfect
fit. Probably not me - what the hell do I know about video players? And it's
one of those interviews where they'll boot you to the curb if you do poorly in
the first half. Whatever, I'll go anyway. And as luck would have it, I didn't
get booted. I did damn well. And in my final phone screen with the CTO, I got
asked how to find the Nth last spot from the end of a linked list.

I really wasn't good at interviewing for a long time. And from the outset, I
didn't know everything I needed to get the job I wanted. It was consistent
studying and a buy-in to the bullshit that interviewing is that landed me a
new job.

~~~
ruaree
> In my previous phone screen they were looking to hire a single person.The
> perfect fit. Probably not me

What country was this in? In Ireland that qualifies as employment
discrimination on the "civil status" ground.

~~~
vdnkh
America. It's a bit hyperbolic, but is it really discrimination to want to
hire a person who meets all your requirements?

Oh, single person. Ha, it is illegal to discriminate on the basis of civil
status. They meant it as "one person".

~~~
ruaree
Apologies, I misread your original comment. I thought they wanted a person who
wasn't in a relationship.

~~~
jbdigriz
They would probably prefer that as well

------
markbnj
There's selectivity, and there's courtesy and respect. Companies are entitled
to be as selective as they like, and if those are the kinds of tests that
yield the people they want to hire then good for them. On the other hand
courtesy and respect would demand that you're clear with the candidate about
your expectations and requirements, that you don't waste their time, that you
respect the investment of time by communicating after the interview to let
them know how they did, and perhaps even that you let them know up front what
areas you expect to cover. Otherwise, as was noted in an earlier comment, it
really is just a lottery to see if you happen to be fresh on whatever thing
they happen to ask you.

There is another side to this which leads me to ask why companies feel they
have to be so defensive? My wife is a registered nurse on a cardiac critical
care ward. If she doesn't know what she's doing actual people can actually
die, something that is a rare outcome for even the worst software developer.
Nevertheless, she has a BS, and work experience, and when she interviews they
don't require her to stand up at a whiteboard and prove she's a nurse all over
again. They respect her experience, and the questions are more about process,
work habits, personality, etc. In the software development world we appear to
have zero respect for experience, and I wonder why that is? Have employers
been burned so often? Or is this more of a geek cred gauntlet thing?

~~~
csixty4
Is your wife re-certified every year or two? Does she have to have a certain
number of continuing education hours every year?

I don't doubt for a minute that there's some kind of alpha geek thing going on
with a lot of interviews. But it's also a reflection of the fact we don't have
a widely-accepted accreditation body that can vouch for people.

~~~
vonmoltke
> Is your wife re-certified every year or two? Does she have to have a certain
> number of continuing education hours every year?

Every time credentials come up with respect to this industry there are a whole
bunch of people who complain that credentials are meaningless because people
can just cheat or coast their way through. They go so far as to include CS
degrees themselves in that category. What makes you think the education and
credentials for nurses are so much better than for software engineers that
nurses can be hired based on credentials and software engineers cannot?

~~~
markbnj
Two possible answers come to mind: the first is that in order to be licensed
nurses, like doctors and lawyers, have to pass an intensive test known as
"boards." The second is that licensing, certification, and recertification are
functions of state government, not voluntary industry guidelines.

~~~
vonmoltke
> the first is that in order to be licensed nurses, like doctors and lawyers,
> have to pass an intensive test known as "boards."

Board certification is not a legal requirement in any jurisdiction I am aware
of. The licensure tests and board certifications are separate, and the former
is generally taken very close to when the doctor, lawyer, or nurse graduates
from their program and completes their internship period.

> The second is that licensing, certification, and recertification are
> functions of state government, not voluntary industry guidelines.

Yes and no. State governments decide what they will recognize, but industry
provides the training. Some of the shit that counts as "continuing education"
for the medical profession is little better than what you get at DeVry for
programmers.

That said, at least these professions have strong professional associations
that birddog state licensing boards to keep the bullshit out. My original
comment, in fact, was motivated by IEEE and ACM's attempts to do the same for
software engineers and the way the industry seems to be laughing at their
efforts.

------
tptacek
I'm torn.

On the one hand: the interview processes this post describes are hilariously
broken. Stand up at a whiteboard and implement breadth-first search from
memory! You know, like no programmer at their desk staring at their editor
ever does. I think "that's the one where you use a queue, right?" is a fully
valid and _complete_ answer to that dumb question.

I also think you're within your rights to demand that your interviewer
implement Kruskal's minimum cost spanning tree from memory at the same
whiteboard _before_ you have to do BFS. That's an extremely simple and
important graph theory algorithm that nobody memorizes either.

These interviews are nerd status rituals. Really good candidates know this and
game them. If you know anyone like this, ask them for stories. I've heard some
great ones. But obviously, this isn't a good way to select software
developers.

 _On the other hand..._

The idea that "front-end developers" shouldn't need to be able to implement a
BFS (at all) bothers me a lot. If you're a software developer, you should grok
basic conceptual computer science. You should be able to work with a graph. If
you're doing web work, you're working with graphs all day whether you grok
that or not!

I've been doing front-end work for the past month, and I've had to do more
low-level profiling and performance work here than in the previous 4 years of
low-level systems work.

~~~
Morgawr
To be honest I was a bit taken aback by the author not being able to implement
a BFS. It's a fairly standard and really simple algorithm and it's probably
one of the most common ones to actually implement because of a need in your
day-to-day work.

What do you do if you have a nested data structure (like a tree) and want to
print it in order? You write a simple BFS on it.

It's not even a question where you _need_ prior knowledge on the algorithm,
it's just logical. He could've easily asked "Print the contents of this tree
to screen" and it would've been the same.

I can see how some questions like implementing quick or merge sort can be
annoying, most libraries have a sort() function that usually implement either
(or similar), you don't often have to write them yourself, but a BFS does not
fall into that category in my opinion.

~~~
tptacek
Hold on. I'm not taken aback by their inability to do BFS _in an interview at
a whiteboard from memory_. That, I think, is a total bullshit question, which
is why I think the right play there is to one-up them.

What I have a problem with is the assertion that a front-end dev shouldn't
have to grok BFS. Not "be able to implement from memory", but "be able to
quickly implement on demand given a few minutes research".

------
49531
Technical interviews became 10x easier when I realized that most companies
aren't necessarily looking for the right answer as much as they are trying to
look into your mind.

As a self taught programmer things like binary search trees and linked lists
are a foreign concepts (especially as a self taught frontend developer). When
I am asked to solve a problem in a way I've never encountered before, people
are pretty open to explaining how the problem works.

I don't get frustrated if a problem seems arbitrary or obscure because that's
typically not the point. The point is, if you're going to join my team, how do
you approach a difficult problem; do you get upset? do you clam up? I don't
want someone like that on my team. I'd say most people would prefer a teammate
who is resourceful rather than one who only wants to solve problems they're
comfortable solving.

~~~
ckozlowski
>Technical interviews became 10x easier when I realized that most companies
aren't necessarily looking for the right answer as much as they are trying to
look into your mind.

This is a great, great point.

I'd like to add one more: Admitting when you don't know the answer. I've been
in a number of recent phonescreens where we'd ask a technical question of a
simple "good/bad" sort. My advise to those reading: If you don't know, just
say so. "I'm really not sure." or "I knew at one point, but I'd have to go
look it up again." Perfectly acceptable. No one's a walking encyclopedia, and
to say you don't know show's humility. I'm much more comfortable with someone
who says they don't know and will go look for the correct answer than someone
who might stand in front of the customer and try to poker face.

To those reading this and taking notes for an interview, I'd say instances
like these are a good opportunity to discuss. If you don't know, ask what the
correct answer was. Ask why. See if you can build off the answer, sometimes
you might get asked a question you couldn't recall the answer for, but once
given, you can expand upon and demonstrate your knowledge in other ways.

~~~
snappy173
> I'd like to add one more: Admitting when you don't know the answer

I'll +1 this, but with a slight caveat. Some interviewers don't get it, and
will ding you for this. Those are the companies to avoid.

~~~
prakashk
Since those are companies to avoid anyway, you are not losing if you are
rejected because of an honest "I don't know" answer.

------
bryanlarsen
The OP is describing the new grad tech hiring process. It looks like an exam
because it's for hiring people straight out of school.

For experienced people, it's not what you know, it's who you know. You tell
your connected friend that you're looking for a job, he tells you who's hiring
and gives you a recommendation.

You still have an interview, but it's no longer adversarial, it's a formality,
it's friendly, it's just a screen to make sure you're not faking it. One of
the people on the other side of the table has seen your work before, so is on
your side. So when you get those stupid questions, it's a joke that you all
laugh at. You handwave at it, and it's enough.

There are obviously problems with the above process -- it leads to hiring
friends rather than the "best" candidate, but I'm surprised that we've moved
so far away from it that the obviously well-connected OP is having so much
trouble.

~~~
Apocryphon
This calls the entire meme of "Silicon Valley is a meritocracy" into question.
This just further validates those who criticize tech for being a monoculture
with lack of diversity.

~~~
jaredcwhite
Anyone who actually believes "Silicon Valley is a meritocracy" is exactly the
reason why Silicon Valley is, in fact, not a meritocracy. :)

------
halis
I interviewed with Netflix for a front-end JavaScript position a few years
ago. I had two technical phone screens. One with the engineering manager and
another with a senior engineer on their team.

Those went smoothly so I was asked to fly out to Los Gatos, CA.

On-site I was supposed to talk first with the senior engineer I had already
interviewed with over the phone. He was out sick so they changed at the last
minute.

In walks a guy in a fedora with full tattoo sleeves. He glances at my resume
and laughs saying he hasn't looked at it at all and really knows nothing about
me.

He proceeds to ask me detailed questions about Node.js. I told him that I was
very clear with them on the phone, that I've played around with Node, but I
hadn't used it to any serious degree (at that point in my career).

He continued with the Node.js questions for a while, some of which I knew
because they were the same as the browser (console) some of which I wasn't
familiar with at the time (EventEmitter).

He then asked me some simple JavaScript, Backbone, CSS questions all of which
were easy. He then asked me a C# question and I knew that too.

We shook hands and after he left, the engineering manager came back in and I
was basically escorted out. He said I was good but that I wasn't what they
were looking for.

I've had some retarded interview experiences but that one took the cake.

~~~
Grishnakh
I wonder if he didn't like you because you didn't look like a hipster....

I'm totally serious: I really wonder how many of these baffling interview
experiences where seemingly highly-qualified candidates get turned down is
really about non-technical and non-work-related factors, but no one wants to
actually admit it. How much of it is due to personal biases by the
interviewers, who may discriminate against people for various reasons? A lot
of people want to surround themselves with people just like themselves, so if
you have a company full of hipsters wearing fedoras and someone comes in for
an interview and they don't look like that, they could easily be passed over
because they're "not a fit for our company culture".

I don't think I'm half as competent as the guy who wrote this article, but
I've had a much easier time getting jobs in general. My background isn't even
CS, it's EE, so I totally suck at all the algorithm questions. But OTOH I
generally apply for embedded programming positions where knowledge of
algorithms isn't that important anyway. I even interviewed at Google (one of
their recruiters contacted me) and had pretty much the same experience as him;
I won't waste my time with that company again. A bunch of recruiters have
tried to get me to interview at Bloomberg LP, but I would never work in that
crappy open-plan environment that they're infamous for. But I frequently
wonder how much of my success is just from being tall and in-shape, not having
any obvious personality quirks, and "fitting in" with the look and the company
culture (I interview with more stodgy places, not places with hipsters with
arm-sleeve tattoos), rather than due to my technical proficiency.

~~~
jjn2009
Netflix has a very strong focus on culture so you are likely correct, although
it doesn't sound like he got to the part where they actually quiz you on their
Netflix culture slide deck they likely did not continue for this reason.

There is some merit to trying to maintain culture if they have some formula
for what works there and they want to maintain it but an engineer could pretty
easily think something along the lines of "he's not hipster enough" and then
make a case that they don't fit the culture but really not care about
netflix's corporate ideas about culture.

------
paddy_m
I hired Sahat as an intern three years ago while he was an undergrad. It was
one of the best hiring decisions I have ever made. He was productive
immediately and our (small) team felt the loss when he went back to school.
This guy is good and gets stuff done, ask people who have worked with him.

I wish Sahat had reached out to more of his network before responding to
random recruiters. Tech interviews as Sahat experienced them are broken, but
tech hiring is slightly less broken especially when you leverage your network.

~~~
falcolas
> I wish Sahat had reached out to more of his network before responding to
> random recruiters.

Has his network moved forward in what they do? I've found with my own network
that so many of them are in the same (or equivalent) spots they were when I
left to advance my career. Not precisely positions of power which I can take
advantage of for the next step forward in my career.

~~~
Aissen
You do not need to be in position of power to refer someone.

~~~
falcolas
The usefulness of contacts only really matters when they are managing (or are
a key-decider in) the team you wish to apply for.

Otherwise, a reference will only add to the burden you have to overcome with
the interviewers - they will consider not only your qualities, but the
referrer's qualities as well. "Richard vouched for Jane? But Richard is
writing testing software, and we're hiring for backend. We don't need a SDET
or we would have hired Richard."

~~~
EdHominem
I've referred people senior to me and been told by the recruiter that it was
significant.

Because I can't be expected to know their work as well as they do I describe
their peers' opinions (well-respected in the NOC) and the soft-skills they
have like mentoring, etc.

"Even though I was only an SDET, Dave took the time to help me fully
understand the math involved in the problem domain and how to efficiently
model it. This allowed for a 60% increase in my deliverables and put the
entire team a week ahead of schedule."

------
unoti
Google and similar companies aren't for everyone. They're looking for people
on top of their game and willing to go the extra mile.

> To be fair, I already knew about Google’s idiotic interview process that is
> optimized for hiring book-smart academic candidates who know their
> algorithms and data structures cold, so my expectations were rather low to
> begin with. I also did not get much sleep that day, so my problem solving
> skills weren’t at its peak.

The author is already annoyed, antagonistic, and planning for failure. He knew
what he was up against, but didn't adequately prepare to succeed by studying.
And didn't sleep the night before.

And none of the reasons for not succeeding are the author's fault, in his
mind.

You can claim that the screening process is dumb, and in some ways you're
right. But at the same time, this process does select to some extent at least
against the people who make excuses instead of bringing their A-game when it
counts.

If you want a job at a place like this, you can do it: commit yourself to a
plan of action for success that involves real work and preparation. Wanting to
change the industry practice of the top tier firms is interesting and all. But
if you want to get in, work and preparation will reap more rewards than
complaining.

~~~
falcolas
With all due respect, being able to recite algorithms from memory is no actual
indication of being at the top of your game. All it really indicates is that
you are capable of memorizing algorithms.

~~~
unoti
It's well publicized what to expect at interviews for these firms. It shows
that you're willing to put in the preparation to make it work. In addition to
putting in the work of memorizing the algorithms, a candidate needs to know
how to apply them, and to write code, and to accept feedback, and to
collaborate and communicate.

If a candidate isn't willing to put in the work to prepare, it's not much of a
cognitive leap for me to envision them telling me that implementing this or
that feature is dumb, impractical and not needed. Many developers have this
"start with no" defeatist attitude as their default position on most problems
of moderate complexity, and it's a real problem. Given a chance to select for
candidates that instead figure out a way to make it happen I'd rather take the
winners.

~~~
tobz
Do you not find it strange, or at least confusing, that you're arguing a point
here that is predicated on studying for an interview, rather than the _actual_
position?

"This person didn't study for the interview, so what did they expect to
happen?" Oh, I don't know, maybe to be asked questions directly related to the
position, amongst other things.

~~~
unoti
> Do you not find it strange, or at least confusing, that you're arguing a
> point here that is predicated on studying for an interview, rather than the
> actual position?

No, I don't find it strange that I want them to prepare for something they're
not going to use normally, but agree it might be confusing.

For the actual positions I'm hiring for, nobody in the world outside our teams
understands the systems. The candidates are going to need to work hard to
learn what's going on when they start their new job. Some of it is going to be
hard to do and not always a complete pleasure. Essentially I see it as a
personality test that selects for the kind of people that figure out how to
overcome technical adversity.

Willingness to do the work to be prepared and eagerness to dive into technical
arcana despite it being not very easy-- these things _are_ very relevant to
the positions I hire for at Microsoft.

~~~
tobz
> I want them to prepare for something they're not going to use normally

<mind blown GIF goes here..>

> Essentially I see it as a personality test that selects for the kind of
> people that figure in it how to overcome technical adversity.

This seems at odds with the original "ask", as it were: study up on some basic
CS algorithms, and now I know you can handle what we're going to throw at you
here. Ignoring the obvious "well, we need to make sure they can learn basic
things", how is this even a viable test if your environment is so advanced, so
high up, that you expect new candidates to encounter actual _adversity_?

------
maxsilver
What frustrates me about this is not even these questions, specifically, but
which companies seem to use them.

If Google wants to ask crazy algorithm questions, that's at least sort-of
reasonable. There's at least a hypothetical chance your work will involve that
knowledge.

But I've interviewed at companies who's entire tech stack is a simple CRUD web
app, or a simple RESTful mobile app, who's so-called "big data" is less than a
few gigabytes in total, and they _still_ want to throw algorithms and brain
teasers at me. These same companies then post some inane blog post about the
"developer shortage" and how "we can't find talented people".

If these companies could actually find the candidate they're testing for --
this hypothetical hyper-intelligent developer who had a IBM-Watson-like memory
of every CS algorithm and it's application in every language, that person
would get completely bored working there and quit in 3 months or so. _These
companies could never retain the type of person their own hiring process
exclusively selects for_

\---

Hiring doesn't need to get fixed, companies need to get honest about what they
are and what they actually want. To restate this in 1-10 scale : Many
companies delude themselves into believing they are a 9 or 10, and are trying
exclusively to hire 10's (and hypothetical 11's that don't exist).

When in reality, most companies are in the 4 to 6 range, they only need people
in the 4 to 6 range, but are rejecting 7 and 8s type candidates, because they
aren't a 10.

This process itself isn't broken, so much as the businesses holding the power
in the process are delusional about...everything (what they are, what they
need, who could provide that, etc).

~~~
brazzledazzle
I've learned that a lot of people need to lie to themselves sometimes to feel
confident. If everyone was honest with themselves about how utterly average
and relatively unimportant they are they'd probably be much less productive.
And in case someone feels I'm looking down my nose, I consider myself
positively average. A tiny part of me hopes/wishes that I'm not, but the rest
knows better.

~~~
mifreewil
Much of the advice around startups is actually centered around the idea of
"fooling yourself" or "faking it 'til you make it" or other strategies of
positive thinking. Working on a startup is a rollercoaster of emotions and
using these strategies can be helpful. Real wisdom may be found in knowing
when to fool (lie to) yourself and when not to.

------
tachion
After reading author's post I've a feeling that its not the programming skills
that the author has issues with, but instead the attitude, stress durability,
expectations to the world around him. True, hiring can be broken, it often is,
but as with everything, the persistence usually allows us to find the proper
company with proper hiring process. He's getting frustrated pretty quickly,
complains when is asked to perform math-heavy coding, complains when is asked
to do proper front end coding, so on and so forth - this type of people are
not very pleasant to work with and very often their feelings, unability to
adapt to difficult situations and attitude is very visible, putting off the
recruiters. That is, of course, my personal feeling after reading that piece
and I might be completely wrong.

~~~
collyw
Persistence is a pain in the arse if you have to spend 1.5 hours every
Hackerrank challenge (plus you are likely to want a warm up of at least half
an hour). Say you have to do ten of those. Why can't employers ask you to
bring in some previous work and discuss it? Surely that is a lot more relevant
than algorithmic stuff that you likely haven't used for years.

~~~
ionforce
> bring in some previous work

Surely your prior work is under some sort of NDA? It's all proprietary (unless
it is open source).

~~~
collyw
I have side projects that I am working on, quite happy to show those - its one
of the motivations for doing them so that I have code to show people.

------
dryajov
Honestly, I believe the industry is cannibalizing it self, and this sort of
practices is pushing out more and more creative and capable people. When I
have to make a choice of whether to practice my algorithms or work on my open
source project, is when things are going to start blowing up. This industry is
built by people with passion and dedication, some of the most powerful and
defining projects were built by individuals who sacrificed their spare time to
build something useful, now they will sacrifice that time to practice...
Algos? C'mon!!! I think our industry has passed the initial honey moon period,
when crazy and beautiful solutions crystalized in garages and basements all
across the county and the world, and we're headed for a bumpy landing were big
corps control open source and the crazies that made them possible are pushed
out. This is not sustainable on the long run, and pretty soon were going to be
regulated to oblivion. Bye bye innovation.

~~~
bogomipz
Good points. I know how I want to spend my time - working on something
creative not "training up" for a potential interview. Companies only started
doing the "throw the CLRS book at them" style interviews when they found out
that was Google was doing. I'm sure Google has their own reasons for that.
However why would a smallish start up want to emulate what works for a company
that has 65K employees? This whole training up for Google/FB/MS/AWS style
interviews has actually given rise to a cottage industry that has sprouted up
around helping you train - "Cracking the Coding interview"/Hacker Rank etc. I
would rather hire someone that:

A) Has good experience

B) Has the ability to reason about problem domains even if they can't scribble
out a perfect implementation with all edge cases considered on a white board
in under 30 minutes.

C) Has good interpersonal skills.

------
grosbisou
Ah I interviewed with some of these companies a few months ago and had the
same experience. Unlike you though I didn’t find this frustating but rather
hilarious.

For example, Lifion interviewers who wanted me to write fibonacci couldn’t
tell me what the sequence definition was, they ‘taught’ me that C++ classes
default visibility was protected or that REST was a protocol, they didn’t like
when I said they should use a relational database if mongodb lack of multi
documents atomicity was such a problem. That was so mind blowing that I
started writing down on my phone all the stuff they said.

I might write an article about all that too actually.

~~~
maxxxxx
I had the same experience a while ago for a contracting gig. The interviewer
threw all kinds of jargon at me and when I asked for clarification he couldn't
provide any. And some of the stuff he talked about was incomplete or basically
wrong.

------
Xcelerate
When I was an undergrad, my team won the Facebook Hackathon at our university
in 2011, so they gave each of us job interviews. None of us got an offer, but
the irony is that one of my other team members went on to work at Instagram,
which was then acquired by Facebook less than a year later. I'm pretty sure
that was about the most expensive way FB could have hired him.

During my interview, the interviewer asked me where I was getting my CS degree
from, and I replied that I wasn't getting a CS degree — my major was chemical
engineering. He was silent for a few seconds, so I'm pretty sure that wasn't
the answer he was expecting.

What I remember about the interview process is that I was asked to implement
some kind of odd search/sort algorithm. I remember thinking "why would I have
this memorized off the top of my head when I could easily Google the best
algorithm suited for the task?"

In high school, I don't think there was ever a chemistry or math exam that I
didn't get a perfect score on, but I would also take much longer to finish
than the other students. I frequently ran over the allotted class time and
worked well into the lunch period (luckily, I had nice teachers who allowed me
to do this). In college, I remember perplexing the physics professor, because
I got 70s-80s on the quizzes throughout the semester, then I got a 113 on the
final exam. I told him the only difference was that I was given 20 minutes for
the quizzes, whereas I had 3 hours to complete the final exam. The extra time
made all the difference.

So I wonder if a lot of companies are missing out when they look for 1) people
who have a lot of simplistic CS algorithms memorized and 2) people who can
work quickly on the spot. I may not be able to write a FizzBubbleRedBlackSort
algorithm on a whiteboard in ten minutes, but give me a week and I'll have you
a parallelized implementation of quantum monte carlo that runs on a hundred
thousand cores.

~~~
madelinecameron
I think anyone with a CS education can design something like that given enough
time.

It isn't a question of whether you can do it, it is whether you can find a
'good enough' solution in an optimal amount of time. It is testing your
creativity and problem-solving abilities.

~~~
dclowd9901
An "optimal" amount of time? So we expect "good enough" solutions to be
materialized in a matter of an hour?

If my PM ever walked up to me and said, "Hey, I have this project, and I need
you to have it back to me in an hour," I would laugh, then escort them over to
their boss, who would also laugh at them before they walked back to their desk
in shame.

It's not testing anything but whether or not you're good at studying for
exams.

------
mikelevins
Yeah, it's broken.

Google studied their own interview process, according to Lazlo Bock, examining
tens of thousands of hiring decisions. The study concluded that their process
was no better than random chance at finding good candidates. They continue
with that process nevertheless.

I have a rich network of Silicon Valley connections, built over 29 years of
working for Valley companies. What I hear time and again is that many highly-
qualified and productive people have a terrible time finding work.

Simultaneously, Silicon Valley companies testify before congress and complain
to the press that there is a serious shortage of technical hires.

If companies can't find enough good candidates, and good candidates can't find
enough offers, and one of the most prosperous companies in technology, with
the most famously rigorous hiring process in the industry says that their own
process is bullshit, then yeah, I'd say that hiring is broken.

Of course, if you happen to be prospering, then it doesn't look broken to you.
You're prospering, after all.

And of course, if some joker comes along and says that the process that hired
you is broken and gives results no better than random chance, of course you
aren't likely to agree. After all, if it was luck that gave you your
prosperity, then luck could just as easily take it away again.

The story we like to tell is that the technical interview screens out bad
candidates. It's just a story, though. Google's research says it doesn't.

Is that such a big surprise, though? How many times in my three decades in
software has a product launch depended on someone being able to solve a brain
teaser in front of a critical stranger? Zero. How many times has a company's
success depended on someone writing the right code on a whiteboard? Zero. How
many times has the bottom line depended on someone coming up with the right
algorithm or data structure off the top of their head in a conversation? Zero.

Technical interviews, if they measure anything at all, measure things that
don't have much to do with technical jobs. So it shouldn't be a big surprise
that they don't do better than chance at predicting someone's performance.

If technical interviews don't work, why do we still use them? Why does Google
still use a hiring process that its own research says is bullshit?

Maybe it's because we don't have anything better.

I think it's because on some level we realize that we don't actually know how
to distinguish good candidates from bad ones, but we don't want to admit it to
ourselves. We want to think that we can pick the right candidate, because it
can be so costly if we don't.

So we ritualize the process. We rely on a bullshit hazing ritual. We wave a
dead chicken over it and tell ourselves that we are screening out bad
candidates and hiring only the best.

Only we're not. If we were, then maybe companies would still have a hard time
finding enough candidates, or maybe good candidates would still have a hard
time finding jobs, but not both at the same time. And the company with the
most 'rigorous' hiring process in the industry wouldn't be concluding that
their own process is nonsense.

Yeah. It's broken.

~~~
codeOfRobin
As John Siracusa once said, Success hides problems.

------
traviswingo
I interviewed at 17 companies before finding one that fit me. It's more of a
persistence game than anything, and I began to realize that a lot of companies
were just testing the waters, only willing to hire someone if they really blew
them away (obviously this is hard to do under interview circumstances).

Once I found a company that actually _needed_ me, the experience became a
positive one - they went out of my way to make me feel comfortable.

I wish there were a way for candidates to pre-screen companies, rather than
the other way around. It's a waste of time on both parties if the company
isn't actually in need of a new hire, but just dabbling in the option pool.

~~~
pyb
Agreed ! So many companies are advertising positions, but are not that
committed to hiring. They just enjoy having people coming to their office to
get grilled. I guess it must be very rewarding for the interviewer.

------
bpchaps
One possible reason is that the brony thing on his github might be a legit
turnoff for employers. It's silly, but it's possible. The two people I talk to
more than anyone else in this world are bronies (to the extent of going to
conventions and whatnot) and have similar issues. Hell, I still don't
understand it and find myself irrationally judging them for it, and that's
even after daily exposure to it.

~~~
hvoiiita
I agree. I cringed when I checked out his Github profile because its one of
those things that immediately throw up a red flag.

To each their own on their personal time, but you can't seriously expect that
being associated with a stigmatized hobby is going to gain you anything.

~~~
brazzledazzle
While it's hardly fair I have to agree. I'm acquainted with a few and they are
generally cool people but part of the brony identity does seem to be tied
directly to the stigma against them. I wonder if feeling like they have to
hide it makes them more resistant to hiding it?

It's such a silly thing, but humans are animals and we have annoying or shitty
things like pack/tribe mentalities.

~~~
bpchaps
From knowing these guys for so long, they try their absolute best not to hide
it and go pretty far to show it off in a way that's not really in your face.
Gotta hand it to them for sticking up for their interests considering how much
negativity the crowd receives. That said, the friends I mentioned really,
really dislike most other bronies for being consistently over the top.

------
spitfire
Tokenadult isn't around to chime in here, so I'll take his place today. Hunter
and Schmit did a meta-study of 70 years of research on hiring criteria. [1]

There are three attributes you need to select for to identify performing
employees in intellectual fields.

    
    
      - General mental ability (Are they generally smart)
    
      - Work sample test. NOT HAZING! As close as possible to the actual work they'd be doing.
    
      - Integrity (The first two won't matter if the candidate is a sociopath).
    

This alone will get you > 65% hit rate. [1]
[http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...](http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf)

Hell one of these companies should hire me to do data driven recruiting.

------
stegosaurus
Is it even just hiring?

Every employer I've worked for has made the experience farcical. If not at the
start, then over time. You interview for one job, and eventually end up doing
something else.

A full time career that doesn't pay enough to buy a home. And they say
software developers are overpaid.

I think the end-game for me is to just go camping with a laptop or something.
I'll code for fun, rather than trying to meet this 'market demand' which
provides people with studio apartments, temporarily, in exchange for ~all of
their productive hours.

~~~
wott
> You interview for one job, and eventually end up doing something else.

LOL yeah, that's what happened to me for my last job. A recruiting process
that lasted 4 bloody months for an electronic designer position, and when I
was finally hired they put me on software testing; not only I had never done
this, but I had never heard it was a thing. Anyway, after less than 2 months I
was better as this than the CS graduates who had been doing it for several
years and they were asking me for help in their work.

But now I have been unemployed for 2.5 years, I made it to the interview stage
_only once_ during that time, and _I have given up on even just applying_ to
any job offer for the last 5 months because it is absolutely pointless and
humiliating to be repeatedly discarded by people who are clueless, who don't
give a flying fuck about the persons they "harvest" and lack the basic respect
in social interactions (like spending 2 minutes of their precious time
answering a question, not blatantly lying, doing what they said they'd do, or
even just showing up at the very appointment themselves fixed!).

So yes, in a way, I've quitted and I am getting ready to become a street
beggar when all savings are gone. In the blogger case, his situation is too
fresh, I don't think his mood of the day will last long for this time (and
after all, he got plenty of interviews, at least), but I am really really
tired of these completely nonsensical recruiting processes and their
humiliating consequences.

~~~
splicer
Would you be interested in another software (or firmware) testing role? Where
are you located?

------
daurnimator
The purposes of these interviews is not (usually) to see if you know the
answer. It's to see how you problem solve.

If you knew the correct answer to e.g. the BFS algorithm, you'll get thrown
another question that they hope you _don 't_ know.

When interviewing, the thing I want to see most is how someone works through a
problem: can they solve from first principles? do they go via trial and error?
do they ask for a computer to google things up/a book?

Picking raw CS problems is an easy option, as its something that you _should_
be able to solve, and it means I don't have to require you to know
Angular/React/Flavour of the month (new tools are easy to teach the right
candidate).

You're _not_ going to immediately know the answer to everything that comes up
in your job; so evaluating how you solve the unfamiliar is very important.

~~~
pjlegato
That sounds nicer than what 95% of programming interviewers actually do, which
is something rather different.

Almost all are simply playing "programming trivia." They name an algorithm or
a data structure, and then evaluate whether you can recite it from memory.
That's it. There is no problem-solving element involved. It is purely a test
of whether you can memorize and recite.

This requires a lot less effort on the part of the interviewer than the style
you describe, and also bolsters their ego and makes them feel clever when they
find a candidate who can't recite properly.

~~~
infinite8s
If that's the case, is that really a company you'd want to work at?

~~~
radnor
When it's the case with nearly every company around you, and you really need a
job right now, what choice do you have?

------
m4tthumphrey
Fancy moving to the UK? :)

Seriously there's a job with your name on it if you're interested.

When I interview candidates I sit with them for half an hour or so to get to
know them. Then I give them purposely broken, poorly written piece of code
which I tell them to pull apart. This proves incredibly effective as even if
they miss some of the more obvious errors I can at least point them in that
area and then see if they can see the problem on their own. There are about
100 different things to talk about so it really gives me an idea of the level
they are at, and also the type of programmer they are; passionate, lazy,
smart, meticulous, inexperienced, confident etc. Then if I feel they are worth
a second interview, I get them back to sit with me and my team for the day to
see how they fit in with the team. Then all being well I offer the job.

~~~
koyote
That sounds pretty much like an ideal interview process.

But do you think this is easier to do if you get less candidates (looking at
your location, I am assuming you only get a small fraction of candidates than
if you were located in, say, London) ?

~~~
shawn-furyan
> But do you think this is easier to do if you get less candidates

This is one of my pet peeves. The number of applications you get has
absolutely nothing to do with the number of candidates you should consider,
because it has absolutely nothing to do with the number of candidates that you
can competently consider. You don't have to get through every resume, and
trying to do so will just lead to biased "how can I say no" ad hoc filtering
games.

The solution is to use an unbiased* pre-filter to restrict the number of
applicants that you let into a thorough consideration process. Random
selection is the pre filter that I would use, but there may be other valid
choices (though outside of random selection, it's easy to let bias slip in).

Bonus points if you are transparent with candidates that get filtered out this
way about why and how that happened. If you're messaging is constructed well,
then they should understand that there were too many candidates to give all of
them fair consideration, and that being filtered out reflects in no way on
their worth as a candidate. So, they will be more likely to apply for future
openings.

Sorry if it feels like I'm criticizing you. I don't mean to at all. It's just
that this idea of being overwhelmed by candidates is absolutely pervasive in
discussions of hiring, and it's a completely fake problem that leads to
absolutely real difficulty on both sides of the hiring process.

* A lot of organizations resort to biased pre-filters to cull resumes, like unnecessary requirements. I'm of the opinion that this leads to suboptimal results, particularly if they align significantly with the biased filters that the rest of the industry your company is competing in uses. It means that there are qualified candidates that end up systematically under-recruited. Those are the Moneyball candidates. You should want those candidates because they are the most productive relative to the salaries they can demand. And even if you don't give them a lower salary than you would give a candidate that passes all the typical filters, then you will still have a significant retention advantage, which all told may be worth more than shaving salary in many (most?) situations.

------
ts330
Considering that it's our fellow programmers doing the interviewing, I'd say
we're failing ourselves here. I'd wager that in almost all cases, those doing
interviews have had zero training on effectively recruiting anyone (let alone
other developers). An effective interview requires preparation - and I bet the
majority of developers do this right between saying " _fuck_ , have they
arrived already?" and starting the interview. Is it any wonder it falls back
to the standard approach of "Google does it, it must be good" or a dick
swinging contest trying to prove how amazing your team is, because "fuck yeah,
we all write search algos every fucking day - it's why our product is
amazing."

~~~
YeGoblynQueenne
I guess the take-home lesson here is that programmers have no idea what makes
a good programmer and how to screen for one. So they fall back to the basics,
CS 101.

~~~
ionforce
> programmers have no idea what makes a good programmer

I disagree. I think we do know what we want, but there is no cheap/easy litmus
test for this. If time, money, and opportunity were free, the way to find out
if someone is a good programmer is to work with them for a long time.

Okay, now find a cheap way to do that while both sides of the interview have
to juggle full time jobs and other interviews.

------
wildermuthn
Front-end lead here, building large desktop apps for my company's internal
use.

I've never had a web-app that failed due to performance. I can't recall any
that ever have, except Facebooks' attempt to use HTML on mobile.

UI performance has little to do with algorithms, and only occasionally
requires opening the profiler to hit 60fps with some tweaks to bone-headed
nested loops. Or maybe reconsider your use of Angular!

Front-end apps fail because long-lived mutable state is a powerful engine of
complexity, and algorithms do not solve complexity. I am constantly telling my
team (CS back-enders prepare yourself!) to _ignore_ performance concerns.
O-whatever has zero-impact on delivering simple, extensible, bug-free web apps
that please its users.

But admittedly, crafting good software isn't as objectively clear as
implementing a mathematical function that makes your server code perform. The
proliferation of front-end frameworks and compile-to-js languages indicates
that writing FE software that _works_ remains a far greater challenge than
writing FE software that hums.

To that point, maintaining a popular github repo for a library or app that
demonstrates your ability to write, maintain, and extend FE software is still
the best sign that you know what you're doing, and that you _like_ what you're
doing. Conversely, knowing a lot of algorithms as a FE candidate tells me
nothing about whether your first PR will be your last.

On a happy note, Netflix didn't ask me a single question regarding algorithms!
Their interview's focus on OOP made sense, even if it didn't fit with my own
focus on ClojureScript and FP.

------
leothekim
I think it's important when interviewing candidates that he/she can
demonstrate fundamental CS knowledge. In any software project, you may be
working out very complicated features, and CS knowledge is often the common
language for conveying complex and subtle ideas.

That said, it's perverse that there's a cottage industry around software
engineering interview training on both sides of the table for the crazy
questions that are being asked. No one wants this, but sadly, once you're in
the door at these places that do these sorts of interviews, the motivation to
affect change approaches zero.

There are some companies that have tried to make this a fairer assessment
though, e.g. Foursquare
[http://engineering.foursquare.com/2016/04/04/improving-
our-e...](http://engineering.foursquare.com/2016/04/04/improving-our-e...).
Putting this sort of effort into an interview process is time-consuming, but
if the software industry is going to make its interview practices assess
candidates more fairly, it's going to take effort.

~~~
geebee
Yes! I really agree. How this will happen I don't know, but it badly needs to
happen.

I don't object to an employer wanting to see a background in data structures
and algorithms, sql, binary, and a few branches of math. This is why I agree
that hiring is broken but also understand that it isn't easy to fix.

Some of it stems from something very wonderful about our profession - we are
flexible about how people can acquire this background. In law, you must do a 3
year JD[1], and you must typically pay way over 100k for it. Alternate paths
toward learning this material are pretty much illegal (as in, we'll put you in
jail if you try to practice law if you haven't done the 3-year degree,
regardless of your master of the material).

For instance, I was a math major, and I only took a bit of formal CS. However,
when I did self-study to try to plug some of these gaps (partially for
interviews, partially for my own education), I was surprised with how much I
actually had covered from a different angle. Many of my math (and later, in
grad school, Industrial Engineering) professors ran "labs", some for a bit of
extra credit, others as an optional set of assignments. I took graph theory
through a math department and stuck around in the lab and so forth to
implement some of the algorithms, to learn about how some types of proofs
actually contain an algorithm. BFS, DFS, minimum spanning set. That all
involved building trees, lists, using pointers. In numerical analysis, I did a
lot of matrix algebra manipulations. And so on. If CS were run like law, it
would be illegal for someone like me to work as a programmer, because my
degree isn't an ABET accredited CS degree.

The downside to all of this, though, is that there is no recognized
credential. I don't object to being taken through my paces, I object to how
random, capricious, and redundant the process has become. I read a blog
article about a programmer who took the bar and studied for 100 hours and
passed. Think on that for a second and compare it to the amount of time people
spend preparing for and taking what are essentially white board exams in
technical interviews. The bar, an exam that is considered one of the most
brutal rites of passage for a learned profession? In some ways, we go through
that every time we do a new round of interviews when we change jobs!

Actuaries have to show understanding of relatively advanced math, but senior
actuaries don't (to my knowledge) get grilled on integration by parts or some
specialized set of partial differential equations when they interview. Why?
Because there is _a proper exam_ for their field (and unlike law, actuaries
are free to obtain this background through multiple educational paths, they
often major in math, but hardly always).

Another problem is the capriciousness of the tech exam/interviews. I believe
that a "bill of rights" so to speak slowly evolved between examinee and
governing board over time in true professions. The nursing and medical boards,
the actuarial exams, the bar - these fields have a tough exam (or series of
exams), but they are consistent, there is a clear study path, there is a
commitment to grade them fairly, there is a clear study path, if you fail, you
get feedback or at least a score (the bar doesn't write you back and say they
"decided not to pursue your candidacy further at this time"), there is often a
second (or additional) change at the exam, and, most importantly, when you
pass you get _a lasting, public credential respected by your peers in the
field_.

People often describe these exams as the most brutal, anxiety ridden,
stressful events of their professional lives. This is why, I believe, they
slowly evolved that "bill or rights" that protects the examinee.

Unfortunately, in tech, I believe we experience these exams over and over, but
without any of those benefits.

I am a-ok with requiring people to show competence, but the way we go about it
is, I think, badly broken. I believe that this process accounts for a great
deal of attrition in the field, as well as people deciding not to enter the
field in the first place.

[1] yes, a bit of handwaving, it's not _quite_ that simple in some states.

------
riyadparvez
The problem with interviews I am having (I am about to graduate and have not
got a job yet) is that the whole hiring process is too one-dimensional. Some
companies only care about algorithmic coding competition skills that you can
only achieve via competing in some sites like TopCoder, CodeChef and some
other companies only care about how many years of experiences you have - does
not matter what you have learned from experiences, it is just how many years
that count.

Coding contest skills are very unfair to senior developers because they are
out of school long time and do not have the time or motivation to engage in
coding competition. And this also creates different incentive models. I have
seen people who flunked very elementary CS courses (OS, networking etc.) to
spend more time coding competition to get hired in big companies. This is
really weird because they have to learn these things to become a real
developer and they are gonna learn these things in company's time which they
should know already. That being said, I personally think, problems like maze
solving and inverting binary tree are fair questions. These are not exotic DP
problems, these are just simple problems.

OTOH, the whole years of experience thing is unfair for new developers who do
not have the experience but smart enough to learn and outperform many
developers with experience who just memorized APIs over years of experience.
There must be a healthy compromise between these two types of hiring.

~~~
ddebernardy
FYI there actually are very few "new developers who do not have the experience
but smart enough to learn and outperform many developers with experience".

Developers like to think they're on top of their game straight out of school
and are able to design and develop 100k LOC apps off the bat. They could use a
healthy dose of humility, because those that can are few and far in between.

The sorrier reality is that most of them spend their first couple of years
learning how to work in a team, and then next 5-15 years picking up good
habits and design patterns, and subsequently learning to not systematically
use them once they know better. (I can't say first hand what comes after, but
I would imagine yet more of the same.)

------
taneq
The examples that always come up of "stupid interview questions" in this kind
of rant: Implement a breadth first search, or reverse a binary tree, or write
FizzBuzz. Are these really such difficult things to whip up, off the top of
your head? Is it really that unreasonable to want to hire someone who _can_ do
so?

Yes, if you need such a thing and it's not immediately obvious how to do it,
off to StackOverflow you go to find some example code, but these are basic "do
you understand fundamental data structure / control flow" type questions. It's
not like they're asking you to implement a theorem prover or something.

~~~
stegosaurus
I don't know what BFS is.

I just googled it. Oh, I know what it is now.

If you haven't been exposed to it, it's just jargon. That's the point. You are
testing for jargon rather than ability.

It is the distinction between saying 'implement FizzBuzz' and going silent,
and actually explaining what it is. As an interviewer it is easy to forget
that whilst you may have asked a question 20 times, this may be the
candidate's first encounter with your terminology.

Steelmanning as applied to interviews, basically.

~~~
bad_user
Trees and graphs are fundamental to computer science and there are only two
ways to traverse them. I don't know what kids are doing these days, but I
learned this because of my high-school curricula.

In other words, it's OK if you don't have a formal education in computer
science, but when you don't have it, you need to make up for it by learning on
your own, because this is basic stuff that high-school kids are learning. And
it's even worse when people do have that education on their resume and don't
know BFS, because it means they cheated on those courses.

And what would you prefer for a hiring test? Straight IQ tests? A requirement
for public, open-source contributions? Or are you speaking of querying
databases and fading out divs? I think we can all agree that neither is
entirely fair.

And keep in mind that for all the pain involved in the interview process, the
only alternative is optimistic hiring for a test period, except that doesn't
work because it causes distress to everybody involved if it doesn't work out.
This is why many companies now prefer internships, because thus they are
dealing with young people that don't have big expectations.

~~~
stegosaurus
I think this makes sense if you consider an interview as extending a hand to a
poor, down-trodden vagrant, rather than an exchange amongst equals.

The article might go over the top a bit with self-pity, but personally I just
see it as suboptimal behaviour.

[http://danluu.com/programmer-moneyball/](http://danluu.com/programmer-
moneyball/) \- Dan Luu explains better than I can.

I think fundamentally the idea of paying developer X 40K and developer Y 80K
(because developer Y has been twice as effective in the past) is broken,
because it negates the impact of environment.

If you pay someone 150K GBP in London they can live next door to the office,
have TaskRabbit like services perform all household tasks for them, and spend
their time exercising and reading 24/7\. They will kill it.

Pay them 30K, and regardless of pedigree, they're going to struggle.

Somewhere in there is a balance and I argue it's far less to do with
certification and more the circumstances of life which as an employer you have
huge discretion to influence.

Basically, it's about steelmanning. Why is someone bad? Is it that they're
inherently genetically dysfunctional? Or is it that they haven't been coached
well or have a difficult environment?

Given good faith, most of the developers I know have the ability to be
amazing. I include myself in that (am I that good? dunno, impostor syndrome
innit). But they are stifled by needless nonsense. Management, open office,
low pay, commute, stress, basically. Kill the stress and you get your '10x
engineer'. Keep the stress and your '10x engineer' turns into a chocolate
mousse.

~~~
bad_user
Are you sure you replied to the right comment? :-)

From my point of view, an interview really isn't an exchange between equals,
but a meetup where two parties meet, state their demands and evaluate each
other. It works in both directions of course.

~~~
stegosaurus
Yes, I am.

>> From my point of view, an interview really isn't an exchange between equals

If you design it that way, sure. It doesn't have to be like that.

The whole principle here is that there exists a growing portion of developers
who can't be bothered with interview ping pong.

If you don't want them, great! Everyone wins. You don't need to convince us,
we won't be working at your company anyway.

~~~
bad_user
So first of all, I'm not hiring :-P I see your point though and I don't agree.

First of all, the point of the interview isn't to determine whether somebody
is bad, or improperly couched. Surely interviewers would love being able to do
that, but it's not possible to do it in a couple of hours.

During the interview all you get to do is to apply a noise filter to get rid
of the incredibly bad ones. Because without that filter you can get people
that are a very bad fit and that can cost you the project and the morale of
your existing employees. It's incredibly taxing to fire somebody. Every time
it happened to see a colleague being fired, internal discussions, personal
attacks and bad feelings happened internally, every single time and not just
at one company. And then in big corporations, because of the risks involved in
firing people, you get an even worse effect - you see them "promoted".

And with a noise filter you can naturally have many, many false negatives, as
in people that are in fact good, but won't pass the test and interviewers are
willing to have that risk, instead of risking false positives.

Of course, from what you're saying, I think you believe everybody can be
great. Well, yeah, I think everybody can be great at something useful, but not
everybody can be great at something specific. We software developers are too
idealistic at times. I don't see surgeons going around telling other people
that everybody can be a surgeon. That would be a preposterous thing to say.

On the other hand I do think that if companies want good people, they should
invest in education.

> _The whole principle here is that there exists a growing portion of
> developers who can 't be bothered with interview ping pong._

I can agree with that. I'm not into interviewing myself. I'm not into
switching jobs that often either. I can't be bothered with that because I've
got satisfying things to work on already. Capitalism and the free market cuts
both ways, right?

------
dmitrygr
The author claiming he'll never need to do a BFS, and thus does not need to
know it is kind of funny to read. You should never be proud of your ignorance.

Oh, you think you're a front-end dev and will never need to do anything else?
What happened to striving for growth (personal and professional)? Why not
_learn_ how to write a BFS instead of writing a rant about your pride in not
knowing it? Are you really just proud of doing your one thing, doing it well,
and have no interest in ever branching out? If so, it is not surprise nobody
will hire you (who needs a single-use tool?). If not, then also no surprise as
you've shown a complete lack of desire to learn (who needs an inflexible
employee?).

I am further sorry to tell you that your github history is irrelevant. I've
seen _ _my_ _ code on github under 10 names. None of them mine. I'd never
trust anyone's github profile - no reason to believe they wrote the code, they
did it themselves, and how many attemtps of guess-and-check they needed (or
not). You know what I do trust? Your ability to prove your "skills", in
person, under realistic pressure, on demand, and on a schedule. You know, by
solving a problem perhaps a bit out of your comfort zone. Maybe a simple maze?

~~~
Filthy_casual
A jack of all trades isn't inherently better at all trades. There's great
value to be found in a specialist.

And if you're hiring a front-end pay him as such. If you want him to know more
than front-end beforehand, pay him extra.

~~~
dmitrygr
specialist != only know one thing

specialist = know one thing well, many things a little

only know one thing = useless one-time-use-tool whom i will contract for
exactly my one-time-problem and then move on from

------
zeemonkee3
Why don't companies who ask these kinds of CS questions in interviews just put
in the job ad something along the lines of "if you pass the initial filter
we'll invite you for an interview. We'll grill you on some data structures &
algorithms & give you some whiteboard challenges".

Which is absolutely OK. If that's what you're going to do - regardless whether
it's sensible or not - then potential candidates can either ignore your ad,
and save everyone's time, or apply to you knowing what to expect. If a large
enough number of desirable companies do this a candidate might decide to brush
up on CS 101 and interview practice.

That's honest and courteous, instead of ambushing candidates in the interview
stage - when they've taken a precious vacation day and taken the time flying
out to see you. And it saves you time - any candidate you get should know what
to expect.

~~~
Xyik
I've interviewed at companies like this (Amazon / Google / Microsoft) and they
do indeed tell you ahead of time there will give algorithms / data structures
/ coding.

~~~
kkapelon
No they don't. I had interviews with both Amazon and Google and nobody told me
that.

After two years Amazon called be back for a second interview. I told them that
I am not interested if they still have that kind of questions. They said they
don't.

I flew to a different country for that second interview and guess what! They
still asked those kind of questions.

------
k__
Don't get hired then. Just freelance and be done with it.

I as a developer can't understand why anyone skilled wants to be employed.

I was employed for about 7 years and now I'm a freelancer. I don't have to
discuss with my customers that I want to work from home, I just do it. I get
more money than before, I spend less for health insurance and taxes, I start
working when I want and not when some manager wants me in the office. And job
security seems a bit odd considering that everyone is searching for devs and
the demand seems to increase every year.

And the best thing is, I don't need to do dumb interviews anymore. When I
freelance people just ask me for solutions and give me money for them. When I
look for employment for doing exact the same stuff I do as a freelancer,
suddenly they want to know the weirdest stuff and ask me to do dumb tests.

~~~
johnward
"I as a developer can't understand why anyone skilled wants to be employed."

I'm mostly scared of the lack of a "guaranteed" salary. I'm a consultant for
IBM Watson. My skills are in demand. I could probably go on my own for about
$150 an hour; work less and make more. I'm afraid to take that leap though. I
have a family I'm responsible for and live paycheck to paycheck now.

I also have similar experience in my job search but I attribute it mostly to
me just being a failure at interviews.

------
aavz
I'm sorry, but breadth-first-search is a simple and fundamental algorithm and
straightforward to write if you understand the concept and have decent coding
skills. You're just visiting a level of the tree at a time: stick each level
in a list, iterate over it, and append the next level's nodes to the next
list. There's no trick to it.

Not being able to do write a basic BFS algorithm suggests a) you didn't do any
interview prep and b) whatever you've been working on hasn't involved any non-
trivial algorithms.

It doesn't mean you're a bad programmer but if you can't answer a basic BFS
algorithms question I wouldn't trust you to touch code with any non-trivial
algorithms in it.

~~~
geebee
That's reasonable, but I'd like to share an experience I had interviewing a
long time back.

I'd been writing lots of mathematically intensive code for building and
solving large scale linear programs for about a year, and I interviewed at a
job that was doing lots of math-ish business analysis. Code would certainly be
written.

I was incredibly busy, and mainly spent my interview prep on math I thought
would be relevant, though I really didn't adequately prep for the interview.

One of my interview questions involved some simple (really, I must be honest
there, it was simple) recursive tree traversal. I blew it, and I'm pretty sure
this is why they didn't hire me.

Six months later, I had to use quite a bit of tree traversal to model a series
of conditions that had to occur in several possible patterns for a
manufacturing system. Because there were various combinations of events that
would "pass", I used trees to model the system, and I needed to recursively
determine, in the event that the system didn't pass, what possible paths
(including the least cost path) existed to bring the system into compliance.

I picked up my old reference books, reviewed for a couple days, and started
writing code. As I did this, I started to feeling kind of embarrassed about
the questions I had failed, since I was now reminded of how basic they
actually were. I was chatting with a coworker about it and mentioned the
interview, and told him that I could see why they didn't want to hire me.

He's my buddy, so he tends to say nice things, but he said (paraphrasing from
memory): "but wait, doesn't that prove the opposite? The moment you needed to
do tree traversal, you knew exactly where to go look. You know about these
algorithms, you've done them and taken exams on them in the past, you just
don't walk around ready to implement these algorithms on the spot."

So ok, BFS is so basic that I'll probably never forget how to to it again. But
right now, this moment? I'd have to reason back through it. To get really
sharp (especially since I won't know the questions in advance), yeah, I'd have
to hit the books for a while.

Just how many times do I need to re-take my Data Structures and Algorithms
midterm?

~~~
pklausler
How the question is posed really matters. What if the question had been "hey,
you have a starting node in a linked structure, and you want to visit /
collect / search all of the nodes that it can reach, without duplicates",
you'd probably come up with DFS or BFS on the spot because the problem is not
that hard and those are really the only two ways to attack it, and having
found one of the two you'd probably also realize that the other approach could
have been used. Whereas, if just asked to implement DFS or BFS, the question
becomes less about problem solving aptitude and more about memorization.

~~~
geebee
All that is true, but I went through some interviews last year at Google, and
honestly, you really can't afford to be thinking about things like this.
Nobody is going to ask you to just implement DFS, but you may get a problem
that essentially reduces to DFS, if you can see it. In my experience, you
really will be expected to solve this problem at a whiteboard in 45 minutes.
Syntax and so forth won't be an issue, but you can't do too much handwaving,
you really are expected to write code that solves the problem.

If you have to stop and reason your way back through DFS, I'd say there's no
way you'll get this done in 45 minutes. You need to know this stuff _cold_.

Rote memorization is useless, of course, because you won't be able to adapt or
modify these algorithms. But there's a kind of memorization in the level of
sharpness and mental prep you need to have when you walk into those
interviews.

~~~
pklausler
I've conducted hundreds of programming interviews for Google, and I'd expect
any good candidate to need way less than 45 minutes to code up a graph
traversal in arbitrary order, even if I believed that they didn't already know
an algorithm for doing so.

------
liquidise
I recently wrote a post on designing better tech interview questions. [1] But
one thing i never see interviewees do is outright ask, "Wait, what does this
question _actually_ tell you about me?" I find myself asking it in nearly
every interview i go to.

If you ask and your interviewer gets glassy-eyed or gives you the laughably
generic "it shows how well you think algorithmically" you know that you are
being interviewed by someone who has little clue what they are doing. It is a
great way, from your side of the table, to understand if your time is being
wasted right out of the gate.

1: [http://blog.benroux.me/4-steps-to-making-your-interview-
suck...](http://blog.benroux.me/4-steps-to-making-your-interview-suck-less/)

~~~
p4wnc6
"We want to see how you think" is a hallmark of dysfunction. You cannot see
how someone thinks from short interviews and coding puzzles. You just cannot.
Anyone trying to is so far from doing things right that you want to run, don't
walk, away from them.

The only way to really see how someone thinks is to just hire them, work with
them for a while, and fire them if they can't do the job. You can either pay
the costs of hiring and firing (like on-boarding, benefits, administration,
severance) and get useful signal about their performance, or you can spend the
same money by throwing it away on useless shit like HackerRank-style trivia
tests. Per applicant, the HackerRank thing seems cheaper, but you typically
have to spam it across many more applicants, endure losses due to great
candidates who won't agree to your bullshit hiring process, and still end up
firing people sometimes when they pass the trivia but (surprise) it didn't
mean they would be good at the job. So overall, it's just as expensive.

You spend the money either way, might as well get useful signal out of it.

~~~
ktRolster
_The only way to really see how someone thinks is to just hire them, work with
them for a while, and fire them if they can 't do the job._

That's the worst idea ever

~~~
p4wnc6
It's what Netflix does, so your dismissal seems badly placed.

~~~
ktRolster
It looks like Netflix has a fairly lengthy interview process, including
technical questions: [https://www.glassdoor.com/Interview/Netflix-Interview-
Questi...](https://www.glassdoor.com/Interview/Netflix-Interview-
Questions-E11891.htm)

They fire people quickly, sure, but they don't "just hire them" either.

~~~
p4wnc6
Only one or two of those interview descriptions mention anything like the
bullshit tech trivia this thread is about. Most describe take-home problems,
extended design conversations, and technical sessions that are more like
extended conversations.

You seem to infer that the phrase "just hire them" means you do absolutely
zero interviewing, which was not my intention.

When I said "just hire them" I meant "do some obvious stuff, like talk about
their experience, ask a high-level question and expect a discussiony answer,
not short, commoditized trivia, and if based on that stuff it seems
reasonable, then just hire them and don't obsess over cramming more dumb
trivia filters into the process."

I took it for granted that everyone reading this would understand that basic
interview (e.g. talk to someone, ask about their resume items, have a
discussion) is always necessary.

The "just hire them" part is meant to say that people should not get stuck up
their own ass with trying to put together a ridiculous number of commodity
filters up front before getting to that conversation stage, and that the
conversation stage should function more like a rolling basis hire than like a
process in which you tediously examine every candidate first, then go back and
eliminate and re-interview, etc.

I think the Netflix process fits what I'm saying very well.

~~~
ktRolster
_When I said "just hire them" I meant "do some obvious stuff, like talk about
their experience, ask a high-level question and expect a discussiony answer,
not short, commoditized trivia, and if based on that stuff it seems
reasonable, then just hire them and don't obsess over cramming more dumb
trivia filters into the process."_

There's a big difference between the words "just hire them" and what you meant
by those words.

~~~
p4wnc6
I disagree. It's pretty obvious that no one would mean to literally hire
someone with zero screening of any kind. It's unreasonable to read "just hire
them" to mean something that extreme.

~~~
ktRolster
_I disagree. It 's pretty obvious_

ok. It wasn't obvious to me lol

~~~
p4wnc6
It surprises me greatly that you wouldn't account for some base level of
vetting of any candidate, and place my comment in the context of much of the
rest of the thread, which is clearly about whether or not commoditized trivia
testing is a useful way of vetting candidates.

It greatly surprises me that anyone enough in touch with tech to even be
reading Hacker News in the first place would choose to read my comment that
way.

I'm not saying you're wrong or trying to defend my writing. I'm just saying
there's no way in a million lifetimes that I would have anticipated even the
most remote possibility of someone taking it that way, and even after reading
that you saw it that way, my prior is still so heavily weighted towards the
obviousness from context that I still wouldn't ever expect this and doubt that
if I make similar comments in the future, they will adequately account for
someone reading it in the manner in which you did. It's just too unlikely of a
perspective.

------
quantum_nerd
While I do agree with the OP that the tech hiring process "might" be broken, I
noticed a pattern in his interviews: it seems to me like a self-fulfilling
prophecy. From the get go, he already considered the interviewers as enemies
and went in with a mindset that they are out to get him. That wouldn't
probably help calm those nervous nerves, neither would it show your
prospective coworkers that you are someone they would enjoy working with(which
is a fundamental part of the interview, I believe).

I have actually noticed that most tech companies(at least they ones I've had
to deal with, namely Facebook, Google, Amazon, and Microsoft) are doing all
they can to take the guess work out of interviews with training sessions,
resources, etc...

All the OP needs is to change his attitude from cynical to optimistic and I
promise, things will change for him.

Also, BFS (and DFS) are as basic as you can get with algorithms. Either of
them is not longer than 10 lines of codes; just remember that BFS uses a Queue
and DFS a Stack...

------
limaoscarjuliet
I am a VP at a medium size company and I do plenty of interviews. I usually
talk about what people are interested in and then ask one question:

"You are in front of PC/Mac/Mobile screen, type www.cnn.com into browser, and
press enter. A fraction of a second images show up on the screen... How? What
happened? Tell me all you can from key press interrupts to underwater fiber
cables".

This question never failed me. It always shows how deep does one go in their
computer science adventures.

~~~
jerich
Wow. What a great question! I found that I was sitting here answering it to
myself. After starting down a rabbit-hole on how the browser would probably
need to do some GPU initialization, I realized how much fun I'd have talking
through this with someone in an interview.

"Let's see, I guess the wifi radio is going to have to do an RSSI
measurement..."

It actually gave me goosebumps when I realized that I was so caught up in it
and how excited I was getting.

~~~
kragniz
[https://github.com/alex/what-happens-when](https://github.com/alex/what-
happens-when)

------
justsaysmthng
What worries me a lot is the proliferation of these puzzle solving interview
sites which waste candidate's time and prove almost nothing except that the
candidate can solve high school olympiad problems.

Many companies require this as a first step, before even talking to the
candidate.

Apart from the problems being totally unlike what your future work will be
like, the time constraint proves .. what ? That a candidate can "think fast" ?

What about code quality, architecture, design patterns, build systems,
concurrency, etc ?

Here's what I've decided to do when they reply with a coding interview task:

I charge my clients 50 EUR an hour. If you want me to spend 3 hours on a
coding interview as proof that I can code, then I'll expect you to pay me 150
EUR as proof that you can pay.

I think this is fair. Otherwise, I'm going to knock on someone else's door,
were I can talk programming with an actual person, share "war stories" and get
excited about building something cool together.

------
kinai
"I could feel my frustration rise as I am struggling to come up with a
solution on a whiteboard....yep, I am definitely not going to pass this
interview. I ran out of time before coming up with a working solution."

Instead of standing there with nothing its better to be straight up and just
say "No idea mate" and then name reasons why that is but how you'd solve it in
a normal situation. It is a lot about human psychology, showing them that they
want/need you, not vice versa.

Sometimes all it takes is balls and a good amount of "I don't give a fuck"
attitude.

I wouldn't let anyone treat me like Sahat got treated.

~~~
mikearagua
Funny. I'm like that too, if the interviewer isn't focused on the actual
position and what I'd be doing in it and the problem solving and knowledge
surrounding the actual work I'd be doing on a day to day basis, I bail because
it's a bad sign to me that I'm talking to people who are _way_ too comfortable
wasting time.

But luckily I'm usually in the hiring manager's chair these days and my
interviews aren't easy but they're not a stupid game.

~~~
kinai
Yea I once left during an interview when I realized that I don't want to work
there anyway (the atmosphere told me).

------
mixmastamyk
> From this moment on, I would rather be unemployed and homeless rather than
> do another tech interview. Enough is enough.

God, happened to me this year, highlights:

    
    
        - "Do you like to wear a tie to work?"  
          (perhaps because I'm 40-ish)
        - "Tell us about your worst boss."  
          (from three guys with frowns and folded arms)
        - "Do/talk through this sorting problem on the whiteboard/webpage..." 
          (With people watching, clock ticking over $100k in suitcase, gun to head)
    

I gave up as well, am now writing a book on software, unsure it will sell.

------
Bahamut
Yep, the interview process is pretty broken. It took me 5 Google phone screens
before I got invited to an on-site (although one of those phone screens had
the technical phone interview waived due to the team's familiarity with my
skills, but I still got rejected amusingly) - the only reason I made it was
because I failed & learned from each of the previous phone screens enough to
pass.

This is an absolutely awful way to interview. However, the author should learn
some patience & attack the problem. You deal with the cards you're given - it
took me 2 1/2 years of applying to jobs before I lucked into get a job in the
tech industry after grad school, and lots of wtfs in many interviews after I
entered tech. Learning how to take it on the chin and keep going is an
important skill for success - he could learn something from sales in that
respect.

~~~
mixmastamyk
If we (collectively) could fail faster it would help, but currently
interviewing is incredibly time-consuming.

------
cottonseed
As someone hiring right now, I feel your pain and, while I hope I compare
favorably to the interviews your describe, I wish I was better.

My one piece of advice: read Nick Corcodilos's Reinventing the Interview:

[http://www.amazon.com/Ask-Headhunter-Reinventing-
Interview-W...](http://www.amazon.com/Ask-Headhunter-Reinventing-Interview-
Win/dp/0452278015)

The basic idea is demonstrate you can provide value to the company, and you
have the skills to do the job. If you're stuck with a disinterested
interviewer asking irrelevant questions, make it about the job you'll do and
your ability to succeed in the job. He has concrete suggestions. I say, if
they're not open to that and it is clearly not working, tell them you it is
not going to work out and stop the interview rather than enduring another
miserable experience.

------
collyw
Its ironic that I would have done better in these hackerrank type challenges
straight out of university, even though the code I write now is way better.

~~~
aristus
It's not ironic, it's very much by design. It's a bit like the Army. In theory
anyone of any age and background can join up, but the physical requirements
and "culture fit" does a very good job of selecting for young males.

~~~
ryanx435
> It's a bit like the Army. In theory anyone of any age and background can
> join up.

this is patently false. There are very strict requirements for enlisting/being
commissioned [0], including minimum and maximum age for new members, minimum
aptitude tests, and either be a us citizen or a resident alien. Also many
people are disqualified for having a criminal record.

> but the physical requirements and "culture fit" does a very good job of
> selecting for young males.

yes, this makes sense. "Culture fit" must be the reason that every single
military in the history of the world from every culture ever has been heavily
male dominated.

/s

[0] [http://www.military.com/join-armed-forces/join-the-
military-...](http://www.military.com/join-armed-forces/join-the-military-
basic-eligibility.html)

~~~
aristus
Sure, it's 17-34, but the curve of applicants weights heavily toward the left
side. And it's not universal; Grace Hopper joined the Navy at 37. Also also,
the "aptitude test" sounds a lot like that whiteboard process, right? That was
my point. :)

------
Apocryphon
This story serves as an interesting counterpoint to Haseeb Qureshi's interview
experience
([https://news.ycombinator.com/item?id=11552780](https://news.ycombinator.com/item?id=11552780)).
I think some discussion about how he and Sahat's experiences contrast would be
useful.

I almost want to joke that it's Sahat should have done a bootcamp, since that
seems to have been Haseeb's advantage; he learned everything about CS very
recently and freshly, in an environment where he would be absorbing material
that's tech interview fodder. Coupled with Haseeb's intelligence and quickness
in absorbing said material, he must have impressed his interviewers. Whereas,
an experienced developer like Sahat is worse off- ironically, by not being new
to the field, he lacked the advantage of seeing like a fast learner. It's
almost like ageism but specific to how long one has been programming.

And on the subject of hacker bootcamps- I've heard a lot of them not only
teach programming, but how to optimize one's interviewing skills. If bootcamp
graduates are doing well because of that, does that mean there should be
bootcamps for experienced devs who want to switch jobs, just so they can ace
interview questions? And is that really what this industry has come to?
Memorizing algorithms and strategies for passing data structure logic puzzles
in cram schools just to get a job?

------
truetuna
I've had my fair share of bad interviews too. Just recently I was interviewing
for a full stack position with a company that tried to get me to recite "what
happens when I type google.com into my browser". I asked them where they had
gotten idea from and showed them this: [https://github.com/alex/what-happens-
when](https://github.com/alex/what-happens-when). They decided ask me another
question soon after.

Sometimes the questions aren't even related to data structures or algorithms.
I'm OK with those because at least you can somewhat prepare for them. I've
once had an interviewer ask me obscure questions about Netscape 6 (this was
2016 btw).

> I much prefer “homework” projects, even if they involve me working “for
> free”, because I feel like they ask for actual programming skills rather
> than the “guess the algorithm” lottery of phone screens and whiteboard
> coding.

Me too but when you're interviewing with 3+ companies at the same time while
working at your current job, it gets difficult. There was one time where I had
spend my Saturday afternoon maybe 6-8 hours completing their "homework"
project. I got a call back from them a few days later for a follow up
interview and they flat out didn't even bother to ask about the project I had
completed for them. What was the point?

Tech interviews suck.

~~~
odonnellryan
> I got a call back from them a few days later for a follow up interview and
> they flat out didn't even bother to ask about the project I had completed
> for them. What was the point?

It's worse when they give you an _easy_ project that takes you ~30 hrs to
complete, they state it "doesn't have to be finished," then disqualify you
because "why didn't you use a graph database for this problem?"

Oh well. Same company was using Mongo+Node on a new startup from when they
were still in year one. Wish them the best..

------
blubb-fish
Why bother applying at those __super __fancy companies. There are loads of
medium-sized shops with a friendly work atmosphere and reasonable hiring
practices.

Vimeo, Facebook, Google, ... they hire elitists and those design the
interviews. And honestly I doubt their work is at the end of the day more
efficient then that of most other "regular" companies.

~~~
pound
because of money?

------
aetherson
I feel like it's a little weird that one of the author's big examples of a
difficult algorithmic question is breadth-first search. While I agree it's not
something that's very likely to come up much in real work (especially for a
front-end dev!), it's also... not actually hard? You check the current node
for your truth condition, you add its children to a queue, you pop the queue
and do the same thing for that node. If the queue is empty, you return false.

~~~
reitoei
Everything is easy when you know how to do it.

~~~
jldugger
> Everything is easy when you know how to do it.

Yes?

The point of an CS education is just as much to study well known algorithms
and re-apply them to new contexts as it is to invent new ones. In fact, for
most professionals, I'd argue the weighting is well slanted towards
reapplication.

Our dev team previously used FizzBuzz, and found that every applicant was
passing it. So they wanted a new take home programming problem, and internally
their most important criteria was 'demonstrates algorithmic thinking.' They
mostly write and maintain simple Django webapps, so I thought this was a bit
silly, and suggested if they wanted to measure that, give candidates a problem
easily solvable with topological sort. Unfortunately they bit hard and only
found out afterwards that pretty much no applicants solved the problem
correctly. We still hired four people from that round. So in some sense,
turnover within a year will mean that none of our dev team can pass their own
interview.

------
vijucat
Experiment : hire 10% of candidates without conducting any interviews. Use
Machine Learning to quantify internal or external candidates' code quality.
Use that model to score candidates' GitHub. Hire them.

Well, OK, throw in a sociability / not-a-psycho score using LinkedIn or
twitter or whatever.

I'd outsource this to gild.com who seem to know what they're doing.

Methinks management will be surprised at how well these 10% do despite not
passing the usual "What happens when I flip all the color bits in a red-black
tree" or whatever shibboleth is being used these days. Admit it : most work,
even at Google, doesn't involve knowing how self-balancing trees work. On the
other hand, getting things done matters everywhere.

~~~
autotune
One caveat: you can't use Machine Learning to quantify someone's overall
personality and whether you actually _want_ to work with them or not. Sure
they can contribute quality code, but if they come in and have to do a 5
minute breakdance after each contribution or throw a hissy fit when their code
gets critiqued, probably not a good culture fit.

~~~
vijucat
True. Maybe (non-technical) team lunches / one-on-one lunches together before
one seals the deal?

------
fecak
The good news is there are plenty of shops that don't ask these types of
questions in interviews. Most of the companies you mention have a technical
reputation as being elite, and as you say they can hire or interview as they
please.

Everybody can't work for Google, and there may be some that _could_ work for
Google if they were better at interviewing the way Google does (and these
other companies do).

The author harbors some hostility towards the recruiters that have landed him
these interviews. I'm a recruiter, and I too harbor some hostility towards
recruiters when they behave badly.

The recruiters in all of these situations seem to have done the author a
service, and there are no explanations of the recruiters behaving badly (other
than the going silent/no feedback scenario).

Telling recruiters to "F __* OFF " is just blaming the messenger. They didn't
design the interviews, they didn't conduct the technical interviews being
complained about, and they didn't make the decision not to hire. They simply
facilitated the process and relayed the message.

Blame recruiters when they behave badly. Lying about salary ranges, 'bait and
switch' jobs, etc. Don't blame them when they do their jobs, just because you
didn't like the outcome.

------
overcast
So there's really no hope for the self taught without formal algorithm
training. I can start from an idea, build an entire site from the ground up,
including hardware, OS, programming environments,
mysql/oracle/rethinkdb/mongodb/arangodb + all their query languages, backend
nodejs/php/python code, all custom frontend css/stylus/vuejs/js/responsive,
domain / dns / hosts, email servers, deployment and administer the entire
stack. But I guarantee I'd fail every single one of these tests.

I guess I'll go back to building my own projects, because none of this sounds
enjoyable.

~~~
tyingq
The flavor here is very much the Google/Facebook/Apple + Tech Startup crowd.

Dev jobs outside of that little bubble tend to have very different interview
techniques.

------
louden
I have been on the other side of the table and I'm sure I came off as
indifferent. The problem is, I have been thrown into the interview as an
interviewer multiple times with about 1 hour notice when I have many other
things to focus on.

It is definitely a broken process in many companies.

------
user_rob
I sympathise. I have not agreed to tech problems in interviews for years. In
my experience I get more job offers for more $ if I refuse to do them rather
than answering problems either rightly or wrongly. Either makes no difference.
I have even turned offers down because of the stupidity of the interviewers.
Stop doing silly interview questions professionals should be above that.

~~~
lj3
Could you elaborate? When somebody gets you on the phone and says "could you
explain how to reverse a binary search tree?" do you just say "no"?

------
JDiculous
Yes, hiring is ridiculous at big tech companies that everybody wants to work
for. Asking a ton of CS questions is justified if the job is actually CS
heavy, but most front end jobs aren't. The dentist analogy is spot on.

My recommendation is to apply to smaller, lesser known companies. Much much
less bullshit and time wasting. There are enough jobs out there that you don't
have to deal with this bullshit.

Time spent on learning extraneous knowledge solely for the purpose of passing
interviews for jobs that don't actually utilize such knowledge is a massive
waste of society's resources.

------
pjlegato
"Programming trivia" style interviews are the bane of our profession. They
serve primarily to allow the people doing the interview to feel clever and
superior when they discover that the candidate can't implement a red-black
tree from memory on a whiteboard. They tell you little about whether the
person is a good candidate.

There is a school of thought, baffling to me, that suggests that knowledge is
mere rote memorization of facts, so the best way to test people in anything is
to check their memorization of the relevant material. This interviewing style
derives from that school of thought.

This is, of course, utter bullshit, especially given that the details of the
topics chosen are almost entirely irrelevant to the actual job of a software
engineer. A working programmer who re-implements a red-black tree from scratch
is almost always doing it wrong. Someone has already built that and debugged
it and optimized it, and you should be using that implementation, not redoing
it from scratch yourself. The "programming trivia" interview style is like
interviewing an architect by handing them some iron ore and asking them to
smelt high grade steel out of it. That's not what architects do. They buy
premade steel smelted by experts, then use it to build other things.

The solution? Real-world programming as an interview. Either give them a toy
problem, or pay them to do some minor bit of actual work on your system for a
day or two, if that is feasible. Then get out of their way. Give them a laptop
and the Internet, leave them alone for a few hours, and see what they can do.

Afterwards, do a code review. Then discuss their programming and engineering
philosophy.

Why don't people do this? It takes a lot longer, and requires the interviewer
to think more. It's much less cognitive load for the interviewer to memorize
some obscure data structures and ask candidates to recite their construction.

------
raverbashing
And of course we then will have to hear the sad stories of companies saying
"they can't find talent"

And that's not even going into the salary/H1B issue, the problem is much
deeper than that.

\- I was an advocate at first, but take home exercises are pretty much
useless. Because they at best won't fail you. And of course you could have
written a new sorting algorithm that works on O(n) but what you'll get back is
a complaint about coding style

\- Having a github might be nice but as the article says it seems to be also
in the category "won't fail you". It seems to barely matter

\- And of course companies like Google ignore everything and make a test out
of your interview, fail/pass grade, period.

People are probably missing an empathy component or working outside of the "SV
tech clique" where if you don't code for 12h per day and doesn't know all
libraries and algorithms by heart you're not even considered

------
m52go
WOW. I thought I was in a weak spot by being self-taught and scattered.

So just who the hell is passing these inquisitions? What's really necessary?

~~~
TDL
I'm right there with you. There is a lot of FUD on both sides of this issue,
it would be nice to know what the reality of tech interviewing is. I can't
seem to get passed perfunctory phone screens right now (if I even get those.)

------
yownie
I'm currently considering jobs directions too and finally have a name for what
I'm experiencing. "career interview fatigue", it's probably similar to
whatever performing elephants in circuses experience right before they snap.

I think it comes from a decade of experience of being asked to jump through
increasingly ridiculous hoop sizes over time, and complicity cooperating with
this nonsense system in an otherwise analytical logical calling.

------
percept
In jobs or sales or relationships (which is ultimately what this is:
interpersonal relationship dynamics), the best outcomes are effortless. If
there's too much friction, it's probably not going to work out. The best
job/deal/friend/partner will simply fall into your lap, and you'll wonder how
it can be so simple.

The challenge is finding these. Careful filtering can help, but it seems to be
largely a numbers game.

This becomes increasingly difficult, as more companies are infected with these
faddish processes every day.

And there's a cost, of time and money and contentment. To help reduce this,
consider spending increasingly less time on opportunities you deem unlikely to
work out, based on past experience.

I often prequalify jobs--sometimes companies respond, sometimes not, but that
also provides me with useful information.

------
robbiemitchell
Most people are commenting about the technical nature of the interviewers, but
the communication between company and applicant is often broken as well. It's
the difference between not getting an offer and then (a) hating the company or
(b) supporting it and recommending it to other potential applicants. Companies
underestimate these effects.

Once you bring someone in for an interview, you owe them a phone call, with
email as a backup.

~~~
GFischer
Some companies do have good feedback processes.

I was rejected twice by a large company, which both had a much saner interview
process (take-home excercises and much better in-person interviews), and I
still think very highly of it (and I know the people that did get in and they
were indeed very good).

------
was_boring
It's unclear what sort of prep work the author put into each interview, but
interviewing is nothing more than a sales pitch and a "game" to be played.

I'm 100% self taught, having never set foot in a CS classroom, and this is
what I do for every interview process: 1\. Find everything you can about
company and their interview style; 2\. skim over Algorithms in a Nutshell; 3\.
Take an hour to refresh Big O notation; 4\. Read up on "best practices" for
the technologies the company uses.

Finally, after the interview always follow up -- say something nice and
memorable, be humble and express interest in learning their technology stack
_before_ your first day on the job.

I find it takes 2-3 company's before I hit my "interviewing stride".

------
746F7475
Didn't care to read after first rant about hiring process. It just seems like
you are not a fit for Google. People always try to find company which
"culture" fits them, but it also works the other way around, even if you wish
to work for Google, maybe just for the salary or other benefits, if you are
poor fit for the company culture then you are a net loss.

~~~
odonnellryan
I interviewed for Google. I didn't get the job, but they were 100% awesome
people. Even followed up after asking if I had an complaints, or questions, or
anything like that.

~~~
746F7475
I would love to get to experience something like that, but I don't have the
educational merits to even be considered by industry heavy hitters like that.

~~~
odonnellryan
I didn't have the credentials, and I still don't. I just submitted my resume
with a cover letter.

------
tyingq
>> _" The first round started with introductions, followed by a coding
exercise — write a maze solving algorithm. What the fuck?! Seriously?...I am
not a recent college graduate anymore"_

I wonder if just writing a brute-force maze solver, and then explaining that
you are aware better solutions exist...but that you didn't have any memorized,
would have sufficed.

~~~
akadien
If you're sure you don't want the job, turn the tables and say something like
"I have no clue. Can you show me?" Most likely, they don't have a clue either.

~~~
jghn
Unlikely. They have likely asked that question countless times and even if
they couldn't initially they could now.

If you could go back in time to before they've ever seen it, well then yeah, I
agree.

------
jmaley
TLDR: Doesn't know computer science fundamentals, doesn't get hired in a role
that requires computer science fundamentals.

Is this Hacker News or Script-Kiddie News?

~~~
kkapelon
Can you explain why a front-end position _requires_ computer science
fundamentals?

If you are a company and have to select between two front-end developers where
one has a vast portfolio of production apps that you find impressive and the
other knows BFS by heart (but has never shipped something to production), who
would you choose?

~~~
jmaley
Consider a scenario where the developer is required to write a custom
directory tree. Each row contains a caret and a checkbox. When either of these
are clicked, you'll need to perform some sort of tree traversal to ensure
integrity of the view -- for example, checking the checkbox on a row may
require that all children as selected too. Additionally, you may need an
upward traversal to the root to ensure the parents are either in a mixed or
unchecked state.

If the developer doesn't understand performance (or at the very least, basic
tree operations like searching/sorting/traversing), they're going to write
some horrible code. Google and Bloomberg have their pick, they don't want a
shitty developer.

~~~
beeboop
From a front-end developer perspective, I would google "navigation tree
jquery", download some library that does this for me, and be done with it. If
all children of a checkbox need to also be selected, that's like a single like
of jQuery. Worst case scenario, something custom is written, and yeah it's not
the best way and yeah it takes 100 milliseconds instead of 4, but who cares?

~~~
dagw
_Worst case scenario, something custom is written, and yeah it 's not the best
way and yeah it takes 100 milliseconds instead of 4, but who cares?_

The person who has to try to understand what the hell is going on and how to
add new features after the original developer has moved on to other things
probably cares quite a lot. The difference between a good programmer and a
mediocre programmer is not that one can solve the problem and the other can't,
but that the good one can solve the problem in an easy to understand and easy
to maintain way.

~~~
Apocryphon
And the difference between a good organization and a mediocre one is if a
crappy custom solution is caught during code review.

------
eulji
You have to go with the flow. Unfortunately.

They treat you like hobo that came to their kingdom begging for a cookie.

They are the kings and queens and you are nothing just a pathetic beggar.

It's really exhausting and painful to go through it again and again especially
when you know that most of the companies are just wannabe hipsters or the same
corporate hellholes.

They pretend they are on the same level as Rob Pike and alike but what most of
the people do is they write shitty code, shitty UI and shitty everything.

Google is definitely worse they cannot really make a compelling product that
would DIRECTLY earn them money .It's all about ADS.

------
NoMoreNicksLeft
I disagree.

A typical adult has the spare time to study 3-5 algorithms prior to an
upcoming interview, and the algorithm question lottery has room for several
hundred.

This means that the practice of trying to stump them with algorithm questions
provides a strong benefit to hiring managers: can this candidate read my mind
even before I've decided what it is I will ask of him?

They're selecting for psychic powers and do-what-I-want-ness. Which is what
most management in the United States (elsewhere probably, but I'm an
uncultured redneck type... wouldn't know) values.

------
niemyjski
Completely agree with all of your points. I think I'd do horrible in most on
the spot interviews, but give me an ide with intellisense and a book of
advanced algorithms and I'll complete what ever you want. I understand the
most common algorithms but I don't use them hardly ever in all the work I have
done over the past 10 years. Am I implementing a big data search engine, no.
So why would I know all the specifics to that, but given an hour or two of
reading I'd be up to speed and be on top of things.

~~~
odonnellryan
Yeah. I think teaching students algo at college does one thing really well: It
helps them understand runtime in association with the data structures they
will use.

Gives you an intuition of the proper way to implement something before you
know the big picture.

This isn't what interviews are testing: they are testing if you can implement
the algo. That is rarely important.

------
abustamam
I have a job at a startup as a software engineer. I waded through dozens of
interviews like Sahat's. "Do whiteboard problems," "solve this benign
algorithm problem."

The two job offers I did end up getting went something like this:

1\. "Show me a project you worked on. Tell us about it. Tell us about future
features. Okay, implement one of those features right now."

2\. _approaching me after an event I spoke at_ "Hey, are you by chance looking
for a job? We'd love to have you with us." _at "interview"_ "tell me about
your past experience, some projects you worked on, and how you learn new
things."

I feel like both of these "interviews" tackle two very important things as a
software engineer--can you use what you currently know to add a new feature?
And if you don't currently know it, do you know how to find it out?

I didn't know a lick about React, SVG, animation, databases, lodash, es6, or
trees, before I started working at my current job. But because they were able
to see how quickly I could learn new things, I started as a contractor (to
"test the waters" so to speak) and impressed them by proving them right.

And I think that's exactly what companies should strive for--hiring people who
can pick things up quickly. Of course, consulting firms may not have this
luxury, because they need to deliver now now now, but for SaaS companies, I
don't see why this method wouldn't work.

------
pacomerh
You're looking in the wrong companies. Based on the things you're solving
you'd be good for smaller companies or even the startup world. These usually
look at your experience more, and pay more attention to what you've done.
Bigger companies don't care about you, or what you did as much. They want to
test you right there. Bottom line, a smaller organization will value your open
source work more, if that is what you're looking for.

------
jfaucett
I think this boils down to just knowing what you are. Are you a computer
scientist or a programmer? These are two very different things - as much as
many people like to think they are not. To be a good (or very good) general
software programmer you need about as much math and physics as someone who has
completed 9th grade.

Some areas of programming will require specialized math knowledge of course
i.e. basic linear algebra for general game programming, and various algorithms
depending on your specialty. But in any programming field you will almost
never be expected to research new algorithms from scratch - this is the job of
scientists - and your job is just to implement those, and know enough to
choose the right one for the job.

This is just a long winded way of saying, I think a lot of HR departments need
to clear up for themselves what it is they are trying to recruit. If they want
people researching, you are going to need the algorithm/math/physics chops
inside and out, but if you are building 98% of the not so super theoretically
revolutionary products out there in the world, you really just want to hire
people who know how to pick the right tool and then use it i.e. code with it.
And to know how to pick the right tool, you do not need a PHD in CS.

~~~
dryajov
This, thats exactly what I think. We as an industry are so confused about what
we do that it's starting to become a real problem. Engineering is very
different from science and many companies are interviewing as if hiring a
scientist, for what is essentially an engineering role, and when they get
someone that can crack algos left and right, but can't code in real life
situations, they wonder WTF?

------
nfirvine
I've been doing a little interviewing at my company, hiring engineers. I tend
to avoid the pop quiz questions because I, having been asked them in
interviews before, can't imagine they're that valuable, and, considering our
field has plenty of introverts and autism spectrum-types, it's probably not
representative of their abilities in a real work environment.

HOWEVER. One candidate had a PhD and was very agreeable, had lots of
experience in other companies in our field. So I skipped the programming test,
since I figured a PhD with loads of experience _must_ be able to code...

A colleague of mine saw the candidate as they were leaving and ducked. I asked
them why. "Well, I personally lead to them getting fired a few jobs ago."
Turns out Colleague worked very closely with Candidate and Candidate can't
code worth shit: Colleague ended up personally redoing a ton of Candidate's
botched work, Boss noticed Colleague working way late for no good reason, and
after several chances, had to let Candidate go since they couldn't do their
job.

Anyway, I've come to the conclusion that I need to ask in-depth technical
problems, but I'll phrase it like this: "I'd like you to describe an A* path-
finding algorithm the best way you can (pseudocode, diagrams, assembly,
whatever). I'm not looking for a 'correct' answer, or syntax or class
diagrams. I want to watch how you solve problems of which you only have a
vague knowledge. If you'd like to refer to some resource, feel free to ask,
and I'll tell you if I know, or I'll find out."

I suspect this is the point of the technical question, but it's hard to tell
what interviewers actually want.

------
roansh
I agree with the most part of it, some of it doesn't seem quite right. For
instance, where author mentions he is a front-end developer and doesn't need
to deal with algorithms, and data structures -- it only gives a (false?) sense
that he doesn't want to deal with the problems. I agree with the "take-home
problems and submit solutions", idea to assess the candidate (or an
alternative solution could be -- work at their own office, like how you would
if you were an employee on the given problem) This basically strips away the
unnecessary pressure.

Now, about the real problem -- It has to be solved by both the parties, for
instance, somewhere in the middle of the article the author mentions he was
asked to write the BFS algorithm. In this particular scenario, the
interviewers should NOT expect the candidate to actually remember the
algorithm and write the solution right away like a bot (or a human who has
used it very recently) would. Here the interviewers can be more humble, more
human. They should check whether the candidate holds the problem solving
skills which is what is essential and NOT whether the candidate has a
computer-memory. Here, they could explain what BFS is, how it works, and then
give the candidate some time to come up with a solution.

Again, interviewers shouldn't expect a correct solution for the problem, it's
the attitude of the candidate towards the problem, and the way he/she thinks
about it -- that should be enough to give some idea about the skills he/she
holds for problem solving.

The idea is simple. Don't just drop some Dothraki (or some language the
candidate does not know) algorithm names, and ask what it is instead, skip the
names, explain the problem in simple words and ask for solutions.

------
koala_man
OP, it sounds like you work by looking up and remember solutions, and assume
everyone does the same. You're saying the questions are BS because you haven't
seen the solution in a long time (or ever):

> it has been a long time

> I vaguely remember

> this would have been a trivial problem to solve from memory, but that’s
> besides the point

> Do I remember how to implement those algorithms? No

> I am not a recent college graduate anymore who has breadth-first search
> memorized

> I haven’t implemented BFS in years, there is no way I can come up with a
> solution right here and now

> If, and when [...] I will go look it up

I normally wouldn't point it out since it sounds really condescending, but
after
[https://news.ycombinator.com/item?id=11554894](https://news.ycombinator.com/item?id=11554894)
I don't know what to assume anymore:

They don't want you to remember or memorize solutions, they want you to be
able to implement it given just an informally explained approach (which you
may also be responsible for coming up with).

Converting ideas into code without having seen the code before is a realistic,
desirable and not at all uncommon skill.

I don't think it's unreasonable to expect a candidate to be able to write code
given the description "These objects have a value and links to similar
objects. We want to find a certain value by first looking at all our nearest
neighbors, then at their nearest neighbors, then at theirs, and so forth.",
even if they had never heard of graph theory or BFS, or seen code for it
before.

------
rayiner
I don't think the specific interview questions are all that y fair. BFS,
shortest path, etc, are building blocks of computer science and familiarity
with them is a good signal someone has a thorough education in algorithms. If
you're hiring an engineer and he's not familiar with the Bernoulli equation,
or a lawyer who isn't familiar with Marbury v. Madison, that'd give you pause
too.

The real issue is why is a front end developer expected to have an education
in algorithms? Part of the problem is that programmers doing the interviewing
like to show off, instead of focusing on the requirements of the position. I
remember the first time I interviewed someone. His resume said he knew C++, so
I asked him about the intricacies of templates. That revealed that his
knowledge of C++, like that of many people in the early 2000s, extended only
to "C with classes." Gave a negative evaluation. But in retrospect, all our
code was C with classes so what did it matter? I was really just showing off
that I had read TCPPPL.

~~~
vonmoltke
> If you're hiring an engineer and he's not familiar with the Bernoulli
> equation

What discipline are you hiring, and what do you define as "familiar with"? If
I am hiring an electrical engineer, I expect them all to know what Maxwell's
equations are and what they represent. I would only expect an analog, mixed-
signal, or power systems engineer to know how to apply them. Even then I would
expect them to look up the equations.

Engineering has been standing on a foundation of reference books for as long
as the discipline has existed. Engineers are expected to know what the
principles are and how to apply them. They aren't expected to do all this from
memory. The PE exam is a mostly open book test for that reason.

------
ig1
One of the fundamental principles that's coming out of a century of hiring
research is you have to evaluate candidates on the same basis - any other
approach is an invitation to bias and subjective decisions.

If you evaluate two similar candidates, candidate A on their github and
candidate B on their performance on Hackerrank then it's incredibly hard to
fairly compare those two candidates without adding subjective bias.

In practice what happens is the company goes "oh well the person with a github
clearly has more initiative". But is initiative part of your evaluation
process ? - have you ensured you've fairly allowed all candidates to
demonstrate it, or have you ended up evaluating candidates unfairly on totally
different metrics.

If you're hiring you can vastly improve your hiring process by doing two
things: (1) Adopting a standardized structured interview where questions map
directly to your needs and (2) using a work sample test (getting candidates to
do a small piece of work that resembles real-world work as closely as
possible).

------
strictnein
Not sure if it's accurate, but it seems like these inane coding challenges are
more common on the coasts. The only time I've experienced any of them was at
an interview with Amazon (for an Email Deliverability Manager role, of all
things...).

I've been tested on code, but it's never been these inane tidbits everyone
went through getting their CompSci degree. Anecdotal, I know.

~~~
Apocryphon
What cities and kinds of firms did you work at?

~~~
strictnein
Minneapolis area

The last 3-4 years have been at larger corporations. Major retailer and a
division of SAP. Haven't always been at larger corps, but after doing the
startup thing for a couple of years, the stability is relaxing.

I also had job offers from some companies that would be maybe "mature
startups"? Not sure of a good term, but around 5-7 years old, profitable, ~50
employees, etc. One of them had zero programming exercises of any type. Just
tech discussions. None had the questions discussed in this article.

~~~
lj3
I've been looking at companies in Minneapolis over the last few months, but
I've been having a hard time finding open positions to apply to. My usual
methods (online job boards) have gotten me precious few results. How do you
find companies in Minneapolis who need your services?

~~~
strictnein
Little hard to answer without knowing where you're at career-wise and what you
do, but here goes. I haven't been looking for about two years now, and I don't
know if I have any unique insights here, but when I did look there was a
couple of avenues:

\- Job boards: Mainly indeed.com, to be honest. Lot of recruiters on both, but
they do a pretty good job of indexing real job posts as well. I think that's
where I found my current position.

\- Targeting specific companies. Got my previous job this way. If you're
looking in and near Minneapolis itself, Best Buy, Target, US Bank, United
Health, Ameriprise, etc are almost always hiring. So are Medtronic, 3M,
Ecolab, etc, but they're not right in Minneapolis and depending on where
you're at might be quite a drive. If you see a job listing by a recruiter and
it mentions Richfield, MN it's almost certainly Best Buy (like this one -
[http://www.indeed.com/cmp/Palnar-Inc/jobs/Ui-
Developer-c059f...](http://www.indeed.com/cmp/Palnar-Inc/jobs/Ui-
Developer-c059f8967494e689) ) or US Bank (which is actually using about 25% of
Best Buy's HQ now). Best Buy hires a lot of their front end devs as
contractors, so if that's what you're interested in, you probably won't find a
listing on their own website. I was a Front End contractor there for 18
months. Not a bad place really, although the front end dev contractors are
definitely 2nd class citizens. If you're looking for a job at Target, they
host (almost) monthly meetups in their pretty cool Plaza Commons (across
Nicollet Ave from their HQ). Free beer and food, some interesting talks, and
there are Target recruiters there usually - [http://www.meetup.com/Skyway-
Software-Symposium/](http://www.meetup.com/Skyway-Software-Symposium/)

\- Recruiters. A lot of junk here, but there are actually some decent ones out
there who aren't complete idiots. Turning the "Looking for a job" flag on in
Linkedin was enough for me (just make sure you turn off notifications for your
network).

Anyways, hopefully that's helpful (not sure if it will be). Unfortunately, I
can't be more of a help directly as we're not hiring at my office currently (I
think we just filled our latest openings).

------
capote
I think it's perfectly reasonable for interviewers to ask scientific and "non-
practical" questions.

1\. If they just went by open-source contribution and prior experience, the
pool of "qualified" people would be immense. You need some way to narrow them
down, and it's fine for a company to pick their way, be it CS questions or how
handsome someone is (joking) or how easy they are to talk to and interact with
(charisma). It's not just about pushing code--lots of people can do that.

2\. Questions like these are not totally unnecessary. Even though you won't be
dealing with CS questions regularly at work, they still show that you put the
effort in to learn them, and that you can think critically and on the spot to
solve problems.

I don't think hiring is _as_ broken as people make it out to be. Just learn
the science and study up on it a lot before... I even bought a book that is a
summary of common CS problems that interviewers ask. It's not a big deal for
me to just read it up for a couple hours a day for a couple days before my
interview. Good companies are looking for people who are ready to put a lot
more effort in than just brushing up on Dijkstra's algorithm.

Note: One of the greatest things I learned from 5 years of undergraduate
school has nothing to do with coding or science. It's the ability to just shut
up and get some work done. Even if it's hard, unnecessary, or it's difficult
to understand the motivation behind being assigned it, it's a useful ability
(for growing professionally) to just crank out some work when you're told to
do so. Many times, it takes doing the work to understand _why_ you should do
the work. Then that lightbulb turns on and you realize how much you've
benefited from learning Dijkstra's algorithm and applying it to something;
it's pleasant.

------
greatemployee
I sympathize with the author. I have been through this as well. I'm still
going through this, really.

I've been rejected many times. And every time, I come away from the process
annoyed and disappointed, but certain that I would have been useful to them
had they hired me. I research companies thoroughly before going into
interviews, and don't waste time interviewing for positions that I don't think
I'd be interested in / qualified for.

I also have decent GitHub activity, handful of open source projects that
demonstrate my abilities. When I started my new job search I assumed that this
mattered, but in my experience it really doesn't. I still get asked extremely
basic questions that I'd hoped my GitHub would eliminate. In some instances
the company that rejected me had some open source projects, and it made me
feel better about myself to see their poor code quality.

Nevertheless, I am also starting to have doubts about the industry. I've
wasted a lot of time on take-home challenges, introductions, technical phone
screens, on-site interviews, etc. to be rejected without explanation. As an
introvert, it's all very exhausting. Why should I, as a computer programmer,
have to be an amazing socialite that my colleagues would like to vape & play
air hockey with? I just want to work on interesting problems. I'm not
stimulated by extravagant team lunches or interrupting meetings to play with
the company dog. I'm not stimulated by fancy windows and games and snacks and
toys. I'm happy to have technical discussions all day long, but I really don't
want to work in a frat house.

I feel like there's a lot of pressure from the industry to be someone I'm not.
Also, it seems like the Joel Spolsky idea about only hiring exceptional
programmers (at the expense of risking a merely /good/ hire) has seriously
penetrated the industry, making the system highly risk-averse in terms of
hiring. I feel like no amount of prior job experience or open source work will
make a difference. Every time I interview, it's a clean slate, and if I don't
nail _everything_ it's a certain no-hire. Even if I did well in prior
interviews with the company, they simply won't risk it. I would really like to
know what the reasoning is, but they never provide feedback.

I will say that I've been hardened by the experience. I'm better at pitching
myself, making appointments, talking to people in a structured way,
preparation. I think if any startup founders lack experience as sales(wo)men,
there's plenty of opportunity to dial-in your skills by pretending to be a job
candidate strictly for practice.

------
splicer
Whenever I interview someone, I try to follow these principles:

1) Simulate a real work environment. This means a dev machine with full access
to the web. One thing I'm looking for is how good the candidate is a finding
information they don't know.

2) Customize the questions for the job at hand. A software tools dev is a very
different position a firmware dev. I wouldn't, for instance, expect a firmware
dev to know much about regular expressions. And I wouldn't expect someone
interviewing for a scripting job to know much about alignment on ARM.

3) Test your questions on coworkers and friends. You need to get a baseline.
Is there enough time to answer the question? Are people coming up with wide
spectrum of solutions, or do you keep seeing the same response over an over?
Are there parts of the problem that people find unclear?

------
shawn-butler
... I really wish companies would be more transparent about their candidate
rejection reasons. From this day on, I was even more disappointed — both with
myself and tech hiring process — rejection, rejection, rejection. It honestly
feels as if I am a complete failure and an unhirable[sic] candidate...

Companies simply cannot give a reason for rejection. It is a "fake/legitimate"
legal liability HR says exists opening the door to discrimination lawsuits.

My advice is never interview at a company at which you do not have some prior
professional introduction (network, friend, foaf, etc). These people will be
able to give you the real feedback on why you were or were not hired.

Some recruiters with longstanding relationships at the companies they are
placing at will also be able to find out, but may or may not be honest with
you.

------
kkapelon
4 years have passed and nothing has changed
[http://www.unlimitednovelty.com/2011/12/can-you-solve-
this-p...](http://www.unlimitednovelty.com/2011/12/can-you-solve-this-problem-
for-me-on.html)

------
drinchev
Wow! As a person that interviewed other people for front-end developers, here
in Berlin, I would say that I will probably offend half of the candidates if I
ask them to code on a whiteboard.

Not to mention that I would feel offended if I'm asked by a hiring team to
solve complex logic task while visiting an office for a first time.

Usually what I do as an interviewer is to select a bunch of questions out of
[1] github frontend developer interview questions and make a productive
conversation, by asking for opinion on different ways of writing front-end
code.

1 : [https://github.com/h5bp/Front-end-Developer-Interview-
Questi...](https://github.com/h5bp/Front-end-Developer-Interview-Questions)

~~~
ddebernardy
Still, you'd be surprised by how may devs can't do a fizzbuzz. Even amongst
the competent looking ones.

------
20andup
“Never memorize something that you can look up.” \- Albert Einstein

------
jaredcwhite
This is why I refuse to participate in tech industry job interviews. Thus far,
I've managed to get enough work in a freelance capacity mostly through
referrals and my personal network to avoid having to go down that route. I
think it's the height of hypocrisy that tech companies complain that they
can't find enough good candidates and how hard hiring is, yet the absurd
processes they use actually turn off some good candidates who just aren't
interested in playing the game.

Kudos to the author for being so forthcoming about his experience. Maybe if
enough programmers start making a big stink about this problem, something will
actually get done about it.

------
beaubouchard
Interview questions are not pass or fail. They are just there to gauge you're
ability to problem solve and function under pressure. I hated interviewing,
but disliked conducting an interview even more. The problem is people act so
antagonistic when an interviewer challenges their ability, but realistically
your character is whats really under scrutiny.

Having a great resume and stellar github is why you get the call back, an
inability to conduct yourself in a professional manner is why you didn't get
the offer. Especially in newyork, a medium post from an employee could affect
stock prices, you can't have a lose cannon working for you.

------
Tomte
With some helpful nudges you should be able to do a simple BFS. Still, not a
very fruitful interview question, IMO.

What's bugging me about the author is that he dismisses everything that
doesn't have direct relevance to the position.

Projects get finished and you still want to work there. Projects get
reshuffled and you're placed elsewhere. Your role in the organization changes.

If an interviewee showed such a myopic view of his future work I wouldn't be
thrilled. He basically says "let me show you that I'm a one-trick pony", while
the interviewer tries to ascertain his capabilities across several potential
jobs.

------
HillaryBriss
I truly appreciate the OP's honest, detailed accounts of recent interview
experiences. Thanks for writing this.

~~~
serg_chernata
Just chiming in to say I agree. Thanks for being brave enough to vocalize
these things. I'm not even on author's level and that is very concerning.

------
mrdrozdov
I think you may benefit from a change of narrative. Evidence from your
interviews (specifically the Vimeo interview) suggests that your potential
employers have a mixed perception about your skills and experience. I
certainly believe you're capable of being a productive engineer that a company
will value, but it still may take some searching to find the right fit. One of
the benefits of leaning a little more on your network than using recruiter
requests is that it increases the probability of finding the right job.

------
TaylorHu
Life is a video game. Well really a series of minigames. Some of the minigames
aren’t as fun as others, but you have to pass them to move on. Right now
you’re on the ‘get hired as a developer’ minigame. You beat that minigame by
memorizing things like Algorithms and Data Structures.

Yes it’s stupid. Yes it’s not something you’ll ever actually do on the job. No
it’s not a real indicator of your actual programming ability. But it’s what
you have to do to beat this part of the game and move on.

And, yes it sucks, but it’s not THAT hard in the grand scheme of thing.
Basically what’s happening is someone is saying “we’d like to hire you for a
job that pays significantly above the national average, is safe, low stress
and generally pretty easy when you think about it. All we ask in return is
that you brush up on some things that you have already had to learn anyway.”

I would also argue that it’s at least partially about seeing how driven you
are. Everyone knows that you’re probably going to get asked Algorithm and DS
questions in an interview. There are literally several very popular books
entirely dedicated to that fact. So you can either have a self-centered,
egotistical, “I don’t think I should have to know this and I know better than
everyone else so I am not going to learn it” attitude, or an open, eager “I
really want this job and I know they will probably ask me some of these kinds
of questions, so if I have to take a week to brush up on these concepts I am
more than willing to do so attitude.” Which do you think makes for a more
attractive potential employee?

------
ojbyrne
"...almost as if they were looking for a reason not to hire me"

Essentially that's what is going on. Easier to exercise your biases when the
default is "don't hire."

------
maxxxxx
When I interview people I usually ask what they have done and let them explain
to me why some things were done in a certain way, what alternatives they had
thought about and so on. When I can have an intelligent conversation the
candidate usually is a go, otherwise not. I just want to know whether they can
think straight or just repeat memorized stuff.

If you know your stuff you usually can separate bullshitters from good people.

This has worked pretty well for me so far.

------
mirekrusin
Couple of years ago one of London companies did it well IMHO, after little
chat about few technical things (which looked more like Friday night chat in a
pub with colleagues than anything else) they said there's computer in the
corner, here's a problem (it was to use macfuse to implement in-memory virtual
filesystem with basic file ops) - I was left with computer, with internet
connection, I could browse whatever I wanted, nobody was looking over my
shoulder etc. Even though macfuse was a bit crap at that time (kernel would
sometimes panic so i had to reboot machine few times) and I never used macfuse
before - it still felt like there was no pressure. After that quick chat about
written code and next meeting was with CEO about the salary etc, all smooth.

Since then I think one of the best approaches is to come up with work related
problem, leave person to solve it with computer, keyboard, internet etc. with
no time limit (if candidate can't solve the problem, they will give up and
just say it after 2h or so). Quick chat about the code afterwards will tell
you in 1 minute if person understands it and didn't copy pasted solution etc.

------
spenuke
Kind of tangential, but I'm wondering: if he is unable to implement BFS in a
reasonable time, how was he able to implement Math.pow over the phone? Would
this have been a Math.pow that didn't account for fractional exponents?

I spent a few minutes trying to recall how it would work and I couldn't, and
it seems like a fully working Math.pow is a little complex for a gatekeeper
question – or maybe I just forgot the trick.

------
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.

~~~
tehwebguy
Author learned that hiring is broken.

~~~
good_sir_ant
This isn't a fact set in stone. These are objective observations. It
completely depends on the goals of those involved. Even in 'bad' interviews,
there is an argument that there's value there. Is efficiency trending upwards
or downwards in building our professional relationships? It's Impossible to
quantify from these anecdotes.

~~~
js_badboy55
"Even in 'bad' interviews, there is an argument that there's value there."

You must have lost your mind.

------
Mysterix
>If you are going to test my knowledge, at least ask relevant questions for
the role.

Even for a front-end developer, I think that algorithms matter, because
developers have to understand what they do.

And the OP's solution in O(N2), as well as the other one with hash maps, seem
quite bad (it can be done trivially in O(Nlog(N), and optimized to reach O(N))

------
plafl
I think that the kind of interview you get tells a lot about the person that
is interviewing you. I have been interviewed by professors and PhDs, and I
have worked with them too, and never they expected anyone to remember some
specific knowledge from several years ago. Hell, I spent more than 5 years
working on Kalman filters and I don't think I could code the algorithm without
having a look at wikipedia (I always forget the formula for the 'K' matrix). I
remember taking Udacity's course about robotics and when Sebastian Thrunn
appeared on the video and said he always forgot the formula too a tear dropped
from my eye. If someone makes you that kind of specific technical questions my
guess is that they lack enough qualification to better assess you, I don't
care if they work in Google, Facebook or whatever.

------
ljw1001
I don't want to pick on any individual response, but the amount of close-
minded - and arrogant - replies on this thread is pretty sad. The OP has many
valid points. I've interviewed hundreds of candidates - some well, some not so
well - and been interviewed many times. I've had four offers in my last five
interviews, so I'm not bitter about the process, but I do think most interview
processes are far more amateurish than the people they're trying to weed out.

Interviewing should be about finding a fit between a worker and work that
needs to be done. The best predictor of that is past success doing similar
work. It's not about imitating Google's process, and except in increasingly
rare situations, it has very little to do with academic computer science.

And there is never a need to treat anyone rudely. So don't.

------
Grue3
I'd rather solve programming puzzles all day long, but every time I do an
interview I get asked incredibly specific questions about a particular
technology that can only be remembered by rote memorisation and can easily be
Googled. That is, if I even get to the technical interview part.

------
clueless123
What kills me is when you go to the trouble of interviewing , do ok, don't get
the job and then... get called to interview for the exact same job 1 year
later! I mean.. something must be wrong on a (recognizable name) company that
does not fill a position for 1+ year..

~~~
scotty79
I got a job a year later. Interview was very different. Company was growing.
It was same position but they were hiring for that position constantly and
over this year I think at least 10 people were hired for this position. At
least that was the rate at which they hired when I was finally working there
and participated in interviews as senior dev. (no algo puzzles, the only trick
questions were about strange things one encounters when doing JS).

------
onion2k
_If a 960+ days GitHub commit streak doesn’t prove it, then I don’t know what
will._

    
    
        crontab -e
    
        30 9 * * * cd /mycode && git add . && git commit -m "Woo!" && git push
    
        service crond restart
    

Ta da!

~~~
j_s
Agreed: GitHub commit history timing metadata means nothing.

[https://github.com/gelstudios/gitfiti](https://github.com/gelstudios/gitfiti)

------
rafiki6
I share a lot of the author's sentiments and frankly a lot of the tech
interviews I've had were terrible and I've also been on the other side of the
table and made great hiring decisions based on conversations about past
experience rather than grilling the interviewee. BUT at the same time, I think
if we want to change the state of affairs software development and engineering
needs to actually standardise what the body of knowledge that's essential to
the job is, create a testable credential around it and make sure your
candidates pass like in other engineering and tech disciplines. That's really
the solution.

------
educar
Ok, here's a pro tip: never go to tech interviews unless you know exactly what
you are getting hired for. If the recruiter cannot give you this information,
they you know this is what is in store for you. This is a game - some are good
at it and some or not. If you are not good at this "puzzle" interview game,
then simply don't bother since they are just demoralizing and a complete waste
of time.

The best approach to getting hired (especially if you know you are good) is to
reach out via your personal network. Get in via contacts and recommendations.
Always keep pushing your existing coding profile at every point of
interaction.

------
riot504
I interviewed for a different position at a company 2 months ago in Seattle.
Had 3 phone interviews, then got called in for an on-site interview which I
had to fly to requiring me to take 1.5 days off of work. I get there ask them
if this goes well what are the next steps, they proceeded to tell me that I
would need to do a take home assignment that would take a week to complete and
if that went well another on-site interview.

Is that really necessary?

I was going to turn down the position in the end due to cultural differences.
In the end I didn't get the position due to lack of technical proficiency
though I was only asked behavioral questions.

Waste of time.

------
Taylor_OD
Tech recruiter in Chicago here.

So many factors go into hiring someone. Often it comes down to little things
that have nothing to do with someones ability to do the job. Maybe a
particular member of the team really didint like you or the manager and you
went to the same high school and you have a connection.

It's crazy how often I will have a developer flat out rejected after a
technical screening from one company only to go to another company who loves
them and everything they do.

I believe the biggest misconception is that just because someone COULD do the
job means that they will or should get the job. A lot of intangibles affect
the final decision.

------
soham
Context and disclaimer: I run a bootcamp for technical interview prep:
[http://InterviewKickstart.com](http://InterviewKickstart.com).

Your frustration is understandable. But you also have to ask and understand
how our industry has come to this point. There are concrete reasons for it,
and despite this process not being the best, it's the least evil when hiring
is done at scale.

The process is here to stay. If you want to work at some of those companies,
don't overthink it. Just prepare for interviews. It'll also give you a
refreshing perspective to software development.

------
coderKen
I really do know the feeling of no feedback. I agree that hiring is really
broken, only 2 months back I went on various interview rounds for a Front-end
position and couldn't quite understand how an Algorithm would help one with
CSS floats. I think I was lucky to interview with a Startup that really knew
what they wanted and all I had to build was an app. I got the job and I love
the job, I don't think I've ever been more in love with my job like this.

PS: The startup's not American, American startups have an inflated ego.

------
Xyik
No offense, but not knowing BFS is kind of a red flag, even if its for a
front-end position. It's the most basic graph / tree traversal algorithm there
is. And you when you work with the DOM on a daily basis and use libraries that
traverse for you its a good idea to have a basic understanding of whats going
on under the hood. It's like saying you're a good programmer but not
understanding basic concepts about memory management and whether things are
stored on the stack or on the heap.

~~~
tptacek
If I took an interview with a random developer at your firm, drawn at random,
not including you, and I spontaneously asked them to implement Djikstra's
shortest path algorithm from memory, what percentage of them would be able to
do that? Djikstra is not only basic and extremely simple, but it's also an
algorithm that everyone who takes graph theory --- or really, computer science
at all --- learns.

I'm guessing 10%.

~~~
Xyik
They all got through the interview process so I'm pretty confident about 80%
of them would be able to do it and 100% of them would be able to implement
BFS.

Also yes it's a basic graph algorithm everyone learns, but its inherently much
more complicated than BFS which is a simple traversal. It's like bubble sort
vs radix sort ... which makes this kind of a loaded question.

~~~
tptacek
Now, I didn't say BFS, did I? :)

I expect they can all do BFS, because your interview process apparently
requires that.

~~~
Morgawr
The parent was talking about BFS, it's not exactly clear to me why you're
asking about Dijkstra's. The two things are entirely different and, as the
parent said, it's akin to asking bubblesort vs radix sort.

~~~
tptacek
My point is that they are not entirely different; both are academic, simple,
basic applications of the kind of graph theory freshmen learn. Described in
terms of a heap, Djikstra is barely more complicated than BFS.

~~~
Morgawr
BFS is far from academic though, it's a very common tree/graph traversal
algorithm when you want to traverse in-order, like propagation of events in a
UI, or printing contents of a nested data structure for debugging purposes, or
searching for the top-most element in a tree that meets your criteria so you
can insert a new child subtree (very common operation in nested GUI). Hell,
it's not even such an alien concept for a web/frontend developer...

~~~
tptacek
I mean "academic" in the sense of "basic". SPF is one of the most fundamental
problems in applied graph theory.

------
sheriff
Here's an O(N) solution to the `findSum` problem in Ruby:

    
    
      def findSum(array1, array2, sum)
        complements = array1.map{|x| sum - x}.reverse
    
        i = complements.count - 1
        j = array2.count - 1
    
        while i >= 0 && j >= 0
          return true if complements[i] == array2[j]
    
          if complements[i] > array2[j]
            i -= 1
          else
            j -= 1
          end
        end
    
        false
      end

------
onmyway133
To be honest, your voice is a bit aggressive. I like open source as much as
you do. Stars on GitHub repo does not necessarily mean we're skilled or
clever, but it means that project is necessary to many people. You look for a
job, but they look for the correct employee. I don't really like to interview
with a company that I don't feel belong to. And if I do, I will focus my time
on it

------
aregsarkissian
When you go on interviews you should be interviewing them as well. So for
every question they ask you should ask them one as well. If they ask you to
code up something them you should ask them to code up something to see if they
qualify as a group of people you would like to work for. This might not go
well at some companies which should be sign that you don't want to work for
them.

------
marme
I find it funny how many people dont realize the "your next interviewer is out
of office so we are going to end early" is code for were have already decided
to reject you so we dont want to waste any more of our employees time
interviewing you. No company schedules a set number of interviews then decides
to hire someone without doing every one of those interviews

------
master_yoda_1
I don't have any problem with coding question as I enjoy doing that. But what
piss me off is that going into google with referral is a piece of cake and
even if I do good in interview I can't get an offer. I know couple of guys who
don't even do coding and can't write a BSF but they get into google apple and
facebook with referrer. This referrer sucks.

~~~
fjgla
As far as I know referral is just a guarantee that you will be called back
after they see your CV. It doesn't guarantee you getting hired. I've referred
plenty of people and a lot of them never got hired or even failed the
screening phone call.

It just means "hey, try out this guy" and they won't be throwing away your CV
into the pile of hundreds of thousands of CVs they get every year. You still
need to go through everything like everyone else.

------
aluminussoma
The only way out of this mess is to start and bootstrap your own company.
Hiring is broken, therefore hire yourself.

~~~
zeemonkee3
Tell that to someone who has rent and loans to pay, medical needs or family to
feed. Bootstrapping takes savings/investment and a LOT of time before you see
a penny of profit.

~~~
aluminussoma
I am totally empathetic to this. I did not intend for it to be a trite
statement. I'm in the same boat.

Not all ventures require lots of savings. (Time? Definitely). It is
conceivably possible to try and bootstrap something outside of working hours.

The original author was able to devote much time to GitHub projects, so it's
not a stretch that the author might be able to bootstrap an idea.

~~~
zeemonkee3
Sorry, didn't want to come off too harsh. I've gone down the bootstrapping
route before and it's very, very hit and miss. Actually mostly miss.

The skills required to build a product or service people will pay you a
livable wage for are not the same as those needed to write an open-source
library. I've seen people with terrible coding skills make successful products
with a "Rails for Dummies" book on their lap as they go (they hired pros later
to clean up the mess), and I've seen excellent coders flounder with terrible
ideas and business execution.

Personally I'd love to jump off the hiring hamster wheel, but realistically -
outside of consulting (which has its own share of nightmares) - I don't see
that happening even if I do come up with the perfect idea in the shower
tomorrow.

------
FLUX-YOU
I see these same algorithms/concepts show up repeatedly in interview rants
posted here. At this point, if I'm going to interview, I'm just going to cold
memorize them over a week or so and then adapt to the specific interview
questions. It's just a ritual that needs to be done at this point.

------
shade23
I am talking from personal experience here: __Hiring is broken __is a
statement that is often the result of long intensive (and multiple ) interview
processes which is met with sheer frustration.I went through that, cooled down
a bit and came to a conclusion which I would like to share :

Hiring is Broken: Yes it is,but not the process,but the people. When you
interview in a big company(especially a profitable one) you need to realize
they are not looking for a typical skillset. Big (for profit) companies tend
to keep their softwares behind closed doors. Hadoop was open sourced by google
atleast a year after internal usage ,the same goes for Bazel(Blaze internally)
.These were open sourced because they had much better versions of the same
software that were consumed internally.When you reach such levels,performance
factors are as important as

\- ability to ship fast \- writing clean/testable code \- and all the other
things that we programmers/coders are good at.

I am not saying that we aren't good at optimizing. But they are not really
looking for the horde. This could also explain poaching college professors/PhD
candidates for jobs.They need to people to push boundaries,not implement/build
things from existing technologies.There is only so long that you can spend in
a domain without having the need to extend that domain which you have been
working in the past 20 years for.

Regular start-ups and other companies need a product.They need to make a mark
in a field by pleasing the customer who would be using their
products/technologies and who are looking for a service alternative mostly.

That is my justification for such interviews.This changed the way how I even
handled interviews.

If I am asked these algorithmic questions,I generally smile and ask them if
they want a Computer[1] or someone who can use a computer.I Immediately steer
the conversation to what do they expect from me and explain to them what I can
do.Often this clears the air and helps me(stress on the __me __) decide if I
would like to join them. What you need to realize is that its you who is
joining them.The impact that the organization will have on you is normally a
much larger of magnitude in comparison to what you will have on the
organization. The environment you end up working in will mould you in ways
that you cannot anticipate.

PS: There are a couple of people who do the job hunting for the massive salary
hikes and those sort of factors.I guess none of my arguments apply for them .

[2]:[https://en.wikipedia.org/wiki/Human_computer](https://en.wikipedia.org/wiki/Human_computer)

------
JSeymourATL
> When I asked the Vimeo’s recruiter for a feedback — no reply, haven’t heard
> from him ever again. Feedback is too much to ask for these days, apparently.

Corporate feedback is mostly BS. And the rare line from bozo recruiters offer
little of substantive value. It's safer for him to say nothing at all.

------
Cpoll
I'll preface by saying I completely agree with the sentiment of the article.

However, I was taken aback by the author's refusal to try to solve BFS. To me,
it feels like someone should be able to reinvent it relatively easy - that
it's akin to a linked-list, palindrome or FizzBuzz question.

------
jarsin
I always ask where they use those algorithms in their production systems.

The typical answer is that they don't :)

------
linux_devil
Hiring is broken , but not everywhere , its hard to set standard rules for
technical hiring across different organizations , as every organization have
different needs. I had similar experience in few organizations but not all
organization are same.

------
DeadReckoning
I've been asked to solve such tough questions during some interviews. Getting
asked to solve really complicated text search problems using suffix trees in a
45 minute phone screen for a junior Android dev position at a small startup
lol

------
malbs
Just went through this process from the POV of employer.

The risk of choosing the wrong person is so great, that it's often better to
not choose anyone. If there is any doubt what-so-ever, it's better to not make
a a hire, it can be too damaging to a team, manager, company.

I've tried so many different "coding interview" scenarios. But I found the
best one was a real task that a real staff member would be expected to do,
extract it out into its own example, and before I talk to someone, they
present their solution to the task, and the only thing we talk about, is their
solution. If they can dissect and discuss their solution eloquently, and
reason about trade-offs, short-cuts, talk about what they may have done
better....

Of course, it can also be a simple case of, "is this person an asshole? are
they going to rub my team up the wrong way? yes? fuck them."

~~~
joesmo
"The risk of choosing the wrong person is so great"

I assume you don't live in the US or if you do, please elaborate because in
the US there are virtually no such risks with at-will employment. It's so
incredibly easy to fire people in the US that such an idea is actually
ridiculous, yet people keep bringing it up all the time as if it's real.

~~~
mkozlows
Legal barriers are not the only barriers. Many companies don't work with a
quick-fire model. If you, as a hiring manager, hire a person and then fire
them within a month, you're going to need to sit down with your manager and
explain what happened. If you do it twice, they're going to have serious
doubts about whether you're qualified to be a manager.

Plus, it's sociopathic: If someone has a job already, having them quit that
job, start working for you, and then get fired and end up on the street
because it didn't work out... man, that's a jerk move. The manager owes it to
the new hire to be confident that they'll work out.

------
PaulHoule
This is just an indication of what will happen to you if you get the job.

------
atjoslin
Why don't more people do, "We're not 100% sure if you're the right fit, but
we'd like to find out. We'll pay you to work with us for [2/4] weeks."

~~~
jaaron
For most companies, the organizational cost is too high.

There's a cost (in terms of time & money) to onboarding someone, integrating
them into the company and team, and getting them to be productive. That's a
reasonable investment for a long term gain, but for a short probation, it
rarely pays off for the organization. The churn itself just isn't worth it.

Moreover, it means the candidate is in an uncertain state. Should they keep
interviewing if it doesn't work? Should they change their lives and relocate?
Etc.

------
josefresco
Wondering if the "cover your ass" is a factor in these hiring decisions. If
you're the guy/gal who hire a new engineer, who turns out _not_ to know their
stuff, your ass is probably on the line. Making engineering candidates jump
through hoops might provide them with a level of protection against future
reprisals.

While I don't interview for engineering jobs, we do bid on municipal contracts
which are dominated by this concept (cover your ass, hire the big guy). A
different animal indeed, but in a employment hierarchy where employees are
held accountable for performance of new hires, it seems similar incentive
would exist.

------
nouney
"How many people can actually write BFS on the spot, without preparing for it
in advance?" A lot of people. You should too, even if you're just a front-end.

~~~
kkapelon
What about the maze solving question?

Should all front-end developers be able to create a maze solving algorithm on
the spot, during an interview, under time pressure?

~~~
tyingq
I would at least offer something back, like a loop that randomly chooses
left/right, restarts loop if dead end, exit loop if solved. Then verbally walk
through how you might improve on it incrementally.

------
websitescenes
Look for a job at a startup. Way easier to get in the door.

[https://careers.stackoverflow.com/](https://careers.stackoverflow.com/)

------
zappo2938
"Write a maze solving algorithm" I just solved that in less than 3 seconds.
Here is the solution in a Fiddle[0] and the discussion on Stack
Exchange.[1]Sorry, I'm too busy solving problems which haven't been solved yet
to bother with problems that have been solved.

[0]: [http://jsfiddle.net/5g7se8qL/7/](http://jsfiddle.net/5g7se8qL/7/)

[1]: [http://stackoverflow.com/questions/16173259/javascript-
maze-...](http://stackoverflow.com/questions/16173259/javascript-maze-solver-
algorithm)

~~~
LaurenceW1
You wrote that in 3 seconds huh

~~~
tgeo
To be fair, I think he meant he "solved" it by googling and finding a stack
overflow link. He wasn't being literal (I thought he was as well at first).

------
ted12345
I wonder if this has to do with your personality, how you behave under
pressure, and how you react to not knowing the answer to something.

You seem more than capable enough to get a good job but in my experience,
interviewers are looking to see how you react to being stumped. If it's
anger/frustration/clamming up then that's a turn off for a lot of employers.
They're looking for more than the right answer.

~~~
p4wnc6
What if he is merely introverted, and responds well to pressure when there is
not an awkward, immediate social situation? There are lots of excellent
programmers like this, you know, and also very few workplaces that actually
benefit from lots of real-time interpersonal communication (as opposed to
cargo culting that from startup bullshit).

------
eachro
I think this is the wrong sort of attitude to have towards hiring. Maybe
interviews are suboptimal for finding good talent. Whatever. But if you want a
job and you already KNOW the sort of tricks and games go on for these
interviews, then why not just play the game? Do the adequate interview prep
and land the job. It's that simple.

------
halis
Rapid Development and Code Complete by Steve McConnell. Those books are
prescient.

------
AndyMcConachie
If interviews require this much effort people should get paid for their
effort.

------
kogone
a quick fix would be to have feedback of your interview be mandatory if
requested.. kind of like a FOIA request

------
paddy_m
I hired Sahat as an intern three years ago while he was an undergrad. It was
one of the best hiring decisions I have ever made. He was productive
immediately and our (small) team felt the loss when he went back to school.
This guy is good and gets stuff done, ask people who have worked with him.

I wish Sahat had reached out to more of his network before responding to
random recruiters. Tech interviews as Sahat experienced them are broken, but
tech hiring is slightly less broken especially when you leverage your network.

*note this is the same comment I made in the other thread. I stand by it. [https://news.ycombinator.com/item?id=11579757](https://news.ycombinator.com/item?id=11579757)

~~~
swayvil
I'm seeing a lot of "reaching out" in this thread. Is this a new thing, like
"passion"?

~~~
eric-hu
No, quite the opposite. It's an old trick for job searching. It doesn't
originate in tech. It's one reason why people go to networking events in their
industry.

My impression of what reaching out means today is a chat over coffee, lunch,
or less preferably a phone call.

~~~
lj3
What frequently gets looked over is who you're reaching out to. It doesn't do
you any good to reach out to a rank and file developer. You need to reach out
to (is seduce a better word?) somebody with hiring authority in order to
bypass the ridiculousness.

~~~
eric-hu
Personally, I don't mind going through an interview process. I actually find
it strange if a company makes an offer without much of a technical interview,
which has happened before.

------
tacos
I do not think junior people realize what senior people see when they look at
your GitHub work. Without exception, the crappier the _oeurve_ the more the
candidate wants me to look at his or her GitHub.

Read a single user's Tweets going back a month and even your best friend
starts to look a little nuts. Do it with their git history and you'll
sometimes get a very different impression of their work habits, too.

In my experience, these services tend to make people look worse, not better.
But I can't always give the benefit of the doubt when I'm making a critical
hiring decision.

------
dimino
I've been in interviews where those stupid "I have three balls and want to
guarantee the ball I pick is red" questions get asked, and what I've noticed
is if they _want_ to hire me, I can just take vague guesses and they'll help
me along, but if they _don 't want_ to hire me, they'll sit coldly, watching
as I flounder about. By the time I've sat down in the chair, a lot of times
the person hiring has already made a choice. I'm not charismatic enough to
reverse their choice, but I'm not antisocial enough to disqualify myself if
they already like me.

The thing I learned about applying to jobs last time I went through this is
that if your primary goal is obtaining a source of income, you need to send
your resume to ~10 people a day, every day, and go on every possible
interview, and do every possible thing people ask you to do.

You'll still lose a lot of jobs to these techniques, because they're
effectively random, but since it's random, your odds of success increase with
volume. Eventually you'll hit a position that you _do_ just randomly happen to
know the algorithm they're looking for, or they don't ask CS theory questions
(I'm self taught, so theory is a weak point for me as well), and you can talk
about/demonstrate your _actual_ job qualifications, rather than some contrived
talent that's entirely irrelevant to the position.

------
twreactistricky
Tech hiring sucks, and the people who continue to do such a bad job at it seem
to wear their behavior and tactics as a mark of pride.

There are a few companies that make it a point to mention they avoid the kind
of interviews you've been getting. Perhaps try to seek them out rather than
rely on recruiters

------
gcb0
when they don't give you feedback, most of the time it means "you're great but
we also found John OK for 1/3 of the price"

------
cloudjacker
Hey Sahat, one problem is the small sample size any one person can get during
the interview process, so I recently did this process and in one month I
embarked on interviews with 15 companies and progressed to various stages. The
recruiter was Hired.com and I wrote about it here:

[https://gist.github.com/ericlw/16b55e038028e1e4768e](https://gist.github.com/ericlw/16b55e038028e1e4768e)

Because Hired.com prescreens companies and have a limited pool of both types
of companies and types of candidates, it is easier to get a better sample size
based on type of role.

I primarily talk about some of the arbitrary offers, instead of the interview
process. But you might find it interesting too.

------
elcct
Not sure what is the problem. If you don't like the hiring methods of those
companies (I agree those methods are retarded), then you are not their target.
Look for something else. There is plenty of this for everyone.

------
notliketherest
If you don't like Google's hiring process, apply somewhere else. There's
plenty of viarety among a whole host of different companies large and small.
The reality is Google gets hundreds of thousands of candidates a year and has
these processes in place for a reason. The interview machine at Google spans
the entire company and everyone is expected to participate and give detailed
feedback at each stage and "rank" a candidate on a 1-4 scale. You have to have
some sort of normalization in place when you're interviewing at that scale,
it's not enough to say "oh, this guy invented homebrew or this guy has some
cool open source project, let's fast track him." It's unrealistic to think
that. A lot of people complain that Google spends too much time on "things
that don't matter like nuances of algorithms" but I'd disagree with that
point. Google's not in the business of hiring "frontend devs" or "node js
devs" theyre looking to hiring well rounded software engineers that would be
expected to fit in any role given to them org wide. And honestly, it's not
hard to pick up a data structure book and a "software engineer interview
questions" book and study for a few weeks prior. You'd probably do pretty
well.

~~~
metaphorm
I'm not sure why you feel the need to apologize for and defend google's
interviewing practices.

they are entitled to interview in whatever way they choose, but you should
recognize that it is a highly idiosyncratic process that has been widely
criticized by many many many people.

~~~
notliketherest
I can't reply to your other comment but I worked there several years ago. Am I
brilliant? No. Did I study my ass off and understand the company's hiring
practice in and out BECAUSE I WANTED A JOB THERE? absolutely. I didn't go in
with some attitude like this guy in the article and resign myself to failure
because of preconceived notions.

~~~
tehwebguy
You are explaining the problem exactly!

Author spends their time building software; Hired Google employee spent their
time studying to win the interview game.

~~~
notliketherest
You realize that "winning the interview game" consists of what's called
"practicing"? Do you expect to succeed in life by winging it? I'm really taken
aback by how many people think they're entitled to passing job interviews
without preparing for them.

~~~
GFischer
The problem is when the interview has absolutely nothing to do with the day to
day work the hired employee is expected to do.

So someone who wants to be hired has to spend a lot of time and effort
learning stuff that are only marginally useful - knowledge isn't bad per se,
but it might be a bad allocation of resources.

I'm not saying that it is so in Google's case, only that I've seen and
participated in interviews where questions had no relevance to the job
description.

------
dang
HN doesn't bowdlerize, so the first thing to do with the title is take out the
stars. But "Fuck you I quit" is linkbait of the kind that the HN guidelines
ask submitters to take out of titles, so we've replaced that bit with a phrase
from the first sentence.

------
askyourmother
When I hired a plumber for my heating firm, I put her through a hazing
interview, tested her knowledge of Maxwell relations and thermodynamic
equations. Oh wait, no I didn't. As she has been a plumber for years, so we
recognised her skill and experience and cut to the chase.

When I hired a programmer for our doomed to die VC life support funded fart of
a project, we put her through numerous rounds of comp sci bingo and algorithm
hell. Why? Not sure. Everyone else does. I mean, hiring in IT is shit, why
should we break from the industry norm? Why should we want to care about the
candidates? Right? I mean if Google can do it...

~~~
wdewind
I frequently hear this basic point: "Software interviews test algorithms and
data structures that are so _clearly_ not relevant to the work being done and
soooo theoretical I don't understand why interviewing isn't better???"

I used to believe this myself, mostly because I didn't have a strong CS
background and was still successful at carrying out software projects at a
relatively high level.

The truth is, as I learned more CS I learned that these things are actually
pretty crucial. Not necessarily for executing one single project, but for
building a large system that scales reasonably? Absolutely. I spent years
reinventing the wheel of basic data structures and algos simply because I did
not know them or how to use them.

Bottom line: I would not want to work with the me of 5 years ago because I
wrote shitty code while proudly proclaiming that CS was theoretical bullshit
that didn't matter in web development, and I think many people who make these
types of claims really just don't understand how applicable a good CS
foundation is.

I'd agree that ideally you want some kind of work sample as well. Either an OS
contribution, github or even small project written specifically for the
interview. You can't ask someone to write enough code on an interview that you
really see what happens when they have to structure a real project (ie:
thousands of lines) or work within a real system (ie: millions of lines). This
is where CS foundations in interviews have their relevancy.

~~~
mkohlmyr
I think you are both taking extreme sides of this argument when there is a
very reasonable middle ground

Should a programmer you hire be able to reason about CS problems? Yes. Do they
need to be able to write out the best possible solution to a problem on a
whiteboard within 15 minutes? No.

The white-board sessions only really serve to intimidate people who aren't
good public speakers, think better with some time and peace and quiet, or
simply haven't bothered to memorize code they never have to write from
scratch.

Legitimately bad candidates could just as efficiently be eliminated by having
a casual discussion about a CS concept that relates to the job description.

~~~
wdewind
I totally agree with this. In one of my other replies I mentioned the concept
of having multiple paths for a candidate to be successful through, and I agree
that "whiteboard coding" should not be the only way to prove you are smart and
competent.

------
morning_star
You know what other type of people are not very pleasant to work with? Nerds
who think they can trace a psychological profile of a person based on a blog
post.

~~~
dang
Even if you're right, an escalating personal attack is exactly the wrong way
to respond. Please don't do this here.

A better reply might simply have pointed out that there isn't enough
information to draw such a conclusion.

We detached this subthread from
[https://news.ycombinator.com/item?id=11581129](https://news.ycombinator.com/item?id=11581129)
and marked it off-topic.

