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.
In these cases, most of your head-space is focused on the problem, which isn't written down anywhere other than PM's requirements doc. It's pretty critical that you understand the algorithm really well, because if you have to look it up you're going to have to unload all the messy problem-domain stuff that's in your brain.
Also, you can learn the algorithm first then figure out the problem. No need to do it on the fly, although sometimes that can help too.
In the cases where I didn't get the job, I naturally asked why. Despite repeatedly having assured me that they just wanted to know how my brain works and not whether I'd memorized specific concepts, I am usually flat-out told the rejection was because I had implemented some minor detail of algorithm X incorrectly; that my implementation failed in some corner case.
I've also passed and worked at companies which do CS trivia style interviews. When they later interviewed other candidates while I was there, I sometimes observed how the people conducting the interview would first study algorithms and data structures for hours on Wikipedia prior to going in -- because they themselves can't recite any of that without preloading.
Maybe Google works differently; I don't know. At most places, the "CS trivia" style interview seems to primarily serve as a vehicle for bolstering the egos of the people conducting the interview -- they get to feel superior and ding people for not knowing the gotchas of algorithm X.
Just came here to say that from my limited experience, I concur with this comment. Google also has improved their feedback loop after the interview, which I find severely lacking in other companies with similar interviewing styles.
That...
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.
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.)
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.
I'm curious about this statement, you say this but... have you ever worked at Google? I'm genuinely interested, not trying to discredit you. It's a bold statement to make if you don't have direct experience on the job.
> I don't have months to study fulltime to cram for the CS trivia challenge
His implication that the reason why he didn't get into google isn't because he's not smart or knowledgeable enough, but because he didn't go to a prestigious school
> No, I don't work there. I didn't study CS in school (much less attend the elite CS schools they are selecting for)
The implication that maths is somehow less important than nebulous concepts like "shipping code within budget"
> "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.
That interviews are processes which dumb people pass, unlike him
> 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."
And then the comments through which I came to know this guy: when someone makes a good point, he replies that "correlation doesn't imply causation", and then when asked a simple question, instead of answering the question his answer is "I have X credentials, therefore I know the answer very well":
> I have a philosophy degree, and I can say with some confidence that I understand that particular catchphrase pretty profoundly. Not everyone who happens to disagree with you is merely an ignorant barbarian in need of enlightenment. See Karl Popper's theory of critical rationalism to answer your questions about causation.
You see, checking boxes (like getting credentials and academic knowledge) is very important, but only the boxes he's checked.
I'm haven't enjoyed a thread this much in a very long time.
I admit it is based on hearsay -- I know a number of people who work there. They say things along the lines of, "The pay is great and the benefits are generous, but the actual work is more or less the same as any other tech company." They tell me about their projects, and it's true. It's mostly CRUD.
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.)