25 ms·

Google's sort of "computer science trivia" style interview is the bane of software engineering. "CS trivia" interviews select for people who know the mathemati

Google's sort of "computer science trivia" style interview is the bane of software engineering. "CS trivia" interviews select for people who know the mathematics of computer science, not for people who know how to ship robust software systems on time and within budget. The two are only loosely related and mostly uncorrelated. In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. Just because someone can recite algorithms and data structures in their sleep doesn't mean they can effectively scope, plan, or execute a complex software dev project; and conversely many of the best engineers either never learned or long ago forgot the details of the CS. This mode of interviewing is like interviewing the contractor you're considering to remodel your bathroom by handing them a pile of iron ore and asking them to smelt high grade structural steel out of it. So why do they do this? Lack of any better option. Their previous "brainteaser" style interview didn't work at all, and this is probably marginally better than that at finding good engineers. But more importantly, it's much cheaper and faster and less risky in terms of confidentiality than hiring candidates as temporary contractors for a real world test doing actual work, which is the only remotely effective way to tell who is actually a good engineer.

walshemj 10y ago
That is is a good analogy.
chii 10y ago
How does one hire a contractor for other industries? I'd garner that word of mouth is the way. The alternative is an association and certification body (not too disimilar to the medical association or the bar for lawyers), and gating the access to this certificate.
EduardoBautista 10y ago
Well they are pretty successful, so they must be doing something right.
mattnewton 10y ago
Who writes those premade robust libraries? Who improves them, when a few percentages of improvement will be multiplied by enough machines to come out to millions of dollars saved? If you have a pile of raw iron and you're currently running your own smelt for cost savings over the other remodelers, maybe even though you are in the remodeling business you could use those skills. I agree though that contracting is by far the best way to grade performance. But the Google style interview is the only reasonable alternative I know of to filter out people who don't actually know the technologies they are talking about and can fake it with other people's code for months.
- blub 10y ago
  Re libraries: the library team I would assume and hope, since this is a very specialised skill.
  - jasode 10y ago
    >the library team I would assume and hope, I've never been at a company that had a dedicated "library team". The common code and functions that go into the libraries are artifacts of programming the other stuff that needs it. It's not a job title. (Unless the company's product to sell is a compiler. In that case, it would follow Conway's Law and you'd have a set of programmer's implementing the standard library. I don't see how that division of responsibilities applies to Google or other companies.)
    - Ar-Curunir 10y ago
      Pretty sure Google has multiple such teams dedicating to writing performance code that can be reused.
- fail2fail2ban 10y ago
  He's saying every company needs a Sheldon or two; they don't need a company full of Sheldons.
  - 10y ago
rawnlq 10y ago
Google internal libraries and infrastructure are very good and way better than most "off the shelf" libraries. Any rank and file engineer can and do contribute to them. In that case I don't see why they should lower their bar to people who can merely consume these libraries when they can take their pick at people who can do both.
- blahfuk 10y ago
  I've seen GWT, and Angular 2.0, they're not any better than other open source frameworks, and many would say they're much worse
  - ashark 10y ago
    Ha, yeah, if they could let some of that "magical internal tools" goodness seep out into the Android SDK I'd be pretty happy, since there's no sign of anything special there now, to put it mildly. Failing that, just buy Square and hand the whole thing over to them, since they seem to have a much better idea of how to write useful, usable, capable tools on the platform than Google does. Please.
- lkmslkmdfsd 10y ago
  > Google internal libraries and infrastructure are very good and way better than most "off the shelf" libraries. Citations needed.
  - adpirz 10y ago
    As much as I'd like to see them as well, I'd imagine we won't get much as that's Google's IP, but would love to know generically if that's true from anyone who has worked with said libraries.
  - lallysingh 10y ago
    https://chromium.googlesource.com/chromium/src/base/+/master https://chromium.googlesource.com/chromium/src/base/+/master
bmay 10y ago
> In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. How do you know that DAGs and rb-trees are the best solution to your problem if you don't even know basic data structures?
- theli0nheart 10y ago
  Ugh, this sort of computer science-shaming needs to stop. I've been building software professionally for 10 years now and not once have I ever needed to weigh the pros / cons of a DAG versus rb-tree. I'm too busy dealing with CSS bugs, figuring out why customer retention is lower than it should be, training my clients on how to use a bug tracker, scaling, and hundreds of other things which are magnitudes more important than this implementation detail. Somehow I've managed to make a career out of this. ¯\_(ツ)_/¯
  - partycoder 10y ago
    But ask yourself: how does your browser layout engine and scripting engine work? Is CSS some sort of self-hosting language that just materialized out of nowhere? Or there's somewhere a group of people responsible for it? (e.g: Google's Chromium team, Mozilla's Firefox team, Apple's Safari team, Microsoft's Edge team, etc.) Those people DO need to know data structures. For you to be able to focus on CSS, HTML and JavaScript, someone, somewhere needs to make CSS, HTML and JavaScript work for you in the first place.
    - fail2fail2ban 10y ago
      > But ask yourself: how does your browser layout engine and scripting engine work? [But ask yourself: how does your car's engine work?]
      - partycoder 10y ago
        My point is: he can focus on HTML, CSS and JavaScript all he wants, and remain abstracted from internals. That's fine. But here we are talking about one of the companies responsible for implementing such technologies, where the science he implies as not being very relevant IS relevant. It's the difference between applying to a truck driver work, to a truck engine designer work. For the latter, knowing the theory of an internal combustion engine IS relevant.
partycoder 10y ago
Google does have projects that require clear understanding of the things you classify as trivia. Their search crawler, their distributed computing technology from which projects like Hadoop drew inspiration from, their cloud platform with custom hardware, Tensorflow, their custom Linux kernel and Android, improvements to network protocols like HTTP, v8, Chrome, Project Zero, and user facing apps like Maps, Translate, etc, etc, etc. All those important projects will require you to know your way around the fundamentals from the ground up and think out of the box. Then, they have lots of applicants. They can be more selective than they need to.
- pjlegato 10y ago
  The second factor is far more important than the first. There are any number of engineers who can simply go read up on the fundamentals as they are needed, or who understand them well enough to work with them but lack a mathematical proof-level command of the material. Google just doesn't need to hire them because they're paying much higher than market rate.
  - partycoder 10y ago
    Trial and error doesn't go that far. Also they have customers and a reputation to maintain, they cannot afford the risk of learning going wrong.
wmil 10y ago
I don't completely disagree with you, but in Google mathy CS skills are probably better than robust SE skills Things need to operate on enormous scale. It's easy to imagine a case where Google would need to implement something algorithmic because well tested libraries aren't quite doing the right thing. The libraries are generally designed to work in RAM / HD. Google needs them to work across multiple servers / datacenters.
- fail2fail2ban 10y ago
  > enormous scale Add more nodes. Scaling is not difficult.
- Shorel 10y ago
  The company itself started because they implemented 'something algorithmic'. They know that's what made them different in the first place.
ng12 10y ago
> This mode of interviewing is like interviewing the contractor you're considering to remodel your bathroom by handing them a pile of iron ore and asking them to smelt high grade structural steel out of it. That's a terrible analogy. I'm hiring a home contractor for a discrete, predefined set of skills. They need to be able to install a sink and retile a floor -- and once they do that I'll never have need of them again. Software engineers are not tradesmen. What you know is less important than your ability to figure things out. If Google wants to select heavily for that quality it's a totally reasonable approach.
- stonogo 10y ago
  > What you know is less important than your ability to figure things out. The sooner you realize that this is true of every single human endeavour, the better off you'll be.
  - vkou 10y ago
    When my sink leaks, I'd rather hire a plumber that has done a standard job ten thousand times, than a bright guy with a pipe wrench, a bag of PVC, and an exacto knife, who can 'figure things out'.
    - stonogo 10y ago
      This is how competent managers regard programmers, just so you know. But that ten-thousandth time, when the standard job goes awry -- that's what makes the difference between a dude showing up to work and a tradesman. The ability to react quickly and appropriately when faced with a brand-new problem is valuable in any role. Pretending otherwise is hubristic at best and kind of gross in general.
    - GrumpyYoungMan 10y ago
      That's the point. Google and the rest of the big 4 don't need ordinary plumbers, they need process engineers (the engineers who design the piping at oil refineries and chemical plants) because they are tackling problems that nobody has done ten times, let alone "ten thousand times".
dragonwriter 10y ago
> In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. Unless, you know, you are implementing the standard library for a new language, so that there is no such "off the shelf library" available. Which its not been completely unknown for Google software engineers to do. "Off the shelf libraries" aren't things that are handed down on stone tablets to the prophet on a mountaintop, they are things that are created by software engineers. In any case, understanding which algorithms and data structures to use, even if you are using a pre-made library, and the impacts of that decision requires an understanding of the algorithms and data structures similar to that which is needed to implement them (it doesn't strictly require the ability to implement, but ability to implement isn't an unreasonable way of filtering for the requisite knowledge.)
- blub 10y ago
  Let's be frank, most google engineers don't create new programming languages or work on library infrastructure. The only common topic they all work on is selling our eyeballs and collecting our data. Interviewing for that would make more sense than the algo stuff. P.S: there's a difference between knowing typical algorithms needed to solve a class of problems and studying to implement them on a whiteboard.
  - dragonwriter 10y ago
    > there's a difference between knowing typical algorithms needed to solve a class of problems and studying to implement them on a whiteboard. I'm not sure that's all that true; even if you haven't specifically studied to implement the particular algorithm, if you are familiar with the concept of the algorithm and proficient in the implementation language, then coming up with some kind of cut of an implementation isn't an unreasonable request. (Now, if the evaluation of the quality of the implementation is unreasonable for the context in which it was requested, that's a problem, but if its used to judge understanding of the concept, if potential problems in the implementation are the focus of probing questions to determine understanding rather than straight rejection, etc., I don't necessarily see a problem.)
- 10y ago
raverbashing 10y ago
Building a good product is not just a matter of knowing CS questions The good thing about CS research is that it can be productized into libraries and tools
skybrian 10y ago
From the article: "From what I've read, you won't implement a balanced search tree in your interview." Despite being an interviewer, I don't know if that's true. I do know it's not what I ask about.
- daveFNbuck 10y ago
  It's pretty safe to say you won't implement one, even if the interviewer does ask you to.
dmoy 10y ago
You're not supposed to ask brainteaser or trivia type questions as a Google interviewer anymore. But yea I agree with the rest of your post. Also another factor beyond confidentiality is that you can't hire people from other companies through that pipeline, cus they won't do it. Also worth noting that for certain classes of engineers (new grads), Google does sort of hire people as contractors (though they're full-time with benefits), see the eng residency program.
- pjlegato 10y ago
  Er. I actually said that they don't use brainteasers anymore in the post.
  - dmoy 10y ago
    Yes, hence the OR. You're not really supposed to use cs trivia style questions either. Both are deprecated. It will take awhile for interviewers to catch up though... I suppose I should have capitalized the OR
- tyleraldrich 10y ago
  > You're not supposed to ask brainteaser or trivia type questions as a Google interviewer anymore. That's what previous means in: > Their previous "brainteaser" style interview didn't work at all
  - dmoy 10y ago
    Yes sorry, my sentence scans better with a capital 'OR'
solipsism 10y ago
Why do they do this? The answer you haven't considered is, "because it works." I assume you haven't considered it because doing so would mean wrestling with the fact that your intuition isn't always right. Google has turned interviewing into a science. They have interviewed millions of engineers, hired hundreds of thousands, rejected and later hired who knows how many, etc. Many incoming interviewees have also interviewed across silicon valley. And all along the way they've been collecting data and refining their process. Do you have anything except your intuition to show us that the Google style interview doesn't work? One thing you may fail to consider is that there doesn't need to be a direct and plain link between the interview questions and the work the engineer will end up doing. All that matters is whether the interview process produces a clean and strong signal that leads to quality hires. As a person who's been through a Google interview, I can imagine many of my former co-workers performing poorly. Those are exactly the kinds of engineers I don't want to work with. I have spent too much of my time explaining basic concepts to engineers who should already be comfortable with those concepts, or who lack the critical thinking skills to be part of the conversation. So there's my anecdote. Before telling a company how they should conduct interviews, perhaps you should gather some data.
- pjlegato 10y ago
  I never told any company how they should conduct their interviews. Google is of course free to spend their money however they see fit. This was not written for the benefit of Google, but for the benefit of the many others who are considering whether something is a best practice simply because Google does it. As for why they do this, your conclusion is kind of exactly what I got to in the last paragraph, "for lack of a better option." It's not that it works in some optimal sense; it just works less badly than the other options available, according to their business constraints. I base my claim on my many years of personal experience as a software engineer, both being interviewed and interviewing others, discussing engineering and CS with numerous people. My anecdote: I once worked with a guy with quite reasonable academic CS skills who decided to re-implement SSL from scratch for a bog-standard webapp, rather than use a library to do HTTPS. That was not a good use of the company's limited budget, which he would have known if he had had any engineering skills (as opposed to CS skills.) In my experience, there is little (though not zero) correlation between "good at CS" and "good at writing software commercially." The Google interview process is probably better than nothing, and probably better than their previous "brainteaser" style interview, but far from optimal. As for what I'd select for? I'd certainly reject candidates who manifest anything like the condescending and arrogant attitude you display towards people you consider to be your intellectual inferiors. Even if you're an amazing engineer who can recite the CS in your sleep, that attitude is toxic for any team environment and will be a net loss to the company.
googlereject 10y ago
I am so happy that early on in my career I failed at multiple attempts to get a job at Google (after having graduated Stanford in CS in 2008). Despite having already built some objectively impressive and popular projects used by millions of people, I was asked to solve boggle, random C trivia questions, and write a sort algorithm I'll never need in my career, all on a whiteboard, and I just wasn't comfortable with that style of interview. I was upset for a while but just kept iterating on my own projects and now I am passively making far more than I ever would at Google even including generous stock grants (mid 7 figures). It's much more rewarding too, knowing I created my own destiny, and not just some middle engineer on a mothership living off of an easy adwords monopoly. My suggestion to anyone who has the perseverance to get through a guide like this is to just forget Google and build something new yourself.
orthoganol 10y ago
Don't forget - Google has a culture they're protecting. I'll play devil's advocate and say while it's maybe not immediately useful, it's probably a very good test for culture fit. If you're the kind of person who thinks about the math of algorithms in your free time, because you enjoy it or think it's fundamentally important, you're probably more likely to be a Google culture fit. If you're a successful product shipper, but you have an aggressive "get shit done" attitude and don't care much about the science and math, maybe you are not going to make the discussions with fellow Googlers that Google envisions happening around campus, or maybe you're likely to be highly success/ money oriented or I don't know, go against the culture fit criteria in some way.
soham 10y ago
[Disclaimer: I run an interview prep bootcamp http://interviewkickstart.com http://interviewkickstart.com] As someone who helped set interview process at my previous employer (not Google), and other companies now as a consultant, your reasoning of why these companies have a process like this, looks right. Let's dig a little deeper too. Consider the following facts: 0. Google has some 30k-40k engineers, with average tenure of say 7 years. So every 7 years, they are hiring 30-40k engineers. That is thousands of engineers every year, even if they are not growing (and they are). It's a massive undertaking. 1. In the field of software engineering, unfortunately, experience has little correlation to expertise. That has been known for a long time. See [1]. And cognitive ability is at least a reasonable predictor of success, better than many others. See [2]. 2. Companies like Google have no dearth of applications. Literally millions or engineers apply. 3. Interviewing is a chore, and mostly not fun. Most interviewERs hate spending time on it, and want to get out of it as quickly as possible. Interviewing is also on top of everyday work which is a lot at many growing companies. 4. As a hiring manager, I have to hire people. There is no choice. I must find a way to hire N people in X amount of time, or the company is literally doomed. e.g. if I'm eBay or Amazon, I can't miss the holiday season. 5. You have to involve multiple people in hiring. Just one person talking to the candidate and making a decision is not sufficient. 6. Programming is so vast, that engineers apply from all sorts of backgrounds and domains. 7. Companies are becoming more and more polyglot. You want engineers to move around different languages and stacks freely. So when you have a lot of people to hire, a lot of people applying, work that's somewhat correlated to cognitive ability and very little time, what kind of process do you end up setting? When you put these constraints together, you realize that your incentive is to design a generic process that's convenient to the company, and not convenient to the candidates. You just want reasonably smart people, fast. You don't care about seniority much, and the type of problems asked, as long as it helps you close N people in X time, by putting in least amount of work. A different process might have selected for different kind of N people, but that process would take longer than this. And time is money too. A process with DS/Algos is less subjective, fast (like you said), can be prepared for (you have to hire), has enough variety that multiple people can ask different questions, lets you interview across domains, and is at least somewhat defensible-ly relevant to the field. And hence, here we are. Not saying that the process is understood by everyone and executed well everywhere and every time, but for several years, we're all still looking for process that's lesser evil, and we haven't found one. As long as the constraints outlined above remain, the process is going to stay. In some form or another. For a very long time. However much everyone hates it, including the interviewers, and the company itself. Many have tried otherwise (including myself), but most have come around to asking DS/Algos somewhere in the process in varying percentages. [1]. http://www.ida.liu.se/~nilda08/Anders_Ericsson/Ericsson_delib_pract.pdf http://www.ida.liu.se/~nilda08/Anders_Ericsson/Ericsson_deli... [2]. http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...
wdr1 10y ago
> In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. I reject your real world assertion, unless you do not count Google as the real world. The reason these questions are asked is that they're relevant to the work engineers will be doing at Google.
thedufer 10y ago
> hiring candidates as temporary contractors for a real world test doing actual work While this is very effective at filtering out poor applicants, it is also very effective at preventing good applicants from applying in the first place. Why would a great developer who probably already has a great job quit for a chance to maybe get hired at Google? In most cases they wouldn't. And at the scale Google hires, they can't afford to lose all of those potential employees.

walshemj 10y ago

That is is a good analogy.

chii 10y ago

How does one hire a contractor for other industries? I'd garner that word of mouth is the way. The alternative is an association and certification body (not too disimilar to the medical association or the bar for lawyers), and gating the access to this certificate.

EduardoBautista 10y ago

Well they are pretty successful, so they must be doing something right.

mattnewton 10y ago

Who writes those premade robust libraries? Who improves them, when a few percentages of improvement will be multiplied by enough machines to come out to millions of dollars saved? If you have a pile of raw iron and you're currently running your own smelt for cost savings over the other remodelers, maybe even though you are in the remodeling business you could use those skills. I agree though that contracting is by far the best way to grade performance. But the Google style interview is the only reasonable alternative I know of to filter out people who don't actually know the technologies they are talking about and can fake it with other people's code for months.

blub 10y ago
Re libraries: the library team I would assume and hope, since this is a very specialised skill.
- jasode 10y ago
  >the library team I would assume and hope, I've never been at a company that had a dedicated "library team". The common code and functions that go into the libraries are artifacts of programming the other stuff that needs it. It's not a job title. (Unless the company's product to sell is a compiler. In that case, it would follow Conway's Law and you'd have a set of programmer's implementing the standard library. I don't see how that division of responsibilities applies to Google or other companies.)
  - Ar-Curunir 10y ago
    Pretty sure Google has multiple such teams dedicating to writing performance code that can be reused.
fail2fail2ban 10y ago
He's saying every company needs a Sheldon or two; they don't need a company full of Sheldons.
- 10y ago

rawnlq 10y ago

Google internal libraries and infrastructure are very good and way better than most "off the shelf" libraries. Any rank and file engineer can and do contribute to them. In that case I don't see why they should lower their bar to people who can merely consume these libraries when they can take their pick at people who can do both.

blahfuk 10y ago
I've seen GWT, and Angular 2.0, they're not any better than other open source frameworks, and many would say they're much worse
- ashark 10y ago
  Ha, yeah, if they could let some of that "magical internal tools" goodness seep out into the Android SDK I'd be pretty happy, since there's no sign of anything special there now, to put it mildly. Failing that, just buy Square and hand the whole thing over to them, since they seem to have a much better idea of how to write useful, usable, capable tools on the platform than Google does. Please.
lkmslkmdfsd 10y ago
> Google internal libraries and infrastructure are very good and way better than most "off the shelf" libraries. Citations needed.
- adpirz 10y ago
  As much as I'd like to see them as well, I'd imagine we won't get much as that's Google's IP, but would love to know generically if that's true from anyone who has worked with said libraries.
- lallysingh 10y ago
  https://chromium.googlesource.com/chromium/src/base/+/master https://chromium.googlesource.com/chromium/src/base/+/master

bmay 10y ago

> In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. How do you know that DAGs and rb-trees are the best solution to your problem if you don't even know basic data structures?

theli0nheart 10y ago
Ugh, this sort of computer science-shaming needs to stop. I've been building software professionally for 10 years now and not once have I ever needed to weigh the pros / cons of a DAG versus rb-tree. I'm too busy dealing with CSS bugs, figuring out why customer retention is lower than it should be, training my clients on how to use a bug tracker, scaling, and hundreds of other things which are magnitudes more important than this implementation detail. Somehow I've managed to make a career out of this. ¯\_(ツ)_/¯
- partycoder 10y ago
  But ask yourself: how does your browser layout engine and scripting engine work? Is CSS some sort of self-hosting language that just materialized out of nowhere? Or there's somewhere a group of people responsible for it? (e.g: Google's Chromium team, Mozilla's Firefox team, Apple's Safari team, Microsoft's Edge team, etc.) Those people DO need to know data structures. For you to be able to focus on CSS, HTML and JavaScript, someone, somewhere needs to make CSS, HTML and JavaScript work for you in the first place.
  - fail2fail2ban 10y ago
    > But ask yourself: how does your browser layout engine and scripting engine work? [But ask yourself: how does your car's engine work?]
    - partycoder 10y ago
      My point is: he can focus on HTML, CSS and JavaScript all he wants, and remain abstracted from internals. That's fine. But here we are talking about one of the companies responsible for implementing such technologies, where the science he implies as not being very relevant IS relevant. It's the difference between applying to a truck driver work, to a truck engine designer work. For the latter, knowing the theory of an internal combustion engine IS relevant.

partycoder 10y ago

Google does have projects that require clear understanding of the things you classify as trivia. Their search crawler, their distributed computing technology from which projects like Hadoop drew inspiration from, their cloud platform with custom hardware, Tensorflow, their custom Linux kernel and Android, improvements to network protocols like HTTP, v8, Chrome, Project Zero, and user facing apps like Maps, Translate, etc, etc, etc. All those important projects will require you to know your way around the fundamentals from the ground up and think out of the box. Then, they have lots of applicants. They can be more selective than they need to.

pjlegato 10y ago
The second factor is far more important than the first. There are any number of engineers who can simply go read up on the fundamentals as they are needed, or who understand them well enough to work with them but lack a mathematical proof-level command of the material. Google just doesn't need to hire them because they're paying much higher than market rate.
- partycoder 10y ago
  Trial and error doesn't go that far. Also they have customers and a reputation to maintain, they cannot afford the risk of learning going wrong.

wmil 10y ago

I don't completely disagree with you, but in Google mathy CS skills are probably better than robust SE skills Things need to operate on enormous scale. It's easy to imagine a case where Google would need to implement something algorithmic because well tested libraries aren't quite doing the right thing. The libraries are generally designed to work in RAM / HD. Google needs them to work across multiple servers / datacenters.

fail2fail2ban 10y ago
> enormous scale Add more nodes. Scaling is not difficult.
Shorel 10y ago
The company itself started because they implemented 'something algorithmic'. They know that's what made them different in the first place.

ng12 10y ago

> This mode of interviewing is like interviewing the contractor you're considering to remodel your bathroom by handing them a pile of iron ore and asking them to smelt high grade structural steel out of it. That's a terrible analogy. I'm hiring a home contractor for a discrete, predefined set of skills. They need to be able to install a sink and retile a floor -- and once they do that I'll never have need of them again. Software engineers are not tradesmen. What you know is less important than your ability to figure things out. If Google wants to select heavily for that quality it's a totally reasonable approach.

stonogo 10y ago
> What you know is less important than your ability to figure things out. The sooner you realize that this is true of every single human endeavour, the better off you'll be.
- vkou 10y ago
  When my sink leaks, I'd rather hire a plumber that has done a standard job ten thousand times, than a bright guy with a pipe wrench, a bag of PVC, and an exacto knife, who can 'figure things out'.
  - stonogo 10y ago
    This is how competent managers regard programmers, just so you know. But that ten-thousandth time, when the standard job goes awry -- that's what makes the difference between a dude showing up to work and a tradesman. The ability to react quickly and appropriately when faced with a brand-new problem is valuable in any role. Pretending otherwise is hubristic at best and kind of gross in general.
  - GrumpyYoungMan 10y ago
    That's the point. Google and the rest of the big 4 don't need ordinary plumbers, they need process engineers (the engineers who design the piping at oil refineries and chemical plants) because they are tackling problems that nobody has done ten times, let alone "ten thousand times".

dragonwriter 10y ago

> In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. Unless, you know, you are implementing the standard library for a new language, so that there is no such "off the shelf library" available. Which its not been completely unknown for Google software engineers to do. "Off the shelf libraries" aren't things that are handed down on stone tablets to the prophet on a mountaintop, they are things that are created by software engineers. In any case, understanding which algorithms and data structures to use, even if you are using a pre-made library, and the impacts of that decision requires an understanding of the algorithms and data structures similar to that which is needed to implement them (it doesn't strictly require the ability to implement, but ability to implement isn't an unreasonable way of filtering for the requisite knowledge.)

blub 10y ago
Let's be frank, most google engineers don't create new programming languages or work on library infrastructure. The only common topic they all work on is selling our eyeballs and collecting our data. Interviewing for that would make more sense than the algo stuff. P.S: there's a difference between knowing typical algorithms needed to solve a class of problems and studying to implement them on a whiteboard.
- dragonwriter 10y ago
  > there's a difference between knowing typical algorithms needed to solve a class of problems and studying to implement them on a whiteboard. I'm not sure that's all that true; even if you haven't specifically studied to implement the particular algorithm, if you are familiar with the concept of the algorithm and proficient in the implementation language, then coming up with some kind of cut of an implementation isn't an unreasonable request. (Now, if the evaluation of the quality of the implementation is unreasonable for the context in which it was requested, that's a problem, but if its used to judge understanding of the concept, if potential problems in the implementation are the focus of probing questions to determine understanding rather than straight rejection, etc., I don't necessarily see a problem.)
10y ago

raverbashing 10y ago

Building a good product is not just a matter of knowing CS questions The good thing about CS research is that it can be productized into libraries and tools

skybrian 10y ago

From the article: "From what I've read, you won't implement a balanced search tree in your interview." Despite being an interviewer, I don't know if that's true. I do know it's not what I ask about.

daveFNbuck 10y ago
It's pretty safe to say you won't implement one, even if the interviewer does ask you to.

dmoy 10y ago

You're not supposed to ask brainteaser or trivia type questions as a Google interviewer anymore. But yea I agree with the rest of your post. Also another factor beyond confidentiality is that you can't hire people from other companies through that pipeline, cus they won't do it. Also worth noting that for certain classes of engineers (new grads), Google does sort of hire people as contractors (though they're full-time with benefits), see the eng residency program.

pjlegato 10y ago
Er. I actually said that they don't use brainteasers anymore in the post.
- dmoy 10y ago
  Yes, hence the OR. You're not really supposed to use cs trivia style questions either. Both are deprecated. It will take awhile for interviewers to catch up though... I suppose I should have capitalized the OR
tyleraldrich 10y ago
> You're not supposed to ask brainteaser or trivia type questions as a Google interviewer anymore. That's what previous means in: > Their previous "brainteaser" style interview didn't work at all
- dmoy 10y ago
  Yes sorry, my sentence scans better with a capital 'OR'

solipsism 10y ago

Why do they do this? The answer you haven't considered is, "because it works." I assume you haven't considered it because doing so would mean wrestling with the fact that your intuition isn't always right. Google has turned interviewing into a science. They have interviewed millions of engineers, hired hundreds of thousands, rejected and later hired who knows how many, etc. Many incoming interviewees have also interviewed across silicon valley. And all along the way they've been collecting data and refining their process. Do you have anything except your intuition to show us that the Google style interview doesn't work? One thing you may fail to consider is that there doesn't need to be a direct and plain link between the interview questions and the work the engineer will end up doing. All that matters is whether the interview process produces a clean and strong signal that leads to quality hires. As a person who's been through a Google interview, I can imagine many of my former co-workers performing poorly. Those are exactly the kinds of engineers I don't want to work with. I have spent too much of my time explaining basic concepts to engineers who should already be comfortable with those concepts, or who lack the critical thinking skills to be part of the conversation. So there's my anecdote. Before telling a company how they should conduct interviews, perhaps you should gather some data.

pjlegato 10y ago
I never told any company how they should conduct their interviews. Google is of course free to spend their money however they see fit. This was not written for the benefit of Google, but for the benefit of the many others who are considering whether something is a best practice simply because Google does it. As for why they do this, your conclusion is kind of exactly what I got to in the last paragraph, "for lack of a better option." It's not that it works in some optimal sense; it just works less badly than the other options available, according to their business constraints. I base my claim on my many years of personal experience as a software engineer, both being interviewed and interviewing others, discussing engineering and CS with numerous people. My anecdote: I once worked with a guy with quite reasonable academic CS skills who decided to re-implement SSL from scratch for a bog-standard webapp, rather than use a library to do HTTPS. That was not a good use of the company's limited budget, which he would have known if he had had any engineering skills (as opposed to CS skills.) In my experience, there is little (though not zero) correlation between "good at CS" and "good at writing software commercially." The Google interview process is probably better than nothing, and probably better than their previous "brainteaser" style interview, but far from optimal. As for what I'd select for? I'd certainly reject candidates who manifest anything like the condescending and arrogant attitude you display towards people you consider to be your intellectual inferiors. Even if you're an amazing engineer who can recite the CS in your sleep, that attitude is toxic for any team environment and will be a net loss to the company.

googlereject 10y ago

I am so happy that early on in my career I failed at multiple attempts to get a job at Google (after having graduated Stanford in CS in 2008). Despite having already built some objectively impressive and popular projects used by millions of people, I was asked to solve boggle, random C trivia questions, and write a sort algorithm I'll never need in my career, all on a whiteboard, and I just wasn't comfortable with that style of interview. I was upset for a while but just kept iterating on my own projects and now I am passively making far more than I ever would at Google even including generous stock grants (mid 7 figures). It's much more rewarding too, knowing I created my own destiny, and not just some middle engineer on a mothership living off of an easy adwords monopoly. My suggestion to anyone who has the perseverance to get through a guide like this is to just forget Google and build something new yourself.

orthoganol 10y ago

Don't forget - Google has a culture they're protecting. I'll play devil's advocate and say while it's maybe not immediately useful, it's probably a very good test for culture fit. If you're the kind of person who thinks about the math of algorithms in your free time, because you enjoy it or think it's fundamentally important, you're probably more likely to be a Google culture fit. If you're a successful product shipper, but you have an aggressive "get shit done" attitude and don't care much about the science and math, maybe you are not going to make the discussions with fellow Googlers that Google envisions happening around campus, or maybe you're likely to be highly success/ money oriented or I don't know, go against the culture fit criteria in some way.

soham 10y ago

[Disclaimer: I run an interview prep bootcamp http://interviewkickstart.com http://interviewkickstart.com] As someone who helped set interview process at my previous employer (not Google), and other companies now as a consultant, your reasoning of why these companies have a process like this, looks right. Let's dig a little deeper too. Consider the following facts: 0. Google has some 30k-40k engineers, with average tenure of say 7 years. So every 7 years, they are hiring 30-40k engineers. That is thousands of engineers every year, even if they are not growing (and they are). It's a massive undertaking. 1. In the field of software engineering, unfortunately, experience has little correlation to expertise. That has been known for a long time. See [1]. And cognitive ability is at least a reasonable predictor of success, better than many others. See [2]. 2. Companies like Google have no dearth of applications. Literally millions or engineers apply. 3. Interviewing is a chore, and mostly not fun. Most interviewERs hate spending time on it, and want to get out of it as quickly as possible. Interviewing is also on top of everyday work which is a lot at many growing companies. 4. As a hiring manager, I have to hire people. There is no choice. I must find a way to hire N people in X amount of time, or the company is literally doomed. e.g. if I'm eBay or Amazon, I can't miss the holiday season. 5. You have to involve multiple people in hiring. Just one person talking to the candidate and making a decision is not sufficient. 6. Programming is so vast, that engineers apply from all sorts of backgrounds and domains. 7. Companies are becoming more and more polyglot. You want engineers to move around different languages and stacks freely. So when you have a lot of people to hire, a lot of people applying, work that's somewhat correlated to cognitive ability and very little time, what kind of process do you end up setting? When you put these constraints together, you realize that your incentive is to design a generic process that's convenient to the company, and not convenient to the candidates. You just want reasonably smart people, fast. You don't care about seniority much, and the type of problems asked, as long as it helps you close N people in X time, by putting in least amount of work. A different process might have selected for different kind of N people, but that process would take longer than this. And time is money too. A process with DS/Algos is less subjective, fast (like you said), can be prepared for (you have to hire), has enough variety that multiple people can ask different questions, lets you interview across domains, and is at least somewhat defensible-ly relevant to the field. And hence, here we are. Not saying that the process is understood by everyone and executed well everywhere and every time, but for several years, we're all still looking for process that's lesser evil, and we haven't found one. As long as the constraints outlined above remain, the process is going to stay. In some form or another. For a very long time. However much everyone hates it, including the interviewers, and the company itself. Many have tried otherwise (including myself), but most have come around to asking DS/Algos somewhere in the process in varying percentages. [1]. http://www.ida.liu.se/~nilda08/Anders_Ericsson/Ericsson_delib_pract.pdf http://www.ida.liu.se/~nilda08/Anders_Ericsson/Ericsson_deli... [2]. http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...

wdr1 10y ago

> In the real world, you use a well-tested premade off the shelf library to traverse a DAG or implement a red/black tree. I reject your real world assertion, unless you do not count Google as the real world. The reason these questions are asked is that they're relevant to the work engineers will be doing at Google.

thedufer 10y ago

> hiring candidates as temporary contractors for a real world test doing actual work While this is very effective at filtering out poor applicants, it is also very effective at preventing good applicants from applying in the first place. Why would a great developer who probably already has a great job quit for a chance to maybe get hired at Google? In most cases they wouldn't. And at the scale Google hires, they can't afford to lose all of those potential employees.