So, if you solve the hardest LeetCode problems, will you become a better developer? Nope. Will learning basic algorithms and understanding how to apply them to real-world scenarios make you a better developer? Yes. I recently had to learn about Postgres' indexing algorithm called Gist, I now know more about how indexes work in Postgres. Did I memorize every detail of how it works? Nope.
Most active software engineers, who aren't spending hours memorizing these riddles, would utterly fail in whiteboard interviews. Yet, they excel in their day-to-day work.
These interviews aren't about assessing practical skills nor real-world problem-solving. They're a memory quiz on specific patterns, patterns that are rarely used in actual jobs. Many candidates dedicate weeks or months to practice hundreds of cherry-picked questions, instead of learning something useful. All to prove they're willing to jump hoops for a shot at a job.
Its not about identifying the most skilled engineers but rather those who fit a specific mold. Most of these so-called "whiteboard questions" are nothing but a test of obedience, not intelligence nor problem-solving ability. It's essentially asking candidates, "How much bullshit are you willing to go through to maybe, just maybe get a shot at working for us?"
Hi! We're The corporation You're "Eager" to work for
We don't need free thinkers or leaders, we need obedient slaves, individuals who'll unquestioningly follow orders and work overtime. Their expertise? Irrelevant. We'll train them, we can afford it, our customers will pay for that.
We need to recruit only those willing to bend to our will, especially those fresh grads, they've been so thoroughly indoctrinated in college that they're ready-made. Give us the naive, the easily duped. we'll cultivate a cult-like following, call it office "family", company culture or whatever, they'll gladly lap up our propaganda, give them free perks from time to time, bread and circuses right? After all, what's more disrespectful than asking for a raise within our family? Or worse, considering leaving our family for another? If we can convince you that you're smarter than other developers just because you work for us, you wouldn't even think about leaving.
How (Most) Interviews Should Be Conducted
You talk about what the candidate accomplished in the past. As the interviewer, you gather general information and then start digging into what the person did, how, and why. Then, you ask questions about what could have been improved, what was good, and what was problematic. Then, you discuss problems within the team (if applicable), etc. The idea is to get an overall picture of the person as a human being and professionally as a software engineer. You might also check if the interviewer has their work publicly available, open-source projects, writings, answers, etc. Someone might have 20 years of "experience," but they can't be useful if it's 20 years of stagnation. You can engage in some open-ended questions like, "We just had a microservice "X" fail, why?" If they do frontend development, they'll rant about all the possible problems that the frontend has, database experts might rant about databases. Others might rant about proxies, infra, security, ops, code flaws, etc... , they'll rant about whatever they excel at. If they're mid, then they can't talk about anything. You get so much more information by asking these open questions and can quickly grasp the validity of someone with how much enthusiasm and detail they can provide.
One Size Does Not Fit All
One downside, though, is if they're shy, they would probably freeze, even though they might have better answers than someone who isn't.
The other downside is this will only work for companies that don't have a lot of applicants, like startups. If you're startup, your best interest is to get quality people, so white board interview problems will not work for you, sorry. And don't think you're slick with it, you're not google (yet).
But, big companies do not have this luxury, they only have whiteboard interviews as the only option to screen out candidates. Aside from acquiring good overworked modern-day slaves, it puts up a standard for people to follow.
Put Yourself In Their Shoes
You're Google, hiring almost 200K people across different continents. Half a million are applying. How on earth are you going to ask all these people a different "good" and actually "deserving" "unique" question? That requires something humans evolved on called communication. Some of us are better at it than others. If asked broad questions like I mentioned, some people are just good at it, and some others just freeze up and can't talk, so they fail. That seems unfair. You know what else unfairness leads to? Lawsuits. If you got big pockets like Google, you better be walking on eggshells to cater to all people and not offend anyone, or else, you'll be swimming in lawsuits. So you need a unified, standard way to screen everyone. Also, how do you make sure the interviewers are good? You simply can't. So you just set up a process in place regardless of the interviewer and interviewee, it works on both.
Also, you don't have to train interviewers for anything. They don't even have to be good communicators. Just have them ask a question that already has an exact, already solved answer. You can't use the technique I described for startups above, you can't conduct that on a massive scale and simultaneously maintain fairness. Plus, your good interviewers are busy writing code or architecting. You need them working, not interviewing.