If you're going to do a coding interview, the question should actually be pretty simple. No tricky things, no can really only do it if they learned about it once, something anyone who can program can do.<p>I do a problem with a defined example input, and a general idea of the transformation to be done with it, but allocate the first 15 minutes to the candidate picking the output format, and refining it. You could do a very simple output format with a potentially large worse case space usage, or you could make the output format more complex and get better space usage; anyway, as long as they've got <i>something</i>, after 15 minutes we can move on, and if they're not going anywhere, I can hint them to the simple solution and maybe they can refine it a bit, or at least discuss the problem.<p>Once that's done, there's two 15-minuteish coding exercises, and the key thing I'm looking for is that they can use the format they just created. Language doesn't matter, but the code should be self-consistent; also I give utility functions for I/O, so nobody has to remember the standard library I/O. Over time, I've learned to do the easier of the two exercises first, so most people can finish at least that one, if it's not in the target time. Also, I've learned that I can't expect any knowledge of bytewise I/O; some candidates just don't know what a byte is, so you have to explain it, sometimes a couple times, but many of those candidates end up doing pretty well, it just wasn't something that was ever previously important.<p>Having done the same problem over years with lots of candidates, I feel pretty well calibrated to figure out slow but good vs can't code at all vs having a bad day vs won't follow their own format. If someone is having a bad day, and you can tell early enough, the best thing is to try to make things go well as much as possible during your interview; if they're having a bad day, you won't get a conclusive evaluation, but if you can turn the day around a little bit, maybe they'll feel better and relax somewhat and the rest of the interviewers can get a more clear picture.<p>All this aside, if you really want the best people, you probably want to hire from your network, and then the interview becomes less evaluating the candidate, and more selling the candidate. Maybe ask them about real problems you're having, and see what they think and also if they're excited about solving your problems. It's less repeatable --- you want to ask about current or recent problems, which means candidates don't get the same questions.<p>You might object to me always asking candidates the same problem then, and it's true it's not an active problem, and it's also an area where 99% of things just use a library because it's complex, but it's a concept that has broad applicability, and I use a very simple form that fits in an interview, and most candidates haven't written anything like it before, which gives it a freshness.