
Study material for tech interviews - rttlesnke
http://www.geeksforgeeks.org
======
luu
I recently did a batch of interviews at a handful of companies. The advice I
got from the best programmers I know was that you shouldn't bother preparing
for interviews, other than, perhaps, spending a few hours skimming an
algorithms textbook to make sure that stuff is fresh. I wasn't sure about that
advice at the time. In retrospect, I agree [1].

80% of the coding questions I got were really simple; things you'd expect any
college kid who'd been through a basic CS curriculum to be able to answer
cold. Not having just taken an algorithms class, stuff like that took a bit of
thought. 20% were things like "implement coroutines in C using setjmp and
longjmp" or "implement a regular expression matcher". How can you cram for
that? Sure, you can cram for any specific question, but, given the breadth of
the question space, your only hope is to understand things well and be able to
reason out whatever comes up.

As far as I could tell, being better prepared was negatively correlated with
getting an offer. I did well in interviews where I was totally clueless and
had to reason things out from first principles. Conversely, I had an interview
at Palantir where I heard the question I was being asked, so I said that. My
interviewer asked me to quickly sketch the answer. When I did, he asked me
another question. After repeating that process a few times he gave up and
asked me a simple design question. Apparently, I failed that interview so
badly that I got kicked out before lunch (interviews there are normally all
day). In general, having heard the question before (and telling my
interviewer), or having a flash of insight and being able to write down the
answer without thinking about it seem to be taken as negative signals.

I was surprised by that until talking to a friend of mine who said "the
interview process is this largely protocol driven song and dance where you're
supposed to scratch your head and be wowed by the technical question and then
slowly and painfully make incremental progress on a solution while the
interviewer can feel smug about knowing it all along and maybe they can help
you along the way. If you blurt out a good approximation in the first thirty
seconds, that ruins the whole courtship." That's not true everywhere, but it
seems to be true at most places.

There are, of course, non-coding questions. Those seem even less useful to
cram for. You might be able to impress someone if you happen to know a
lg(lg(n)) data structure you can use instead of a red-black tree, but most
non-algorithms questions are about thinking on your feet; just having lots of
knowledge won't help you there.

[1] This assumes that you have a solid background in CS fundamentals. If not,
interview prep has a very high payoff.

~~~
jlarocco
This has been my strategy for a while, and it's always worked for me. I never
study for interviews, and I can usually find jobs.

In my experience, technical questions typically fall into two categories. The
first is trivia about a programming language or other tool. The only people
who need to "cram" for these are people who lied on their resume. Everybody
else will answer these questions pretty easily just from working with the
tools and having hands on experience. These are weed out questions to keep
people honest.

The second category is to see how the candidate thinks about problems and
solving them. It's not helpful to "cram" for these because the problem space
is too large, and it would defeat the point anyway. If a company wanted people
who've memorized "Coding Interviews For Dummies," they would just put that in
the job requirements. In reality, the job they're hiring for doesn't have
cookie cutter problems and solutions, and they want to see how the interviewee
will work through a problem to find a solution. Knowing the answer to these in
advance can actually hurt because it doesn't show them what they're looking
for.

------
mempko
How about we collectively protest these kinds of interview questions. I vote
that instead of answering questions, we ask difficult ones to our
interviewers. When they protest, we explain "Just making sure I won't be
working with idiots".

Remember folks, these companies are getting more from you then you are from
them.

~~~
brianto2010
_> Just making sure I won't be working with idiots._

I think the the interviewer (or company) would probably take this as an
insult.

But I do agree with you in that these types of interview questions are
pointless. Spitting back an answer verbatim demonstrates nothing.

A neat approach that I've seen people use is to take a you-should-know-this
concept such as the merging part of merge sort and put a twist in it, so it
isn't a simple spit-the-answer-back, but different enough to require some
thought.

~~~
mempko
"probably take this as an insult."

Yet isn't it surprising perspective employees don't feel the same? Or maybe we
do but we suck it up to get the job.

------
akanet
And if you want to see if you could literally, truly derive a working solution
to any of these puzzles in a realtime interview environment, I make a tool for
that: [https://coderpad.io](https://coderpad.io)

It also works for administering the interview!

------
jiggy2011
All of these examples are in C , is it common for interviews to be conducted
in C for major tech companies (assuming the job is not a C programming role)?

~~~
spullara
Generally the candidate picks their best language. Personally, I would never
pick C because there is too much minutiae and not enough meat.

~~~
georgemcbay
"I would never pick C because there is too much minutiae and not enough meat"

There's really not much minutiae at all when it comes to C. C++, sure, I'd
agree, but not C.

You do have to be be pretty comfortable with how processors and memory work if
you're going to be answering questions in C, but that aside the language's
syntax, keyword usage and standard library are all quite small.

~~~
spullara
You spend half the time allocating memory, deallocating memory and checking
error return values. I gave a couple hundred interviews at twitter, people
that picked C wasted a ton of time not solving the problem.

