
Hiring Is Broken - zerogvt
https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-broken-bb8f3a48d324
======
Stoids
Yikes... Interviewing sucks but half the reason interviewers ask these types
of questions is to see your attitude and how you respond. Writing an Instagram
clone in Angular doesn't really tell me much about your problem solving skills
when faced with a unique problem.

> How many people can actually write BFS on the spot, without preparing for it
> in advance?

Ughhh, should I tell him?

> why would they ask me this question, what does breadth-first search has to
> do with front-end development

Tree data structures are really common in front-end.. like the DOM or JSON.

~~~
y-c-o-m-b
This feels condescending.

I've been developing for well over a decade as full stack engineer. I've
worked as a successful software dev at some big corporations (like Intel, and
yes it was fulltime for several years) and almost always outperformed my
peers. I work in finance now where everything is about managing portfolios for
people - lots of numbers and heavy calculations.

I have no fucking clue how to write a BFS. I've never needed to know how to
write a BFS. I will probably never need to know how to write a BFS. Coders
like me write business applications where these things are literally never an
issue. If there's something I need to know and don't, I simply research it.
That's the point he's trying to make. Don't interview people on algorithms
they will never ever use. It's as simple as that.

There are more productive ways to interview someone; for example take a bug in
your product and see if the candidate can fix it. Or if you're worried about
sharing proprietary info, then make a sample program that simulates a bug or
feature that your application will use and observe the candidate working on
that.

~~~
castis
The theoretical interview was never about writing a BFS. Its about how you
approach answering the question.

~~~
eagsalazar2
The fallacy here is that you are actually getting to observe people's problem
solving approach when asking them questions like this (vs their ability to
talk) and that your subjective perception of someone's problem solving ability
in those situations maps to actual job performance at all (vs your own
biases).

~~~
castis
The entire point is that I _am_ gauging their ability to talk with me through
something they may or may not be uncomfortable with. This has worked well in
the past and most people deal with this favorably.

If their response is "this is stupid, no one has to know how to do this" and
storm out with the same indignation that is present in half of these comments
then they are not the ones who dodged a bullet.

------
alexandercrohde
The thing that appears to me, most overpoweringly, is the bitterness.

I understand, I've felt bitter about interviews before, I'm sure some
interviews were unfair. But I also recognize this bitterness is a weakness of
mine, unproductive, unattractive.

The way the author indulges in this resentment would make me very cautious
about recommending him regardless of technical capability. An employee who has
low tolerance for the massive randomness/unfairness in the world probably
would get sick of most companies pretty quickly.

~~~
ptero
This was my impression as well. There were likely real issues that made the
process annoying, but the tone of the post is basically "how dare you ask me
those stupid questions at the interview you invited me to?".

On site interviews usually evaluate not only technical competency but also
whether that person is OK to work with, especially during crunch times. Being
able to point to a few github projects is good, but not sufficient. When faced
with a question one cannot answer staying positive and trying a few options is
often sufficient to get off the hook.

~~~
zanny
It _is_ insulting to someone with tens of thousands of lines of public code in
open source. You can work at a tech giant for half a decade and slip under the
radar with no way to prove or disprove your competency there unless you can
get references from the job, but for those who have put out tons of work for
free having those who want them to write code for them asking for grade school
pop questionnaires is an insult to their expertise.

You don't ask a published drug researcher with patents or papers written to
build simple molecules out of building blocks during the interview, but in
software even senior engineers are asked to regurgitate things from CS202 for
decades on end instead of actually acknowledging their accomplishments or
talking about their legitimate capabilities.

------
SamWhited
> I really wish companies would be more transparent about their candidate
> rejection reasons

I always wish this too. At my previous job a (also at BigCorp) candidate
reached out to ask why they hadn't been selected so I started putting together
a little email for them trying to give polite feedback and encouraging them to
apply again in a few years (they were great, but we needed a more senior role
and had no open junior positions at that time). I asked my boss to review it
and make sure it was okay, and he told me that under no circumstances do we
ever give candidates feedback because if you say one wrong thing it's a
lawsuit waiting to happen. Having been on the interview side where I really
wanted to know how I could have done better, I was a bit angry on behalf of
the candidate.

~~~
faitswulff
> under no circumstances do we ever give candidates feedback because if you
> say one wrong thing it's a lawsuit waiting to happen

Wow, how widespread is this? I've _always_ asked for feedback and I've gotten
meaningful feedback _maybe_ once.

~~~
scarmig
Universal, for all the companies I've worked at.

~~~
adjkant
Seconding this.

------
cal5k
Hiring is hard. It's very difficult to figure out what combination of
activities/questions will correlate to actual job performance, not to mention
uncover someone's day-to-day personality when their guard is up.

With that said, my interview process basically is:

* 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further

* 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job

* If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along

That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake
we try to recognize it within 6 weeks of the person starting in that position.

~~~
anderber
This seems like a reasonable process. However, for me personally, I have a big
portfolio of side projects with open-source code. And it irks me if a company
asks me to prove my programming skills by wasting my time doing some silly
tests, where if they just read my code we would be able to skip it. From all
the places I've worked, the companies with the better programmers were the
ones where they actually looked at your past code and had hardly any exercise
or test.

I think the 6-week "probation" period is an excellent idea. Since most of the
time you can recognize if they are a good fit or not.

~~~
quasse
One problem I have with this is that tons of people like to push the "GitHub
is my resume" thing, but 75% of the time they have 25+ "forked" copies of
major open source projects with maybe one or two extra commits on top.

It can be a real drag to try and suss out who actually has real contributions
or real original work on their GitHub. Our approach for hiring is to actually
have people cherry pick out one or two items they're really proud of and have
them send a brief overview / sample.

That approach is also nice, because it gives you a great interview starting
point to dig into a technical item that they (should be) comfortable with and
passionate about.

~~~
noobiemcfoob
Your cherry picking idea is fine, but your reasoning for it is bs. If someone
wrote the code (or read it enough to grok it), asking them some questions on
the internals will sift out who just copied some free repos.

------
40acres
I think developers complain way to much about the interview process. The fact
of the matter is that it's very clear what type of questions will be asked for
most technical interviews and there is a wealth of resources available to
prepare. The ROI on spending a couple of weeks preparing is definitely worth
the possibility of a substantial raise at a big technology company.

I can't think of another industry that is as high paying as software
development, with such a low barrier to entry (formal education matters less
and less) with such transparency regarding the interview process (books,
blogs, literal guides from the company itself). And HN is flooded with a
couple of posts like this every single month, is it perfect? No. What is? At
the end of the day this just looks like entitlement.

~~~
zanny
It is a total failure of industry to ask people who are productively writing
software one day to waste dozens of hours learning to dance an artificial
interview game to get hired somewhere to start writing productive software
again weeks later.

If the candidate has no resume and nothing to prove they have any skill then
yes, give them a rigamarole. But for don't ask a staff artist to speedpaint
you the view out the window with crayons in a lined paper binder in half an
hour. They give you their porfolio, you inspect it, and if they are accredited
and recognized you don't waste their time on quizbowl.

Arguing about it though is mostly pointless. The awareness is out there that
these companies are throwing away not just the on hand candidates they turn
down for failing their charade game but also the legions of potential
employees turned off by the theatrics and immaturity of software hiring. The
OP is absolutely right to say interviewing in tech is _draining_ because you
go from thinking yourself competent on the outside to interviewers trying to
beat you into a sobbing mess on the inside. Its adversarial from the start at
almost every company, it certainly contributes in large part to the lack of
women participating in development, and businesses seem to be just fine with
the outcomes since they know what they are doing is awful but so long as they
are "hip" and popular they can get away with it, with an endless list of
potential hires to give the rigamarole to.

~~~
otras
> if they are accredited and recognized

This jumped out at me. What do you think is analogous to that accreditation in
the software industry?

~~~
zanny
A portfolio of shipped code, preferably open source. No different than how an
artist might have to jump through a lot of shit to get hired if they don't
have a substantial show of work, but if they do, you are often fast tracked
into employment.

That doesn't preclude spending some time to insure your candidate isn't
plagiarizing their cited works, but that is a problem other industries have
solved well for years without turning the process into an adversarial circus.

------
joshstrange
Can we get a (2016) added to this?

Also previous discussion:
[https://news.ycombinator.com/item?id=11579757](https://news.ycombinator.com/item?id=11579757)

------
ebg13
> _The first round started with introductions, followed by a coding exercise —
> write a maze solving algorithm. What the fuck?! Seriously? Mind you, this
> was an interview for a front-end developer position and I am not a recent
> college graduate anymore._

If you balk at breaking down a relatively simple and straightforward problem
into approachable steps that a computer can interpret, then what exactly do
you think that programming is? You don't need to _know_ the algorithm. You
need to be able to think like a problem solver. And if you can't do that, then
what exactly are you doing?

> _Anyway, that did not go too well, obviously, because it has been a long
> time since I took an Artificial Intelligence course in college_

You should be able to do this even if you've never done it before. You have a
start, you have an end, and you have decisions to make to get from the start
to the end. That's the literal definition of programming.

The only people I know who think that basic pathfinding is some voodoo dark
magic artificial intelligence problem and not just a simple straightforward
algorithmic process that you should be able to do in your sleep for the rest
of your life immediately after the first week of Intro CS 100 are not software
engineers.

~~~
lkbm
> If you balk at breaking down a relatively simple and straightforward problem
> into approachable steps that a computer can interpret, then what exactly do
> you think that programming is?

Programmers tend to be good at putting their head down and solving a problem.
They tend to be very bad at live coding for someone whose job is to judge you.

A hiring process that measures you on the latter rather than the former is
broken. It's like interviewing a novelist by asking them to extemporize a
speech for you.

It's very annoying that every attempt to make the case against the latter is
met with people equating it with the former. _They 're very different skills._

Maybe for some people evaluating performance in live coding is a good proxy
for evaluating their programming ability in general, but it's pretty obvious
that there are a ton of excellent programmers for which it's a _terrible_
proxy.

~~~
ebg13
> _Programmers tend to..._

Please don't generalize about people this way. It's not useful, and it's
almost certainly a bad idea to hand-wave away not being able to think through
something trivial with an audience.

If someone asks you to identify whether a bird in a photo is having a good day
or a bad day, then it's reasonable for you to say "Wait, what?" Because that's
a research problem that covers a whole host of different subjects (bird
psychology, for one) and doesn't have a solution.

If someone asks you to implement efficient image segmentation, something that
you probably don't know how to do unless you have a PhD in computer vision,
then it's reasonable for you to say "I don't know how to do that but I can go
home and research how to do it".

But OP wasn't asked to solve a hard problem. OP was asked to solve an
incredibly simple problem and got angry about it.

> _It 's like interviewing a novelist by asking them to extemporize a speech
> for you._

OPs given scenario is more like interviewing a novelist by asking them to put
a handful of words in an order that constructs a grammatically sound sentence.
If you can't do that, then they don't want your novel.

------
Twirrim
"I really wish companies would be more transparent about their candidate
rejection reasons."

There is just too much legal risk from doing so. Too much risk of wording
being misinterpreted and being turned around to be discrimination etc. To
provide feedback you'd have to have so much oversight and absolutely
ridiculous levels of paranoia about the potential interpretations of what
you'd said that the risk is just not worth it.

The value giving feedback to candidates provides to the company is next-to-
nothing as well, especially for the larger companies.

~~~
maxxxxx
"There is just too much legal risk from doing so"

How about having them sign an agreement that the candidate would under no
circumstances sue the company for the rejection? I would sign it in a
heartbeat if I received some feedback.

~~~
tick_tock_tick
Most state explicitly do not allow a person to give up their right to sue
based on discrimination. Such a contract would be unenforceable and perhaps
even used as evidence in a discrimination case.

------
georgeecollins
There is a hiring infrastructure which is sort of like those dating apps that
say they want you to find true love but really they want you to keep dating. I
am thinking of a lot of HR at companies, recruiters, and people that enjoy
interviewing. I have worked at startups that weren't really growing that fast
but we're always interviewing to fill in the churn. Interviewing feels
productive, feels like a company is growing. They say: We only accept the best
so any test is reasonable. This tends to discount people's accomplishments and
the idea that smart people can learn.

The internet makes it possible screen a zillion candidates, so like dating it
feels like there are a million fish in the sea. Why value anyone's time when
there is so many to consider? I was thinking about putting my CV for a very
senior role and before you could put it in they made you take this like web IQ
test. Seriously? I would worry about anyone who go through that for a job that
expected more than ten years high level experience. Pass.

------
bluejay2387
The core problem IMHO is that a great many of the people hiring developers are
not themselves developers and have little to no technical knowledge. Companies
depend on these ridiculous hiring processes because many decision makers
believe it allows them evaluate candidates that they have no other way to
evaluate. They see Google using these approaches and figure if it is good
enough for Google it is good enough for them -- not realizing that Google is
an entirely different situation with needs that don't match their own (Note to
99% of companies in existence, you are NOT Google and Facebook). I speak from
experience. I have been hiring and managing IT staff for 20 years. I also
happen to have 25 years of experience in development and infrastructure. One
of my priorities when taking over an IT division is to get rid of these
useless tests and I have received push back from internal recruiters, HR, and
non-technical management every time I have attempted to do this. It requires
moving a good percentage of of the hiring process from non-technical
management to the IT staff and its not an easy change. Recruiters and non-
technical management see it as a threat to their positions. Until there is a
realization that you have to know something about a topic to judge the
skillsets of others I don't see this improving (I expect that to happen...
never).

------
nunez
I disagree with the OP's premise. Yes, nobody is going to write a BFS or
`Math.pow()` on the spot, but it's way too easy for people to bullshit about
their experience to rely on that alone, so BFS and `Math.pow()` is what we've
got to work with. While I'm a proponent of giving interviewers a bit of
homework and making the interview a pairing session, there are plenty of
people that complain about this being free labor (even if it isn't). OP
mentioned earlier that looking these up is easy enough, so what's the harm in
looking these up before the interview so you can get that out of the way?

Also, failing five face-to-face interviews smells of personality or culture
fit issues, not tech issues, IMO. I've interviewed tons of people over the
years, and the ones that pass the phone screen but fail the tech screen
usually failed due to poor culture fit (or padding their knowledge a little
too much). I would see if it's possible to message one of your past
interviewers and ask for a honest opinion of what they thought of you. While
you're unlikely to get a response (giving interview feedback is, sadly, a big
HR no-no), some people might budge on your offer.

Good luck?

------
devonkim
I'm not exactly a gifted programmer or anything but a BFS seems pretty
reasonable in an interview depending upon the amount of rigor / efficiency
being demanded. I remember doing it for one of my very first interviews where
I was asked to implement a website crawler and hold onto URLs. Having written
a lot of them while trying to scrape sites for info before every other site
had an API, this was super fast for me and was a very practical problem. It's
not like they're asking for a topological sort of a graph where you can use
Prim v. Kruskal and now you have to make sure you remember that near the
neurons that activated your memory of your 3rd week of sophomore year 2nd
semester when you had a really nasty cold. If you haven't heard of breadth-
first v. depth-first that should be simple.

I do this problem constantly on my laptop when I'm looking for files and start
getting annoyed at how long a search is taking. You start applying -maxdepth
to a find command and fumble through directories perhaps and do a for loop.
This is how I wind up doing a crude variant of k means clustering using cut,
sort, uniq, and some creative use of awk when trawling through a bunch of log
files.

But I do feel that anyone pretty serious about programming as a career
understands there's little to be gained by more or less bitching about the
state of hiring and a lot more to be gained by spending a few hours or so
working on some problem sets occasionally. We're all busy and have to keep our
technical knowledge up to date of course, but almost every well paid
professional has to do this (doctors and lawyers are required to do this to
even practice, in fact). I don't bother interviewing for FAANGS because my
brain's fried and burn-out makes working on interview prep an order magnitude
harder, but I don't go around blaming everyone for acting in their own self
interest either.

------
stunt
In this regard, A lot of interviews are designed to test soft skills.

I know many recruitment teams aim for soft skills first because they don't
want to bother their technical staff if a candidate is not a good match.

Many algorithm questions are designed intentionally to see how you tackle an
uncommon problem or even an unfair situation and to see if you have a strategy
to solve it. Of course, a candidate invited for front-end position at a decent
company knows how to tackle his common tasks regardless of how complex they
are in comparison.

However, that is definitely not true about all interviews. Many companies just
copy these interview formats without understanding what is the actual idea
behind them. Or how to facilitate these interviews correctly with different
candidates from different cultures in different situations.

But you shouldn't go to interviews with this assumption. I'm sure at least one
of those BigCorps had a professional recruiter.

After all, hiring a professional recruiter is as hard as hiring a good
software engineer.

~~~
craig1f
This is a good answer. I was talking to someone at a company that actually
used questions like this.

He asked me a question like "You're shrunk down to a couple inches in height
and put inside a blender. How do you escape?"

My response was "Is there anything else in the blender? Can I see anything
nearby?"

He told me that I "already passed", but if it was an interview, we'd probably
have a 1 or 2 minute conversation about it and then move on. The fact that I
didn't start rattling off ideas, but instead asked smart questions, was what
he was looking for.

It's easier to take a measure of someone if they can't figure out what they're
being judged on. If they know how they're being judged, they optimize for just
that one thing.

------
rossdavidh
I believe the fundamental problem is, most organizations interview in a style
similar to testing in college: ask a question about a technical topic,
evaluate if the answer is correct. This doesn't correlate especially well to
how well a candidate will program if you hire them, but it's the method people
learned in school for evaluating someone's knowledge of a topic, so it's what
they use. Most developers, and most managers, have almost no training on how
to interview well in order to determine who would be a good candidate, so they
fall back on the only halfway-similar experience they have.

Now, this raises the question of why our society's method of educating people
(or determining if that education has been effective) is not very well
correlated to their real-world performance, but that's a whole 'nother
conversation.

~~~
mattkrause
The weird part is that this is almost exclusively found in organizations that
think of themselves as "tech"-y.

I work somewhere on the border between neuroscience and machine learning.
Interviewing in a "neuro" group usually involves a lot of talking--what you've
done on project X, how would you approach Y, what do you know about Z. Coding
does come up, but in the context of stuff that I've done or would do on the
job.

Applying for a very similar job in a tech company usually starts with me
reversing strings on a whiteboard or abusing C++ templates to calculate
factorials or something....

~~~
Ngunyan
Exactly. I worked in Business Intelligence and having both an accountant and a
programmer background, whiteboard coding never comes up in interviews. Its
more domain knowledge that's important, which is mostly about
finance/accountancy.

------
vram22
Breadth-First Search (BFS) and Depth-First Search (DFS) are actually both
pretty interesting algorithms (although relatively simple for the basic cases
- there are some variations), partly because of their applications.

It's actually initially a bit surprising that BFS has such a simple algorithm
using a queue, as mentioned elsewhere in this thread and in the Wikipedia
article about it [1]. Might be non-intuitive on first look, but then turns out
to make perfect sense.

[1] [https://en.wikipedia.org/wiki/Breadth-
first_search](https://en.wikipedia.org/wiki/Breadth-first_search)

[https://en.wikipedia.org/wiki/Depth-
first_search](https://en.wikipedia.org/wiki/Depth-first_search)

~~~
megous
And this being front-end, ie. JS, you can just use map/flat in a loop to get
breadth first traversal.

    
    
       function bfs(list, cb) {
           while (list.length > 0) {
               let i = list.find(cb);
               if (i) return i;
    
               list = list.map(i => i.cn || []).flat();
           }
       }

~~~
vram22
Interesting, thanks. The Go Programming Language book also has a couple of
nice examples of DFS and BFS, in the middle chapters. One is for sorting
courses by prerequisites, and the other is for a web crawler, IIRC.

------
blunte
Many (most?) programming jobs are about understanding the tools and libraries
of an ecosystem well enough to build something useful.

When I interview people, I want to know if they can think. I want to know what
their attitude will be like (to work with/near them). I want to know what gets
them excited (in the context of work, mind you).

The older and/or more things a candidate has done in their life, the more
accumulated wisdom they will have. This will translate into making better
choices earlier (about approaches to problem solving). Testing against
university compsci concepts is more likely to get a candidate who will either
ignore a well tested and commonly understood library in favor of rolling their
own (less-maintainable) code.

------
normal_man
This guy probably got a negative reaction because he says "hiring is broken",
when what he meant was "my strategy for getting hired is broken." The goal of
"hiring" is for companies to satisfy their needs, not to guarantee that every
smart person that comes their way gets a job. A "hiring is broken" article
coming from the position of a hiring manager would carry more weight.

Also I've never heard of this guy, not sure his handful of Medium articles and
cookie-cutter tutorials is sufficient justification for his belief that Google
should be lucky to talk to him.

~~~
NotAnEconomist
I've had a 100% success rate at getting an offer once I realized the problem
was _me_. (And I've had some bad interviews in my life before I got there, for
sure.)

If the company doesn't extend an offer, it's because _I_ didn't show them the
value I can deliver their organization. Either I didn't present myself as a
teammate that makes the group stronger or I didn't present the technical
skills to make them realize the talent I bring individually.

Maybe I'm lucky -- it's a low sample size.

But I suspect that we all can do better at interviewing and at selling
ourselves. Traditionally, that's a weakness in engineers.

It's also why, when I'm interviewing, I try to remind applicants what I need:
give me something, anything I can use to sell you to my manager -- to argue
"yeah, this cool guy is the right business choice". Help me help you. If you
can't, you won't get hired.

~~~
extra88
You are lucky, it's always possible to fully show the value one can deliver
but for there to be another candidate who they decide will deliver more value.

I agree that it's common for interviewees to sell themselves well.

------
kskdndnsn
Usually the people that says hiring isn’t brokens are the ones that benefit
most from it. Algorithms and programming are not one and the same. The overlap
but knowing algorithms tells me nothing about your knowledge of programming.

You know what I would be more interested in candidates knowing? Solving
problems that have no immediate answers. For example, understanding how to
architect a program without using a framework, Debugging a bug even though you
know nothing about the library you are using (eg. Be able to read code and
race the problem), and understanding the difference between algorithm and
architecture in overall performance of a system.

You can memorise algorithms. You can’t memorise problem solving and
architecture. Albert Einstein said something along the lines of, “Don’t
memorise knowledge that you can look up in a textbook.”

What have you learned since becoming a programmer? Did you push your knowledge
of programming or are you rushing to the next hype framework? I see many more
of the latter than the former.

Knowing algorithms is like optimising for the flow of water for your tap in
the house without understanding how the pipes layout affects the overall
output. And that’s the problem when you only work on one small section of the
program your entire career.

Apologies for the rant..

------
drugme
_I was asked to write a function findSum(array1, array2, sum) that returns
true if two numbers from two sorted arrays add up to a given sum. I was able
to solve it with my eyes closed using a double for loop — O(n²) time
complexity. For the remaining time I was able to reduce the time complexity by
converting arrays to hash maps, then finding the difference by subtracting sum
from the first list element and checking if that difference is a “key” of the
second hash map._

OK, I can accept the fact that in some environments, knowledge of BFS (and the
ability to implement it from scratch) can be considered a must-have skill for
a front-end developer. (Not in _all_ environments. But granted, in _some_
environments).

But can someone please explain how the need to implement a function like
_findSum_ in less than O(n²) -- and in particular: to be able to whip out the
sorting trick necessary to achieve it, while standing in front of a shitty
whiteboard with strangers staring at you --

Can reasonably occur in an actual front-end engineering role?

------
banachtarski
Yikes as an engineer and not a hiring manager, I do NOT want to work with this
person, and I would thank the hiring manager that passed.

It's not even just the attitude. It's the competence too. If you can't code a
BFS on the spot, sorry... that feels like far too low of a bar.

~~~
bgdam
You really should walk into your office tomorrow and ask your team mates to
write out BFS on a sheet of paper in half an hour (and take away their
phones/laptops). I have a feeling you would be quite surprised at the outcome.

~~~
banachtarski
It really depends on what you do but I doubt your average graphics programmer
wouldn't be able to do it in a heartbeat.

------
fopen64
Tech job interviews: the Tinder of labor marketplace

[https://medium.com/@carlosreutemann/tech-job-interviews-
the-...](https://medium.com/@carlosreutemann/tech-job-interviews-the-tinder-
of-labor-marketplace-d5ea644e0501)

------
ukj
Why does nobody get it?

The coding interview is not about memorizing algorithms!

The coding interview is about demonstrating that you can think from first
principles and DERIVE an algorithm!

If you understand the problem and the strategy for solving it, you don't need
to remember the algorithm.

~~~
jeffreyrogers
A lot of those algorithms were research questions that people spent a large
amount of time on. The best way to prepare for these types of interviews is
doing tons of practice problems until you get the pattern recognition to know
what algorithms and data structures apply and fill out the code. Some things
like DFS are pretty easy to derive from scratch, but others require more
thought and very few people will be able to do it under pressure in an
interview.

~~~
ukj
Are you seriously trying to tell me that you remember the code for quick sort?

I know what it does. Mechanically. I can visualize the recursive divide-and-
conquer in my head.

I can implement it in any language.

All you have to understand is WHY the algorithm works.

~~~
jeffreyrogers
I know how quicksort works well enough to write out some pseudocode quickly.
Then once I've got the structure I can implement it. Same with lots of other
algorithms, but if I had never heard of quicksort there's no way I would be
able to come up with it during an interview.

------
mudsizita
On the other end of the spectrum, I have little software engineering
experience but having dabbled in competitive programming, I can solve almost
all algorithmic interview questions optimally within minutes if not seconds. I
still failed half of my interviews though (including Google even though I
believe I answered every question perfectly). Perhaps it's due to my
presentation, or my lacking portfolio, or perhaps the positions have simply
been filled.

On another note, OP seems to rely on recruiters to approach him? Wouldn't it
make sense for OP to actively apply to positions which may have better fit?

------
dev_dull
This candidate reminds me of someone who went on a date and is bitter they
didn’t get a call back for a second, despite their qualities that obviously
made them the right choice as a partner. Dating must be broken...

~~~
lelima
Totally agreed!

This dude most play League of legends

------
jonathankoren
The 2016 discussion on this very article
[https://news.ycombinator.com/item?id=11579757](https://news.ycombinator.com/item?id=11579757)

------
efficax
I'm going to join in and say: you should be able to puzzle out the pseudocode
for a BFS, not from "memory", but by thinking about the structure of a tree
and asking yourself what would be required to touch each node at each level
before moving on to the next level. It's not fantastically difficult, and if
you can figure it out just by reasoning about trees then you're a smart
problem solver that I'd like to work with.

------
povertyworld
I think the real reason programming interviews have become torturous is to
discourage people from changing jobs. It's a kind of unspoken anti-poaching
agreement.

------
jb3689
I used to feel like the author of this post, but trees have come up at each of
my last few jobs.

BFS is a trivial algorithm and you really should know it. It is only a few
lines.

Do you work with things that have dependencies? Do you work with hierarchical
data? What about hierachical apis? Tree traversal is a powerful tool, and not
knowing how to use trees is a sign you may take the stick-and-rock route when
it comes to solving problems

------
rossdavidh
Is it just me, or is HN, normally a much calmer and more reasonable forum than
almost anywhere else on the internet, actually a little bit flamey and ranty
when you get on the topic of tech interviewing? I've seen reasoned
conversations about world politics, war, gender issues, etc. etc. on here, and
never as much sturm und drang as on this issue. I do not necessarily exempt
myself from this statement, btw.

~~~
beefalo
Sunk cost fallacy/hazing mentality. "If I spent 6 months of my life memorizing
programming problems to get a job at Google, then everyone should have to".

~~~
rossdavidh
I have a similar impression.

------
ilovecaching
The google interview really isn’t that bad. In fact it’s kind of unfair in the
sense that someone who just did leetcode for a month can pass it while also
being a terrible coder.

It’s true the interviews don’t test your real coding abilities. It’s probsbly
very low signal you aren’t going to go in and write spaghetti algorithms (but
they will at least be fast).

~~~
dajohnson89
>In fact it’s kind of unfair in the sense that someone who just did leetcode
for a month can pass it while also being a terrible coder.

That isn't unfair, that's just a bad interview.

~~~
beefalo
It is very unfair to people that have other obligations than doing leetcode
for a month.

~~~
Twirrim
If you can pass a Google interview just from doing leetcode for a month, you
got some bad interviewers there.

Last time I interviewed there I got pushed on just about every aspect of
knowledge I had, going back over a decade+ of experience.

There was an awful lot of bullshit trivia questions buried in it, though, and
a bizarre obsession with apparently expecting me to know every argument flag
for a CLI off the top of my head.

------
shinepl10
If I had to resolve BFS problem I wouldn't bitch about it like this guy,
because the only thing you need to know is how to move across the tree. The
rest - you can come up with that - it's not that hard and it's showing your
thinking process.

~~~
pdpi
Yeah, precisely. BFS and DFS are part of a very small collection of
algorithmic questions I consider fair game — but I would never ask them
directly. Instead I'm likelier to ask something like pretty printing a
directory structure, so a function that prints out something like

    
    
        bin/
          sh
        usr/
          bin/
          local/
            bin/
          var/
          ...

------
amrx431
Here we go again. This bickering is never ending. Personally I have stopped
caring.

------
williamqliu
One of the things that I wish we could meet in the middle on is getting the
option to use your favorite text editor or IDE during these interviews.

------
ioncube
This article is from 2016. We are in 2019, I'm curious what happened to the
author, did he eventually found a job? switched career?

------
xiphias2
I don't get the entitlement of people who try to interview with Google. The
ROI of a few months (or in my case years) of preparation for a Google
interview is huge. In Google you are supposed to work on things for a year
before it comes to fruition (and you get promoted), but people are patient.
Getting to know a few algorithms is like real work: you put in the effort and
you get a nice paycheck at the end.

~~~
Traster
Well firstly, Google's plan is not to hire people who are well-prepared, it's
to hire people who are smart and familiar with working day to day with the
concepts that are used in Google's interviews. If a significant number of
people spent months prepping for the interview Google would have a serious
problem with their interview process - unable to find the truly talented
engineers amongst the naturally gifted.

But secondly, if months of prep is required to work at Google what you're
saying is they're selecting for young people, rich people, male people - ie,
all the people that can afford to be spending their spare time on interview
preparation as well as holding down a day job. Go explain to a mother of 2
that the reason she can't get a job at Google is because she can't spend her
evenings and weekends on hacker rank despite a job at Google never really
requiring work at evenings and weekends.

~~~
xiphias2
What you say may be true, but there's a loophole for women that Google does
specifically: at least in the Zurich office interns are 90% female. Also
Google made a new category, called step interns (interns who are in the first
years in university). They generally just need to be young, have good reviews,
and this way they just need to get through 1 interview when they are
converting to full time engineers.

As for old people: don't even try, Google has a huge age bias.

------
chronotis
Why is this article popping again now? It's from over 2 years ago.

------
sleepysysadmin
Something the author might not realize. It might be name discrimination for
why he's struggling.

------
PaulHoule
Why is it that people who post on Tedium find it hard to hire people or get
hired?

Maybe the problem is that they are writing on Tedium.

[https://www.youtube.com/watch?v=_f4oJ-
DQdSY](https://www.youtube.com/watch?v=_f4oJ-DQdSY)

------
BeetleB
I stopped reading in the middle.

I sympathize quite a bit with his frustration, but he does a good job of
making it difficult to sympathize with him. He goes on about how there are
books written on how to interview at Google, yet it's patently clear he didn't
even _try_ to read one of them. It's one thing not to know BFS on the spot
because you didn't want to prepare. It's another thing to be totally _shocked_
that they asked the question. A few minutes of searching the Internet, or
casually browsing the table of contents of several books, would give you an
idea of what they want you to know.

And not to defend Google or other companies, but frankly, BFS is not some
super complicated academic problem that only smart people can code on the fly.
It is one of the more basic recursive[0] algorithms there. So even if you
haven't memorized it, it's not ridiculous to expect you to "derive" it.

And equating maze solving with AI. Really?

I've gone to interviews without preparation, just because "Why not?" However,
I don't go on a rant when I do poorly on it.

[0] Actually, it need not be recursive.

~~~
scarmig
BFS isn't really suited for recursive solutions. Trying to do so usually
amounts to trying to write BFS with a stack only.

