They really need to hire less geeky people (disclaimer, also geek but with self awareness). We hire a percentage of people whose first degree is not programming and have formed relevant career paths.
It's not clear to me why this would be a result of their engineering hiring practices as opposed to their business strategy and product management culture.
Nobody happy with their pay and job is going to grind leetcode.
They could just ignore leetcode and ask puzzle problems instead to test ability.
One of the hiring fads before leetcode was to ask puzzle questions, with a heavy emphasis on Fermi questions and trick questions. These had the same failure modes.
It turns out that hiring is hard, involves some risk, and always tends to illustrate Goodhart's Law: whatever process you put in place to avoid that risk will ultimately become worthless when people start optimizing for it.
However, I agree with the general sentiment that almost nobody is doing the research to ensure their interview process selects for the things they actually want.
2. Its not a hamster wheel because you get a high paying job for your efforts
These companies don't want an employee who starts to question "why" things should be done or why things are important. Demonstrating that you are willing to apply yourself at something objectively useless simply because you are required to is a huge plus.
Grinding is a poor proxy for work ethic. It is a good proxy for submissiveness.
In fact this is how you become "smart" - some talent and a lot of hard work (grind)
Hmm. I think this is a different definition of "smart" than I'm used to. I would say that some talent and a lot of hard work gets you "skilled", not necessarily "smart".
Skill is a form of "functional intelligence", where skill = talent + grind. The more talent, the less you need to grind, but combined the two are killer. To me, "smart" where the grind is 0 is not "smart", but just "lucky" (born with talent)
I'm not going to grind leetcode regardless of how happy I am with my pay and job. I have very strong objections it. If a company requires it, I take that as a pretty strong signal that I won't get along well at that company.
In a "can you solve this new leetcode problem that just came out and is not in the training data"? Awful.
If you want to see an example of a new problem check out https://news.ycombinator.com/item?id=37910297. You'd think if leetcode makes you good at solving problems then it should be doable any higher ranking leetcode programmer.
The comment I replied to claimed that "LLMs would do pretty well at leetcode interviews". OpenAIs own report [0] shows how GPT-4 fails miserably at medium/hard leetcode problems that are not in the training data.
This extends to every test though. My ACT score jumped massively on my second try. The reason: I didn't realize how much little time they gave test-takers, so I ran out of time on some portions. The second time around, I rushed through as fast as possible.
Or do you do well solving the problems on your own and just have trouble when being interviewed?
I did extremely well in algo classes in school.....but since then I have built actual applications that run businesses and haven't used algorithms at all.
Grinding leetcode feels like running on a hamster wheel for me.
How did they measure "smartness"? The Leetcode algorithms are mostly solved problems and I know people who can "solve" any leetcode you throw at them, but they are very poor at actual real world problem solving.
It's quite a bit like saying people who memorised Wikipedia are smart, because they know things.
To me being smart is to know where to look.
I'll just get the smartest of the smarts and rule the world! If I only get the alphas of the alphas, I'll surely win.
Reminds me of all the NBA players getting schooled in FIBA, because the international teams have better chemistry. At one point they had to do a total re-boot, because it was so embarrassing.
I know of at least one second tier, non-sv shop that goes hard to hire the best developers in terms of intelligence. It actually leads to huge quality problems during recruiting and poor diversity. There's just something about mega-nerds with extremely poor social skills that keeps the women and minorities away.
What I'm talking about isn't just awkwardness and lacking charisma. I'm talking about randomly telling women that they can tell she is on her period and things like that.
> What I'm talking about isn't just awkwardness and lacking charisma. I'm talking about randomly telling women that they can tell she is on her period and things like that.
These don't seem limited to SV and Big Companies™ like Google, all it takes is a cursory scroll either through this website (even this thread!) or a trip to any of the CompSci-focused boards on Reddit. Additionally not limited to women and minorities, but anyone from a non-traditional background as well.
If anyone feels like working on these issues, the problem is extremely local, you don't even have to leave HN!
As a result you get pretty average people. Even the weirdos tend to be just quiet and reclusive. My brother on the other hand, went to work for a smaller B tier to google, and he had multiple co-workers that were just beyond bizarre.
Have you considered that what's actually happened is people are finally realizing that they don't want to optimize for the characteristics that Google is optimizing for?
Setting aside the question of whether "smart"s are something that can be sought out without a more specific definition, the average business doesn't need "smart" programmers. They need programmers who are predictable, who reliably produce good-enough software, who communicate well in speech and in writing and who work well on a team. Algorithmic ability provides essentially zero signal for these capabilities, so it's not so much that people have lost the intent that they're realizing that the process they cargo culted isn't appropriate for their hiring needs.
Also, I wouldn't take Google's (nor anyone's) claimed research about hiring at face value.
For backend web devs I'm hiring I established a modified version of a process that has worked for me well before:
1. Interact with a RESTA api and solve the problem by doing cURL requests and some lightweight string mangling and computation to generate key. Then submit the result with your BASE64 code in the request.
Your code is analyzed with ts-node (I look for TypeScript devs) and we check the validity of your generated key.
On success I get an email with the person info and the code. To follow up.
I give the url of the challenge to anyone whom I get their CV and seem interesting for the position. A lot of people disqualify themselves because they dont know a REST endpoint needs the correct content headers, or dont know how to send Auth Bearer token, etc.
Then I see the code, and if I like it, i send them a link to self book a 90hr interview. 30/50 mins are to talk about their experience, resumé in hand, and the rest is to make a version of the server to process the requests from the client they submitted. The problem is common knowledge for both of us, its basically what tgey will be doing, and it allows me to vouch for how they code. Mind, I dont care if we dont finish it, I just want to see if we can solve a problem together with the candidate driving.
And that's it. At the end of the interview I can tell them if I'm going to make them an offer .
I try to do interviews the way I'd like to be interviewed. I hate tech interviews, its stressful and seems pointless sometimes. Why would I do that to people who will be my peers? Bad taste.
The initial reason why we have Leetcode today is that Google originally determined through their interview research that the smartest candidates were the ones who were best at algorithms. Google wanted to hire the smartest people, not necessarily the best coders, so that’s why their interviews were mostly algorithmic.
Of course everyone started copying Google without doing the same research and the message got lost. They just blindly asked coding algo questions and that’s why we have an entire industry built around coding algos and the signal is entirely lost now.
It’s funny that people have lost that intent and are now creating derivatives around that, ie thinking code reviews are a good replacement.
It might be, but there needs to be data done to research it to see if you get what you want. If you interview using code reviews, you get good code reviewers. If that’s what you want, great.
But remember that Google’s initial goal was to hire smart people, and there’s no research to suggest that good code reviewers are smarter than average.