6 ms·

How to Crack the Toughest Coding Interviews

113 points by chapel 14y ago

seiko55 14y ago
I'd like to ask a question to google interviewers: when someone does not manage to get the best possible solution to a few questions, do you people chat together saying things like "he's not like us"?
DannyBee 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        Except that when you are using it as marketing in a book, there are very important distinctions. Lies of omission and all that.
        glaak 14y ago
        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.
  - glaak 14y ago
    I was in Seattle / Kirkland, and it was invite only there. I showed up every week (as did the vast majority of the Kirkland HC). But, yes, I could have been more extensive in my credentials. Unfortunately, "How to Crack the Toughest Coding Interviews by ex-Google engineer, ex-Google hiring committee member who showed up every week, ex-Apple dev, ex-Microsoft dev, author of Cracking the Coding Interview, and author of The Google Resume" was a bit too long :).
    - DannyBee 14y ago
      Fair :) I'm just used to MTV HC's, where you may have 75 HC members, and 10 active ones. I expect the "newer" offices (relatively, of course) may not have this issue.
capkutay 14y ago
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 14y ago
  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.
  - Zenst 14y ago
    A very fair point about talent at doing a job and talent at explaining the job in interviews. The term interview technique is like exam technique and in that is something that abstracts from doing the actual job. Unless that job entails interviewing people. With that this is probably a better read. Alot of people who fall into the boat of being good coders with social skills of dead fish often have a hard time. One appraoch is to create some wonderous application and get broaght out, recruitment that way. Or in the process, end up refining there social skills to the stage that not only can they interview ok but are running there own company. Coding interviews should be done via a shared terminal/IDE screen and chat windows, that approach would be more realistic to some. But I'm one of those people who don't socialise too well at times, interviews/exams, that type of thing.
  - pacaro 14y ago
    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...
Zenst 14y ago
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?
- MattSayar 14y ago
  "What is your company culture like?"
- Swizec 14y ago
  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.
  - Zenst 14y ago
    Now ticketing, that reminds me of the ITIL standards and reamedy fun (slang for nightmares). If a company has ITIL I always ask them what proactive support measures do you have in place, always a good question that as ITIL is in essence more reactionary/event driven and as such does not lend itself well by design for catering for proactivity. I was in a server room once, smelt burned solder type smell, traced to a server that smelt like something had blown. All services/diagnostics/monitoring checked out fine and indeed it was working fine. I wanted to plan a changing of the server/have a hot standby ready for it being proactive as literly something smelt wrong. Alas the ticketing system did not alow such a ticket to be rasied as the server was not faulty and there was no issue showing. Two days later that very server failed, turned out PSU had died and taken out the raid controller on the motherboard in the process. The impact of this was more work than had it not been proactivly addressed. That is why when they say ITIL, then I fear how it is implemented and as such ask how do they proactivly deal issues. At the very least they should have root cause analysis mentioned, idealy they will sing all about there great Q&A processes and how that is all catered though open to suggestions. Your right about the canned marketing responses, most of those forget the interview is a two-way process sadly and deem any question you ask as a waste of there time, that is a sign you should take note of.
dabent 14y ago
A few other links for those wishing to get familiar with the process: From Google: http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/ http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/ From MIT: http://courses.csail.mit.edu/iap/interview/materials.php 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-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... 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 14y ago
  > 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 14y ago
    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 14y ago
      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.
  - Evbn 14y ago
    It is the only socially acceptable bigotry. Something JS to be the scapegoat....
Swizec 14y ago
I shared my experience in a blogpost: http://swizec.com/blog/inside-a-google-onsite-interview/swizec/4352 http://swizec.com/blog/inside-a-google-onsite-interview/swiz... 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.
- abecedarius 14y ago
  Hm? Hashing is O(N) unless it's oblivious to some bits. Though the prefix tree part is optional, yes. :-) Better luck next time. (For some reason programmers really love tries / prefix trees when answering on stackoverflow and such. I'd like to understand why -- tries are neat, but you don't see them nearly as much in actual use.)
  - JoshTriplett 14y ago
    > Hashing is O(N) unless it's oblivious to some bits. O(N) only makes sense when you agree on what N means. When using big-O notation, always make sure you agree on the base N values you want to work with. In this case, it sounds like you interpreted N as the number of bits to hash, in which case yes, any sensible hash algorithm has to look at all the bits so it'll use an O(N) algorithm. However, the post you replied to talked about hash tables, a structure used to implement (among other things) maps from keys to values. For such a structure, N refers to the number of items stored in the table; hash tables have the rather unique property of supporting O(1) insertion, removal, and lookups (modulo amortization arguments about the size of the table).
    - pjscott 14y ago
      Well put. I'd like to add that, while hashing time is proportional to the key length, in practice it's very, very fast for all non-enormous keys, at least on modern processors. Compare with the cost of pointer-chasing in a tree, and hashing time starts to look pretty constant-ish. (Yes I'm handwaving around the details. So is everyone who talks about big-O notation in connection with real software.)
philhippus 14y ago
“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.
jsnk 14y ago
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 14y ago
  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)?
  - rimantas 14y ago
    Because for programmers what they are asked to do in the interview can (and often is) very different from what they have to do on the job. Unless your job is to reverse strings on the whiteboard.
  - mrexroad 14y ago
    whiteboarding perfect syntax, delving into absurd language minutia and "gotchas", f'ing around w/ brain teasers while an interviewer introduces behavioral stressors (sighs, ticks, etc.) to see how i problem solve "under pressure" ...is all bullshit. so yeah, ask me to program. i mean, srsly program. let's hack together for an afternoon; hell, let's do a full day of paired programming to knock out a small bug in your code base. you'll learn a hell of a lot more about what i know, how i communicate, steps i take when i do when i don't know something, and what my processes are. this soft, inter-engineer-social stuff is overlooked over far too often; i wan't to work with people who will amplify my process and abilities, and in turn i'll amplify theirs. smarts don't count for enough.
    - robocop 14y ago
      I don't think this approach would scale, due to the time investment required. It also suffers from making it hard to compare one candidate to another in a fair way, unless you have everyone fix the same bugs. Having a bunch of canned bugs to be fixed doesn't seem much better than asking a CS puzzle.
cperciva 14y ago
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.
haberman 14y ago
> 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.
- seiko55 14y ago
  you are a googler, right? i think we've seen your posts.
  - haberman 14y ago
    Yes (I don't keep this a secret, it's right on my userinfo page). How does that pertain to this thread?
- Zenst 14y ago
  Indeed, sometimes the question is silly and you should not be afriad to question it. I was once asked about video conferencing in detail for some task and explained that recording via VCR and sending the output via tape would be more suitable and cost effective for what they were trying to use it for. You have to look at the initial question and peel of the layers until you find the reason for the question and then you can address the true problem. Sometimes somebody will ask how to computerise this and you will ook at it and sometimes find yourself asking how does it work now and again sometimes saying that what they have is already better or as good as a computerised system to that problem. In this cube land question you can answear, how are you defining the centre and just revering that process will already give you the code you require. What they are doing you don't know so you have to ask, may be they are trying to reinvent a wheel and with that the best answear may be how to draw a circle as there question is flawed. This is the problem with made up interview questions, if they are based upon real world experience then you get a good question that you can truely answear. You may have a better answear or approach which with them having lived it, makes enough sence to know you would of saved them 2 days debugging that problem and thats from a quick chat walking of the street. If it is a made up question then your approach and alternative answear can be missed and ignored and your genius is not appreicieated.
- 14y ago
nandemo 14y ago
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 14y ago
  >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 14y ago
    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 14y ago
      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.
ionwake 14y ago
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?
- mrbgty 14y ago
  Nope.
- dclusin 14y ago
  What industry do you work in?
- suyash 14y ago
  you get paid daily..what kind of company is this?
  - gutnor 14y ago
    Contracting in the UK. You are either paid per day or per hour. You bill per month typically.
- lexandstuff 14y ago
  Well, I'm 25. But I'm also a well paid developer (early six-figures in Melbourne, Australia) who would be pretty hopeless in these interviews.
- joezydeco 14y ago
  Not by a long shot. I'd love to work at a place like Google and would probably do just fine, but I'm 100% certain I'd never make it through the gauntlet. And I've been coding 25 years longer than the kids doing the interviewing.
- icelancer 14y ago
  Depends on the interview, but yeah I'd bomb most of the "CS theory" ones. And have.
drivebyacct2 14y ago
Step 2 is the most important from my experience.
stcredzero 14y ago
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.
- danielweber 14y ago
  Why were you typing while doing a phone interview? Was it related to the interview?
mrbgty 14y ago
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 14y ago
  Actually at most big company jobs the programming tasks have well known solutions but need people to grind them out.
barbs 14y ago
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 14y ago
  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 14y ago
    Sounds a like a good recommendation to me, thanks :). What would you recommend for the remaining 25% of the way?
    - wting 14y ago
      It's probably personally dependent to shore up your own weaknesses. Mine would probably more practice with recursion, dynamic programming, graph theory.
- Evbn 14y ago
  Yegge's blog post and CLR textbook are all you need. For a more social version go read the Reddit subrddit on interview problems or read glassdoor.
account_taken 14y ago
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 14y ago
  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.
wting 14y ago
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 14y ago
  > 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 14y ago
    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.
blaines 14y ago
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.

113 points by chapel 14y ago

I'd like to ask a question to google interviewers: when someone does not manage to get the best possible solution to a few questions, do you people chat together saying things like "he's not like us"?

DannyBee 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      Except that when you are using it as marketing in a book, there are very important distinctions. Lies of omission and all that.
      - glaak 14y ago
        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.
- glaak 14y ago
  I was in Seattle / Kirkland, and it was invite only there. I showed up every week (as did the vast majority of the Kirkland HC). But, yes, I could have been more extensive in my credentials. Unfortunately, "How to Crack the Toughest Coding Interviews by ex-Google engineer, ex-Google hiring committee member who showed up every week, ex-Apple dev, ex-Microsoft dev, author of Cracking the Coding Interview, and author of The Google Resume" was a bit too long :).
  - DannyBee 14y ago
    Fair :) I'm just used to MTV HC's, where you may have 75 HC members, and 10 active ones. I expect the "newer" offices (relatively, of course) may not have this issue.

capkutay 14y ago

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 14y ago
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.
- Zenst 14y ago
  A very fair point about talent at doing a job and talent at explaining the job in interviews. The term interview technique is like exam technique and in that is something that abstracts from doing the actual job. Unless that job entails interviewing people. With that this is probably a better read. Alot of people who fall into the boat of being good coders with social skills of dead fish often have a hard time. One appraoch is to create some wonderous application and get broaght out, recruitment that way. Or in the process, end up refining there social skills to the stage that not only can they interview ok but are running there own company. Coding interviews should be done via a shared terminal/IDE screen and chat windows, that approach would be more realistic to some. But I'm one of those people who don't socialise too well at times, interviews/exams, that type of thing.
- pacaro 14y ago
  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...

Zenst 14y ago

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?

MattSayar 14y ago
"What is your company culture like?"
Swizec 14y ago
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.
- Zenst 14y ago
  Now ticketing, that reminds me of the ITIL standards and reamedy fun (slang for nightmares). If a company has ITIL I always ask them what proactive support measures do you have in place, always a good question that as ITIL is in essence more reactionary/event driven and as such does not lend itself well by design for catering for proactivity. I was in a server room once, smelt burned solder type smell, traced to a server that smelt like something had blown. All services/diagnostics/monitoring checked out fine and indeed it was working fine. I wanted to plan a changing of the server/have a hot standby ready for it being proactive as literly something smelt wrong. Alas the ticketing system did not alow such a ticket to be rasied as the server was not faulty and there was no issue showing. Two days later that very server failed, turned out PSU had died and taken out the raid controller on the motherboard in the process. The impact of this was more work than had it not been proactivly addressed. That is why when they say ITIL, then I fear how it is implemented and as such ask how do they proactivly deal issues. At the very least they should have root cause analysis mentioned, idealy they will sing all about there great Q&A processes and how that is all catered though open to suggestions. Your right about the canned marketing responses, most of those forget the interview is a two-way process sadly and deem any question you ask as a waste of there time, that is a sign you should take note of.

dabent 14y ago

A few other links for those wishing to get familiar with the process: From Google: http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/ http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/ From MIT: http://courses.csail.mit.edu/iap/interview/materials.php 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-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... 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 14y ago
> 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 14y ago
  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 14y ago
    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.
- Evbn 14y ago
  It is the only socially acceptable bigotry. Something JS to be the scapegoat....

Swizec 14y ago

I shared my experience in a blogpost: http://swizec.com/blog/inside-a-google-onsite-interview/swizec/4352 http://swizec.com/blog/inside-a-google-onsite-interview/swiz... 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.

abecedarius 14y ago
Hm? Hashing is O(N) unless it's oblivious to some bits. Though the prefix tree part is optional, yes. :-) Better luck next time. (For some reason programmers really love tries / prefix trees when answering on stackoverflow and such. I'd like to understand why -- tries are neat, but you don't see them nearly as much in actual use.)
- JoshTriplett 14y ago
  > Hashing is O(N) unless it's oblivious to some bits. O(N) only makes sense when you agree on what N means. When using big-O notation, always make sure you agree on the base N values you want to work with. In this case, it sounds like you interpreted N as the number of bits to hash, in which case yes, any sensible hash algorithm has to look at all the bits so it'll use an O(N) algorithm. However, the post you replied to talked about hash tables, a structure used to implement (among other things) maps from keys to values. For such a structure, N refers to the number of items stored in the table; hash tables have the rather unique property of supporting O(1) insertion, removal, and lookups (modulo amortization arguments about the size of the table).
  - pjscott 14y ago
    Well put. I'd like to add that, while hashing time is proportional to the key length, in practice it's very, very fast for all non-enormous keys, at least on modern processors. Compare with the cost of pointer-chasing in a tree, and hashing time starts to look pretty constant-ish. (Yes I'm handwaving around the details. So is everyone who talks about big-O notation in connection with real software.)

philhippus 14y ago

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

jsnk 14y ago

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 14y ago
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)?
- rimantas 14y ago
  Because for programmers what they are asked to do in the interview can (and often is) very different from what they have to do on the job. Unless your job is to reverse strings on the whiteboard.
- mrexroad 14y ago
  whiteboarding perfect syntax, delving into absurd language minutia and "gotchas", f'ing around w/ brain teasers while an interviewer introduces behavioral stressors (sighs, ticks, etc.) to see how i problem solve "under pressure" ...is all bullshit. so yeah, ask me to program. i mean, srsly program. let's hack together for an afternoon; hell, let's do a full day of paired programming to knock out a small bug in your code base. you'll learn a hell of a lot more about what i know, how i communicate, steps i take when i do when i don't know something, and what my processes are. this soft, inter-engineer-social stuff is overlooked over far too often; i wan't to work with people who will amplify my process and abilities, and in turn i'll amplify theirs. smarts don't count for enough.
  - robocop 14y ago
    I don't think this approach would scale, due to the time investment required. It also suffers from making it hard to compare one candidate to another in a fair way, unless you have everyone fix the same bugs. Having a bunch of canned bugs to be fixed doesn't seem much better than asking a CS puzzle.

cperciva 14y ago

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.

haberman 14y ago

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

seiko55 14y ago
you are a googler, right? i think we've seen your posts.
- haberman 14y ago
  Yes (I don't keep this a secret, it's right on my userinfo page). How does that pertain to this thread?
Zenst 14y ago
Indeed, sometimes the question is silly and you should not be afriad to question it. I was once asked about video conferencing in detail for some task and explained that recording via VCR and sending the output via tape would be more suitable and cost effective for what they were trying to use it for. You have to look at the initial question and peel of the layers until you find the reason for the question and then you can address the true problem. Sometimes somebody will ask how to computerise this and you will ook at it and sometimes find yourself asking how does it work now and again sometimes saying that what they have is already better or as good as a computerised system to that problem. In this cube land question you can answear, how are you defining the centre and just revering that process will already give you the code you require. What they are doing you don't know so you have to ask, may be they are trying to reinvent a wheel and with that the best answear may be how to draw a circle as there question is flawed. This is the problem with made up interview questions, if they are based upon real world experience then you get a good question that you can truely answear. You may have a better answear or approach which with them having lived it, makes enough sence to know you would of saved them 2 days debugging that problem and thats from a quick chat walking of the street. If it is a made up question then your approach and alternative answear can be missed and ignored and your genius is not appreicieated.
14y ago

nandemo 14y ago

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 14y ago
>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 14y ago
  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 14y ago
    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.

ionwake 14y ago

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?

mrbgty 14y ago
Nope.
dclusin 14y ago
What industry do you work in?
suyash 14y ago
you get paid daily..what kind of company is this?
- gutnor 14y ago
  Contracting in the UK. You are either paid per day or per hour. You bill per month typically.
lexandstuff 14y ago
Well, I'm 25. But I'm also a well paid developer (early six-figures in Melbourne, Australia) who would be pretty hopeless in these interviews.
joezydeco 14y ago
Not by a long shot. I'd love to work at a place like Google and would probably do just fine, but I'm 100% certain I'd never make it through the gauntlet. And I've been coding 25 years longer than the kids doing the interviewing.
icelancer 14y ago
Depends on the interview, but yeah I'd bomb most of the "CS theory" ones. And have.

drivebyacct2 14y ago

Step 2 is the most important from my experience.

stcredzero 14y ago

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.

danielweber 14y ago
Why were you typing while doing a phone interview? Was it related to the interview?

mrbgty 14y ago

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 14y ago
Actually at most big company jobs the programming tasks have well known solutions but need people to grind them out.

barbs 14y ago

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 14y ago
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 14y ago
  Sounds a like a good recommendation to me, thanks :). What would you recommend for the remaining 25% of the way?
  - wting 14y ago
    It's probably personally dependent to shore up your own weaknesses. Mine would probably more practice with recursion, dynamic programming, graph theory.
Evbn 14y ago
Yegge's blog post and CLR textbook are all you need. For a more social version go read the Reddit subrddit on interview problems or read glassdoor.

account_taken 14y ago

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 14y ago
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.

wting 14y ago

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 14y ago
> 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 14y ago
  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.

blaines 14y ago

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.