She's spot on. I consider myself a competent developer (6 years experience, "big fish in a small pond"), and I don't really interview often. I've interviewed at Google twice, the first time doing 2 phone interviews and a round of on-site interviews, and the second time not making it past the phone interview.
I have prepared well for the interviews every time. I understand the algorithms, the data structures, and can program them on my own time no problem. But the second I'm in an interview setting, I lock up and can't think. I stumble across stupid thoughts (How many bits are in a byte? Oh yea, 8. But what about the 0th bit? What to do?!) and just work myself into a corner. All the while trying to seek approval from the interviewer. After about 2 minutes, I become a wreck and am hopeless.
I also don't consider myself non-social, and deal with coworkers very well. I still don't understand what it is about the technical interview setting that makes me act like this.
I'm no rockstar, but I can honestly claim to be pretty comfortable in technical interviews. I chalk that comfort up to two main things.
1) A mentality that says something like...
"I'm good, I'm solid. Fuck this guy."
The point isn't the specific words, or expressing this outwardly, it's about getting into a mental state of calm confidence, pushing out the anxiety and concerning yourself only with the moment.
2) Talking with and being challenged by smart people on a regular basis. Ideally people who are smarter and/or more knowledgeable than yourself. I expect being the big fish in a small pond generally works against this.
I don't usually think of it as "Fuck this guy", but rather, "I can help this company." There's a lot implicit in that statement - that I want to help this company, that this company can be helped, etc. But fundamentally, it's that I am offering more to my employer than they are offering to me. If they choose not to take me, that is their loss.
Actually, that seems to be a good mentality to build confidence in general. I've heard (I haven't managed it yet) that the secret to getting girls is to think of offering them the chance to be with you - you aren't trying to "get" the girl, but rather offering your companionship and emotional investment to a suitable girl who's willing to take it. The secret to networking is to offer favors to people in need of them. The secret to negotiation is to offer something of value to the other side and ask for something that they value less in return.
This is my secret to interviewing and speaking as well. On the inside I repeat, "Fuck this guy" or "I could beat the shit out of everyone in this audience" even though I don't truthfully want to cause harm to anybody. It helps surpress the deer-in-highlights fear resulting from being in the spotlight.
I think people feel comfortable in settings where they draw on a concrete body of knowledge (like most normal job interviews). With programming though, everything is logic, being able to dynamically model rules and patterns in your head is everything. You build these models in your head, using your programming talent, but they are like volatile memory, and you always need to reconstruct them. So when you go into an interview, you have little concrete knowledge to lean on, so off the bat you lack confidence and get worked up because you don't realise why this should be.
This kind of "skill" elitism will not help google create products that people want to use. They do not live in the same reality as their average user. The consistent failure of most of it's products in the past few years was caused - in part - by the complete lack of understanding people in general.
The average is nowhere near qualified to build the product they use, though, so that's not the problem. Focusing on CS algorithms more than HCI, maybe.
Valid point. But my opinion is that you cannot have your whole staff made of the same "category" of people. I guess diversity is not only about race, color or religion, is about people that come from all kinds of backgrounds, I'm "sure" that there isn't one single black guy without a degree that used to live in the bronx there. Maybe they are making products they want to use, not people in general. Intelligence is just a social fitting, really.
If a lot of talented engineers from Microsoft and Amazon are having trouble in Google interviews, doesn't that indicate that Google is testing the wrong things?
If writing a binary search tree thingamabob isn't relevant to the job they have 10 years experience in, why is the answer to that question so important at the goog?
Why not ask questions that are relevant to the experience the candidate does have ...
Because Google engineers don't seem to be hired for their experience with specific technologies/areas, but for their general competence.
EDIT: Sorry, I really should have avoided making a comment at all. Google's hiring practices have been debated here a billion times and I can't really add anything that hasn't been said before.
Google wants people who have a strong understand of CS fundamentals (which includes knowing core data structures). Google also wants people who are good coders (which includes being able to translate an idea into code).
A good coder who knows CS fundamentals should be able to do that. Thus, not knowing how to implement a binary search tree is revealing.
And, really, the question is rarely "implement a binary search tree." It may, however, be to implement a binary search tree which support a getMedian() operation.
Of course, not knowing how to write a library quality Java w/generics implementation of a a search API on a non-search tree, on the whiteboard, as one of my interviewers once demanded, is something a bit else.
I'm not sure that's a really good perception.
I've been on 3 of our hiring committees for about 5 years now.
The vast majority of candidate packets I see are well rounded in the interview space (IE don't just test theoretical aspects, but practical stuff as well).
There are occasional ones where one or more interviews is unhelpful or useless.
It would be very odd to see an interview where someone started out by asking about algorithm complexity, rather than "how do i sort this", "code it", "great, how fast does that run", "can it be made faster" or something similar.
I have never seen anything close to the last one.
Most false positives i've seen are culture fit or motivation issues, not technical capability ones.
Thanks for your answer. The last example was really an exaggeration.
"Most false positives i've seen are culture fit or motivation issues, not technical capability ones."
Interesting. Well, "everybody wants" to work at Google, but usually the way companies work is opaque to the outside (but then again, it's supposed to be like that usually)
Even though the interview is certainly intended to remove people that may not be a great fit (because of the time it takes, for a start) maybe something could be done in that respect
I've seen it all and some technical people really aren't a fit to certain cultures. Not to mention some work environments are the opposite of Google and bringing people from those environments may be a challenge.
The same is historically (and notoriously) true of Microsoft. I think the point is more that with this kind of screen there is just an inherently high false negative rate. That's a problem only if it's actually preventing you from hiring successfully.
More accurately, Google has the freedom to do that, because there are so many people applying to Google that the amount of talent they forfeit by not taking those guys is negligible.
Not true -- we need all the talent we can get. If someone that's good gets rejected, we'll contact them in a few months and hopefully not mess it up again. Mistakes are made in the interview process, but hopefully they aren't unforgivable.
After the last time I was interviewed (unsuccessfully - in 2007) by G I feel I have been blacklisted by them
Apparently there's a period before you can apply again (can't remember how long this is, 1 year maybe) but then again feeling like every contact you make goes to /dev/null is not nice.
Thankfully I know better today about what's it like to work at Google and probably won't be applying again (not that I find it bad, but it is not what I want).
I have had many failed interview cycles at G over the years, but sourcers kept reaching out every year. They used to be awful at maintaining relationships (contractors disappearing and ending the cycle without notifying anyone), but they are more organized and recruiting staffed up to match the workload recently.
I'm not a recruiter and have, in fact, interviewed a total of zero people at Google. But I'm betting we don't call people and say "you are not smart enough to work at Google". If anything, that's a bit too honest for a large corporation, don't you think :)
But seriously, interviews are very very subjective and interviewers have very wide latitude to ask anything they want. Individual interviewers pick the questions they'll ask, and everyone has their favorites. I have a friend that has a phone interview question that I probably couldn't answer correctly with an hour and a whiteboard: I just don't get it. So if I got a few more interviewers like that when I applied, I would not be working for Google, even though I'm theoretically "smart enough to work at Google".
Furthermore, you may be really smart, but that may not come out in the interview. If your interviewer asks you "what's two plus two" and you answer "four" and the rest of the interview consists of you making a latte, the interviewer may write "My candidate knocked the question out of the park. I asked him what two plus two was and he got the answer instantly. And then he made me a cup of coffee! Must hire!" When the hiring committee reads this, though, they might not reach the same conclusion: "It's great that he got an easy question and can make coffee, but is that really what we want?" In that case, you didn't mess up the interview at all: Google did.
So anyway, one should not be disheartened if they "fail" a Google interview. Hiring is a fine art and we are constantly learning. Please re-apply if you are interested in the work we do, and always give feedback to your recruiter. It's OK to call your recruiter after the interview and say "I was being hired to work on TCP optimization and they asked me questions about Java dependency injection frameworks, even though I said I've never used Java."
Many people who switch jobs aren't specifically looking (didn't Joel say the best candidates never are...?), but could easily be tempted by a good offer / company.
> If a lot of talented engineers from Microsoft and Amazon are having trouble in Google interviews, doesn't that indicate that Google is testing the wrong things?
From my experience the average quality of engineer at Google is very high. I think it simply indicates a different hiring bar.
Ironically, her book won't get you through the google interview if you are a new college grad. It may have sufficient coverage for Microsoft/Amazon interviews but not google.
From my experience the average google interview requires you to be so deeep into the algo/datastructure space, you should be able to code up the KMP algo off the top of your head. You have to be a topcoder with atleast 1200 rep or equivalent algo & coding skills. Coding speed also matters.
You should be able to scribble Floyd warshall.
Why this way? Well that's where google did most of their recruiting from back in the day. Anyone who says they got hired without this are either lying or got lucky in the interview process. Same goes for the new wave of startups in the bay area..facebook/palantir/quora etc.
I was very much into the OS, compiler space in school and that was what I was interested in. Got an offer from msft, amzn but not google. So kids, read up on CLRS & the algorith design manual, solve every problem there & also create your account today on topcoder if you'd like that job at el goog. Any other book that says otherwise is equivalent to Linux programming for dummies or Complete C++ in 21 days.
This sounds like sour grapes to me. Getting an offer from amazon and microsoft aren't trivial, and from the looks on glassdoor the salary range is the same. Why aren't you happy?
The Microsoft representatives have told me to use a short one page resume.
The Google representatives instead told me the exact opposite and said for me to put down everything relevant to the position regardless of length.
I now have two resumes, a short one for on the floor career fairs and a multi-page that I submit online.
i think the best answer to any google interview question i didn't know is..... "i'd google it"!
but seriously, why do i need to remember information about languages or algorithms i don't use daily? my memory is limited and i prefer it to be filled with the most useful information at the time.
This mentality works in general, but there are drawbacks. A large part of your problem solving ability is unconscious. If you don't have critical pieces of information committed to memory, you're essentially creating a ceiling on the types of problems you're capable of solving.
This might be the most insightful comment I've read on HN. I think this is the point people either miss or don't bother to address when claiming that they can just search for "arcane" facts instead of memorizing them.
In at least some cases, you can get by with having only the solution metadata committed to memory. For example, you might remember various data structures and their time complexity well enough to select the proper one, without necessarily being able to implement them all from memory.
This is tangental, but I find this an interesting topic - your memory not limited, at least not the way most people think it is. To be accurate - a body of experiments has failed to turn any evidence for old knowledge preventing formation of new knowledge, or new knowledge pushing out the old.
What prevents formation of new knowledge is time - you could learn A or B, but not both at the same time. What makes us forget piece A is not the piece B committed after A, but absence of repetition of A. If you repeat A every so often, you will remember it equally well regardless of whether you also repeat B or not during the same period.
i agree, memory is not limited in that sense. a better analogy is memory in some sense is sorted. topics that are used daily are generally near the 'front' of the que while older topics slowly fade to the background.
when fading to the background i envision a bubble forming around certain topics allowing one to use and reference them unconsciously at a macro level, but leaving the micro information hidden.
an example would be when i worked in games and did a ton of 3d math to animate and move objects around the world. at the time i was a gameplay programmer these ideas where at the tip of my fingers. i didn't have to think twice about matix multiplications, dot products, vector projections.
currently i work on ios/android development. i don't use 3d math much when deving any more. if you were to quiz me, i may not be able to implement or use those ideas very easily. a few weeks working with the same topics would bring them back to the forefront.
i learned all the sorting algorithms in college. i could probably implement a couple, but most of them i don't recall immediately or at all since i rarely care about the efficiency of the data i sort these days. i know of their existence, but to a degree that is all. if i were in a position where sorting was important, i would make sure to educate myself to appropriately.
i google almost everything. there are rarely days when i don't google something for work. learning is infinitely fun. i think being able to research a problem and find a solution is as valuable if not more as already knowing the solution.
Long term memory might not be limited but short term working memory is certainly limited. The short term working memory is important in solving problems in general.
This is actually an argument for committing those "arcane facts" to memory. The more of a concept you have internalized, the fewer slots it takes up in working memory when solving a problem, thus increasing your problem solving capacity.
You don't need to, but you should be able to recall them quickly when a problem starts to look like something already solved. There are a lot of developers who rewrite everything or whose lack of familiarity with the ins and outs of their language or how to apply simple algorithms leads them to come up with really complicated solutions to simple problems.
Perhaps there is too much emphasis on the interview process. Why not use the contract-to-hire method? It could be a short duration spanning a few weeks.
There are of course multiple drawbacks, but at least this method could help alleviate the problem of false negatives.
It takes many months to become a productive Engineer at Google, and in all of that time you are earning your full salary and being exposed to confidential information, so it's not realistic to try people out, as it would really only be valid after ramp up time; The challenge we face is figuring out if people will be successful here after they have picked up everything they need to know.
Good employees just won't do contract to hire. WHy give up a good job at MSFT or Goldman Sachs where you earn $150,000/year to do contract for hire for a couple of weeks with the chance you'll be out of a job?
The upside is you have a job that pays about the same at a company with about the same "brand name" value, ie working at all 3 is about equivalent.
Some may buy it for that reason. Are you implying it isn't likely to contain any useful information or advice on people who are actually interested in preparing for their interviews? Seems like a very pessimistic view.
probably not, unless you're really good at filtering out what you need from 1312 pages. a more tightly-focused programming interview study guide is probably more beneficial if your only goal is prepping for these sorts of interviews.
I (re-)ead a dozen chapters and sketched solutions to almost every problem in my head, over a few weeks of evening and weekends, leading up to my best interview performances ever. YMMV, but I saw a correlation with obvious mechanism of causation. For the most coveted jobs, "fake books" don't cut it, you can't memorize every question you will see.
I have prepared well for the interviews every time. I understand the algorithms, the data structures, and can program them on my own time no problem. But the second I'm in an interview setting, I lock up and can't think. I stumble across stupid thoughts (How many bits are in a byte? Oh yea, 8. But what about the 0th bit? What to do?!) and just work myself into a corner. All the while trying to seek approval from the interviewer. After about 2 minutes, I become a wreck and am hopeless.
I also don't consider myself non-social, and deal with coworkers very well. I still don't understand what it is about the technical interview setting that makes me act like this.