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.
> 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.)
When I worked at Google Search Infrastructure (not any ML stuff) I actually built a performant, persistent red-black tree implementation in C++ for creating persistent sorted lists with good insert and delete characteristics. It's was a pretty niche need, but we had it and the existing libraries we could find didn't cover it. We needed it for doing some speculative programing where we were doing some constraint solving and were using a greedy-ish algorithm to explore the constraint space. Arbitrarily solving the constraints was theoretically and practically impossible in a performant way, so we settled for a greedy exploration of the search space but we needed a way to back out of failing lines of exploration.
So, yeah, we needed engineers who were strongly familiar with the theory of how hard things are to solve and knew a lot about different types of data structures. We were in a space the existing libraries didn't really cover.
Maybe not all engineers need these skills, but it was valuable that our team all had them and were thus able to have deep design discussions about it.
The skill that's lacking the most at Google is project management, which is not necessarily a skill that every engineer needs.
There is another point to this: You shouldn't have all in your head. If you're actually going to implement a standard library for a new language it's reasonable that you spend some time and energy on researching and looking stuff up.
I don't see how being able to recite trivia questions from memory is a good indicator even for implementing a standard library.
Having a rudimentary understanding of algorithms and data structures is useful but in many cases it's also something you could look up.
> Unless, you know, you are implementing the standard library for a new language, so that there is no such "off the shelf library" available.
The ability to write down a complex algorithm on the whiteboard without any references is not a very good proxy for being able to implement the algorithm in a standard library.
It vastly over-selects for people who are good at memorization.
I know how to use these algorithms and data structures, and in fact do use many of them regularly. I can even implement them myself when I need to. But I certainly don't go to implement them without access to any references—if you're writing a standard library and don't consult references when doing so, then that's a bigger indication of you being a bad engineer than a good one.
It's really just an elaborate signaling ratio that you're willing to devote lots of time to studying. I personally don't think Google is such a mythically fantastic employer that I would spend tons of time studying just to get a job — and that's probably the point.
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.
Yes, that is true. A tiny percentage of Google engineers build new languages. If you're hiring someone to write a compiler, say, then it is absolutely appropriate to ask interview questions about compiler design.
The point is that that is not how these interviews work at all. They test for the ability to memorize and regurgitate on demand a standardized and generic set of "CS fundamentals" based on the curriculum of elite CS schools -- nothing more.
For almost all jobs, even at Google, almost all of that knowledge is never used at all. Even at Google, most coding jobs are unglamorous CRUD. You just don't hear about them in blog posts because it's far more compelling to write up their cool new programming language project.
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.
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.
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.
The point was that their interview doesn't select for "ability to contribute to the company libraries" at all. It selects for "went to Stanford or MIT and has a good ability to memorize abstract computer science material."
> 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.
Their interview doesn't select for "ability to figure things out" at all. It selects for "ability to memorize and regurgitate academic CS curriculum on demand." I'm sure many people who can do that are also good at figuring things out, but it's mostly uncorrelated.
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.
Knowing what these structures are and having a working knowledge of how to use them is not the same skill as being able to implement them from scratch (on a whiteboard, in an hour or less.)
If you can drive, you probably have a pretty good idea of whether a car or a truck or a motorcycle or a tank is the best vehicle for a particular transport application, and you can probably actually drive all of those with minimal practice. That doesn't require you to know how to build a car, a truck, a motorcycle, and a tank from scratch. That's a different skillset.
Google pays far above market rate, so they have the luxury of hiring petrochemists to work a gas pump. Even at Google, once all the shiny is stripped away, most of the projects are simple CRUD.
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. ¯\_(ツ)_/¯
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.
While it's undeniable that Google has an excellent engineering team, it's also undeniable that their products often/usually leave a lot to be desired from the end-user perspective. There's definitely a missing piece of the puzzle there when it comes to UX and human-centric design. Who's to say that their focus on low-level engineering at all costs hasn't left something on the table?
I can't say for sure that their interviewing process is broken but as a user of many Google products (many of which get randomly discontinued) I will say there's something lacking.
> The answer you haven't considered is, "because it works."
Just because something "works" does not mean it's optimal or even very good.
Google's interview strategy could also be to pick random resumes out of the pile, hire 10 people for every position, and fire the 9 who didn't work out. It would still "work" because enough people want to work at Google that they have a huge hiring pipeline and plenty of money for excess employees.
Worshipping Google as having a great interviews is not helpful to anyone. They can easily be doing it incorrectly.
In fact, the very data which you're talking about showed that many of their older techniques were in fact terrible indicators (brain teasers, GPA, etc.).
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
This is a bit meta, but it bothers me sometimes how much virtual ink is spilled on how to pass algorithmic interviews. Especially considering how little of your career will actually depend on the knowledge being presented.
I'm slowly learning that despite how much more money I've earned by skipping between companies, skipping is not a path to knowledge. It provides better earning opportunities (to a point), it provides new challenges on a regular basis, but I've lost the ability to go deep into a topic. The depth that can't be achieved in two or three years.
I guess I'd really like to see a bit more ink spilled on "congratulations, you got a job; now what?" What interpersonal skills are most important? What are good resources for continued learning? What do C level people actually do? How can I help the company succeed? What career opportunities are possible for me without having to skip jobs? What can I learn from this company before I go to create my own?
That would be much more valuable, IMO, than a primer on how to pass an interview process.
In this vein, I wish people would ruminate on a topic like, "Senior Engineering: So now what?". When I first wanted to get into engineering, nothing helped or inspired quite like these posts. But, since I have "made it" so to speak. I feel like I've done the majority of growing and introspection required and now I can basically handle anything a Senior engineer should be able to handle. But... now what? I am kind of at a cross-roads where people tend to either stagnate (I've met a lot of 50+ peers with senior titles they earned 20 years ago), run off to manage people (do I want to do that? I dunno...) or end up as Principal Architects, co-founders, or some similar upper-echelon engineering role.
Not to knock this content, anyway. I found this repo to be well organized and genuinely interesting -- just not super relevant for me...
I think the only way to really prepare for working in industry is to actually work in industry.
Being able to parrot the crap you where taught in college is only useful for interviews, which is a sad reflection of what interviews actually test for.
You are completely right about what you said but I'd like to add one thing is the most important for any software engineering roll at any company: your ability to learn as you continue practicing in our field. That should be the highest priority. How do I familiarize myself with all my tools and resources not so I can do my job really well but so I can move to any task and execute it well?
That should be the focus of any practicing software engineer. To be able to learn and adapt as requirements and goals change.
I have done maybe 20 or so interviews in the last 2 years and this is the #1 thing I look for. However, I have still hired people who do not display a talent for continuous rapid learning, that is to say, they will only learn on company time and they take a long time (reasonably) to learn anything new. The flip side is that these people "work with what they know" and you can rely on them for a steady work pace and consistent quality. Much like so many development tools, people come in lots of shapes and sizes that benefit your organization differently.
You're probably right, but there are probably millions of software engineers who can have a successful career at Google. But they won't get in unless they can pass the algorithmic interviews.
I agree that the emphasis Google puts on algorithmic interviews is a bit dumb, but that how their hiring system works. So anyone who really wants to get a job at Google needs to work on that, regardless on whether it will be useful inside the company or not.
Are there really millions of engineers who will have a successful career at Google, or are there only a hundred or so every year?
There are millions of programmers, most of which will never get a job at Google. Is their time perhaps better spent optimizing their existing careers instead of doing "dumb" things for a chance at the gold-plated goose?
Agree that it's not a bad strategy for Google to hire the way they do.
It is a bad strategy for most other companies though, as by running the same interview process, they'll get people who couldn't get a job at Google.
"What interpersonal skills are most important? What are good resources for continued learning? What do C level people actually do? How can I help the company succeed? What career opportunities are possible for me without having to skip jobs? What can I learn from this company before I go to create my own?"
Pretty sure tons of content have been written about all of these topics, and not particularly hard to find.
Read Shapiro's "Corporate Confidential". Despite the rather click-baity (read-baity?) title of the book, it's an fairly good explanation of career management and politics of mid-size to large companies. I'd recommend it to all new graduates entering the workforce.
The problem is that the algorithmic interview is the gatekeeper.
As you say, almost none of your actual job depends on knowing any of that material in any way. However, you aren't even getting in the door unless you know it all, which is indeed arbitrary and a waste of everyone's time and energy.
Thus, good engineers who didn't happen to study academic CS at Stanford or MIT must regrettably waste months of their lives self-studying CS trivia which they will never use again except at other interviews. Being good engineers, they have studied how the system works and taken the rational and necessary step to participate in it. That's why so much ink is spilled on it.
> aren't even getting in the door unless you know it all
This is the key to only one (admittedly pretty) door, though. Are the benefits of getting through that particular door truly worth the cost?
I think this question is even more important when so many other companies are now moving away from algorithmic interviewing techniques since they aren't Google.
While we could debate on the meaningfulness of his goal, I find the person admirable. We could perhaps award more credit to the fact that this is a 44 year old person who is taking the difficult course of going through the material of CS on his own and then setting a clear goal to aim for. And of course not forgetting to celebrate his virtue of learning for life.
People complain about Google style of interviewing but I like the idea that you can at least prepare for them. I'm sure there are many companies that wouldn't even consider because you're too old or because you don't have the right background.
I used the same approach last time I was interviewing -- keeping a wiki of "everything I knew or sort-of-knew about computer science" and then trying to fill in the gaps.
At a glance, a few things I would throw in are:
* UTF-8 (a basic understanding of how wide characters are encoded)
* streaming algorithms
* lock-free data structures (what they are and why you probably shouldn't implement one)
In some sense it's like trying to hold the entirety of CS in your head for one day. You might spend 30 minutes learning about something so you can mention it as an aside. But... I think it's worth it, more for the knowledge.
Knowing that something is possible (e.g. encrypted search) opens doors in the same way that working cross-discipline can.
I like the idea of using a wiki to track a lot of concepts you've learned. How do you keep track of everything that is in the wiki? Do you have a front page that is organized like an outline, or maybe a long list of concepts?
While joining Google is probably the last thing I want to do, this is a perfect resource for someone who hasn't had a formal education in computer science.
Indeed, I have no degree but have been working for +7 years in the field. Recently I decided to start searching for new challenges but thanks to ATS [1] my resume has been rejected 90% of the time, the other 10% has been invested in interviews in fairly popular companies including Amazon and Booking.com. After having studied CtCI [2] and practiced on LeetCode [3] for two weeks (yes, just two weeks) I was able to pass most of the technical interviews, so I can testify that using this repository as a way to improve your skills actually works.
PS: Just to clarify, I haven't been hired by any of the "Big 4" yet, but that is because — again — I have been studying for only two weeks, if I invest more time on this, maybe in 5-6 months I can guarantee an offer in one of those popular companies that appear featured on HN all the time. And as the parent comment says, even if you have no intention to work for Google or any other of the big corporations, this still is a good list of resources to improve your skillset.
I also feel bad that he has seemingly tied up so much of himself into this. Although the technical interviews at Google kind of require this prep, at the end of the day interpersonal skills and other factors contribute to the final decision as well. It's possible someone interviewing him will find this distasteful. It's also possible someone might just not like him. It's impossible to know exactly what will happen, I just hope he's somewhat psychologically prepared to not be offered a job.
Even if he doesn't get the job he's going for, mastery of that curriculum will be tremendously valuable. So it's a pretty benign delusion, as long as it's motivating him to study.
Yeah, I had thought this was just a fun way to organize a set of CS learning materials, but this guy seems to both 1) be very certain this will work, which is no guarantee even if the learning program is perfect, as there's obviously more that goes into hiring decisions, and 2) be really quite focused on Google specifically, which may not make sense.
His LinkedIn shows that he worked for/founded a lot of startups and other smaller ventures. I'm kind of lost as to why he thinks Google is the logical next step.
"If you like this project, please give me a star. "
So it's "like, comment, subscribe", and now "give me a star"? It's the first time I've seen this and I hope this doesn't catch on. The current system of aggregation/curation/voting works fine imo.
Readit News
"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.
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.)
So, yeah, we needed engineers who were strongly familiar with the theory of how hard things are to solve and knew a lot about different types of data structures. We were in a space the existing libraries didn't really cover.
Maybe not all engineers need these skills, but it was valuable that our team all had them and were thus able to have deep design discussions about it.
The skill that's lacking the most at Google is project management, which is not necessarily a skill that every engineer needs.
I don't see how being able to recite trivia questions from memory is a good indicator even for implementing a standard library.
Having a rudimentary understanding of algorithms and data structures is useful but in many cases it's also something you could look up.
The ability to write down a complex algorithm on the whiteboard without any references is not a very good proxy for being able to implement the algorithm in a standard library.
It vastly over-selects for people who are good at memorization.
I know how to use these algorithms and data structures, and in fact do use many of them regularly. I can even implement them myself when I need to. But I certainly don't go to implement them without access to any references—if you're writing a standard library and don't consult references when doing so, then that's a bigger indication of you being a bad engineer than a good one.
It's really just an elaborate signaling ratio that you're willing to devote lots of time to studying. I personally don't think Google is such a mythically fantastic employer that I would spend tons of time studying just to get a job — and that's probably the point.
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.
The point is that that is not how these interviews work at all. They test for the ability to memorize and regurgitate on demand a standardized and generic set of "CS fundamentals" based on the curriculum of elite CS schools -- nothing more.
For almost all jobs, even at Google, almost all of that knowledge is never used at all. Even at Google, most coding jobs are unglamorous CRUD. You just don't hear about them in blog posts because it's far more compelling to write up their cool new programming language project.
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.
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.
Citations needed.
These are only loosely related.
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.
The sooner you realize that this is true of every single human endeavour, the better off you'll be.
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.
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?
If you can drive, you probably have a pretty good idea of whether a car or a truck or a motorcycle or a tank is the best vehicle for a particular transport application, and you can probably actually drive all of those with minimal practice. That doesn't require you to know how to build a car, a truck, a motorcycle, and a tank from scratch. That's a different skillset.
Google pays far above market rate, so they have the luxury of hiring petrochemists to work a gas pump. Even at Google, once all the shiny is stripped away, most of the projects are simple CRUD.
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.
I can't say for sure that their interviewing process is broken but as a user of many Google products (many of which get randomly discontinued) I will say there's something lacking.
Just because something "works" does not mean it's optimal or even very good.
Google's interview strategy could also be to pick random resumes out of the pile, hire 10 people for every position, and fire the 9 who didn't work out. It would still "work" because enough people want to work at Google that they have a huge hiring pipeline and plenty of money for excess employees.
Worshipping Google as having a great interviews is not helpful to anyone. They can easily be doing it incorrectly.
In fact, the very data which you're talking about showed that many of their older techniques were in fact terrible indicators (brain teasers, GPA, etc.).
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.
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.
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.
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.
Add more nodes. Scaling is not difficult.
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.
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.
That's what previous means in: > Their previous "brainteaser" style interview didn't work at all
The good thing about CS research is that it can be productized into libraries and tools
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.
Despite being an interviewer, I don't know if that's true. I do know it's not what I ask about.
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_deli... [2]. http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...
I'm slowly learning that despite how much more money I've earned by skipping between companies, skipping is not a path to knowledge. It provides better earning opportunities (to a point), it provides new challenges on a regular basis, but I've lost the ability to go deep into a topic. The depth that can't be achieved in two or three years.
I guess I'd really like to see a bit more ink spilled on "congratulations, you got a job; now what?" What interpersonal skills are most important? What are good resources for continued learning? What do C level people actually do? How can I help the company succeed? What career opportunities are possible for me without having to skip jobs? What can I learn from this company before I go to create my own?
That would be much more valuable, IMO, than a primer on how to pass an interview process.
Not to knock this content, anyway. I found this repo to be well organized and genuinely interesting -- just not super relevant for me...
Being able to parrot the crap you where taught in college is only useful for interviews, which is a sad reflection of what interviews actually test for.
You are completely right about what you said but I'd like to add one thing is the most important for any software engineering roll at any company: your ability to learn as you continue practicing in our field. That should be the highest priority. How do I familiarize myself with all my tools and resources not so I can do my job really well but so I can move to any task and execute it well?
That should be the focus of any practicing software engineer. To be able to learn and adapt as requirements and goals change.
I agree that the emphasis Google puts on algorithmic interviews is a bit dumb, but that how their hiring system works. So anyone who really wants to get a job at Google needs to work on that, regardless on whether it will be useful inside the company or not.
There are millions of programmers, most of which will never get a job at Google. Is their time perhaps better spent optimizing their existing careers instead of doing "dumb" things for a chance at the gold-plated goose?
1. they have a lot of applicants to pick from.
2. they do it for cultural reasons rather than purely for on-the-job performance reasons.
Culture is a long term investment.
Deleted Comment
Pretty sure tons of content have been written about all of these topics, and not particularly hard to find.
Read Shapiro's "Corporate Confidential". Despite the rather click-baity (read-baity?) title of the book, it's an fairly good explanation of career management and politics of mid-size to large companies. I'd recommend it to all new graduates entering the workforce.
As you say, almost none of your actual job depends on knowing any of that material in any way. However, you aren't even getting in the door unless you know it all, which is indeed arbitrary and a waste of everyone's time and energy.
Thus, good engineers who didn't happen to study academic CS at Stanford or MIT must regrettably waste months of their lives self-studying CS trivia which they will never use again except at other interviews. Being good engineers, they have studied how the system works and taken the rational and necessary step to participate in it. That's why so much ink is spilled on it.
This is the key to only one (admittedly pretty) door, though. Are the benefits of getting through that particular door truly worth the cost?
I think this question is even more important when so many other companies are now moving away from algorithmic interviewing techniques since they aren't Google.
The signal that it is measuring is "How much did you prepare to get this job." Which isn't that bad of a signal.
Deleted Comment
At a glance, a few things I would throw in are:
* UTF-8 (a basic understanding of how wide characters are encoded)
* streaming algorithms
* lock-free data structures (what they are and why you probably shouldn't implement one)
In some sense it's like trying to hold the entirety of CS in your head for one day. You might spend 30 minutes learning about something so you can mention it as an aside. But... I think it's worth it, more for the knowledge.
Knowing that something is possible (e.g. encrypted search) opens doors in the same way that working cross-discipline can.
PS: Just to clarify, I haven't been hired by any of the "Big 4" yet, but that is because — again — I have been studying for only two weeks, if I invest more time on this, maybe in 5-6 months I can guarantee an offer in one of those popular companies that appear featured on HN all the time. And as the parent comment says, even if you have no intention to work for Google or any other of the big corporations, this still is a good list of resources to improve your skillset.
[1] https://en.wikipedia.org/wiki/Applicant_tracking_system
[2] https://www.amazon.com/a/dp/0984782850
[3] https://leetcode.com/
Google should not be the only option.
[0]: https://github.com/jwasham/google-interview-university#get-i...
[1]: https://github.com/jwasham/google-interview-university#follo...
"If you like this project, please give me a star. "
So it's "like, comment, subscribe", and now "give me a star"? It's the first time I've seen this and I hope this doesn't catch on. The current system of aggregation/curation/voting works fine imo.