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'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.
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.
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.
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.
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.
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.
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.
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.
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.
I've had my share of the second kind, which were without exception some of the most unpleasant interviews I've ever gone on.
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.
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.
If only all interviewers were like you.
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.
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.
