Comment by dragochat
1 day ago
...the f?! why are we interviewing ppl for things like this?!
you either:
(a) want DEEP understanding of math and proofs behind algorithms etc.
(b) can get away with very high level understanding, and refer to documentation and/or use LLMs for implementation details help
there is no real world use case for a middle-ground (c) where you want someone with algo implementation details rote-memorized in their brain and without the very deep understanding that would make the rote-memorization unnecessary!
> there is no real world use case for a middle-ground (c) where you want someone with algo implementation details rote-memorized in their brain and without the very deep understanding that would make the rote-memorization unnecessary!
I was watching a video recently talking about how Facebook is adding KPIs for its engineers' LLM usage. As in, you will be marked negatively in your performance review if your code is good but you didn't use AI enough.
I think, you and I agree, that's obviously stupid right? I imagined myself as an engineer at Facebook, reading this email come through. I can imagine two paths: I roll my eyes, find a way to auto-prompt an LLM to fulfill my KPI needs, and go back to working with my small working group of "underrecognized folks that are doing actual work that keeps the company's products functioning against all odds." Or, the other path: I put on my happy company stooge hat, install 25 VScode LLM forks, start writing a ton of internal and external posts about how awesome AI is and how much more productive I am with it, and get almost 0 actual work done but score the highest on the AI KPIs.
In the second path, I believe I will be more capitalistically rewarded (promotions, cushy middle/upper management job where I don't have to do any actual work). In the first, I believe I will be more fulfilled.
Now consider the modern interview: the market is flooded with engineers after the AI layoffs. There's a good set of startups out there that will appreciate an excellent, pragmatic engineer with a solid portfolio, but there's the majority of other gigs, for which I need to pass a leetcode interview, and nothing else really matters.
If I can't get into one of the good startups, then, I guess I'm going to put on my dipshit spinny helicopter hat and play the stupid clown game with all the managers so I can have money.
I think the influx of many truly self-driven and resourceful self-taught programmers in the 2010s established a perceptible need (not necessarily an accurate one) of needing to "properly vet" non-degreeed candidates. Stuff like Leetcode is what emerged. The truth is, the "vetting" was originally done via self-selection. Generally computer-oriented and creative people gravitated toward application development and it was worth something to the world. The world probably didn't know how to value this group of people, so continuously tried to put in some kind of formal process.
But like Art, the artists came from everywhere. We're being dishonest if we don't acknowledge what truly made these developers get to where they are, and it wasn't because they originally went "Oh, I know what I'll do, I'll do thousands of Leetcode problems', that is absolutely not the true story of the developer in the last decade.
Leetcode is a sloppy attempt at recognizing and appropriately handling developers. It was an "attempt", a failed one imho. It fundamentally ignores the spirit in which these developers operated in, it reduces them to gym rats, and that's not how they got there.
This being a spiritual problem is what makes the most consistent sense. Even those that grind Leetcode will tell you their heart is not in it (just like GP mentioned above).
Maybe it's just me, but I want people that are reasonably competent and you can work with. Maybe there are some jobs that require deep understanding of maths/proofs etc, but those are what, maybe 1 in 100 engineering jobs?
More often than not a deep interest in a particular technical domain is a liability. It's like that guy that insists on functional programming design patterns that insists on a fold with tail recursion where simple mutation could have easily sufficed. Or endless optimization, abstraction and forced patterns. Bro, you're working on building a crud app, we don't need spacecraft design.
The math puzzles like this are supposed to show deep mastery. I assure you that you don’t need DP in 99.999% if cases as well, but idiots are still asking house robber.
People are sheep. Someone somewhere used mathematical puzzles as interview questions. That someone became big. Others assumed it was because their interview process was amazing and followed blindly. Soon enough the process started to be gamed.
I'm seeing this trend again in the field of AI where math olympiad participants are being given God like status by a few companies and the media.
Truth is even the most prolific computational scientists will flunk these idiotic interviews.
Hundred percent. Classic example of academic smarts vs real world smarts.
It's why developers as a group will lose negotiating power over time. You would expect a smart person to question why that 'problem' exists in the first place rather than forge ahead and making a solution for a problem that doesn't exist. It's like your manager telling you to write a software that does something, whatever that is. Your first question should be why and you should not type a single letter until you understand the domain and whether a software solution is needed in the first place.
For all the intellectuality modern devs give to themselves, they are still asking how high when told to jump. And in some cases even bragging about jump heights. Only difference is that many devs look down upon others (or simply are unable to understand those) who refuse to jump.
We all know devs have better things to focus on, given the state of modern software development.
I am guilty of this. I started asking simple programming questions back in the early 90s. It was just a way to see if interviewee knew how to use for loops and conditionals, to see if they can solve simple problems. It was great when taken unprepared, but once people started drilling and memorizing them, the problems became a lot harder. It got to the point where you really have to study, it is not enough to have 20 years of professional programming experience.
Fun story. For years, I used a set of problems that I took from a very old programming book. I have probably seen dozens of solutions for these problems. About 6 years, in an interview, somebody happen to ask me about one of these problems. So, I wrote the solution and the interviewer told me it was wrong, but he couldn't tell me why it was wrong. Then he proceded to clean the screen. (It was remote interview). So I flunk the interview with a problem that I knew back and forth.
Yes, and it's mostly the fault of a handful of companies like Google and Facebook that were started by founders who were still in college, so choose interview problems that look like CS algo puzzles instead of anything related to real work.
> why are we interviewing ppl for things like this?!
Ship has definitely sailed