I prefer to ask the applicant to either submit code that they are proud of, or to do a small toy problem if they don't have anything they can readily share. The

I prefer to ask the applicant to either submit code that they are proud of, or to do a small toy problem if they don't have anything they can readily share. Then we talk through their code during the interview, asking them questions like: what problem were you trying to solve, did you solve it, what problems did you run into along the way, how would you design this code differently, and of course any specific questions if we find glaring technical issues in their code. I've found this approach to have a very high signal-to-noise ratio as it's virtually impossible for someone to talk at depth about their code if they don't know what they're doing. Also, you can't study for this type of interview, so you can't game the system.