I reckon that coding as part of an interview is really just to make sure the person isn't a total fraud. There's that guy who for some reason thinks he can nab

I reckon that coding as part of an interview is really just to make sure the person isn't a total fraud. There's that guy who for some reason thinks he can nab a high paid job by blagging it, and then there's the guy who thought he was a coder but it turns out that writing some VBA macros isn't quite the same thing. Those kinds of people will be found out immediately if you ask for a FizzBuzz type question, and that is maybe a reason to do it. Beyond that, there's no point. You won't discover whether the guy who passes is the kind who writes undocumented spaghetti, or if he doesn't know how git works, or if he doesn't know how to assess an OSS library. What seems to always work for me, having hired dozens of people over the years, is a technical chat. Tell me what's interesting. What's the difference between this language and that one? Why did you make the choices that you did? You talk, not me. Someone who can say substantive things about different techs has spent the time. Someone who has formed opinions has spent the time. Someone who's spent the time won't run out of opinions. I will concede that while this has worked for me, a hiring manager in small financial teams, there's a fair chance it won't work for Google. For one, nothing I've just recommended can be measured. It also can't be taught to junior interviewers, and thus relies a fair bit on the reputations of the firms on the CV for filtering. Finally, and perhaps most importantly, there's a big difference between the decision maker doing the interview and someone who is just an advisor (ie an agent) for them, in that the agent needs to have something concrete to say to his boss as well.