

The Gap in Technical Interview Preparation - dkathayat
https://www.quora.com/Anshuman-Singh/Posts/The-Gap-In-Technical-Interview-Preparation?share=1

======
jkyle
Let's think about this like an engineer solving a problem.

What we have here is a population (interviewees) that we want to sample
according to some metric. We want to apply some series of filters that limit
the sample to only candidates that exceed some threshold of suitability for a
task.

After forming a model for that filter, we apply it and begin to suspect that
we're not extracting the optimal subset of interviewees.

In _any_ other scenario, the answer to this lack of fit would be to change the
sampling method/filters. But for some reason, unique to the interview process,
interviewers decide the solution is for the population of interest to "study"
at passing our filters. In other words, we find we have a bad measuring
instrument and instead of designing a new instrument, the reaction is to
insist that the samples work harder to fit the bad measurements.

I'd like to propose if qualified candidates have to study for your "test",
you're test isn't very good at finding qualified candidates.

By the time a candidate makes it to an interview, initial screeners should
have eliminated those that haven't proven their ability to study for a test
when given the parameters of that test in advance. Try coming up with better
questions to determine if they're a good fit for your company.

...

Now excuse me while I go re memorize all the big-O worst/best case performance
for algorithms from my first year of undergraduate instead of just deriving it
out or looking it up in a table like we all know we do in reality. (unless we
use it every day)

 _edit_

Oh, and the tool looks really fun and will probably help in said interviews.
;)

~~~
anshumansingh26
Hey, Anshuman here. Just came across this. Can't agree with you more. I'd
change the process if it was up to me. However, building a new process, I
guess, will take a lot of time with the same set of experiments happening
again. Its highly unlikely that it will be adopted immediately everywhere
else. This is more of a quick fix to the process till something better comes
along.

There are a lot of things that are broken here. The huge gap between the
university curriculum and the real world industry needs shouldn't exist in the
first place. Which is what our longer term vision is. Watch out for more :)

~~~
jkyle
I hear you. It just sparked a pet peeve of mine as an interviewer and
employee. ;)

I suppose it's easy pointing out flaws without offering solutions.

I think one possible solution would be a system where potential new hires were
given real world problems under real world working conditions. Today, people
often study for months to "pass" the interview tests. Generally taking up many
hours of multiple interviewers time.

Instead, if a potential candidate were given a sufficiently unique and
difficult problem and a time window to complete it representative of the
desired work output it would provide a much better idea of what kind of
employee they would be.

\- Did they complete the job earlier than the given time, but turned in sloppy
or a less than ideal solution?

\- Did they eat up the entire allotted time, but turn in truly stellar work?

\- Best of all, turned in early, unique solution with good, commented, test
driven code and asking for another problem?

And really who cares if they had to review their algorithms or operating
systems book to do it? That's why we keep them on our shelf.

I'd say for sufficiently hard, and original, problems I spend 80% of my time
with my nose in a book or reading papers and 20% engineering a
solution....unless I'm doing it day in and day out.

After that, it's mostly about personality and team fit. Bring them in to do
some white booarding (full access to resources) and work with the team, make
sure they aren't smoke and mirrors. Then make a call.

 _edit_

For example, take your ops guy. Best interview I've ever seen for ops is to
throw them in a broken sandbox environment, give them root & tell them to fix
it, and walk away.

------
slarkx
Well, I think nothing beats a good book, written just for the exact purpose,
something like Cracking the coding interview is worthy enough to get the right
kind of info for preparing for any kind of an interview. It also gets revised
every year. Plus moving from one chapter to another, just take flipping a few
pages : UI is simple and efficient. I can just read what i need to read, I can
workout the problems on my own, or if I am stuck I can see hints of the
complete solution. I mean there is no stopping to my learning, and the pace,
flow and direction is set my me. Shouldn't some problems be deemed solved in
the offline world, and not be bloated to online proportions?!

------
soham
Founder of [http://InterviewKickstart.com](http://InterviewKickstart.com)
here. This is a great observation and I fully agree with the author.

I joined Box.com as an Engineer in 2008, when we were 5 engineers. Grew
rapidly with the company and was most recently a Director in Engineering,
managing multiple teams full of amazing people. Left after 6 years, to fulfill
my entrepreneurial dreams. Box was my career-launching company. (And it is,
for many other engineers). I have also worked at Microsoft and eBay.

Along the way, I had the incredible opportunity to help our technical teams
grow from 5 to ~250 engineers. This meant living and breathing the
interviewing machine exploring all its nooks and corners, and ups and downs.

Box is also a company that constantly questions and improves its interviewing
processes. That relentless focus helped us hire great engineers.

I noticed however, that despite all that attention, hiring took an
unreasonably long amount of time and much agony. We’d go through hundreds of
resumes, countless phone screens and countless onsite interviews for each open
position.

That bothered me to no end. If most of our interviews were of reasonably
average difficulty, our scoring method was well-structured, and our
interviewers well-trained, why would only a few candidates clear our
interviews? Yet, in the end, our pass rate was <5%. I was not ready to believe
that rest 95% of people were not competent.

I dug into this extensively, and realized that while everyone was hard-working
and very smart in their own way, they vastly under-estimated the amount of
preparation it would take to clear programming interviews at top companies.
They only had a vague idea of what to expect, and did not have enough practice
to solve interview problems under time-pressure. Their daily jobs or schools
did not prepare them for handling interviews.

I found more evidence of this from the career-coaching I did on the side (pro-
bono). Many candidates would even want to change their careers, thinking they
were not good at programming, simply because they weren't able to crack
interviews.

I'm now doing something similar in the valley, but in a very high-touch,
classroom setting way, for experienced professionals:
[http://InterviewKickstart.com](http://InterviewKickstart.com). We've been
lucky to have had excellent success and very satisfying career transforming
stories.

------
mrinaltrivs27
I feel the product is highly needed looking at the big gap between the
curriculum and the actual industry. Plus the engaging factor and gamification
is going to develop the skills at backend along with the real-time enjoyment.

------
KNeeraj
Great tool!! By some really awesome people. A boon for people who aspire to
work for top companies :)

------
AJIIITM
This looks like a very promising product and fulfills a long inherent need

------
KNeeraj
A boon for people who aspire for top companies. Must try :)

