Hacker News Reader

Comment by remoteorbust | Hacker News Reader

> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard.

What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams?

I hate this concept that if it's not typing code into an editor then it's not "real work".

I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low.

Now if this particular skill isn't interesting to an employer and they'd rather spend the time talking about some other candidate capability, that's a whole different story.

View on HN

Ugh, communicating with a whiteboard has no overlap with developing a solution to a completely unexpected quiz (if you didn't cheat) on a whiteboard in front of someone scrutinizing your every move with your future career on the line.

Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not.

If you defend whiteboard leetcode using this excuse you are deluding yourself and you are part of the problem. The only thing the modern FANG interview hires for is people that can solve algorithms problems in a silo under pressure. No checks for software engineering skills, collaboration skills, testing skills, reviewing skills, and on and on...

The whiteboard interview is why so many engineers unexpectedly suck.

Agree with most of what you said except the conclusion.

The reason many engineers unexpectedly suck is because it’s a high paying job where performance is difficult to measure let alone predict.

White boarding interviews are a symptom of the problem, not the cause of it.

> Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not.

They you are asking the wrong questions. I use whiteboard for developers, and for junior developers I give them a simple task such as reverse an array, turn a string into a palindrome (and explain what it is if they don't know). If they want to be a developer they must be able to solve those simple tasks. I don't really care how, as long as they think loud. Then I use it as a starting point for enhancement discussions, perhaps stack/heap questions, recursion, assignments ect. During all this I coach them, teach unknown concepts in simple terms - this is what they can expect when they ask their mentor a question so in that sense they get a feel for us too.

Some argue that it's still not good, and that we're filtering out people that work best alone. That is true, but that is by design. We work as a team, having 10 individual developers not working together unless forced is an architectural nightmare.

If you think someone looking over your shoulder while you solve a problem with your future career on the line is anything like "working as a team", I weep for whatever work environment your developers work in.

So a simple problem solved while communicating, asking for clarification, and telling your thoughts is "someone looking over your shoulder while you solve a problem"?

I'm not asking them to impelment van Emde Boas tree because I spend countless of hours implementing and analyzing it getting my degree. I ask them to turn a string into a palindrome, or return the sum of all even index in an array of ints, ect. They're free to ask all the questions they like. It's a litmus test to see if they know simple programming, akin to seeing if a contractor knows how to drive in a nail using a hammer.

Is it high pressure while your future career is on the line? Absolutely, but they are not special snowflakes, and it's the case for any interview for any kind of position. I'm not going to throw thousands of dollars after someone just to figure out that they have in fact never written a functioning for loop.

I always thought it would be a good idea for the interviewee to also come up with a question and then have the interviewer try and solve it with their guidance. I imagine it may be more helpful than the other way around.

If the interviewer leaves frustrated because they couldn't solve anything and it was a mess, or the question was formulated terribly, or the interviewee was under prepared, etc etc, then it provides a lot of insight into the capabilities of the interviewee. It almost provides more insight into the qualities required of a developer than just putting them on the spot.

>I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low.

I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in a team meeting with someone from product who will watch your demo of a potential new project/idea/concept.

We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as more of a conversation, we're less concerned about getting to the "right, fastest, or most optimized" answer. Not a hard problem, no mindgames, no syntax rules, and no complicated pre-known algorithm work other than an if and a loop. Let's just talk about some pseudocode.

We've never rejected somebody for having a "bad" answer, because they were able to at least talk about what they're doing. We have had people flat out refuse to even try, and that seems like a pretty big red flag.

That sounds like a much better way of handling a whiteboard problem.

In my most recent on-site interviews, my interview would be in a room with full floor to ceiling glass windows, the next interviewer would come in, ask one or two personal questions, and then either cut me off after a couple minutes or just simply say "we're going to move on to the whiteboard now, do this". Meanwhile people are walking by staring into the room, looking at the whiteboard, etc.

Which is just too rigid, IMO.

When I interview a candidate, I want to know that they'll be able to work together with myself and my current teammates as a team. So I would rather do something similar to what you described.

Yeah, that's the trick. It isn't a technical exercise really. Its really a communication/team fit test.

Every time an interviewer has told me something like this, they then nitpick syntax and appear to be primarily concerned with "does my whiteboard code compile" sorts of problems. And getting stuck / asking for help feels like I get docked for getting stuck. Same with less optimized. So it's hard to trust such an explanation - clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options.

So it seems to me entirely reasonable to still be nervous.

Mind you, I don't have a better answer, but I don't think just explaining that suboptimal is ok and it's a discussion really helps.

This is generally the same experience I have had. I'll even talk through the assumptions (e.g. "Can we assume I know how to do argument checking?") and then after I've done the heavy-lifting of the problem-solving I'm now discussing how I didn't do something I brought up as an assumption.

Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.

Writing down the assumptions can help.

Even if you didn't say

> Can we assume I know how to do argument checking?

I would probably question you at some point about a particular value of an argument and almost all candidates will get points for thinking out load that of course a NULL would get it crashing and that a simple check could stop it. Then it leads to discussion about how it should be handled. Sometimes a NULL means the program should cast an exception, other times it should just return without any side effect.

IMO the hate for whiteboard questions is really a symptom of poor interview technique.

Maybe I was just lucky, but I interviewed with google and dropbox recently and both companies gave me laptops to type in, did not ask me once about if my code compiled, didn't comment on my style, nor did I have to perfectly know the standard library (for google, they told me to just guess at the random library functions and I also forgot some of the functions names for a set. For dropbox, one of the guys re-explained to me semaphore functions and how they worked since I forgot since it had been so long since I used them in college). I passed both.

Granted, I will give you that optimized code has definitely been important. One of those interviews even had me use a bit array (at least I think it was that) to efficiently a store a list of booleans but at least they gave me the relevant function calls to use an already implemented one.

All these discussions conflate a related, but separate problem with tech interviewing: most tech interviewers don't have much experience interviewing, and have never had good coaching on interviewing, and as a result mostly suck at it.

Picking on whiteboard code for not compiling is not good interview technique. But it's also a common enough failing that it's hard to say a bad interviewer in that regard means a bad workspace, unfortunately.

Bad workplaces are so common though that it’s a perfectly good heuristic to guess that if a place asks you to do whiteboard questions it’s a bad engineering workplace. You’re not missing much by passing, and the heuristic probably won’t be wrong much.

I guess you think every major tech company is a bad engineering workplace? Seems like a broad brush.

Is it even disputed anymore that the experience of working at the big tech companies is abjectly awful? I mean, you gotta work somewhere and they “are fine” and you might as well try to get paid well, but that’s a far cry from a workplace that stands out as good.

The only place I’ve worked that was “good” instead of “treats people poorly but where else are they going to go” was a small, boutique financial company.

Small companies that are randomly led by non-dummies are the best, but are exceedingly rare. Out of the vast majority comprising the other stuff, it’s mostly all so miserable that you’re doing yourself a favor to skip it unless the pay is some dramatic increase for you or you otherwise have some emergency requiring you to take some job.

Of course it’s disputed. There are lots of happy employees of tech giants. Any company with thousands and thousands of employees is going to have a wide variety of teams of varying qualities.

(And yeah, the pay makes a difference. Not a lot of places where you can make a few hundred thousand dollars a year.)

I work for a large tech company and don’t know of any company like that with a large number of employees happy with their company.

(I’m making a distinction between the idea that a job “is fine” where one “is happy” merely because the culture is at least not worse than elsewhere while the pay is better vs actually feeling positively about one’s company’s culture and corporate behavior.

For example, my friends who work at Facebook are “happy” with their jobs, mostly because of pay and because they know if they switch to other companies, politics, corporate misbehavior, etc., will just continue. But these same people tell me frequently how sad, upset, soulless, disappointed they regularly feel because of their employer.

That feeling I think is extremely widespread in tech, almost all employers. That’s the only part in my viewpoint that matters for whether someone “is happy” at their job, and it’s that type of bad culture I think can be easily flagged by little stuff, like bad whiteboard interviews.)

I blame the modern attempt to turn software developers into assembly-line workers. With sprints and tasks and momentum and a million tiny cuts that take the innovation out and replace it with anonymous criticism and process over product.

I largely agree. Modern companies are set up to cargo cult lots of process and pay lip-service to innovation while taking extremely risk-averse and conservative approaches to practically everything they do.

Nobody has any idea what’s going on; nobody has clarity. And when someone does have clarity, middle management is only interested if they can set it up like a battery to harvest credit from. If they can’t, their incentives are usually more aligned with intentionally abusing process to “manage out” innovative people.

seems true

I wouldn't go as far to say whiteboard interviews == bad company. I will evaluate the company if a whiteboard interview is run poorly however and consider it a bullet dodged.

going through / having just gone through this process this is where i've basically ended up as well... crappy interview experiences are universal enough that they don't disqualify a company automatically (though obviously i'm not terribly fond of them :-).

the one thing i'd add is that i do take particularly thoughtful / empathetic interview processes, interviewers who actually know and understand the question (rarer than you'd think), etc. as a fairly strong signal, as those sorts of things don't just happen by chance-- they are the byproduct of a culture of thoughtfulness (and thoughtful people tend to be thoughtful about most things).

I caught an interviewer red handed once by handing him the marker and asking him to show me. He tried and failed and then his coworker tried to fix his mistake and failed.

Ya I did not get that job lol.

Good for you for asking. As an interviewer myself I wouldn't dare ask a question I couldn't answer.

By the time we get to the whiteboard problem we've already assessed technical skills as well as we can. The whiteboard problem is to test their fit on the team. It has worked well for us and certainly weeded out some people who could have been problematic culturally. Is that a "failing?" Maybe we lost some more technically skilled individuals that way, but our team isn't exactly lacking because of it.

> clearly my interview would be better if I came up with the perfectly optimized solution, or gave a lecture on the options rather than trying to discuss options.

Right. And a competency based interview goes better if you have a perfect example for every question. But it isn't an auto-fail if some of your answers are mediocre

Personally though - I'd rather hire someone who is able to properly communicate their thought process over an imperfect solution, than someone who was unable to discuss/explain the perfect solution they scrawled down.

Give feedback to the company.

When I give interviews candidates often say they don't remember some API. I tell them I don't care and they should make something up and I'll figure out what they are doing from context. The only time this burns candidates is when they clearly don't understand an ADT well enough to give it a sane interface.

As a candidate, to me, that sounds a lot like, "we're going to do the same things we would normally do in a technical interview, but we're going to evaluate you based on random, arbitrary, subjective criteria that you will never know about rather than your actual level of skill."

I'll bite: yes, if there's rapport and the candidate doesn't feel caught off-guard or needlessly pressured. If it's whiteboarding like you'd whiteboard while on the job with your coworkers, that's a good idea that can tell you a lot about a candidate. Unfortunately, in my experience, that doesn't seem to happen very often. A lot of people seem to treat it as an adversarial process or expect, for lack of a better description, a "performance" over contrived problems.

I've had my share of the second kind, which were without exception some of the most unpleasant interviews I've ever gone on.

> We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them. This is meant as more of a conversation, we're less concerned about getting to the "right, fastest, or most optimized" answer. Not a hard problem, no mindgames, no syntax rules, and no complicated pre-known algorithm work other than an if and a loop. Let's just talk about some pseudocode.

If only all interviewers were like you.

We do the same thing as well. As long as the candidate can explain their abstractions in pseudo code we are good. We also keep to a 1-1 between interviewer and candidate so that the candidate isn’t intimidated.

I’ve interviewed at Facebook as well and although the interview was not successful I have never been nitpicked about syntax and compilabiltiy/runnability of my whiteboard solutions. I came off with a very healthy appreciation of the way they try to engage the candidate and reduce stress.

You are asking the candidate to compartmentalize their thoughts to solve a toy problem during a period of time when they are attempting to put various nascent clues about your organization together in order to form a better understanding and to identify how they can provide value / fit into the flow.

Fizz-buzz tests have their place, but I think an onsite interview is past that point. In general I have found that white board exercises don't allow me to either understand or convey how I can apply my expertise to provide value for the organization.

Agreed. For us this is a communications/team fit exercise and not a technical exercise. It has done a good job of filtering out bad fits, like the guy who refused to talk to the women on our team regarding anything technical.

> We do whiteboard problems, BUT we also emphasize beforehand that the interviewers in the room are there to work through the problem with them.

Except at the end of the day this is an interview, you are judging their answers and evaluating their performance. I have been part of white boarding sessions like this and it does not reduce anxiety and still feels completely removed from what I actually do on a daily basis.

Not judging their answers. The only thing we're judging is their ability to communicate in a group setting similar to what happens on the team on a regular basis.

We at least on a weekly basis somebody has some small problem they need help working through, it generally ends up being diagraming or pseudo-coding to figure out the best approach. If somebody can only participate by hiding in a corner typing out code, then the process worked for both sides.

Well, when you first start your job, you won't really know the people you are working with so I don't see how it is that much different.

Incredibly different.

I highly doubt a normal engineer is going to be giving a demo to their team with high stakes in the first three or so months. I understand if they're possibly a senior engineer, architect, or lead of some sort because they were probably hired with a plan to spearhead a specific project.

I'd say in the average case a new engineer will have enough time to at least break the ice with their new team before being put into a high pressure situation.

I gave a demo of my intro project after a month to my 100 person org at my last company and I was a new grad. In fact, when I was an intern, all interns did project demos at the end of their internship.

Was the presentation of that demo standing between you and being fired or keeping the job?

Was a hundred K on the line? Clock ticking? Random subject you couldn't have/hadn't prepared for? :D

I communicate my ideas using a whiteboard too. But I never produce those ideas using a whiteboard in front of my coworkers under pressure of being fired.

Well this is hardly the fault of white board interviews. That’s just interviews. Any interview (regardless of the style) is going to be in front of “coworkers” and “under pressure of being fired.”

My experience agrees with this. I am a different, significantly less comfortable person to be around when strangers are asking me so many questions about myself. I think it’s just about the worst way to get to know me.

When I get hired this way, I always feel a little bit of guilt because I know they actually hired somebody else.

What can be done? I’m not sure, but I can say one thing: my level of discomfort is multiplied by the number of strangers in the room. Does this ever get considered with interviews?

I am far more comfortable coding in front of 1 or 2 people who each give me a little bit of background about their coding experience; just so I know. If they are experienced engineers, it’s probably not going to change what I say aloud, but it just makes me more comfortable. I guess more overlap of technologies in our background does help. It’s nice to not feel pressure of worrying if my solutions reflect general programming conventions enough to be language agnostic. I have never really used Java, for example.

The "produce the ideas during the interview" part is the fault of whiteboard interviews. There's nothing that says an interview should cover brand-new material as opposed to material the candidate is supposed to be familiar with.

If communicating ideas is part of your job, I'd bet any amount that you decide what ideas you want to communicate well before you do the actual presentation (or other physical delivery of the ideas).

That’s just interviews.

Nope. There was a great submission a few years ago about a guy who applied to two categories of jobs: management and software development.

In the SD roles, everything was oriented toward rejecting him. Any possible "red flag".

In the management roles, the interview was focused on finding areas where he could contribute to the company.

Whiteboard interviews are a problem in and of themselves, and the propagate terrible attitudes into the rest of the interviewing process.

hfdgiutdryg any chance you can find the link to that submission? It sounds fascinating, and I couldn't find it via HN search.

Then test that. Having someone code on a whiteboard, even if they are explaining what they are doing while they go along, is simply not the same thing as being good at using on the fly visual aides while communicating. In any case, that isn’t coding either.

You have 40 minutes to make a slide deck that explains bloomfilters and 5 minutes to present in front of the director of engineering.

That is the same as saying who can code the fastest rather than who does the best job. But at the PhD level there will be a presentation given regardless.

It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything. It's one-sided combat where someone with a secret tries to get someone who doesn't know the secret to regurgitate the secret, on the spot, while pretending that s/he didn't memorize the secret in advance while cramming a great big "Cracking the Programmer Secret" book to prepare for the entire silly exercise in Kabuki theater.

If you want to test communication skills amongst programmers, I dunno...ask them to write something in coherent English. Or here's a crazy thought: ask them to document some code. I guarantee that 80% of working "rockstar coders" will fail (but not before whining, crankily, about how unfair it is that you would actually make them do such a useless thing, since, y'know...never actually documents anything IRL, dude).

Programmers like whiteboarding because it lets them believe that interviews can be reduced to purely objective functions, and because GooAmaSoftBook does it. They're too scared to deviate from the pack, lest people think they aren't as "elite" as everyone else.

or do a code review

Indeed. Or give a talk, or write a design doc, or...so many better options, all of which could be balanced out across a day of interviews.

Think how much you might actually learn about a candidate if your interview process replaced a day of solid whiteboarding with a code review, some pair programming, a session of documenting someone else's code, behavioral interviews, etc. It's almost as if you'd be treating them like a...person!

> It's bizarre to me that you think that whiteboard coding tests "communication", in any way. It's not like a presentation, or anything.

I feel like we're probably at an impasse if I can't convince you that a whiteboard is a decent medium to communicate ideas around datastructures and algorithms, but I appreciate your point of view.

I can only say my experience, which I hope you will take into account as one anecdote. I don't read books about "cracking the coding interview" or do leetcode or hackerrank. I left school 14 years ago or so my stash of cs trivia/secrets/gotcha isn't particularly full. I've done whiteboard interviews where I come up with at best a naive solution.

And yet I've received offers for fairly senior engineering positions at Amazon and Twitter and (hopefully tomorrow) from Google. Most of the whiteboard interview isn't even around the code, although that's a small part. Most of it is analyzing the problem, discussing constraints, discussing tradeoffs, walking through data structure manipulations, drawing arrows and boxes, that kind of stuff. Some code, maybe 30% of the interview. I just keep having this experience where nobody wants to play the gotcha game, they want to know how well I can communicate while solving a problem and they think they get that information out of the interview (I agree with them).

That experience makes it hard for me to understand a viewpoint that believes that whiteboard interviews are about memorizing secrets in advance.

Have you considered that your experience interviewing at these places might have been atypical?

Every set of interview prep material I've seen from Facebook, Amazon and Google recruiters asking me to interview in the last 3 months has included links to things suggesting "cracking the coding interview" is a good start and pointing to similar docs otherwise.

> I guarantee that 80% of working "rockstar coders" will fail (but not before whining, crankily, about how unfair it is that you would actually make them do such a useless thing, since, y'know...never actually documents anything IRL, dude).

Are you sure you're not just replacing one stereotype with another here? Do you think it's fair to say that 80% of people who do well at whiteboard coding value documenting their software so little that they'd be fail at it while disparaging the concept?

I think that was hyperbole for emphasis, not a strong generalization as you imply. I've met and worked with plenty of programers up and down the scale of ability who think "code is self documenting."

There are plenty of things one can gauge candidates on via the whiteboard. System design, application design, psuedocoding implementation (or real coding, if necessary - it should be natural flowing from psuedocode to implementation though), problem solving with visuals to denote intuition...the possibilities are vast.

There seems to be a bunch of ingenuous assertions here that is characteristic of someone who doesn't think one should have to prove oneself. I'm at a FAANG and we don't even ask anything crazy hard for algorithms/data structures like Google or Facebook does, but our interviews still manage to be intense for technical and soft skills - they will challenge even strong candidates and one cannot pass the interview without displaying strong technical acumen or communication skills.

There is so much more to technical assessment than just coding. A whiteboard is just a standard medium for communicating ideas in a collaborative manner that still works the best for any sort of deep collaborative design when compared to any other medium so far.

The point is that the interview style in question overemphasizes on-the-spot responses. How is prowess in a game of "gotcha" an important indicator of engineering skill?

I tend to agree with (what I think is) the sentiment of some of the respondents in the article: if your whiteboard interview is a game of gotcha, then the problem is your interviewer, not the whiteboard.

I think the complaint that programmers pretty much never have to think about code under pressure is a fair criticism. The whiteboard really puts you on the spot. But if it's your company and your hiring managers are playing a game of gotcha on the whiteboard, you need better interviewers.

in a sense, I agree. this is a signal to the candidate that the interviewers do not fully understand what they are measuring.

which also means the team might consist of people selected by using this metric. this is a good signal ;-)

State dependent learning is a bit of a factor too. I can count on one hand the number of times I’ve presented anything on a whiteboard at work, yet just about every company asks these questions during interviews. A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in.

Whiteboard coding interviews are one thing that I have to go out of my way to practice for and get better at over time when interviewing (ie over the course of a few failed interviews). I don’t feel more skilled or smarter by the end of the set of interviews, but I inevitably do better at these kinds of problems. Should the interview be testing my competency at day-to-day work skills or how well I’ve practiced my interview skills, because whiteboard coding problems only achieve the latter.

> A screenshare would be a better representation of on-the-spot problem solving, if that’s what you’re testing, because I’m at least in an environment I typically work in.

I do coding interviews in the following manner: I select an interesting problem from a book. I personally complete the problem, measuring what was challenging and the time it took for me to complete the problem. I check the textbook solution, making notes of how my solution differs from the textbook's. If I like the problem, and if it fits with the development role, I invite the candidate to bring a development laptop, I give them a hard time limit of twice the time it took me to complete it, and have them share their screen while they attempt to complete it.

Afterwards we test their solution, I ask them some questions about it. I grade based on code taste, the number of hints they need, and their completion time. All candidates for a position are given the same question. Performance in coding interview is about two third's of the overall candidate evaluation. The ability to sit down and write good code in a time constraint manner is a very important part of being a developer.

This would be a good method if your goal is to hire a carbon copy of yourself.

First, your definition of "interesting problem" probably includes a lot of personal biases. What you find interesting probably touches stuff you've had experience with, but just because you've done work on say, customized implementations of binary search, doesn't mean it's a good baseline for all developers everywhere. Maybe they've worked on different domains or solved different problems and can't relate to questions you personally find "interesting".

It'd be much fairer to select a boring question that involves standard stuff that everyone has to face at some point in their careers, like string manipulation. And even then, it just involve normal transformations ('look for and remove special characters') and not wacky, HackerRank-style rules ('no two bs after cs but before as').

I mostly agree with this approach. I think that you absolutely should be measuring the "boring stuff" because that's 90% of the work by number of hours spent.

On the other hand, I think there needs to be some proxy for "how well does the interviewee navigate complexity?" Because a programmer who does it well is far more valuable than a programmer who doesn't, and there's high variance on this between programmers and between fields of expertise.

The systems design interview sort of gets at it, and whiteboard interviewing often tries to get at it. I feel like I've yet to settle on an approach I'm happy with.

> Whiteboard coding interviews are one thing that I have to go out of my way to practice for and get better at over time when interviewing (ie over the course of a few failed interviews). I don’t feel more skilled or smarter by the end of the set of interviews, but I inevitably do better at these kinds of problems.

You have a good point, I noticed this about myself as well. However, I don't think whiteboard interviews are special in that regard. I noticed that I got noticeably better at the "sit down and code me a simple web API endpoint" interview, and I got noticeably better at the systems design interview, and so on.

I do think that whiteboard interviews tend to lean very algorithm-heavy, which doesn't reflect the role's actual day to day. And practicing algorithm interviews really does feel like an inefficient use of time unless your role truly demands algorithmic proficiency (like if you're a graphics dev).

> How is prowess in a game of "gotcha" an important indicator of engineering skill?

It's not; I couldn't agree more.

In real life when using engineering "skill", not only am I not anxious/stressed by trying to write on a whiteboard, but I'm using my laptop, with my editor, as well as access to man pages, docs, and google to look things up.

In addition to the overemphasis of performance responses, I think "how much do you know from memory with 10 seconds of thinking" vs "how much do you know with 10 seconds of google" is useless. The only fairly complex datastructures I can perfectly describe from memory are the ones which I used most recently...

"Gotcha" is about being adversarial. An adversarial attitude and a high-pressure situation are different concepts entirely.

> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams?

Perhaps it would be more effective to have the candidate whiteboard a concept that they are already familiar with, be it a high-level engineering principle or a system/solution they have built in the past. Attempting to solve a problem you have just been presented with AND communicating the solution effectively is a big ask.

That's an excellent idea. I'm in no way saying the existing method is perfect. Just that some of the things it tests around communication and being put on the spot and analyzing a problem in a way that is understandable to the rest of the room is actually a really good engineering skill. There can be other great ways to measure those skills.

I know my opinion is unpopular, but I sometimes do think I've figured out something other people miss. I think when it comes to whiteboard inteviews, candidates are often playing the wrong game. They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough. I don't think that's true, they are just trying to game the thing that's easy to measure.

In my experience with the "terrible" FANG companies, it's not about gotcha questions. I get the offers even though I don't often find a non-naive solution. The people I'm in the room with really do want to see my thought process and they really do want me to communicate the tradeoffs with them. People don't fail the gotcha questions because they don't know trivia or because they forgot a detail from their CS classes. They fail the whiteboard interview because they see an unfamiliar question and say: "I don't know that trivia" instead of drawing out possible solutions and having a conversation with their interviewers.

Thanks for elaborating so well on your initial premise, I think you bring up some good points about how this kind of interactive problem-solving can be an effective tool available to the interviewer. For better and/or worse, there's a reason why it's so prevalent now and controversial.

I'm inclined to describe it as a sort of interrogation technique, you're offering a stimulus (the problem) and aggregating a number of reactions to form an opinion, and open up new lines of questioning. Very delicate work.

I think problems arise when unskilled interviewers present an excessively obtuse problem to the candidate, then read far too much into their responses (this approach is also easily "hacked" by those who've memorised common problems of this ilk). To stick with my interrogation analogy, it's the equivalent of screaming in the suspect's face, noticing that they gulp before shifting in their seat and scratching their face, then deciding that "they must be lying".

They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough.

But ... if you read some of the feedback from interviewers at "those companies" that rely on these interviews, they say the reason they failed someone is exactly because they "didn't leetcode hard enough". It is manifested as:

"Well other candidates got the same solution as you, they just did it 10 minutes faster"

"You missed an edge case, even though your core algorithm was correct".

This is a huge issue with these interviews. It's all too easy for interviewers to evaluate candidates based on how fast, correct, neat or "complete" you answer was. It's easy and takes no time.

> "You missed an edge case, even though your core algorithm was correct".

That may have been a reason why I have failed some interviews but I feel like most interviewers are actually good about this and will say something along the lines of "what about this input?" where my code does not work and then I have that "oh shit, that won't work for that" and then I fix it.

Agreed, thats a disingenuous point. "It's not about getting the right answer but the way you think". I've never found that to be true. If you don't get to the right answer, you're gone. If they planned to ask two questions and you only got through one, you're gone no matter how you "thought" about it. A huge part of this is Leetcode practice. If you can't solve most algorithm questions on whiteboard in less than an hour (because you haven't practiced) then you won't pass any interviews.

I try to start there, but most candidates act shockingly uninterested in going into details of their past work. I've directly asked about what the interesting parts of a project were to them and gotten things like "I had to learn ES6 and I hadn't used much JS recently" without much elaboration able to be teased out.

If you can't give me good examples from your past, I'm going to throw my own questions at you. I tend not to do coding on the whiteboard, though. Lots more boxes and lines and schema and system interaction-y stuff.

That's an awesome idea -- as someone who rabidly hates whiteboard interviews, to the extent that I'm looking at the responses in this article as a note of who to consider applying with next, I would love the challenge of "explain a complex concept you're already familiar with". I've never gotten that in an interview before.

even then, this is not what's being tested with the whiteboard.

thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.

So if you're looking for someone who can execute both at the same time, whiteboard coding is ok?

If your looking for someone who can think, code and present at the same time, yes.

Coding on a whiteboard while being questioned by two or more interviewers isn’t really a true representation of a work situation. It’s always more stressful and some people thrive on it, some people don’t. Im not sure what the better alternative is to demonstrate verba/technical communication skills however. The problem is, it’s hard to figure out if someone is a good fit with just a couple of hours of vigorous questioning. Maybe that’s the problem. I’d say I’ve worked with plenty of colleagues where it took me weeks or months to fully appreciate how extremely valuable they are to the team.

I agree with the sentiment but find most of my whiteboard time concerned with a much higher level type of problem solving than writing lines of code or absolutely correct algorithms. I also mostly do it with colleagues I know on shared problems we are working cooperatively to solve. Where I’m using one with strangers I’m much more often working as an expert in an explanatory manner. It feels quite remote to my experience of solving an unknown problem in an interview situation.

Yes!

What you're testing is the ability to discuss a problem with your peers. That is the critical thing.

Do the whiteboard but don't make the coding the standard. Don't get too hung up on the details of the problem.

Make the problem easy but fuzzily specified.

VPE at Eaze here -

Clear and respectful communication is one of the most important skills for an engineer to have.

If you read the second half of my answer in the article I go into the communication side of things. In my experience there are better ways to evaluate a candidate's emotional intelligence and social skills than asking them to code in front of someone.

I'd say you should stick to your guns - I like your approach. Interviews are inherently adversarial: "are you good enough for us to hire you?", "are you better than the other 5-10-1000 candidates". As a result there's a built-in bias which makes whiteboarding a bad fit.

I've written code on white boards at work, and I've discussed about code on white board with colleagues or managers. It's not the same thing as during interviews. The schedule is never as tight, scrutiny is way laxer and the overall mood is completely different when I'm working with colleagues or even bosses.

I kind of understand why the BigCo's do it (they need a super rigid filter since they have so many candidates), but in their case they could select for people with the best pink leotard on interview day and they'd still get decent programmers, because their companies are in such high demand and they generally already control their markets (software, natural monopolies, etc.) and can afford to pay a ton so the competition would be cutthroat anyway.

>> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams?

In that case I would recommend reading the candidate's resume beforehand, look for prior experience publishing, presenting, or teaching and ask them about it.

Never seen anyone write code on a whiteboard at work.

Do write lots of sequence diagrams, block diagrams, ui sketches, arch diagrams and very occasionally someone might draw a data structure.

This. Plus network diagrams, message passing sequences, and first drafts of checklists.

I agree, and as an employer I find a happy medium is to test on a whiteboard, but be completely okay writing filler, a comment saying "code for this goes here", etc. So long as they're building the correct general approach, that's all I need to see.

Whiteboard interviews where the interviewer says "it's actually `.toLowerCase()`, not `.lowerCase()`, you fool!", or "oops! You forgot to `position: relative;` the containing element that you `position: absolute;`d below!". you're not testing anything useful. Maybe if we were still coding everything on punchcards and using massive user manuals, but docking applicants for things their editor would highlight or one ctrl-r on the page would find is ridiculous.

What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams?

This is incredibly common, and you tell the candidate in advance that they will be expected to give an n-minute presentation on a subject of their choosing (need not even be tech) so they can prepare.

Tell me this: when did a mob last ambush you at your desk and demand that you invert a red-black tree on a whiteboard that they happen to have with them right now? I'm guessing that never happens where you work. If it does then fair enough :-)

I think now a days, selection through the whiteboard process simply comes first to how much you grind leet code and the like.

Ironically this leads to min- maxxers who ignore a good chunk of their courses simply to master leetcode. My smartest peers are ones who work on interesting projects and research, thus never finding time to grind interview questions.

Then there are also companies that expect your white board code to compile and have perfect syntax, which imo is very unreasonable.

I don’t think there’s much criticism of those types of whiteboard interviews. I’ve had programmer interviews that involved sketching out a system architecture or database scheme on a whiteboard, which I think is perfectly reasonable.

It's one thing to do it with colleagues for whom you have rapport and the risk of saying something wrong is low. It's a different thing when doing it around total strangers and a new job is on the line.

How about testing architecture (and implicitly communication) in front of a whiteboard and programming behind a keyboard?

Reply on news.ycombinator.com