[spike021]

>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.

[Tobani]

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.

[pkteison]

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.

[majormajor]

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.

[mlthoughts2018]

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.

[hobls]

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

[mlthoughts2018]

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.

[sam0x17]

seems true

[Yhippa]

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.

[keeganpoppen]

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).

[Tobani]

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.

[cakes]

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.

[hvidgaard]

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.

[pmiller2]

Writing down the assumptions can help.

[amzn_82582]

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.

[Ntrails]

> 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.

[UncleMeat]

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.

[spike021]

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.

[Tobani]

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

[itronitron]

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.

[Tobani]

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.

[philwelch]

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."

[zebraflask]

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.

[qudat]

> 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.

[Tobani]

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.

[dingo_bat]

> 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.

[gautamdivgi]

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.

[amzn_82582]

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.

[spike021]

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.

[mrep]

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.

[mixmastamyk]

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

[spike021]

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