We do live coding exercises as part of our hiring process, but we generally shy away from Algorithm problems and instead ask them to solve problems like: * Cou

We do live coding exercises as part of our hiring process, but we generally shy away from Algorithm problems and instead ask them to solve problems like: * Count the number of vowels in a string * Transform a dictionary that's key'd on file name, with the value as the file owner into a new dictionary with owners as the keys and their value as a list of files. * Deduplicate an array while preserving order in linear O(N) time * Solve a simple problem using a closure (You can even google what a closure is) We go out of our way to make sure the interview is conversational; we talk to candidates like they're our colleagues. Too often, technical interviews seem like interrogations and I absolutely hate that. Candidates can code on their own laptops, ask us questions, and even google stuff. The only rule is no googling for the problem directly, but if you need to look up if some datatype has method X or forgot its signature it's not counted against you. The point of this is to just to do a basic smoke-test of the candidates programming skills. They don't need to get them all correct, but they should be able to solve at least 1 or 2. If they can't, then we politely end the interview. The rest of the interview is talking about coding, projects they've worked on, challenging and interesting problems, wish lists, and for more senior people architecture/planning, and a mock code review: we give them some bad code and ask them to give feedback. The entire process takes about 3 hours.