this is the in-depth reply that illustrates my flippant comment. there can be an inherent competitiveness in white-boarding interviews. the interviewer can implicitly want to show their superiority over the candidate. i think that's the core reason behind a lot of overly difficult problems being offered that have no analogous presence in the day to day work. how many times have you written a graph traversal algorithm on the job? or implemented a geofence in 45 minutes, from scratch, without a search engine?
i whole heartedly agree on the pair programming approach being practical and yielding good results. i think you can skip exposing the candidate to the internal codebase, and replicate an internal problem in a more generic and high level way.
>>> there can be an inherent competitiveness in white-boarding interviews. the interviewer can implicitly want to show their superiority over the candidate
This can be present even in non-FAANG interviews. Early in my career, I had an interview at a financial company and for a question about how do you style html pages, my answer was CSS and the interviewer expected something about ASP.NET webstyles. He was't ready to accept my answer saying you are a dotnet dev and should use ASP.NET functionality since it was more superior rather than CSS. I was like CSS is a web standard and anyone even designers can modify CSS.
So yeah, it depends on the maturity of the interviewer.
right — it’s certainly not FAANG specific but seems to arise from these styles of interviews. maybe it’s lack of interviewing training or standards? i think the standard now is, “pick your favorite hard problem and have a candidate do it on the whiteboard.” which presents this opportunity for an interview lacking compassion.
haha — my email is in my profile page if you really want to talk about it. i have interjected at previous companies where it was possible to influence the process a little bit. my biggest question would be “how could you do it differently than triplebyte when they first start?” they started by interviewing people themselves which is hard to scale.
i whole heartedly agree on the pair programming approach being practical and yielding good results. i think you can skip exposing the candidate to the internal codebase, and replicate an internal problem in a more generic and high level way.