> almost no one wants to take a chance trying to develop a new way to interview.
I'm guessing your in the under 40 camp, but interviews did used to be better.
In the early days of the startup explosion interviews where much better. The biggest signal at the time was having an active github profile or otherwise existing portfolio of code. The strongest signal back then was serious contribution to any open source projects (strangely today that almost seems to count against you). It also wasn't required that you had these, but they were a very strong signal.
Interviews were largely technical conversations, to see if you understood the concepts, and even more importantly, it was okay if you didn't know. I remember being asked a question about TCP vs UDP. I didn't know much networking at the time, and explained what I knew about TCP but admitted my understanding of UDP was basically non-existent (admitting ignorance used to be a huge plus back then). The interviewers then explained how it worked and asked if I could explain when and why this would make for a better solution than TCP. I answered about the obvious application to media streaming and passed. Interviewers didn't care that you knew everything, they wanted to see how you think.
Even the original predecessor to our current leetcode nightmare, fizzbuzz, was never supposed to hard it was meant as a basic sanity check. There were some devs who had just followed the flow at some big bank and literally couldn't code on their own. Fizzbuzz was just to make sure that given a blank page you could implement basic code.
Of course as tech started to boom, so did the bootcamp/interview industry. People were trained to do fizzbuzz, instructed how to create a github repo filled with meaningless, half started project (or forks of other projects), and people where told how to flood OSS projects with minor pull requests so they could claim to be contributors. Then companies wanted to be like Google and have hard white board challenges.
Then you had a generation of engineers that never knew any different and largely had forgotten (or never known) how to assess technical competency anyway than through a series of hazing rituals.
That second article is interesting in this conversation because it's main contention is that the vast majority of any applicants to any position you're trying to hire for are going to be terrible.
Which is the phenomenon seen by others as well and discussed in Atwood's 2007 one.
They don't really talk about the Google style DS/algo problems, so yeah, seems like those became popular later.
But it suggests the hiring experience for companies has long been awful.
The sort of experience you had - a good conversation about a detailed relevant technical area - is something that I've never personally found common when trying to hire. Most candidates still aren't great if you're looking to do even moderately greenfield development (even if not particularly interesting - just being able to put together a decent scaffold of an idea).
Leetcode - the site - is an interesting phenomenon because it's full of problems far harder than any I've seen in practice at FAANGs and similar. Stuff I've encountered in the real world seems to fall into the Easy or Medium buckets.
After being at a BigCo and hiring some people who aced whiteboard coding and failed on simple everyday things, though, I certainly would never again use something like that as the only factor.
I'm guessing your in the under 40 camp, but interviews did used to be better.
In the early days of the startup explosion interviews where much better. The biggest signal at the time was having an active github profile or otherwise existing portfolio of code. The strongest signal back then was serious contribution to any open source projects (strangely today that almost seems to count against you). It also wasn't required that you had these, but they were a very strong signal.
Interviews were largely technical conversations, to see if you understood the concepts, and even more importantly, it was okay if you didn't know. I remember being asked a question about TCP vs UDP. I didn't know much networking at the time, and explained what I knew about TCP but admitted my understanding of UDP was basically non-existent (admitting ignorance used to be a huge plus back then). The interviewers then explained how it worked and asked if I could explain when and why this would make for a better solution than TCP. I answered about the obvious application to media streaming and passed. Interviewers didn't care that you knew everything, they wanted to see how you think.
Even the original predecessor to our current leetcode nightmare, fizzbuzz, was never supposed to hard it was meant as a basic sanity check. There were some devs who had just followed the flow at some big bank and literally couldn't code on their own. Fizzbuzz was just to make sure that given a blank page you could implement basic code.
Of course as tech started to boom, so did the bootcamp/interview industry. People were trained to do fizzbuzz, instructed how to create a github repo filled with meaningless, half started project (or forks of other projects), and people where told how to flood OSS projects with minor pull requests so they could claim to be contributors. Then companies wanted to be like Google and have hard white board challenges.
Then you had a generation of engineers that never knew any different and largely had forgotten (or never known) how to assess technical competency anyway than through a series of hazing rituals.