3 ms·
I've been doing interviews pretty frequently lately. Maybe it's just the limited scope of my experience, but I've never asked anyone to code bubble-sort, nor d
by charles-salvia 10y ago
I've been doing interviews pretty frequently lately. Maybe it's just the limited scope of my experience, but I've never asked anyone to code bubble-sort, nor do I know anyone who has ever asked that, nor have I ever been asked that at a job interview. The closest thing I've seen to this, probably, is generic tree-traversal questions, like find the lowest common ancestor of two nodes, or whatever. Apparently the feeling these days is that these sort of questions suck because they're not "real world" enough, and you'll never need to know about such stupid things like "nodes" and "algorithms" and "computer science" on the job.
So now I guess the trend is to ask more trendy, design-oriented questions like, "how would you design Facebook?", etc. But the problem with all this backlash to algorithm-heavy whiteboard interviews is that it ignores the reality that there are tons and tons and tons of crappy candidates out there. I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level. It's not that I am claiming that most on-the-job programming is implementing algorithms and data structures (it's obviously not), but being able to do these things indicates a certain quantifiable level of aptitude.
The trick is to present the questions in a way that isn't vulnerable to rote memorization. Don't ask someone to simply code a tree or graph traversal algorithm. Instead ask them about the most efficient way to route packets or whatever. And more importantly, tailor the interview questions to the actual experience they claim to have on their resume. If they claim to be a machine learning expert, ask them to sketch out how a multilayer-perceptron actually works. If they claim to know about the Linux kernel, ask them to design a page-cache, etc.
I agree the "you have 5 minutes to implement quick-sort now!!" is not helpful. I also hate the stupid logic-puzzle crap. But let's not completely dumb-down the whole interview process as a remedy to all this, just because "real-world" programming is more about import java.util.* rather than coding up custom radix tries.
- deleted 10y ago[deleted]
- Domenic_S 10y ago> I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level. If the position you're hiring for involves those things on a regular basis, fine. If not, you're probably selecting inefficiently. The reason for the swing over into high-level questions is managers are learning that smart, often academically-inclined engineers will happily burn weeks on something they find interesting but adds value incongruent with the expenditure. The recent trend of hiring experienced engineers to be engineering managers either exposes the problem or exacerbates it. If two candidates are equally qualified to do the job, but one demonstrated they can think through high-level designs -- I pick that one.
- Apocryphon 10y ago> the reality that there are tons and tons and tons of crappy candidates out there. Maybe we need to start asking why that's the state of the industry right now. How did it come to this where quantity is so high and quality is so low? And how can these candidates better themselves?
- watwut 10y agoBecause it became cool and well paid and thus many guys decided to give it a shot, fake it till they make it. Some even succeed. Also, because many peoples confidence is much higher then skill. They get away with it because confidence tend to be confused with ability.
- charles-salvia 10y agoIt's probably more related to the universal constant that 90% of everything sucks.