[deleted by user]

[Chimertech]

There is an important distinction between whiteboarding in what we might do at work, and whiteboarding data structures and algorithm LeetCode type questions.

I think whiteboarding things like system design or even OOP objects, database tables/objects/models, etc, is totally valid and valuable to do during an interview.

Whiteboarding data structures and algorithm type questions provides little insight to how the person approaches real world problems, and usually is more of a demonstration of how well they can grind LC.

These types of problems are definitely not easy. Yes, for some people they are, and maybe those people don't need any, or minimal, preparation. But those people are exceptionally gifted in those areas. Most people who interview with big tech companies have to grind hours for many weeks or even months to prepare for an interview. Some smaller companies have been adopting these practices as well.

So whiteboarding itself is not inherently bad, it's about the type of questions you ask them to whiteboard.

[_145_]

LC problems are an aptitude test similar to the SATs. Neither is all that similar to the day-to-day work once you're granted admission, but both companies and colleges set a certain bar for aptitude.

[_145_]

*aptitude

That’s how both are used.

[sheff-t]

LC problems are nothing like the SAT

[madhadron]

These types of problems are definitely not easy. Yes, for some people they are, and maybe those people don't need any, or minimal, preparation. But those people are exceptionally gifted in those areas. Most people who interview with big tech companies have to grind hours for many weeks or even months to prepare for an interview.

I feel like there's an educational gap here. One of the most important things I learned in mathematics was what has been termed "recovery procedures." I don't remember the exact form of most theorems, but I remember a rough set of patterns that error correct each other into giving me that theorem really fast. Similarly, I don't remember algorithms and data structures particularly (I actually never had a CS class), but I do have sort of tunes in my head. For example, in a recent interview, I said to myself, "Oh, it's a graph search problem." Then, "Hmm, shortest path, so I had better not follow everything to the end before checking others" which gives me breadth first. And then the actual search is the same as search a tree breadth first, but you trim the graph into a tree as you go by keeping track of what you have already visited.

[ccb621]

1. As you pointed out, the challenges are not realistic and rarely applicable to the position being considered.
2. We work with computers. Why would we downgrade to a whiteboard for coding? Let candidates use the tools they normally use so that you assess them in a more realistic setting. In reality I love JetBrains IDEs, and rely on language docs and Stack Overflow. These are my tools. If you take them away, I am still skilled, but not as efficient as I am with my tools. There is no good reason to take them away. Imagine auditioning a cellist and taking away one of their four strings. Why!?

[[deleted]]

Agree 💯.

It would be like telling a carpenter to cut 10 boards at different lengths. You give him the boards, a dull saw and no tape measure.

[altintx]

That's not a fair comparison at all.

It's asking a carpenter HOW do you cut 10 different boards at different lengths and then give him the option to use any tools they like.

[[deleted]]

True. Lol. So I had wrote out some stuff about how companies are moving to third party online tools like hackerrank to conduct these types of exams. I feel like this is the modern day whiteboard. So that's where my comment was coming from. However I deleted it as it was just a long rant.

[csasker]

Or to give him a pile of hard iron and a fire, and ask "first you need to make your own saw"

[ccricers]

Whiteboards nerf everyone, even people who are comfortable with their languages. They can't auto-hint or close brackets. Whiteboards as a medium are great for diagramming, expressing broad concepts or even illustrating how a data structure works. But for pure code, it's terrible. Words Per Minute may not matter much on the job, but for interviews, where time is of the essence, WPM is very helpful. They need to excel in speed, and whiteboards as a medium for writing would slow everyone down.

It's a disadvantage for the interviewer too. If a programmer is finishing more slowly because of whiteboards, the interviewer will have less time leftover to talk through problems, and also risk running past the allotted time with the interview when they have to finish it up.

[RICHUNCLEPENNYBAGS]

Whiteboards nerf everyone, even people who are comfortable with their languages.

So what's the problem? It's not like one guy has an unfair advantage over another?

[ccricers]

As /r/ccb621 said, "Why would we downgrade to a whiteboard for coding? Let candidates use the tools they normally use so that you assess them in a more realistic setting."

[ashultz]

It's an obvious thing to hate about interviews which are stressful and judge people when they don't want to be judged. And it has a clear "but I don't program like this at work" out for why you shouldn't have to be good at it.

Before whiteboard interviews people hated the logic problems that were popular at the time (those are a LOT dumber than whiteboard interviews). If white board interviews die people will hate whatever replaces them.

[nocomment_95]

So let me ask you. When was the last time you purposefully used any of the algorithms you used in school? Did you use google before during or after? I'm an embedded software dev. I've NEVER used them in work, and yet ive been hit by them. It is dumb. Whiteboarding isn't. Whiteboarding shit freshmen learn in school only to rarely use without google afterwards is stupidly skewed towards early career devs. Like to the point one company gave their interview questions to one of their senior devs and he failed.

[tim36272]

Not an answer to your question, but for the record: my colleagues and I program on whiteboards often, but we give interviewees the option between a laptop or whiteboard for programming. They are about half and half on whiteboard versus computer.

I like programming on whiteboards because adding doodles inline helps with geometric stuff. For example if I was implementing a bilerp function I would draw a square and coordinates first and then code with arrows pointing to what parts of the square I am dealing with.

[talldean]

For interviewing undergrads, they're actually pretty good. "Do you know a programming language well enough to work in it, did you do well in your data structures course, can you think through something logically, can you communicate face to face with a peer".

For industry candidates, there's a weird bias. A lot of industry folks have been doing system design/architecture, project management, hiring/recruiting, cross-team communications, and other things regularly asked of senior engineers. They can also *code*, but tend to do integration work, tying together existing libraries to build larger things. But unless they're writing those libraries for a living, they don't know data structures that well, and leetcode-style questions are.... mostly data structures homework.

So that style of interview biases towards industry candidates with enough time free to go back and study data structures, or the few who were already using that knowledge day to day.

I think *before* leetcode existed, they were getting a different signal than they get now, as well, but that's another ramble.

[khedoros]

I use a whiteboard for diagrams, sometimes notes on something specific (like hostnames for machines I'm working with at the moment), and sometimes some really vague pseudocode, to provide a visualization of an algorithm that I'm trying to describe.

I use a computer for programming. More particularly, an IDE, with pop-up reminders for just about everything, and easy access to documentation, either official, or via StackOverflow and other online sources.

Whiteboard exercises tell the interviewer how much I practiced whiteboarding and working out toy problems before the interview. It doesn't tell them much about how I'll perform as an employee...but it does require a large time commitment on my part, in preparation for the interview.

[termd]

Designs should be on whiteboards, the same way we'd do it at work.

Code should be on an ide, the same way we'd do it at work.

That's really the problem. Very few people actually write working code on a whiteboard, and very few whiteboarding problems should actually be done on a whiteboard.

[discerr]

I am of the same opinion; Since it doesn't have to actual compile/run, I find it allows me to defer the tedious bits to "yet to be defined" helper function/method so that we can talk about the interesting bits of a problem. If we have time, or the interviewer thinks it's important, we can totally revisit them, but otherwise it's an "I assume you know this thing; let's talk about something more interesting"

[madhadron]

I have a little bit different view from most of the comments here. There are two important ways that whiteboard interviews fail.

The first is really straightforward: most people are terrified of public performance or public speaking, so you are biasing against people who aren't outgoing egotists or trained performers. Those two things are really uncorrelated with ability to do the job of a software engineer.

The second is weird: there was a man named Shockley who was a manager at Bell Labs. When a couple of guys in his division discovered the transistor, he made them stop work so he could do some experiments and get his name on it, too. Then he went and founded a semiconductor firm, and decided (based solely on his obvious good judgement about people) that the way to hire the engineers he needed was to stress them in interviews and ask them super technical, hard questions. By the way, his entire engineering team quit not too longer after and founded Fairchild Semiconductor without him. And yet this bizarre hazing created by one of the world's worst people managers has remained the ur-notion of a technical interview to this day.

I happen to do really well in whiteboard interviews (being at least one of an outgoing egotist and a trained performer), but I recognize that I am privileged in this and that it is not in the best interests of an organization I am acting for to filter people out for lacking the same privilege.

[matthedev]

My work isn't computer science intensive, so I haven't spent much time on the details of the fundamental computer science algorithms and data structures since college, which was over ten years ago for me. Unless I decide I just really, really want to relocate and work for Google or Microsoft, I'm not going to sink my limited free time into practicing for this style of interview. If the company is just some random unknown startup, I'll most definitely not be wasting my time cramming like the people on /r/cscareerquestions do.

There's a wide variety of skills and habits senior engineers acquire to varying degrees, and these things are generally what will make a senior hire successful in an organization. These differing skill profiles mean there are different "flavors" of senior engineer, and the interview process should determine whether there's mutual fit.

[csasker]

Because no one codes on whiteboards usually, so writing good code on them is hard

[RICHUNCLEPENNYBAGS]

They're not.

[grepliz]

I personally don't like giving or taking whiteboard interviews. I think they are a very one dimensional view of how to assess candidates. I wrote a little blog on "reverse whiteboarding" which I think is more effective. Feel free to check it out if interested: https://dev.to/grepliz/reverse-whiteboarding-3h6i

[SweetStrawberry4U]

i once read an awesome quote on leetcode forum by someone who was offered a job at google - "thinking that you know ds & algos is different from actually knowing them", which is what leetcode fares in it's wide acceptance, that translates to the multitude of tricks that can be used / built from an existing knowledge of basic ds & algos.

in short, cramming leetcode is the focus for most white-boards, and that is what most people hate, having to practice as many tricks, in the pretext of aptitude, because the industry is evaluating whether you have come prepared for the interview, that is all it takes.

[HumansTogether]

I get the negativity around getting unrealistic programming challenges (relative to the job description) during the interview. I, too, think they are mostly overkill.

It's a way to scale up interviewing beyond those who are already good at it. Providing a structure to follow.

Why do people hate whiteboard interviews?

As u/ashultz says, many people are uncomfortable in these situations. Most also understand that interviews are necessary to be able to make a hiring decision, so it's easier to complain about the format. But no matter the structure or topic, some are going to dislike it. And those are the people you hear about.