Yeah, we definitely keep the work minimal up front. My process is to filter applications down to anyone who's completed the little 5-minute problem. Then I'll

Yeah, we definitely keep the work minimal up front. My process is to filter applications down to anyone who's completed the little 5-minute problem. Then I'll send each of them a quick note thanking them for their application, and asking a question about the answer they submitted. (Generally I can just pick from a small set of questions, since there are a very limited number of ways to solve it given the simplicity.) That starts a dialogue where I can learn a bit more about how they think, and they can see that I'm actually interested/invested. From there we make a shortlist based on those discussions and résumés (and cover letters if present), and move on to a few more involved programming tests, which try to replicate the actual kind of work that would be done here. (Each was taken from actual development or bug fixes we did in the past, then simplified and encapsulated to make a reasonable assignment.) We start with one of these and ask that the applicant pull the assignment repository, create a branch, make some commits as appropriate to solve the problem, and then start a pull request, which we review much like we would an internal code review. We also encourage them to ask questions and share thoughts throughout the process, as they would as a member of the team. Through all of this the goal is to show both sides what it would be like to actually work together. (As well as to demonstrate to the applicant that we are as invested in this process as they are.) I'm sure we do lose some good applicants with the initial quick question on the application, but it does serve to filter out essentially all of the really bad applicants, which gives me the freedom to give real attention to those who remain.