The way I see it, you can master coding interviews by practicing solving small problems quickly under pressure. But this kind of practice takes time--time that

The way I see it, you can master coding interviews by practicing solving small problems quickly under pressure. But this kind of practice takes time--time that is probably better spent mastering the skills you'll use day to day. The studies that get brought out every time this comes up are very clear. The best predictor of future success is a work sample test. Solving a bitesize problem in 20 minutes while someone watches over your shoulder is not a work sample test--it's about as far away from a work sample as you can get and still call it programming. At the very least why not let the candidate work on the problem on their own for 30 minutes and then check back in. I've said it before, the best interview process I've ever heard of is this: Pair the candidate with an interviewing engineer, give them an hour or two to solve a problem as a team. The interviewer isn't an adversary; their job is to assist the candidate like they would if they were working on a real problem. Repeat this process if necessary. Get everyone together and talk about past projects the candidate has worked on. Have the interviewers evaluate the candidate, and make your decision. You know whether the candidate can code, and you've removed the adversarial nature and unnecessary stress from the interview process. Most importantly, you got to see them work in a much less artificial environment that's closer to what they'll be doing day to day.