| I've gone through about 6 coding interviews in my life and I failed one. I've given hundreds of interviews, many at some of the biggest companies. Here's the thing. There aren't that many different kinds of problems that you'll be asked to solve. The recipe for 80%+ of the interview problems I ever see is this: 1. You have a data structure (tree/array/matrix/graph/string) that may have some special properties (sorted? directed? etc?) 2. You solve one of a few classes of problems:
* Find an optimal <blah> (shortest path, highest value node, longest subsequence, etc)
* Mutate the output in some interesting way based on the values 3. You do that using some other data structure (Queue, Stack, Hash, Heap) or technique (dynamic programming, recursion, etc) for efficiency. There's probably also a brute force solution you should be able to implement and that shouldn't take too long to do. My point is, these interviews should be easy for a good candidate because the fundamental problem space for a typical question isn't huge and there's tons of places to practice online. For most interview problems, you should be able to say "Oh! I recognize the general shape, I can apply a few primitive patterns together and get a solution that's basically correct, and maybe I'll have to tweak it a bit to optimize it later". Instead, I tend to get candidates with 15 years of experience who think they're so hot but somehow can't implement a trivial depth-first search. I don't want to spend the whole interview on trivial coding problems. I want you to finish that part in 15 minutes so we can spend the rest of the time on interesting topics and technologies. |