How to Score a Google Onsite Interview

Leave a Reply

Comment as a guest.

  1. I’ve been working as a contractor for several years and am constantly surprised by interviewers asking me questions about obscure topics or coding references. Stuff you would never memorize. Some interviewers act like you’re never going to have the internet to reference anything and all your knowledge is locked inside your head.

    1. Indeed. The more banal the coding questions, the less likely I am to want the job. I’ve cut short interview processes for asking me things like “which of the following is not a reserved keyword in C#?”
      Really? You want me to tell you what is not a reserved keyword in the primary language I was using for the last five years? I guess the rest of my resume wasn’t very interesting, then.
      Algorithm questions are a little more fair game–I ask these, just because it’s hard to figure out how else to gauge someone’s intelligence. But they’re imperfect at best–I think I’ve only had to write a sorting algorithm myself twice in the last some-odd years (and if you’re doing it much more than that, you’re probably doing it wrong).
      The issue I have with Allen’s essay isn’t that it’s inaccurate–this is, in fact how it is at companies like Microsoft and Google–but that it doesn’t ask the hard questions of how we, as interviewers, can do better. I am a pretty good interview candidate, but I know I’m a horrible interviewer. What I really want to know is how to do that better.

      1. Yea, I agree – getting interviews right is hard, and I certainly wouldn’t call myself an expert. I’m going to think about it a little bit, though, and perhaps write another article on it.

        1. I guess I also have little faith in my ability to judge which of my coworkers are good and bad even after working with them, so judging candidates is a lost cause. Incompetence is noticeable, and brilliance usually shines through, but the difference between moderately good and moderately bad? As an IC, I don’t need to recognize this, but it does make me think I’d be a shitty manager.

          1. To draw an analogy from baseball, most of the greatest managers were not great ballplayers themselves. (There are a few exceptions, such as Joe Torre.) What made (makes) these managers good is that they know how to maximize the production of their ballplayers. They understand the importance of teamwork; of recognizing when they have to make key strategic decisions (do you leave the starter in to face one more batter; do you steal a base; do you sacrifice a runner over in the hopes of scoring a single run even though you are giving up an out). Good managers realize there are going to be days when their starting pitcher is roughed up; when their #3 hitter is going to take an 0-for-4; when their Gold Glove fielder boots a routine play. They understand that a baseball season is 162 games (at least), so they need to manage for the long haul, not just focus on individual games or game situations.
            At least from my perspective, the types of interviews that are given do not test people’s ability to do jobs in realistic situations. Especially for people with lots of experience — they don’t commit implementation details or facts to memory. Instead, they recognize certain situations call for certain types of problem approaches, so they reference appropriate sources as solution aids.
            For those of you who interview people, and wonder how candidates get things wrong that they hadn’t done in 5,10, 15 years, think of something that you do not do regularly, but someone else thinks is important. If these things had come up on your interviews, you might not be working where you are right now.
            The other issue is that there is so much competition for jobs right now (at least at companies that have achieved a visible amount of success) that it’s basically a crap shoot whether you will get a particular job.

      2. Speaking as one of those interviewers known to ask language syntax, if you claim a decade’s experience, but cannot tell me which of abstract, public, and closure are reserved n the java version you claim to have used, I am going to have doubts about your resume and background. I have had people interview who could not write a line of code in what they claim as their favorite language. Not one.
        A gent who claimed a decade’s web and HTML development experience could not tell me what a doctype did, or give an example of a valid HTML page with a head and body tag.
        Don’t get insulted by a basic question. Assume your interviewer is spot checking the resume for blatant lies, and for some way to find the things you actually care about. And assume he has seen those lies before.

  2. “And I make no excuses for some of our interviewers who seem to have a chip on their shoulder and will put down candidates because they deem them unworthy of being a Googler, perhaps because they don’t have a Ph.D in CS or they don’t have a handful of github projects under their name.”
    Very good points. I think these rough interview processes tend to become like a fraternity hazing ritual–having gotten through them, employees believe that those tough questions are in fact the best indicators of true merit, no matter how ridiculous they really are.
    The one way I do think I have improved as an interviewer over the years is that I try more and more these days to be sympathetic and helpful to the candidate. We talk the problem over, discuss reasonable solutions, and look at his code together. In the real job, he’s not going to have me peering over his shoulder making smart-ass comments, but he will have me down the hall to help him out if he gets stumped. What I want to know is whether, with that help, he can be a great employee.
    For what it’s worth, my own experience interviewing has been that those gotcha questions seem in decline. I think some of that is a real trend and some of that is that I’m a bit more senior now, and people are more interested in asking me about my experiences than in getting my goat. For a college hire, unfortunately, I think there’s still a lot of goat-getting going on.

  3. I think I would enjoy interviewing at Google if I could meet Guido. Still, I dislike phone interviews. So will probably will never see the inside of google plex.

      1. And Allen you better stop posting all this on the internet, you are not a very competent interviewer to start with and you are now being an unworthy employee.

        1. I’m confused – I haven’t posted this article for months, nor have I interviewed for Google for months (I’ve left the company more than 6 months ago).
          As to my competence in interviewing, I wouldn’t know how *you* could know either way unless I personally interviewed you, and if I did and you found problems with it feel free to contact me directly.

  4. What is the “quirk” with (“x” == x) vs (x == “x”)? I’m not sure which language you’re referring to, but in most languages I’m used to (C, Python) string comparison is an abelian operation (order doesn’t matter). It’s ambiguous which is better if equality holds either way. (“x” == x) has the advantage of returning an error if you accidentally type an assignment, but the (x == “x’) is readable and arguably canonical. Personally, I’d pick whatever style you see in the source, but I don’t see how either option is advantageous over the other.

    1. Exactly why it’s a “quirk” and not a hard-and-fast rule – you may be writing your code as (“x” == x), or subconsciously using ++i or i += 1 instead of i++, and it wouldn’t matter in most languages, but it’s a sign that you’ve been burned in the past and understand the underlying issue. (another example I just thought of, some assertion libraries’ assertEquals() return the value of the first argument when the comparison fails)

    2. I can’ speak for other languages such as c or python, but in Java (x==”x”) may result in a NPE.

    3. What happens if you typo and forget an ‘=’? One of those alternatives is safer than the other, especially in weakly-typed languages.

      1. Still, I and most other developers I have seen still do (x==”x”) simply because it feels more natural.
        I wonder if there is a possibility in some languages that if x is in fact a property than the execution of the property get will occur at a different point in the compiled code thus causing a different result in certain conditions (threading/event triggering issues perhaps?). Though if your code is reliant on something that side-effecty then it’s probably way too brittle and needs a heavy redesign.

      2. Arguably, in K&R, which is considered a quality reference work for C programmers, (x == “x”) is liberally used. I can’t speak for C++, having done very little programming in it (and none recently).

  5. cracking google interview is pinnacle of job interview specially in programming they really test your so called programming skill not the language skill like Java and C++ . there questions requires real brain storm and there followup are even more tougher but noways there are lots of resource available so don’t forget to use those before heading for google interview.
    How Classpath works in Java

    1. You have to be joking. I went to a google interview and they asked me three easy coding questions. I didn’t do well and have no defense except for I was nervous and trying to write python with a cryon on a wall. But when the interview finished before being asked a single question that requires real thought, I was a very surprised. To top this off, I asked my interviewer what its like to work for google, which he then used as an opportunity to brag about his awesomeness. I wasn’t impressed to say the least…

  6. Let’s say I had a phone screen or in person interview with Google and it went badly, for whatever reason. Would that at all inhibit my chances later on, say a year or so down the line? Or even with another branch or section of Google? I really would like to work there but I’m not sure my current skill set is up to par… yet.

    1. I don’t think it should, unless your feedback is laced with big bold “DO NOT HIRE THIS PERSON UNDER ANY CIRCUMSTANCES” disclaimers. Which you wouldn’t get unless you personally insulted the interviewer with your intelligence.
      So yea, you’re fine. =)

  7. “quantify your experience with various technologies”
    Do you think it’s worthwhile to list the languages with which you are only peripherally familiar or ones that you haven’t used in the last, say, 5 years? As an example, I’ve done a little php hacking now and then to tweak pre-packaged web sites I’ve set up, but I wouldn’t even know where to start from scratch. Or, I used a lot of Java for several classes in college, but that was 10 years ago. Would you recommend leaving that stuff out entirely, or is there a good way to word it so I can set expectations low but still have the buzzwords?

    1. On my own resume, I separate the two by listing my favorite languages as “familiar with…” and ones I’ve come across as “have experience with…”; it should be clear esp. if you list them right next to each other. You’re right in that having the buzzwords on your resume will get you past sourcerers and recruiters, though.

      1. Weird. Familiar is a weak word to me on a resume. Maybe I have been picking the wrong words. In a conversation, if I answer “Do you know X?” with “I am familiar with it” then I am really not inviting you to bank on my knowledge, but if I tell you, “I have good experience with X.” Now I am telling you ready to rock: lock and load with your questions!

    1. I actually recommend that people when I’m doing phone screens. I want to see their code, not watch them do mental gymnastics trying to cope with the editor.

      1. Generous of you. The other thing that made me giggle in Docs is a Python triple-quoted docstring:
        “””don’t try this at home”””

  8. I’ve probably interviewed at least 100+ people in the past 3 years for different languages/teams (not for Google though). Personally, I think it’s harder to differentiate a candidate on paper than in interviews. All the resumes begin to look the same, and most people who tries to look different just ends up sounding…weird.
    I agree with Allen on most of the points he discussed in this article. It is most essential I think to talk out your thinking process; even if you don’t know the answer to something, as long as I know how you’re thinking, I can judge how well you can logically think things through or your ability to analyze a problem. Some candidates can not even see what the problem is when I ask an analytical problem or they are not solving the real issue. I don’t always care about the correct answer either, because a good candidate now may still be a good candidate tomorrow or fall slightly behind the crowd, but a candidate who can become great tomorrow, that’s what I am looking for (for full times only, for contractors though, you better know anything and everything).
    Once I had this candidate who talked the problems out loud, and her thought process was good, she set up the individual steps to solve the problem perfectly, but somehow she ended up with the wrong answer albeit very close to the correct one so I gave her somewhat of a positive mark anyways.
    My advise is that don’t think of this as an interview, think of of this as a discussion between experts on some of the issues that we need to solve. If you don’t know the answer, ask and find out (it just might show up on your next interview), or tell me you have tried some things that didn’t work. Remember, when Edison was asked “why do you keep trying after failing 2,000 times, before finally inventing the light bulb”, he answered “I didn’t fail 2,000 times, I found 2000 ways how not to invent a light bulb”. You really can’t fail a interview as long as you learned everything that was there to be discussed in it.
    I do ask a lot of exotic coding questions that you’d use only once in a life time. I don’t base your interview on getting those wrong, but it tells me where you have explored in this language. Normally, people are satisfied with completing their job according to requirements. If requirement says loop ten times, you write a loop that loop ten times, you’re done. Rare individuals ask, hey, do I really need to loop ten times? Is there a better way? This individual will say there should be a better way….he/she will do some research on the internet, and find something called recursive functions and implement that if it fits better. Either way, he/she now knows what a recursive function is while most programmers don’t. This is obviously a simple example and most of us knows what a recursive function is; but this is the illustrate while people ask these kind of questions. If you don’t get it right, that’s ok, but if you DO, you’ll capture my attention immediately.
    Be honest, you can put 5, 10 years of experience, but if I ask you the most basic question and you can’t even answer that, then you either lied or wasted all those years, either way, I don’t want you. I’ve interviewed candidates with 12 years of experience (and we verified through our network that, that person have at least 9 years of verifiable work experience solely at that company so it’s probably true for 12 years), but the candidate had problems even with the most basic questions. It does depend on companies, some companies will let you do only 1 project, after project goes live, you support this project until it is obsolete. You’d obviously have no stress what so ever but you’ll lose your skills over the years.
    Your best tool in your interview is your communication (and I don’t mean perfect english). Good communication can make your lack of knowledge look average and your average knowledge look good. It is the basis for understanding what is being asked and what you are answering. If you explain something and I understand exactly what you have in mind without any loss of information and without possible mis-interpretations, you’ve got the communications down, even if you have to draw diagrams, use hand gestures, NO LIMITATIONS on how you communicate to me.
    Try different things out, be confident and put your personalities into it. Good luck everyone!

    1. ” … and most
      people who tries to look different just ends up sounding…weird.” Your grammar is … weird. People do not “tries” – they “try”.

      1. Well, English IS my second language but:
        “The noun people has both a PLURAL sense and a SINGULAR sense.
        In the PLURAL sense, people is used as the plural of person very frequently. It is a plural count noun and takes a plural verb. It never has an –s ending; it is already plural.In contrast, the SINGULAR sense of people is used to refer to ALL the men, women, and children of a particular tribe, nation, country or ethnic group, speaking of them as a UNIT, and so the phrase a great people is indeed singular. It is a singular count noun”In the above case, people referS to the group of personS who TRIES (because the subject is A group) to look different but fails. My POINT is that it is hard to look different on paper. This also reiterates my point that communication is not about perfect EnglishI do apologize for some of the mistakes in the reply, I never intended to write such a long reply, just wanted to help; I am trying to submit my resume to Google so my friend sent me this link. I was in a hurry so some of the later parts sound weird. For those who are looking for real advice, look beyond the words and read the message!

        1. LOL. Acrien, the message is important. But you said “most people” – so what unit exactly is “most”? Just pointing this out – I mean language and being correct in usage is important…

  9. Geez, it’s been so long since I had a job actually doing what was listed as the requirements or responsibilities or asked about during the interview process an actual interview would be tough to get through.
    I’ve always worked in places, oh, there is a problem, see if you can solve it.
    As far as the guy with a 5 page resume and willing to take any job I would surely empathise with the guy and at least try to see if he might be of use rather than just scoffing at him; but no, I wouldn’t want to be him. I mean, after all, most resumes I’ve seen, even at one page, are very poorly written. So a well written resume of 5 pages, well that says a lot to me…

  10. “I’ll see someone put “expert in Javascript” on their resume, only to find that they barely know the syntax to jQuery…”
    You must be joking. Just because someone is not familiar with the jQuery library means they do not know Javascript? Personally, I HATE having to download big Javascript librarys–most of which will be unused–just so the site can do some stupid javascript tricks like expanding image boxes or annoying accordion menus.

    1. I generally agree that *BIG* libraries are problematic, but the jQuery site lists the minifed/gzipped size as 31kb. Also, your quote is a little out of context; the next line suggests the candidate did even worse when the library was taken away.

  11. Is not asking any questions (as the interviewee) during the phone screens considered a show stopper ?
    After all, one reads a lot about
    the workplace culture at Google. Other questions about the daily work such as ‘how large data sets do you actually need to deal with’
    are probably
    asking for classified information…

    1. Not at all. If there’s something we can’t tell you, then we simply won’t; it’s not like we’ll take points off because of curiosity. So go ahead, ask away.

  12. Well, I have been through a Google on-site Interview for an SRE position. I did not get an offer (although they have contacted me again recently), and in retrospect,I believe the problem was that I have done real and often complicated work in too many different languages and think in terms of the problem and algorithmics, as I am sure I can code it later in whatever.r That means ttanstansi@tansi:disqus i@tansi.orghey are systematically screening out people with broad programming experience that regard one more language as one more tool. This strikes me as an extremely bad thing. In my experience, developers that only know how to do real things in one or two languages usually think in terms of the language and are completely unsuitable as designers or architects and often have serious trouble learning anything new.
    Consequentially, I now have to explain to a Google recruiter that after that interview 2 years back I am not interested anymore. I have already exhausted the polite options. Seems to me they are really not used to that reaction.

    1. I went through exactly the same thing (on-site for SRE) many years ago and came away thoroughly unimpressed with the interview process. I got asked a lot of what I call “manual page” questions: things I know about, have forgotten the details and know where to go for reference next time the need arises. It ended with “we’re not interested because we think you’re too broad and not deep enough.” I had to chuckle at that because I was working for a company that values people with broad experience and am still there because the problems I work on require breadth of experience to solve effectively.
      Many of the people who interviewed me were much younger than I was, which put them in a phase of their careers where being “good” means depth as compensation for lack of breadth. I don’t fault them for that because I went through the same thing but was fortunate to have been mentored by people who’d been around the block and came to appreciate what that experience brings.
      They’ve called back a couple of times since then, and I can’t help but think you’re absolutely right, that their recruiting process is predicated on the idea that people will fall all over themselves to work there. The recruiters also had no clue whatsoever that I’d interviewed there before. *SHRUG*

    1. There are Google engineers with no CS degree (like me). You have to know computer science, and how to write code. 

  13. I like what I do and I’m good at it; been coding over 20 years. Made it on-site last year in Mountain View only to find that everyone there is about 29 years old. Never had a chance…..

    1. @6123237b4d6e901a2f58e7c0bbd883a7:disqus I’m laughing right along with you! I’m damn good at what I do, but I’m too “old” for this job market. Anyway, something must have happened to the English laanguage while I was away working, because I can’t understand a damn thing the HR people say these days.

    2. Laughing right along with you! I’d love to see all these hotshots in 20 years when they realize no one’s hiring THEM because they’re “too old.” A word of advice, kids: plan for the future, and I don’t mean hoping you’re going to score big in an IPO.

  14. so apparently you are going to have a company filled with CS fresh graduates? a set of newbies fairly homogeneous with no variety in style or ways of thinking or even age?
    why not simply hire the next 6,000 resumes that come in as “interns” (if their resumes are vaguely in the ball park) telling them that they might not be there in 2 months, and then see who actually produces and who’s personalities you like, and let the rest go not caring what was on their original resume)… you’ll end up with maybe 500 candidates in three months, and then hire another 6,000 etc… it’s not like you pay “interns” do you? or at least you pay them very little correct? so you’ll spend a little more on managers managing for a year before you are at 1/2 speed, big deal. how is that going to be any different after hiring 6000 new people anyway?
    At least now you will have a lot better/varied environment of talent after one year than a set of CS kids that probably all think too similarly (freshly taken a binary search database class) if they pass the standard interview process, this is the type of person who will pass such phone interviews anyway.

    1. A number of problems w/ your assertions/ideas:
      – No, we don’t hire just fresh CS grads. Turns out good engineers still remember their CS after having years of industry exp. I myself joined after being in the industry for 6+ years.
      – I’d recken we don’t even get 50 hires after screening 6000, much less 500.
      – Yes, we, like most other tech. companies pay our interns, and probably above industry average.
      – You’d have to find projects self-contained enough and small enough for interns to do. Turns out those are hard to find.
      – Interns actually cost a lot of money, not in salary but in having to spend engineering time to manage them. What’s the easiest way to piss off a bunch of good engineers? Make them work with bad ones.

  15. All you coders and programmers are lucky. Don’t complain. I was a 6th grade teacher for 7 years and got laid off. I had to buy my kid’s birthday presents at Goodwill this year. I work three part time jobs and still visit the food bank. Be happy for what you have.

  16. After the second interview I had two years ago the arrogance and sense of general superiority I found in both the interviewers and to some extent the questions themesemlves really struck me, so much so that when last year they contacted me again, I politly refused the interview at all…

  17. Neat post! Really helpful for upcoming Software Engineers to get a good look at how interviews are designed. 

  18. Well written post.You have done a great job by sharing this information with us.Its really an informative post.Keep in touch with us in future too.

  19. All the point covered in the article are very useful not only for interview in Google but in any software company. I just completed my graduation and going through some interview in local  companies. I find them little tough specially with cross platform questions. I just imagine how tough a interview can be in Google. 🙂

  20. Brilliant blog. Definitely given me something to think about.This is my first time reading this blog. Definitely won’t be my last though, really enjoyed it.

  21. Really great to finally find a blog I can relate to. Just my kind of thing.I hadn’t thought of some of these Interesting piece. 

Sliding Sidebar