
Coding Interview Preparation Bootcamp - fahimulhaq
https://medium.com/educative/3-month-coding-interview-bootcamp-904422926ce8
======
mchannon
Wikipedia has an excellent article on this under
[https://en.wikipedia.org/wiki/Imperial_examination](https://en.wikipedia.org/wiki/Imperial_examination).

Essentially, the system used to recruit candidates into the Imperial Chinese
state bureaucracy was an-ever-more-elaborate progression of less- and less-
relevant testing, and more- and more-gamable (and expensive) testing. If you
thought getting quizzed about FizzBuzz was bad, imagine getting quizzed about
Beowulf with the same degree of seriousness.

"Intense pressure to succeed meant that cheating and corruption were rampant,
often outrunning strenuous attempts to prevent or defeat them."

"In the 19th century, critics blamed the imperial system, and in the process
its examinations, for China's lack of technical knowledge and its defeat by
foreign powers."

This doesn't amount to any huge revelation to many of us when we're seeking
jobs, nor any comfort, really.

Maybe a little bit of solace that the coding interview you inexplicably
failed, which had the trappings of a serious attempt to gauge your fit, but
the actual behind-the-scenes decision-making progress involved the finesse
you'd expect from a group of blindfolded monkeys throwing darts, will
eventually pay a dividend for all the fat dumb and happy juggernauts in the
bay. Amazon may be the Sears of the 21st century, but I strongly suspect it
and its cohort will meet the same fate a century later and for the same
reasons.

~~~
watwut
FizzBuzz is relevant to job. People complaining about izzBuzz havent had the
pleasure of working with someone able to talk about development well while
being unable to write simple code. Problem of FizzBUzz is that it is too easy,
so folks get insulted.

I have worked who are totally passionate and read all the blogs and can talk
about all new buzzwords and techniques. Who simultaneously had problem write
simple code. That is incomparable to Beowulf.

~~~
throwaway2016a
I agree completely on Fizzbuzz. It has saved us from making so many bad hires.
It takes 15 minutes during the interview and you learn so much about a
candidate. Not only if they can do basic coding but also how they react when
they encounter something that don't know or conversely how they react when
they think something is "easy" or "beneath them".

10 years ago I was asked how to tell if an integer is divisible by two without
using division or modulus. What they expected was to bit mask the 1s place in
the integer and check for equality with 0. I'd take Fizzbuzz any day.

~~~
jiveturkey
come on. this is so obvious. read an int at that location and see if you take
a misaligned read fault. so easy.

if CPU masks it then time the read.

ok partly sarcasm but partly: this isn’t a hard question. i’m sure i could
enumerate ALL the possible ways to do this. maybe i’m good at puzzles.

if your comment is about how awful an interview question it is, in that case
yeah i agree. but not because it’s hard. anyone should be able to answer this.

~~~
throwaway2016a
I never said it was hard. I was pointing out that people have been asking easy
screener type questions like fizzbuzz for at least 10 years.

Further I was pointing out I prefer fizzbuzz because it at least bears a
resemblance to what would be done on a daily basis on the job.

> anyone should be able to answer this.

Anyone should be able to answer fizzbuzz yet people who look good on paper
constantly fail it. This is why it is useful. And that is why it is actually
not a bad interview question. (in my opinion)

------
kylnew
I imagine that the longer you’ve been coding in the real world, the harder it
is to justify doing all this studying for interviews to get a similar job,
especially if you aren’t motivated by money alone.

Recently interviewed with one of the big ones and they were enamoured with my
Swift and iOS dev knowledge but I’m not great with identifying graph
questions. After many long internal discussions and even a letter of
recommendation they passed/asked me if I was interested in other semi-
technical roles at the company. In moments like this my sentiment is ‘take me
or leave me’.

------
Traubenfuchs
It is sad to see the huge divergence between skills required for coding
interviews and the skills required to be a good software developer/engineer.

~~~
hknd
Apparently it's still the best indicator for hiring engineers on large scale.
It's proven that there is a big correlation between performing good during an
coding interview and performing good during your day-to-day job.

Ofc the coding interview is bad, but it's the best of all available (viable)
options.

tbh: most people say it's bad because interviewers focus on the optimal
solution or something like that. Most of the time that's incorrect as an
interview is literally capturing: "Can the candidate solve a difficult problem
and transfer his thoughts into code, while being a nice guy to work with"

disclaimer: I'm doing interviews for a faang company.

~~~
inasring
"It's proven that there is a big correlation between performing good during an
coding interview and performing good during your day-to-day job"*

*citation needed

~~~
hknd
Unfortunately it's internal. All faang companies spend a lot of time and
resources on hiring to make it more fair for everybody and to get signals
faster. And nobody internally enjoys doing a lot of coding interviews - it's
as frustrating for the interviewer as it is for the candidate.

If there would be an easier way then these companies would definitely use it.
A candidate usually has 5-7 interviews (if he is not failing the phone
screen), which is 5-7 engineers spending at least 1 hour for the interview + 1
hour for the feedback. I am having 2-5 interviews per week, which means I
spend between 4 and 10 hours per week just on hiring. If we could reduce this
number we would definitely do it, as it's costing a loooot of money.

To be fair: there is some innovation and traction in those areas, s.t. some
candidate s do a coding project at home and then present their solution (to
reduce the number of interviews).

~~~
Kaveren
Just for context it seems the above user works at Google based on previous
comments.

The idea that Google has internal research indicating this wouldn't be
surprising to me.

~~~
vonmoltke
> The idea that Google has internal research indicating this wouldn't be
> surprising to me.

The problem with internal research on these matters is the nearly total lack
of negative examples. Depending on the quality of the pre-on-site screening
the quality of candidates at that point might be so high that random selection
might be just as good.

~~~
hknd
A negative example would be someone who scored good within the interview
process, but then performs bad on the job (bad performance rating). Such
examples get discussed internally by the hiring committee (senior people doing
the last hiring decision for every candidate).

I think the biggest issue with the current approach among faang interviews is
that a lot of really good people get filtered out (false negative) - but faang
get so many applications that they are ok with this.

------
Mc_Big_G
Funny to read this and look back at a recently downvoted comment
[https://news.ycombinator.com/item?id=18445332](https://news.ycombinator.com/item?id=18445332)

------
NotANaN
I should start a bootcamp to help prospective students prepare to attend a
bootcamp.

------
thedevindevops
Who is this article aimed at?

~~~
chosenbreed
> Who is this article aimed at? Presumably at anybody looking to 'crack' the
> coding interview. Obviously not all of it is going to be relevant for every
> role but I found some useful things in there. At the very least I think it
> offers a structured approach on which to model your own preparation.

