A lot of people are really not good at conducting interviews. It's a hard skill, it has absolutely nothing to do with the rest of your job, nobody teaches you

A lot of people are really not good at conducting interviews. It's a hard skill, it has absolutely nothing to do with the rest of your job, nobody teaches you how to do it well, nobody checks to see if you're doing it well, and there's no good resources for learning. You get like a couple hours of "interview training" (50% of which is "here's how to not get us sued 101"), maybe some shadow interviews if you're lucky, and then they just throw you in the deep end and never check back. Whiteboard interviews do suck, but they exist because nobody's figured out a better alternative that works at scale. If you're a small company, you can get away with a less sucky interviewing method. If you're a massively large company, a lot of those fall apart because of various reasons (you can't ask for take-home tests because a significant percentage of your applicant pool will refuse to do it because they already have a job and stuff to do at home, you can't ask to "talk about interesting code/projects you've worked on", because either (a) they already have a job but can't show you any code because it's owned by another company, or (b) they just outright lie about everything and you don't figure it out for 6 months, etc etc). So whiteboard interviews suck, but we're stuck with them. There's some really weird things about conducting a good whiteboard interview which are not obvious 1. The candidate should not know if they're failing. The candidate should basically always get the sense that they're doing okay enough, even if they aren't. If the candidate fails your interview, but aces all the others, that's fine. Probably they should still get hired. But if the candidate fails your interview and feels really badly about having bombed it, then they just go on tilt and fail the rest anyways. That's not good signal, it wastes the candidate's time, it wastes the rest of the interviewers' time, all because you the earlier interviewer couldn't figure out how to not tilt the candidate. This is less important if you're the last interviewer on a loop. - so generally you want to start out easy, be really encouraging, and ramp up difficulty as they go on. Tilt is real, and it is not helpful in an interview situation. (Caveat to #1 - this is assuming you're working at a big enough company where your policy is to give zero actionable feedback to the candidate due to lawsuits, which is probably any large company. If you're not at a large enough company where this is true, why are you even doing whiteboard interviewing? Stop lol, whiteboard interviewing sucks) 2. You can't ask anything crazy domain specific. Sure maybe the specific super detailed queuing problem you're working on right now is fun, but it probably doesn't scale well to arbitrary-engineer who hasn't thought about queuing for a decade. Unfortunately this means you have to spend a lot of time figuring out what to ask, because the things you're currently working on are almost certainly terrible interview questions. Corollary to #2 - if you pick questions from online, or even from within your company, candidates will absolutely have seen them before, memorized them, and go from there. Your question needs to be able to be modified, expanded, and you need to know what it 3. Benefit of doubt should always go to the candidate. Forgot a library? You tell them the library, and don't count it against them. You are the candidate's StackOverflow for the interview, be reasonable. #1 up there is the hardest. Even simple things become very difficult to broach. If the candidate is digging themselves in a hole and you are having a hard time figuring out how to hint them out without psyching them out, feign ignorance about your own interview question and try to "collaboratively" work your way out of it. Sometimes it's impossible. Sometimes you'll get a candidate who literally does not know even the most basic of programming stuff for their own chosen programming language (obviously has not ever written code at all). I don't actually know how to handle that. Sometimes the recruiters will make mistakes and just send you candidates for the wrong job. So this isn't all-encompassing advice, because there's always edge cases.