Ask HN: Can engineers from Google or Facebook solve whiteboard questions easily?

It's that last one that I think algorithms/white-board coding entirely fails to see the trees for the forest. You would think as an industry that seems to lean heavily towards introverts and people in various places on the autism and social disorder spectrums, that the industry would not rely so much on high-pressure inter-personal communication scenarios for interviewing.

Which is not to say that soft skills don't matter: they absolutely do, and most industries their job interviews are much more highly focused on soft skills. The point is that you are testing soft and hard skills together in a highly charged mix.

If I want to sit down and play with an algorithms problem, I'd probably like to do it in a quiet room with no one watching/looking over my shoulder, and if I'm writing anything for most of the thought time it's scribbles and doodles, not algorithm-appropriate diagrams. "Programmer's Tourette's" of a sort imply that I'd probably be swearing at it for a while as I work to make sense of it. Asking a complicated algorithms question in a whiteboard scenario requires me to "play-act" a more linear string of thoughts, which diagram nicely, than I would use in an actual puzzle situation, while trying to be personal/presentable/well-spoken. I can certainly do that, but that mix of social skills and problem solving skills is very rarely needed in real life where we mostly compartmentalize such things to meetings versus coding time.

Then add in the ticking clock anxiety, that I don't feel like I have time to breathe, much less patiently tease out a solution to the problem.

Then add in the exhaustions of jet lag and trying to do all of that for 8 hours.

I feel like a lot of these sorts of questions, I could solve the problem rather well on my own time, or I could be a great, sociable, and presentable candidate with smart thoughts but maybe not immediate solutions. You want to the test for the former, but present only situations where the latter works well.

I feel like I'm not far from a baseline human on inter-personal skills, and even am somewhat more extrovert than the average programmer, and knowing that I have problems doing "both" the soft and hard skills for an eight hour interview day, I sometimes can't imagine how anyone in this industry gets hired because it's almost like we've optimized interviews to be intentional hells for programmers by trying to test hard skills in high pressure soft skills environments.

I very much believe that the technical interview culture as it exists today meets the definition of hazing [1], and that one day the industry will look back on it and wonder what was it thinking.

[1] https://en.wikipedia.org/wiki/Hazing

My point was addressing the frustration with whiteboard interviews. It sucks to feel qualified and still get rejected. That doesn't necessarily mean they all way outclass you (they might!). If you treat interviewing like applying to colleges (3 or 4 big schools, a few backups) you're going to be a lot less burned by the system.

Sure, hate the system. But we've covered blaming the interviews. But that's not helping anyone right now.

As to the model, in my experience if you do sufficiently poorly on one and leave any doubt on another no one interview will save you. Sure you could add in the probability of failing two vs one. But that's numerically the same as just making that .95 a .9. It's a made up number, so what. The conclusion is kinda the same: doing pretty well can still lead to a failure for any given job, but you can still do pretty well in your job hunt.

1. having seen the specific class of problem before and knowing, as you're writing that solution, to stop and switch to the class of solution you've seen before that would solve the problem more efficiently, or

2. finishing the obvious, poorly performing solution and then optimizing it like an real engineer would do. The problem is that there's not going to be enough time for this to occur in the interview session. The act of writing out the poorly performing solution will consume the entire session.

Therefore, the only way someone would have passed your interview question would have been if they had seen this class of problem before.