We use shitty algorithmic questions as a proxy for answering the above question (in the vast majority of cases).
The companies that popularized this were and still are EXTREMELY lucrative, and get a TON of competition.
They can afford to be choosey. So they can try to find not only the person who can do the job but also do it BEST.
And that's really hard to tell from just looking at their work experience. You want to see how their brain works under pressure, dealing with an ambiguous new problem they've never seen before.
A lot of people who rag on modern tech interviewing don't get this. Unfortunately, so do a lot of people DOING these modern tech interviews. "He said the algorithm was O(n log n) but the answer is actually O (k log n). Not inclined"
And so, we spiral.
Selecting people based on how well they can code some linked-list traversal, in a web editor, while someone is timing them is not a good metric for overall "best". In fact you might reject candidates that think more about larger design problems, and overall your code might suffer.
This is the part I dislike the most. They usually disable copy-pasting too because they know it's that easy to google so you can't just code in your IDE and paste.
At some point it's all just signaling and wild guesses.
Google bureaucracy expected from Ken Thompson (!) to pass a C language exam (!!).
https://www.theregister.co.uk/2010/04/21/ken_thompson_take_o...
"So Mr Thompson, you say you have some programming skills"
"Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off" [0]
More details two years later here [1].
[0]: https://twitter.com/mxcl/status/608682016205344768
[1]: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
From what I understand it is like a "driving license" for each language - if you haven't passed the driving test you can still drive but you need to have an instructor keep an eye on you. If you haven't passed the coding test you need someone to review your code before submitting.
The philosophy is that all Google code base should look like it was written by 1 person. It's great actually in practice: code in a big company should be hard to write and easy to read, as it's read by many people.
> The philosophy is that all Google code base should look like it was written by 1 person.
But all google products look like they are written by only one person so the aim is achieved. The worst thing however is that other person started doing the same.
That said, I would not be surprised this would happen at Google as they truly believe their process is vastly superior, as they believe themselves.
Pretty sure they would ask Linus to to a C programming test as well, and score him badly because he can't remember the exact details of some algorithm he has not used since he wrote the first lines of Linux.
I'd say it's about doing the work for which he came there, from TFA:
"Google hired Thompson to create a new language, Go. But Google also requires all of its recruits to pass a language test. According to Thompson, he hasn't quite got round to it yet - and so can't submit code."
And no, I have no understanding for that utter stupidity, or any attempt to accept it.
Code committed to the internal repo requires a review from someone certified familiar with that language's internal style guide.
He was hired to work on Go, not C, and just didn't get around to writing enough C to bother getting that certification. He can write C whenever he wants to, just like literally every other engineer, he would just get a style guide review at review time.
"Google hired Thompson to create a new language, Go. But Google also requires all of its recruits to pass a language test. According to Thompson, he hasn't quite got round to it yet - and so can't submit code."
It's not and it wasn't about any C++ "certifications." He was involved in the creation of a new language. For the new language there could have not been any existing certification. And as far as I know, the initial implementation language of Go was not C++ but C. In creation of which was Thompson also directly involved. And as far as I know the people worked on the parts of the code before Google and these parts of said C code already existed before Google (Go had some dependencies on code from https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs and https://en.wikipedia.org/wiki/Inferno_(operating_system)).
So it was indeed as absurd as it could have been. He was a part of the team that directly invented both the language and the style guide of the language, but some bureaucratic exam was expected from him to submit the code to the source control system.
I don't know how they managed to get that statement, but it's misleading. Many misconceptions begin with an element of truth. I'm guessing the element of truth here was the "certification" process. (Maybe it was something else, like a mixup having him as an advisor accidentally caused him to not be hired into the engineering group and thus there was a wait before he got engineering credentials to view/edit code. But that kind of thing is just silly paperwork and clearly fixed promptly.)
I just checked. He had literally written some C++ code before that snippet was published.
It was not the absurd statement it's been made out to be. It sounds unbelievable for a reason: It is unbelievable because it didn't happen.
Your failure to even recognize all that (instead mentioning "C++" and "certification" which is not the same) and to address the fact that these circumstances completely differ from your own much more narrow experience with established practices when checking in C++ code for which the bureaucratic rules already existed simply doesn't tell me that you can be believed regarding organization's capability to not react bureaucratically. Which is what Thompson apparently said and I still find, as I explain, very believable.
That is how I searched in the responses for any claim which would directly support your opinion, and still haven't found it.
I have no problem to admit I was wrong, but I'd really like to see some direct proof. Like somebody investigating what actually happened there and getting some first hand account. Not the talk about "C++" and existing rules for that (for which there is up to now a confirmation of strong enforcement, not tolerance).
But ken was at Google a long time before the Go project started. (The Go project was not developed in Google's monorepo and was not subject to Google's readabiliy process, as is the case for many Google projects.) What ken was referring to was indeed the C++ Readability process (which doesn't stop anyone committing code, just requires a review from a person with the 'readability' certification before committing; as mentioned upthread). I know this from talking to him about it, specifically.
I can't offer you any more proof other than the fact that I was a witness. If you don't believe that, then I'm sorry? Not sure what else to tell you.
FWIW your conduct in this thread is extremely obnoxious. I'm sure you'll find a way to debate that, too, but please consider that I have no vested interest in telling you this other than hoping you might better learn how your conduct is perceived by others.
Perfect! So what's the exact story, then, finally?
1) Was the quote from him completely invented?
2) Was he allowed to check in or not? Did he need the test to check in at that moment to which the quote refers? (I don't care about the moment when it was published).
3) And even more specifically: were there ever the times where he was in Google but when he not able to check in the code lacking some Google-prescribed "test"?
Just "yes", "no" or "I don't know" there, please. Also (just for my curiosity):
4) How long that period lasted?
Then you can elaborate where I was wrong by searching thorough what I've written -- I've specifically quoted the article and talked about his C background and involvement in a new language, never claimed anything about his C++ code and a "certification." I have an impression that your perception of what I've written and that, what I actually have written don't match.
If that's what you read out of the post, when I literally said the opposite, I can't reason with you.
He could probably get around this easily if he tried
Still a funny quip though
It'd actually be really, really cool if more than few people of Guido/Linus/etc's calibre did go in for some of the whiteboarding interviews (under an anonymous resume of course).
As both of them explicitly acknowledge - they don't (or no longer) consider themselves as top notch "coders" as such. Linus has said something like "I'm not even a programmer anymore" recently. And Guido said something like "I'm not the best Python coder by far - on a scale of 1-10 I'd say I'm at most a 6". Not because they're lousy coders of course. Just that (in recent years) they've had far, far, far bigger fish to fry.
So they go in, and "fail" the contrived Sudoku / Knapsack / "build me an Instagram clone, please" problem... then get strung along and gaslit for a while, before receiving an email 6 weeks later tell them that they're "not a fit".
That would be lots, and lots of fun to see.
Or you know... an algorithm and data structures class that's part of a serious Engineering/CS curriculum.
If someone knows he's interviewing at a place where there will be a coding interview, he would be crazy not to take a look at his algorithm textbook.
And maybe if the course only only gave the candidate a passing familiarity it wasn't thorough enough?
A reasonable interview prep cycle would be closer to 200 practice problems, under time pressure.
Why? what's wrong with going "purely" into interview?
Good luck remembering the kind of details a typical interview asks for 10 years into the business.
It's so ridiculous to see these replies. So Microsoft should've sent Guido van Rossum a note saying, hey study algorithm/DS for at least a month and do 100 leetcode before you come talk to us or it's a waste of time, thanks, bye.
Discussions of the industry tech interview process are now poisoned by these factors:
* There is an entire industry built around tech interview prep now (books, websites, practice/mock interviews). Many would defend this practice because their paycheck directly depends on it.
* Many see this as a hazing ritual that protects their high compensation and often their egos as well. These people are often young and will eventually see how harmful these interviews are when they get older and need to switch jobs. But by then there will be a new generation of young engineers defending the practice.