This is another reason that, while I understand people’s complaints, I still believe CS interviews should include algorithmic and whiteboard tests. I know they may seem “outdated” or “irrelevant” to some, and yes, it is very unlikely that you will need to implement Dijkstra’s algorithm by hand without any reference, but it is more that it shows a general competence in computing which will transfer to other, more relevant areas. Also, another key insight to whiteboarding is whether you can recognize the fundamental nature of the problem as an instance of another problem, which is essential to CS since the entire field is about solving problems efficiently.
Funnily enough in my career, whenever I took a job after an algorithm and whiteboard test, I would find myself doing the most basic CRUD applications whereas when I interviewed in a more humane way, by talking and exploring the knowledge set I bring to the table, I ended up working with cool algorithms in some highly technical areas.
You mean you're not constantly balancing binary trees and implementing your own bubble sort algorithms? I figured from interviews that this is 95% of what engineers at SaaS companies are doing.
>since the entire field is about solving problems efficiently.
The entire theoretical CS field yes. In the practical field of CS engineering, this is only a subset of the useful competences and a small one at that. Communication, working as part of team, reliability, ability to look up and learn things you don't currently know, caring about the state of the code you write, mentoring others, being able/willing to push for things you believe can be done better (not just in terms of algorithm, but processes affecting the entire business) etc. are all as important.
I would much rather hire someone that sucks in algos/data structure, but is fairly good on all those other points than the opposite.
So yes, whiteboarding can be useful to assess how a candidate is doing on one of the specific skills that are useful for a CS engineer, but if 50% to 90% of your hiring decision is based on that, just like it is in FANGs today, you have an inadequate hiring process IMHO.
For the average SDE job. If your job is to implement and optimize a compiler, then sure it's extremely important.
I used to have a co-worker exactly like you describe. He was great for consulting business: the clients liked him him so much that they hired two additional consultants. One to fix everything that he broke and another to do the job he was supposed to do and took credit for.
* You also used to have many other coworkers that weren't very good at whiteboarding, since even very good engineering teams in FANGS have many people like that, and that didn't have that problem since you specifically said you had one occurence of that.
So hear me out: maybe there isn't a single predictor that you can just automatically throw at interviewees, like a hard leet code problem, and hope that it will magically filter out the very best engineers for you to pick from. Maybe you should have an interview process that test the different areas I mentioned proportionally to what the actual job you are recruiting for requires.
I'm a firm believer that you should include them, if they are part of the job. If not, especially if they're completely unrelated, then they're just a reason somebody is going to have a harder time passing your interview. If you want that, that's your prerogative, but generally IMHO you should focus on finding owners, people who are going to give it their best to provide quality and love their code/contribution. Whether they know how to rock from day one, or they're going to learn it on the job.
It's not an easy thing to look for, I know, but it's what we should be striving towards IMHO and what I'm focusing on. So far it has had great results, with a few misses, but a better success rate than just handing out technical stuff.
If I hire you, I'm going to be a lot more interested if you know how to get a backtrace for every thread in a process than if you can whiteboard Dijkstra's algorithm. I'm going to be a lot more interested if you know anything the issues with denormals and use of -ffast-math than any of your familiarity with sorting algorithms (which will no doubt exceed mine). I'm going to be a lot more interested in whether you understand how to iterate over a utf8 string than your understanding of how to construct an AST and use it.
I worked in a (good) CS department for 4.5 years. They did not teach programming skills to anyone. Most (not all, but most) of the jobs you might be hired to do require far more from the programming skills area than the "computer science" area. People coming out of that program (even at the PhD level) often didn't not even understand how to use a debugger!
It really depends on what kind of developer you're looking for. In the web applications I've worked on, knowledge of application architecture and experience with linux trumps anything I learned in a college course.
Based on my experience, theory problems on white boards is about as useful as dropping a CUPs automation problem on unsuspecting interviewees.
Build me a CUPs driver that drops pdf into in folder in 15 minutes or less. Without documentation.
Bonus points if you can ask if you can skip that bullshit and install and configure an existing a package.
Note: I'm a senior developer with at least a decade of experience. I don't just slap two libraries together. If you want to have fun, dig into how macOS sandboxes CUPs. My bash scripts were not happy.
Agree on what you said. Whiteboard tests on textbook algorithms is a really efficient *and* lazy way of objectively testing a candidate's abilities. The nature of the questions will prevent the interviewer from mistakenly getting impressed by hyperbole.
That said, I do understand why people complain about algorithm questions -- it's undeniably a good filter if you have a large pool of candidates (and a reasonable predictor of ability), but it's mostly irrelevant to most software jobs today since you can usually import textbook algorithms as OSS modules.
The "correct" but harder way to interview is to tailor the interview questions to your actual requirements. This is much more involved and it requires the interviewers to divert attention from whatever they're working on just to set the problems. Setting a problem that's at the right difficulty level and evaluates the right set of skills precisely tailored to the team's needs is hard. (I don't think most typical software engineers have the chops to do this, even experienced senior ones.)
So it's kinda understandable that everyone just randomly picks something from leetcode and use that instead. It's probably not so much a failure of the software industry on the recruiting side, but more of a symptom of how we have failed to come up with skills, tricks, standards and practices that everyone actually agrees on. (eg. it's mostly fruitless to determine whether a candidate is hire-worthy with a question like "would you use Javascript to implement a backend system?") At least the algorithm questions are objectively agreed to be true (even if possibly irrelevant) by everyone and is actually part of most CS cirricula...
Knowing Dijkstra's algorithm off the top of your hand doesn't show a general competence in computing. It shows that you've memorised Dijkstra's algorithm and can get through leetcode "problems". Does the person you're hiring need this knowledge to do their daily job? If not, then you shouldn't be wasting your time questioning them about it.
