I wonder if they asked him algorithm problems in his interview /s
This is cool though. I'll be curious to see what he works on.
This is cool though. I'll be curious to see what he works on.
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.
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.
(Runs for cover)
I'd imagine no matter the problem he would breeze through an interview and leave the interviewer with some enlightenment on programming. It wasn't necessarily about whether the code was "correct". I remember once interviewing a ~20-year old for the summer program who when I gave him a problem he started talking about some linear algebra and geometry that I didn't even know were relevant but quickly made sense to me. But he was so humble about it, and looking to me like he wasn't sure if it was the right approach to take (It was hard to keep a poker face and not give away that he was a "definite hire" after about 5 minutes). His 5-liner to solve it had one bug but he clearly "passed" with flying colors. Unfortunately for us he ended up joining a startup in SV (and now is doing big things there).
Well, after seeing what happened to Leslie Lamport, i don't have high expectations.
And to be clear: If you are unable to solve these common algorithmic questions that companies like Microsoft ask, then that's not the right place for you to work. This is a tangent, but there are literally thousands of companies that won't require you to solve these problems. The thing is, at Microsoft & co. you don't just do this in an interview. You do it at your job too. We do foundational work in many teams and we need to solve algorithmic problems practically every week. If you are unable to code yourself out of a DP problem or scared of NP completeness and approximation algorithms, then maybe find a different job instead of complaining about the interview process?
1. This is Guido van Rossum. If I were him and asked to solve puzzles, I'd tell the hiring company to fuck off.
2. These quizzes aren't so bad, but the pressure and stakes make it incredibly stressful. There's no standard, and often times the interviewer is the one that sucks.
> We do foundational work in many teams and we need to solve algorithmic problems practically every week. If you are unable to code yourself out of a DP problem or scared of NP completeness and approximation algorithms, then maybe find a different job instead of complaining about the interview process?
I'm pretty sure your opinion here is not that of your employer.
When I was leaving Google the first time, I asked my skip lead (who was employee #48 there, ended up running all of Search, and was previously a core HotSpot engineer at Sun) why he chose to work at a small startup when, coming off of HotSpot in 1999, he could work anywhere. He replied "Aside from them being one of very few companies with an engineer-centric culture, they were the only company that required I interview. Everybody else was willing to hire me on the spot."
For some personality types - and particularly the ones likely to do world-class work - being challenged is a positive sign. It means that the employer does their due diligence, and they will mostly be working with other people who react positively to a challenge.
To me, due diligence would be more like using software that someone has created. If it feels snappy then they're good enough at algorithms for the kind of software that they create, if it doesn't then maybe it's worth looking into whether or not there's a good reason for that.
Like if you apply for a job at the NYT, I doubt they make you do a timed writing test with people staring at you and asking you questions in the middle. They probably just read some of the previous work you've done.
I do not want to work with anyone who finds that getting their hands dirty is beneath them. It is very, very rarely going to be a good use of their time to do those problems. It will often be a good use of their time to teach those problems. A senior engineer, even one who’s unlikely to work with junior engineers on a regular basis, will need to explain their thinking. They need to show humility and compassion. Those are practiced attributes. This precise situation is the best practice you can get - New and Unknown person, some amount of challenge and complexity involved.
Thinking that whiteboarding problems are a bad use of time is a very strong signal for a senior person who is out of touch.
When you are considering hiring a nobody, this is acceptable. You will interview multiple people, and they will interview at multiple places, so the randomness isn't that important.
But if you want to hire one specific guy as a strategic hire, suddenly the randomness may no longer be acceptable.
It's really scary to go to company that is willing to hire you without ever talking to you.
(Unfortunately this happened in a small Eastern-European country, so the company was an investment bank, not Google.)
That would be amusing, but he'd have to be disguised, as he's rather recognizable, having done a lot of 'State of the Python' talks and the like.
He doesn't look as much like Rick Moranis as he used to, though, so that helps: https://gvanrossum.github.io/images/Guido@200dpi.jpg
Not sure what you're trying to get at:
MacOS homebrew creator is an effin nobody compared to Guido, therefore he should "know his place", "get in line" and invert a binary tree on the whiteboard and act like an obedient tech interview candidate that he really is?
OR
MacOS homebrew creator should've told Google to fuck off?
"The US constitution is like an overgrown enlightenment dissertation. The founding fathers did a good job at growing the United States, and this is a great achievement! It requires certain personal traits not everyone has. But at a technical level, they made many beginner's mistakes when drafting the constitution, which the country tried to fix later, but not always successfully."
:-P
You'd certainly be wrong to assume that Americans are all in favor of our foreign policy, to say the least. Aside from that, some of the downsides to the US constitution that inspired my comment include the way the founding fathers totally failed to anticipate that the nation would be completely polarized by a two party system, and that this polarization would happen along geographic lines.
Admittedly, this compromise whereby rural states with lower populations enjoy disproportionate political representation is baked into the constitution being agreed to in the first place (the 3/5ths compromise being relevant here as well). As we've moved to more direct democracy, with things like the electoral college being bound to the (local) popular vote and the direct election of senators, the original intentions of having a federation of mostly autonomous states becomes more and more anachronistic, while still fueling an increasingly polarized electorate that pits high-tax revenue and high population centers like SF and NY against low-tax revenue and low population centers that make up most of the country.
The United States is large geographic region with a heterogeneous economy. I don't know if a parliamentary form of government would have served this kind of country well, but certainly most friends from abroad who have spoken to me on the subject have implied that proportional representation is far more sensible than FPTP voting, and that parliamentary forms of government avoid the gridlock and polarization that our de facto two-party system engenders.
Please find me another "Masters Project" that has 8 Million+ Users and drives the backend for thousands of tech companies worldwide. Good Luck.
If you think a single function is equivalent to an entire Language you should get your head checked.
And I'm willing to bet when Google hired Guido in 2005, they didn't put him through a coding challenge humiliation clown show day.
Yes, that's exactly what he should have done.
I really just want to thank you for putting this useless mentality on display.
Almost 30 years of BDFL of Python, sorry don't care, go do 200 leetcode before talking to us. And if you don't spit out the answer a few seconds faster than that fresh graduate, clearly you're a lesser engineer and should be rejected.
I think it's my favorite example of how crazy some interview processes can get, lol.
The real question is why Larry Summers is going to a quant interview? Did he apply for a quant role?
I had a Nobel Prize winner as a physics professor in college who got three successive different wrong answers when attempting a freshman physics problem in office hours. That doesn't mean that physics isn't the right place for him to work.
not going to debate that, but I'm curious, what do you rank as #1 and #2?
That list is ranking languages by current popularity, though, rather than 'importance'.
I'd define 'importance' as more along the lines of "amount of havoc created if all software written using that language were broken/deleted at once".
We should not give too much importance to this, but the fact is that Python is now ranked consistently #1, #2 or #3 in sufficiently many rankings to consider it seriously.
Google or Wikipedia can tell you who Guido van Rossum is.
(that said, my path to being hired did involve writing a sudoku solver, but that wasn't in an interview for a position at Microsoft)
My story likely isn't replicable, but everyone has to find their way
I interviewed for Citus a couple weeks before they announced being acquired. I found out about the acquisition on Hacker News before having received an offer. They were able to get me in without going through the hiring process again
Initially I'd be moving to San Francisco but I wasn't eligible for any visas as I don't have a post secondary education. Staying in Canada's worked out
Some examples of things working out here: I was asked to implement some parsing, & well that's not so hard when you've written a Lua parser a year beforehand: https://github.com/serprex/luwa/blob/master/rt/astgen.lua (an astute reader will notice I don't handle precedence here, which is pretty important for arithmetic parsing. That's because I opted to implement shunting yard during codegen phase)
What value does this story give a reader? I only think it'd serve to continue an argument about how not everyone is so lucky, which isn't the original argument of "unless you're VP/Distinguished Engineer, not even Guido van Rossum gets to skip whiteboarding"
Keep telling yourself that as you fix mindless bugs in some Advertising platform lol.
Oh so that's why the Azure Portal UI is such garbage. Their frontend developers are just busy solving knapsack problems...
""" Python's BDFL-emeritus, Distinguished Engineer at Microsoft, Computer History Fellow. Opinions are my own. He/him. """
Lol! I'd bet my year salary they didn't.
That being said, ability to solve coding problems efficiently (not necessarily spit A* graph algo in sleep), but a decent close to real life coding challenge is fair game.
Programmer here. It's true. I deal with NP completeness every day.
It works here on HN too, many of my comments are upvoted jokes and I liked yours. It's sad it attracted animosity though.
I like browsing HN mostly for the interesting discussions, but I enthusiastically take the occasional jokes that come with them.
(I might have been upvoted by people taking my jokes seriously now that I think about it. I don't know if this is a terrifying or a funny thought!)
No way they even considered doing it... That's for people out of college...
If you are applying for a principal or higher engineer role and your job involves coding, you are asked coding questions. May be not just focused on a complex bookish algorithm only, but rather more close to a real life distributed programming / synchronization problem etc. for example.
The problem is rewarding rote memorization in a whiteboard interview, at the expense of actual understanding, and ability to research the problem.
If the profession being discussed is "academic work in Computer Science", sure.
If it is "software development", those things absolutely are not really "table stakes".
If it is "software engineering", then I don't think there is broad consensus on what that profession even is, much less what table stakes in it are.
No, nor do I think he was he hired for the other thing I discussed, academic computer science. The post I was responding to made a general comment about "CS graduates" and "our profession"; I was responding to that. Whether that post itself was material to, or merely tangential to, the discussion of GvR's hiring at Microsoft is an argument that, while perhaps interesting to some, was not the focus or concern of my response.
I would have thought that if you actually needed people to perform under pressure, you would design your test explicitly around that, instead of using “comfort with the whiteboard” as a proxy...
Do you mean it should be used as an actual speed test?
Table stakes for what exactly?
Senior engineers in such companies need to work and cooperate with hundreds of people. If they find solving such problems beneath them, or expect to be treated as a higher class of person, or not willing to get hands dirty, they will not be as valuable as employees. (Occasionally, the lone genius is great, but the lone genius is a worse employee than the genius that can cooperate well)
My company would keep doing such interviews, but the expectations change of course. A new grad needs to do these well. More senior people can do worse, and make up for it using other skills showcased in other interviews, or based on their record.
But if you find a senior person that finds solving algorithmic questions is beneath them, you might want to be careful about them and how they will interact with your company’s culture.
I mean, it's OK to ask for basic algorithms in interviews, to see if the interviewee has at least some understanding of basic stuff and/or can think on their feet and/or can reason about problems appropriately...
But I would still welcome it if instead of giving an interviewee a boring, memorizable problem like "invert a binary tree", the interviewer would find a more general problem and would see how the employee would tackle it, and if the interviewee refers to binary trees as part of the solution without writing out a full implementation from memory that's OK (as long as binary trees would be a valid approach to solve the problem, of course).
those are the best interviews imho. specially when both the candidate and the interviewer engage into a productive discussion about the solution the candidate gave.
at the same time, those take time and a lot of companies want a "fast" hiring pipeline, which leads to "invert a binary tree on this whiteboard!".
I see a bunch of comments that look to me as strawman, or really bad interview experience.
A good coding interview should: - not be known by the interviewee if they spent even a few weeks on leetcode - avoid requiring anything that isn’t covered in an average CS101 class - draw its challenges from the need to process a new problem, and gradually uncover the edge cases in it and how to handle them gracefully.
I don’t do leetcode. But went now and tried the first hard question I found. It was “find the median of two sorted arrays”. I find this question to be a good example of very little background knowledge needed. (You’d need to know how to deal with arrays, and what’s a median - not everyone will know these, but it’s a pretty low bar)
This question already has plenty of room for mistakes, edge cases and problem solving. I’m going to take a wild guess from knowing talented veteran engineers I’ve seen that they can surely handle it in the interview structures I’ve experienced.
I don't know any product that's pleasant to use that was developed in the way you describe. Python certainly wasn't.
If you tried to implement those algorithms on my team without a very good reason, there would definitely be some serious conversations that followed.
In any case, vomiting algorithms on command doesn't seem to correlate strongly to programming ability. Almost all programming problems have a lot more to do with handling much higher-level complexity issues. The knowledge and art of knowing how to poke some undocumented third-party API to implement our system is much more practical. Knowing how to think at a high level is much more practical. Leave algorithm questions for research positions in that area.