
How to Crack the Toughest Coding Interviews - chapel
http://gklst.tumblr.com/post/34361344887/how-to-crack-the-toughest-coding-interviews-by-gayle
======
stcredzero
I think I've been a victim of ageism here in the SF bay area. One member of a
group met me in person, and we had a positive experience during the coding
interview. (I look young for my age.) I gave him some Python code that solved
his problem, as well as a version optimized for common prefixes and another
that gave the same tally by user as well as the total aggregate. Note I am
_not_ primarily a Python coder, and it's not what I would've been hired for,
but it's a good language for quick coding and it looks like its own
pseudocode.

The next two members of his group never met me, so all they know about me is
the sound of my voice and facts on my resume, and during the phone interview
they came across like they thought I was some dimwitted old duffer and that I
was Googling the answer because I was doing stuff on my own command line. The
guy in charge told me to stop coding, because as he said, "You will take too
long and never get done," [1] even though I've been coding in dynamic
environments for 15 years, and so my problem solving techniques are all
oriented around very rapid iteration. So he effectively disarms me, then
proceeds to be the annoying kind of smarmy pair programmer and tell me
everything I'm doing wrong as I'm coding. (All of which I could catch if you
just let me at it.)

Just a few minutes after the interview, I send him running code, then correct
code that solves his problem. (So he's _wrong!_ \- [1]) He was probably some
fresh-faced kid out of school who doesn't understand other than a C/Java
workflow.

The lesson I've learned over the years, is that an organization that
interviews you incompetently is one that you don't want to work for anyways.

EDIT: Another thing that really irks me about this interview, was that they
sprung a relational data modeling problem on me. That has almost nothing to do
with what I'd be hired for, and most importantly they left out the key
premise: They're looking for a generalist who can just hop in and do whatever.
(Which I can do, as well as being methodical and researching the problem
first.) So basically, they're looking for some fresh-faced kid like them who's
fearless because they don't have the experience to know that _your first model
is going to suck_. If they had let me know this premise: "we just want to see
how you handle just getting something done" versus "we're going to grade the
quality of your ER modeling" then I would have done that part totally
differently.

Exactly the kind of group I don't want to work for.

~~~
tjdetwiler
I've been in interviews where I felt like the interviewer went a little power-
hungry with the situation.

For example:

    
    
      Interviewer: "How you implement this calculator program?"
      Me:          "Well I would try to read a number...."
      Interviewer: "HA! You cannot assume the type of input"
      Me           "Okay, fair enough... does the input reflect a valid math expression?"
      Interviewer: "Of course, why would you ask such a question."
    

In the moment I really felt like the (relatively young) interviewer way trying
to lead me in the wrong direction, and then when I realized I needed to make
no assumptions, criticized me for trying to clarify other parts of the
problem.

I didn't get that job, but after that experience I was hardly disappointed.

~~~
monksy
I've been on interviews like that. Its a double edged sword. if you assume the
worst about the input in the first place you're screwed. If you don't they'll
bring it up later.

~~~
planckscnst
Sounds like a good solution would be to think about it while you create your
solution, and when the bring it up, say somethint to the effect of "Yeah, I
thought of that while I was working on it; you'd just do x and it's fixed."

------
Zenst
Interviews work both ways - what questions do you ask them?

One I used to ask was do you have IS9002/BS5750, but that was 15 years ago and
there are better questions to ask. A good question is also sometimes better
than a good answear as it shows you understand things from another perspective
and have the ability to ask questions instead of blindly accepting what you
are told all the time if your unsure.

So what are your favorite questions and not how much TAX did the company pay
type questions, the ones that give you lots of wonderous information and yet
still puts them on there toes a bit as well if they are weak in some area's of
managment/running the company of methodology. I asked what Q&A methodologies
do you use in a interview once for a company called RIM; Was not a great
answear. My question about IS9002/BS5750 was one which showed how well
organised the company was at the job in hand and how well documented the role
was. The answear tells you what kind of mess your getting into and also if you
should be asking for more money (danger money if its somebodies spagbowl
code/system :).

So what questions as a programmer do you ask the company in an interview, that
is applying for your service. Anybody have one they care to share?

~~~
Swizec
In order:

Do you use git?

How do you do ticketing?

What's it like working here?

In my experience engineers at big companies will not give you an answer to
those, but canned marketing responses. I don't know why.

~~~
kami8845
You have to be more sneaky. Rather than asking something as generic as

>What's it like working here?

ask them

>What do you like the most about working here?

If they give you something like "the stability" or "the high pay" those are
generally bad signs. Better signs would for example be "the great people I get
to work with every day" or "the autonomy to get to choose what I work on".

~~~
hkmurakami
You can probably throw the "If you could change one thing about the company,
what would it be" type question as well.

~~~
mirkules
That's a nice play on the "What are you biggest strengths and weaknesses"
interview question, in reverse. The only problem with that -- as we've been
conditioned over the years of being asked this stupid question -- is to list a
strength as a weakness
([http://jobsearch.about.com/od/interviewquestionsanswers/qt/w...](http://jobsearch.about.com/od/interviewquestionsanswers/qt/weakness.htm))
so you don't actually get much meaningful information (other than maybe subtle
red flags, like "stability" or "benefits are good", as someone mentioned).

------
dabent
A few other links for those wishing to get familiar with the process:

From Google:

<http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/>

From MIT:

<http://courses.csail.mit.edu/iap/interview/materials.php>

Steve Yegge's well-known advice:

[http://steve-yegge.blogspot.com/2008/03/get-that-job-at-
goog...](http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html)

Essentially it seems to build down to knowledge of data structures and the
ability to use them in concert to develop solutions on a whiteboard. There's
more to it than that, but being able to code without an IDE is critical.

~~~
danielweber
> Steve Yegge's well-known advice:

He says:

 _Don't say "choo choo choo" when you're "thinking"._

God damn it. Now I'm going to have to fight the urge to do that during
interviews!

~~~
maeon3
The "choo choo choo" people make my skin crawl. Not sure why. It could be
subconscious because everyone I've met in life who did that was not good for
my career to associate with them.

~~~
danielweber
People do this for real? I thought Yegge met one person who did it and was
making a joke at that guy's expense.

 _EDIT_ I suddenly got it. They're doing long exhales. I think my kids might
do this when they're pretending to work. Then again, they are kids.

------
Swizec
I shared my experience in a blogpost: [http://swizec.com/blog/inside-a-google-
onsite-interview/swiz...](http://swizec.com/blog/inside-a-google-onsite-
interview/swizec/4352)

A few days ago I finally realized why they said I'm not good enough at big-O
to play with them (despite saying my coding was excellent). For some reason I
had a mental block that day and wanted to implement hash tables as prefix
trees _every single fucking time_.

I have no idea why. Of course I know a hash table is O(1), but for some
reason, that day, I kept trying to convince everyone it should be O(N)
(N=length of key) because it's implemented as a prefix tree in the background.

Idiot.

~~~
timr
A hash table lookup is O(n), where n is the number of elements in the table.
They have _amortized_ constant time lookup (i.e. constant time in the average
case).

~~~
shrughes
Or it's O(log n). Depends on how collisions are handled.

~~~
timr
If you use a balanced tree instead of chaining or probing, sure. But, of
course, nobody ever does that in practice, because the complexity isn't
justified by the theoretical gains.

Point was, worst-case time complexity isn't constant. I'd be happy to see more
people get that right in interviews.

------
jsnk
I feel like developer interviews are a cover for conducting an IQ test in a
manner that is politically passable.

And only people like developers would put up with being tested like lab mice
in this manner for a job.

~~~
glaak
Consultants are asked case studies. Writers are asked to write something (or
submit writing samples). Actors are asked to audition. And programmers are
asked to program.

Why _shouldn't_ you validate if a programmer is, in fact, a good programmer
(which is a mix of many things, including intelligence)?

~~~
softbuilder
>And programmers are asked to program

Programmers are almost never asked to program. They are asked to solve 50-year
old CS problems on a whiteboard.

~~~
dspeyer
At Google, at least, we try to make up new questions frequently and retire old
ones.

~~~
Evbn
There aren't enough problem in the world for that to be possible, ignoring
extremely superficial differences.

It always comes down to exercises from CLR lightly dressed up.

~~~
theootz
Sorry, but what's CLR?

~~~
cagey
<http://en.wikipedia.org/wiki/Introduction_to_Algorithms>

------
DannyBee
Google does not have just one hiring committee, and anyone can be on hiring
committees if they want to and one of the committees has a need of new members
(IE it's not invite only).

So this is like saying "ex-Python-dev mailing list member".

~~~
glaak
Actually, it was invite-only when I was there. But that's sort of besides the
point. It's irrelevant whether or not it's an "honor" to be on the hiring
committee. The point is that being on the hiring committee does give you some
insight as to why people tend to get rejected. Without being on the hiring
committee, you really only see why you're rejecting people -- smaller sample
size, biased, less diversity of questions, etc. But, for hiring committee
members, you see the results of many people's interviews.

~~~
DannyBee
I'm on 3 of our hiring committees, and i've been at google for over 6 years.
It hasn't been invite only for as long i've been here, AFAIK. Either that, or
I was secretly invited!

It is irrelevant whether it's an honor, but as to whether it gives you
insight, you are generally right but you did miss an important point:

The vast majority of people who are "members" of a given hiring committee
often don't show up every week. A lot, in fact, show up never, but are still
members. (for example, they were part of it years ago and nobody removed them,
they got asked, said yes, never actually did anything, etc)

So while you are correct that it does give you some insight if you actively
participated, simply being a "member" of a hiring committee is a necessary but
not sufficient condition to say that you have that insight.

~~~
incision
That doesn't seem to be a point missed so much as one that's obvious and
generally unnecessary to state fully qualified descriptions of everything in
casual conversation.

~~~
DannyBee
Except that when you are using it as marketing in a book, there are very
important distinctions.

Lies of omission and all that.

~~~
glaak
A lie of omission would apply if you state a selection of true facts and
ignore other ones so as to make yourself look better than you are.

In this case, I'm stating that I was a hiring committee member and not saying
that I attended regularly, when I in fact did. This is not a lie of omission.
At worst, you could accuse me of not offering additional qualifications.

------
ionwake
Am in the only 30 year old coder here, who earns around £300 a day coding, but
would fucking die in one of these interviews?

~~~
suyash
you get paid daily..what kind of company is this?

~~~
gutnor
Contracting in the UK. You are either paid per day or per hour. You bill per
month typically.

------
cperciva
Another piece of advice: Think carefully and don't assume that the obvious
algorithm is the best one. Interviewers will usually be satisfied if you
notice that they're describing an instance of 3SUM and give them the obvious
O(n^2) solution; they'll be _impressed_ if you notice that the problem they're
describing is actually a dense special case and can be solved faster using an
FFT-based convolution.

------
account_taken
Man, I wouldn't do well in these interviews except for the tinyurl.com
question. Who thinks at the level of binary tree implementations? I know what
they are and how to use them and I had to could remember and implement one,
but I don't remember having ever needed to implement one from scratch.

The interview questions I ask are more around problem solving and thinking out
of the box but I deal at the web application level not building compilers,
databases, etc.

~~~
pjscott
The binary tree thing is simpler than it sounds; don't be faked out by the
fact that it involves binary trees. You can traverse a binary tree from the
root to any node, and record the nodes on that path. Do so for each of the two
nodes, then compare the two sequences, looking for the first node that is
common to both of them. You can do this in O(lg n) if the binary tree is
balanced, or O(n) if it is not. And if this sounds complicated in words, just
draw a picture and it'll suddenly look simpler.

------
philhippus
“Describe how you would implement the tinyurl.com website.” preferably without
realising you have the technical skills to do far better on your own than
wage-slaving yourself for us.

------
haberman
> Given a cube with sides length n, write code to print all possible paths
> from the center to the surface.

What is a path through a cube? This seems like some weird combination of graph
theory and geometry.

~~~
jsolson
Perhaps they're assuming that the cube is a set of integral points and they
want you to count lattice paths. This is trivial in 2-space (e.g., give me the
number of paths that go from (0,0) to (5,5) by going only up or right one
point with each move (that is, each move is either (0,1) or (1,0))). However,
I vaguely recall counting lattice paths in 3-space being a wickedly hard
problem with no known polynomial time solution. Could be completely wrong on
that, though, and don't feel like looking it up just now.

You could of course write a program that would solve it (trivially), but it
might take exponential time :)

Of course, the phrasing doesn't _say_ they have to be lattice paths, so
perhaps we can say a countably infinite number of paths of we're only
considering integral (or rational) points and have no direction invariant.
Uncountably many if we're allowing the reals. Still uncountably many if we
allow the reals and have a directional invariant. We reach the realm of a
finite solution if it's a finite set of points and we have a directional
invariant or another constraint (e.g., the path might be prohibited from
visiting any given point more than once). Most of these are still completely
intractable as far as I know :)

~~~
Someone
_"I vaguely recall counting lattice paths in 3-space being a wickedly hard
problem with no known polynomial time solution."_

I think you can easily write the recursion:

    
    
      p(x,y,z) = p(x-1,y,z) + p(x,y-1,z) + p(x,y,z-1)
    

Leave out the term with x-1, y-1, or z-1 for the edge cases for x, y, and/or z
equal to zero.

With that in hand, it is easy to compute all values bottom up, starting with
those where x+y+z = 0, 1, 2, etc.

Definitely fewer than (x+y+z)^3 values to compute, all of them in O(1)
(disregarding cases where the numbers become bignums)

Generalization to any number of dimensions seems easy, too.

A closed form solution, that might be harder.

~~~
pjscott
You're assuming that all movement must be in one of three directions, but in
general, you can go in six directions -- forward or backward along the x, y,
and z axes. Your cubic-time DP algorithm doesn't solve the self-avoiding walk
problem, which I think is what jsolson vagely recalls.

<http://en.wikipedia.org/wiki/Self-avoiding_walk>

~~~
jsolson
So, the professor in question was Dana Randall. I believe she was talking
about this topic: <http://en.scientificcommons.org/42983059>

Basically, yes, self-avoiding paths.

This was basically a brief aside in her honors undergrad algorithms course, so
the topic was a bit beyond what I was prepared for at the time :)

------
nandemo
I got that book. While the questions and answers are useful, in my experience
this book alone is nowhere near enough to get prepared for a Google interview
(not that the author claims that).

I studied CLRS's Introduction to Algorithms and a couple of other books for
about 2 months. Even then I could not answer the hardest questions during the
onsite interview. And if you cannot come up with an optimal algorithm for a
given problem, all of the items mentioned in the article (communication, clear
coding, testing) don't really matter.

~~~
drivebyacct2
>And if you cannot come up with an optimal algorithm for a given problem, all
of the items mentioned in the article (communication, clear coding, testing)
don't really matter.

That's just not true and if any company is only interested in whether or not I
can generate a correct answer under pressure in 20 minutes, then I'm not
interested in working for you.

~~~
nandemo
You seem to be disagreeing with something I haven't said. I'm simply
describing my experience interviewing at Google: I didn't give an optimal
solution to a couple of problems, and didn't get an offer. So I infer that the
other items mentioned in the article don't matter as much _for getting a job
at Google_.

~~~
glaak
You also did not wear a pink and blue striped hat, and did not get an offer.
And yet, you seem to not connect your failure to wear a pink and blue striped
hat with your failure to get an offer.

I'd suggest you read the section in the article about how you're evaluated.
Yes, how optimal your solution is matters -- of course it does. This doesn't
mean that you have to get an optimal answer though. You have to do better than
the majority of candidates (maybe ~80% of candidates).

For some problems, being in the top 20% of candidate will mean getting the
optimal solution. In other cases, it may not. The optimal algorithm might be
trivial, and it might be more about coding skills. In another problem, it
might be totally unrealistic to expect that a candidate needs to get the
optimal algorithm.

Additionally, you seem to assume that since (according to you) getting the
optimal answer is necessary, that it must also be a sufficient condition.
That's obviously false. It's entirely possible that a candidate needs to get
the optimal answer AND implement it well, in which case these other factors
come into play.

~~~
nandemo
> You also did not wear a pink and blue striped hat, and did not get an offer.

I don't understand the point of this quibbling.

Say I was asked 30 questions; I missed 3 of them and didn't get hired. It's a
reasonable to assume that these 3 questions were considered important in the
general assessment.

> You have to do better than the majority of candidates (maybe ~80% of
> candidates).

I know, I said I read your book. ;-)

But that doesn't substantially change the story, it means it's likely other
candidates got the optimal solution or got closer to it.

Of course this is all based on my self-assessment, since Google doesn't
provide any sort of feedback post-interview. But I'm pretty confident that I
went well in the other questions. 4 out of 5 interviewers were pretty nice in
giving feedback during the interview, even if indirectly. E.g. they'd ask
progressively more involved questions on the same topic, so I more or less
knew when I had answered the previous questions correctly.

> Additionally, you seem to assume that since (according to you) getting the
> optimal answer is necessary, that it must also be a sufficient condition.
> That's obviously false.

No, I haven't made any such assumption. I only assume that getting the optimal
answer was the "high bit" in my case.

Apparently this works for Google, and unlike other people who have failed to
get the grapes, I don't call them sour.

~~~
glaak
"Say I was asked 30 questions; I missed 3 of them and didn't get hired. It's a
reasonable to assume that these 3 questions were considered important in the
general assessment."

That would be true if those answers were assess on a strictly correct /
incorrect basis AND those were the only things you were assessed on. Neither
of those are true though in this case.

It's very possible that the questions where you didn't get an optimal answer
you actually did very well on. And that there are other questions where you
got the optimal answer, but it took you too long or you made too many mistakes
in coding. Or you just came off as arrogant. Who knows?

I've seen many many candidates make similar assumptions to yours -- thinking
they bombed specific interviews, when in fact they did very well on those. You
might be correct about why you got rejected. But it's even more likely that
you're wrong.

But this is absolutely true: getting the optimal solution in all interviews is
not a necessary and sufficient condition.

------
wting
I'm kind of surprised at some of the negative comments people have towards
these styles of interviews.

I'm a current student still going through the interview process with Seattle /
SV / Austin companies (big and small).

 _Every_ interview is the same:

\- review resume

\- 0-2 behavioral questions

\- 1-3 technical questions covering design, data structures, algorithms,
sometimes language specific (usually pointers)

Here are two recent questions asked of me this past week:

1\. How would you detect the largest sub array (i.e. max sum of adjacent
numbers) given an example array:

[ -1, 5, 2, -4, 6, 3, 9]

2\. Given N cubes painted 1-6 sides (duplicate colors on a single cube is
possible), what's the largest stack you can build such that all faces on each
side are the same color? The stack is 1 cube wide and deep, solve for height.

Maybe wherever you're employed / looking for a job doesn't ask these type of
questions. Congrats. However it doesn't change the fact that these questions
are the norm for top tier US tech companies, and a quick glance at
GlassDoor.com will corroborate.

Their effectiveness (or lack thereof) is up to the hiring companies to decide.
Seriously, hot companies get flooded with applications (I believe Google gets
>100k annually). They don't have time to sit down with you and pair program
for an entire day, especially as a 1st or 2nd round screening.

~~~
pjscott
> 1\. How would you detect the largest sub array (i.e. max sum of adjacent
> numbers) given an example array:

That's a fun one. The obvious solution is O(n^2), but there's a less obvious
way to do it in O(n). (I'm not giving spoilers, because this actually is fun
to solve.)

~~~
wting
A sad fact is I had to look up the answer, and the algorithm is well known
from one of my university's professors which I've had class with.

------
capkutay
You can also crack the toughest coding interviews by being a good coder who
has created cool things and completed some challenging coding projects. You
could also review the stuff you learned in algorithms right before your
interview.

I'm not worried about losing a potential job because I couldn't crack some
obscure mind puzzle.

~~~
alanctgardner2
You can be an excellent coder and suck at interviews. This post has nothing to
do with hard skills about algorithms, and everything to do with how you
present your work. A lot of good coders might miss out on jobs they want
because this is an unusual situation they werent prepared for.

~~~
pacaro
I've interviewed a lot of people (at Microsoft). I don't claim to be good at
it, I think that I do OK, but that's why one interviewers opinion should never
be the be all.

I've definitely encountered people who were clearly good, and equally clearly
sucked at interviewing, as an interviewer I had to ask myself the question
"why?"

I encountered the following cases (among others)...

The ill-prepared - This may come down to background, some candidates didn't
seem to know that they should prepare for an interview - this can be
excusable, but in a world where advice about this is one web-search away is
increasingly tough. Usually (but not always) this is a barrier to recommending
hire.

The chronically nervous - This is always at least 50% my fault. I believe in
asymmetric responsibility, as the person with more "power" in the situation, I
feel part of my job is to help a candidate past their nerves; if this means my
interview is entirely spent putting them at their ease to (potentially) do
better with the next person in line, so be it. This has rarely been a barrier
to recommending a hire.

The arrogant - "I can't believe you asked me such a demeaning coding question
when I'm applying for a senior role, clearly my resume tells you all you need
to know about my coding chops" - sorry, if I can't pierce this, no hire.

The inarticulate - often in this case the code speaks, even if the candidate
can't, I usually associate this with nerves, sometimes it is language issues,
sometimes stress sensitive speech impediments. I'm pretty sympathetic to this
if the code speaks, but communication is part of the role so this is always a
judgement call.

Can't code on a whiteboard - I'm inclined to call this ill-prepared, you
should expect to have to do this coming into the interview, but I do get that
this is equivalent and opposite from "inarticulate" - I will take a coherent
and detailed description of a solution as being nearly as good as the
whiteboard code, but there is a bottom line, you have to be able to show me
your ability - sometimes one really insightful question or observation is all
that it takes...

~~~
mech4bg
As an interviewer, it always surprised me how little people would prepare for
an interview.

For every interview I have done as an interviewee I have studied what I am
likely to be asked, what their interview technique is, boned up on the
language(s) in question, and tried to think of some interesting questions to
ask the interviewer (the last one also includes learning as much as I can
about the company and its history). I think these are the basics any
interviewee should do - that's just the bare minimum for the big guys. For
Google I was pulling out dusty old CS books and revising CS theory and that
was still just barely enough preparation.

Meanwhile I've given interviews for a C++ position where the candidate hasn't
even had a quick brush up on C++ recently. I've had candidates who do C++ as
their JOB and not know how to initialize memory, someone describe "polyformic"
behavior, and had a good 75% not know at all how virtual functions work. It
blows me away.

~~~
malyk
I've never studied for an interview. I guess I have some internal feeling that
you should hire me based on what I know...not what I crammed for the night(s)
before an interview.

Or maybe it's confidence? I don't know. I've been programming professionally
for over 10 years. I think I should be able to sit down and work out almost
any problem in an interview.

I've definitely been to interviews where I ran into issues and didn't get
offers, but I've also been to interviews where I ran into problems and did get
offers.

I guess, in my gut, I feel like studying for an interview is cheating a bit.
It might not be the right outlook, but it's something I can't shake.

~~~
pacaro
I think this is an interesting one, I might make a distinction between
studying and preparing. Working through some interview questions as an
exercise in intentional practice provides a different type of preparedness
from trying to cram CS theory that you don't truly grok. I think that the
former helps you manage the unfamiliar interview scenario better, the latter
can lead to you digging huge holes when you start talking about something that
you don't know much about.

There is also a difference between an experienced industry hire - as you say,
if you've been doing this for 10 years you can go into an interview and show
them a pretty good picture of what they are getting - and a less experienced
or campus hire, where what is important might be an expression of potential -
the practice helps with letting the interviewer see that, if your interview is
the first time you've tried to code at a whiteboard, or solve a problem with
someone trying to push you to the edge of your comfort zone, then you are
doing yourself a disservice.

I have, however, encountered candidates who just didn't know, they didn't go
to a top school (or indeed any school), they haven't worked in this
environment, they don't have any understanding of what to expect - even the
simple web-search that would have warned them requires some level of _a
priori_ knowledge - not every candidate has that - I suspect most of these
candidates do badly, but just watching how someone learns through a day of
interviews tells you something, that higher level bit about learning when in
over your head is one of the most valuable.

------
mrbgty
Personally, I don't really get this type of interview. For one it sounds like
they've pretty much standardized it for all developers with little insight
into how a new candidate might fit into an existing team best.

Also, it simply does not reflect in anyway what it will be like to work there
or what it will be like to work with that person. One key reason is that the
interviewer asks questions they already have the answer to and that unbalances
things and results in an inaccurate analysis.

In real life, none of the people in the room would have the answers and they'd
all be working together to solve the problem.

These people come and interview all day. The team would be better off just
having that person tag along with them and work on real problems together all
day.

~~~
Evbn
Actually at most big company jobs the programming tasks have well known
solutions but need people to grind them out.

------
blaines
I've been doing lots of interviews lately. Most of the coding questions have
been fun, and I've learned. Some have been just plain strange - they seem like
well intended questions in a specific context (which I'm not aware of). Those
are the hardest.

I've noticed the strange ones seem to be coming from people that aren't
prepared to be interviewing. So just a word of advice (and I'll elaborate with
a blog post soon) to interviewers, please prepare ahead of time. I'm
interviewing you too.

Asking the most abstract or complicated question possible probably won't help
you find the people you're looking for.

------
barbs
Has anyone read the book put out by the blog post author? I thought the post
was well written, and would like to know if the book is worth getting as
well...

~~~
wting
Her "Crack the Coding Interview" book basically is an expansion of that blog
post, goes into more details, includes a lot of problem sets of different
types and various strategies for attacking each one.

I like using it to study for interviews. It's not sufficient by itself, but
will get you 75% of the way there.

*Disclaimer: I'm 3 degrees of separation away from the author. :p

~~~
barbs
Sounds a like a good recommendation to me, thanks :). What would you recommend
for the remaining 25% of the way?

~~~
wting
It's probably personally dependent to shore up your own weaknesses.

Mine would probably more practice with recursion, dynamic programming, graph
theory.

------
drivebyacct2
Step 2 is the most important from my experience.

