I think one of the major takeaways here is, stop asking algorithm questions [1]. Everyone. Just stop it.
In my opinion, and modest experience (I've done several dozen interviews, so there are plenty more experienced then me, but I'm at least not new, plus nearly all interviews were for my team so I had to live with the results!) it isn't that hard to come up with small sample questions related to what the job actually is doing. From there, in addition to the mere fact of whether or not they were able to complete the task, you can learn about how they did it, look at their practices, stop them for a moment and discuss the implications of something they just did. You can add a wrinkle to the task ("what about unicode?" "what about cross-site scripting vulnerabilities?"). I also find being this kind of flexible, rather than being stuck on "did they solve this algorithm challenge in the proper manner" also gives me room to be human, to take a moment to try to calm the candidate down in what is inevitably a stressful situation for them (even if it's basically just Tuesday afternoon for me in my current position in the world). I think of an interview as "I want to find all the positive I can", rather than as a process of locating all flaws, and you can't do that if your candidate is frozen in the headlights the whole time.
Interviewees are pouring forth a wealth of information. The idea that the only way to find out how good they are is by asking this one narrow set of questions is absurd.
And the interviewers are pouring forth a wealth of information too. Consider what message you're sending with a rigid adherence to something we all know is broken.
[1]: Unless it really is relevant to the job! I expect that if I'm hiring a senior level machine learning researcher that you better be able to describe gradient descent to me, for instance. We may not implement it literally in the interview but I have a reasonably case for saying the researcher ought to convince me they could get there. But in a lot of cases, what's more relevant to me is that you know the characteristics of algorithms rather than exactly what they are. You can know the runtime and weaknesses of quicksort or RAFT consensus even if you can't spew the actual algorithms on to a board.
Actually, my parenthetical here almost makes me want to rewrite this whole post, although this thought is still fresh and I'm still chewing on it. Is that perhaps the error we are making? Are we conflating knowing the algorithms for knowing the characteristics of the algorithms? The latter is legitimately important and I see screwups based on failing to understand characteristics of algorithms all the time. Knowing the literal, actual algorithm to the point that you could simply open up a terminal and bash it out yourself is rarely important in this era.
I left Google in 2009, quite unhappy about the difference between a startup and corporate politics. After that I worked at 3 startups (5 years), 1 telco (1 year) and at McKinsey (3 years).
I ended up interviewing at Google again in 2018, after deciding that a) I liked programming more than management consulting and b) my comparative advantage was in programming. I definitely could have felt entitled after 1) passing Google interviews once before, 2) having had three somewhat successful startups and 3) proving I can also handle the corporate side.
I was asked multiple questions that could be interpreted as 'algorithmic' (and I have to admit that after 3 years of not coding I was nervous about them). However, they can also be interpreted differently, more charitably. They all followed the structure of: 1) give a reasonable but not completely defined problem - you should be able to clarify enough of this to show you can deal with some ambiguity; 2) turn that into an algorithm - you should be able to articulate an easy algorithm and be able to discuss improvements to it; 3) turn your algorithm into code - you need to show you can actually program. I definitely didn't have to memorize and regurgitate textbook solutions.
I acknowledge that a) the above may optimize for rejecting all negatives at the cost of some false positives and b) it's still a very basic lower bar and doesn't predict who will perform highly vs. ok. However, I did think it tested for the core skills I expect from programmers.
I've also set up interviewing processes at startups. I did end up emphasizing ownership and 'getting things done' more than Google does. I do think startups should test for different attributes than 100k+ FTE corporations.
You missed a big one - giving them an idea of how you approach a problem and work through it. That's the biggest take away.
If someone just spits out an optimal solution straight away that's not actually a great sign. It doesn't matter if you struggle a little, or need a few hints, but showing you know how to break a problem down into smaller sub-problems and work your way up is an invaluable signal.
This is incomprehensible for me. If someone happen to see your question before it is bad sign? And also, what exactly about my internal process are people trying to learn from "how I approach a problem and work through it"?
I think I tend to make good impression on these ... but I am aware it is interview skill where I somehow picked up social signals I am supposed to send. I am adjusting what I am saying to how interviewer looks like (happy, annoyed, bored, etc). It is social skill, but not same social skill as pretty much anything I do in actual work. In actual work, people are not interested to listen to me work out problems in front of them.
It is even more useless if you know the answer and then proceed pretend to split it into smaller problems and then work your way up or down. That neat thought process is neat precisely because I know the answer and I am performing idealized problem solving process.
In case of actual real problem, you don't do that so nicely. You have at least some bad turns, random guesses, break it multiple times badly and so on.
I’ve been in interviews where I’ve seen the problem before, and know the solution. I’ve always said so if that happens and the interviewer either continues and delves into why it’s an optimal solution, or switches to a different question.
> Knowing the literal, actual algorithm to the point that you could simply open up a terminal and bash it out yourself is rarely important in this era.
Yeah. In a world where Google exists (or even where Knuth exists), what's the value in having algorithms memorized? Knowing the characteristics, sure. I agree that that's important. But the algorithms themselves? Why? I've got better things to do with the memory space.
There's no value in memorizing algorithms. There is, however, a lot of value in the ability to solve algorithmic tasks. I don't think anybody is intentionally structuring interviews to measure how many algorithms a candidate has memorized... interviewers are looking for the ability to solve problems, they just... fail at doing that.
In principle, my interviews, which tend to be a lot more about "take this text from a DB and process it in this way and display it on a web page" are algorithmic too. I mean, if anyone's writing code, they're writing algorithms. But there's day-by-day algorithms where you're basically gluing lots of things together, and there's Project Euler problems. In my 20+ years of software engineering, I've personally encountered maybe 3 or 4 Project Euler-type problems in my real job. (And even those weren't as clean as those problems; I still had to integrate them back into some other real-world code base.) Expecting your candidates to be good at inverting red-black trees recursively when you want them to hook databases to web pages without massive security vulnerabilities or performance issues is silly.
"Gluing lots of things together" is a descriptive term, not a derogatory one. There's a ton of things you need to know to be a good gluer nowadays; security, performance characteristics of all the pieces, we're adding more and more distribution into our systems, higher level stuff like integrating with teams, documentation of your code, how your workflow goes... there's more than enough to interview all day on these issues without ever having to quiz the candidate on puzzles from the back of a Knuth book.
In my opinion, and modest experience (I've done several dozen interviews, so there are plenty more experienced then me, but I'm at least not new, plus nearly all interviews were for my team so I had to live with the results!) it isn't that hard to come up with small sample questions related to what the job actually is doing. From there, in addition to the mere fact of whether or not they were able to complete the task, you can learn about how they did it, look at their practices, stop them for a moment and discuss the implications of something they just did. You can add a wrinkle to the task ("what about unicode?" "what about cross-site scripting vulnerabilities?"). I also find being this kind of flexible, rather than being stuck on "did they solve this algorithm challenge in the proper manner" also gives me room to be human, to take a moment to try to calm the candidate down in what is inevitably a stressful situation for them (even if it's basically just Tuesday afternoon for me in my current position in the world). I think of an interview as "I want to find all the positive I can", rather than as a process of locating all flaws, and you can't do that if your candidate is frozen in the headlights the whole time.
Interviewees are pouring forth a wealth of information. The idea that the only way to find out how good they are is by asking this one narrow set of questions is absurd.
And the interviewers are pouring forth a wealth of information too. Consider what message you're sending with a rigid adherence to something we all know is broken.
[1]: Unless it really is relevant to the job! I expect that if I'm hiring a senior level machine learning researcher that you better be able to describe gradient descent to me, for instance. We may not implement it literally in the interview but I have a reasonably case for saying the researcher ought to convince me they could get there. But in a lot of cases, what's more relevant to me is that you know the characteristics of algorithms rather than exactly what they are. You can know the runtime and weaknesses of quicksort or RAFT consensus even if you can't spew the actual algorithms on to a board.
Actually, my parenthetical here almost makes me want to rewrite this whole post, although this thought is still fresh and I'm still chewing on it. Is that perhaps the error we are making? Are we conflating knowing the algorithms for knowing the characteristics of the algorithms? The latter is legitimately important and I see screwups based on failing to understand characteristics of algorithms all the time. Knowing the literal, actual algorithm to the point that you could simply open up a terminal and bash it out yourself is rarely important in this era.