How to Crack the Toughest Coding Interviews

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 <i>not</i> 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.<p>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.)<p>Just a few minutes after the interview, I send him running code, then correct code that solves his problem. (So he's <i>wrong!</i> - [1]) He was probably some fresh-faced kid out of school who doesn't understand other than a C/Java workflow.<p>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.<p>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 <i>your first model is going to suck</i>. 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.<p>Exactly the kind of group I don't want to work for.

Interviews work both ways - what questions do you ask them?<p>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.<p>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&#38;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 :).<p>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?

A few other links for those wishing to get familiar with the process:<p>From Google:<p><a href="http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/" rel="nofollow">http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/</a><p>From MIT:<p><a href="http://courses.csail.mit.edu/iap/interview/materials.php" rel="nofollow">http://courses.csail.mit.edu/iap/interview/materials.php</a><p>Steve Yegge's well-known advice:<p><a href="http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html" rel="nofollow">http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...</a><p>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.

I shared my experience in a blogpost: <a href="http://swizec.com/blog/inside-a-google-onsite-interview/swizec/4352" rel="nofollow">http://swizec.com/blog/inside-a-google-onsite-interview/swiz...</a><p>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 <i>every single fucking time</i>.<p>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.<p>Idiot.

I feel like developer interviews are a cover for conducting an IQ test in a manner that is politically passable.<p>And only people like developers would put up with being tested like lab mice in this manner for a job.

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).<p>So this is like saying "ex-Python-dev mailing list member".

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?

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 <i>impressed</i> 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.

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.<p>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.

“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.

&#62; Given a cube with sides length n, write code to print all possible paths from the center to the surface.<p>What is a path through a cube? This seems like some weird combination of graph theory and geometry.

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).<p>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.

I'm kind of surprised at some of the negative comments people have towards these styles of interviews.<p>I'm a current student still going through the interview process with Seattle / SV / Austin companies (big and small).<p><i>Every</i> interview is the same:<p>- review resume<p>- 0-2 behavioral questions<p>- 1-3 technical questions covering design, data structures, algorithms, sometimes language specific (usually pointers)<p>Here are two recent questions asked of me this past week:<p>1. How would you detect the largest sub array (i.e. max sum of adjacent numbers) given an example array:<p>[ -1, 5, 2, -4, 6, 3, 9]<p>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.<p>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.<p>Their effectiveness (or lack thereof) is up to the hiring companies to decide. Seriously, hot companies get flooded with applications (I believe Google gets &#62;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.

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.<p>I'm not worried about losing a potential job because I couldn't crack some obscure mind puzzle.

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.<p>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.<p>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.<p>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.

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.<p>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.<p>Asking the most abstract or complicated question possible probably won't help you find the people you're looking for.

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...

Step 2 is the most important from my experience.