I went through a round of resume filtering and interviewing for interns recently, but I'd use a similar process for FTEs (just less lenient probably). I mainly

I went through a round of resume filtering and interviewing for interns recently, but I'd use a similar process for FTEs (just less lenient probably). I mainly used the Github profiles (for those who had them) as another seed for questions besides the resume itself, and it could give me a feel for how well they'd do on our simple coding challenge. For example one candidate checked some API keys into his projects, those are generally supposed to be non-public. I asked about the dangers of accidentally committing private keys in general and he talked about AWS keys and relayed a story of compromise that happened to a friend, then I asked what a main problem of checking in API keys could be and he mentioned rate limiting denials. So he understood the problems, I asked why he had API keys in some of his repos, turned out to be he thought he had disabled the ones that were checked in (at least one I tried wasn't) and they were for hackday projects anyway. With some context on it, and other discussion, all in all I was happy with him. I try not to let presence or absence of Github matter (and in general I try to differentiate on common information rather than lucking out to see a very negative / very positive trait in 1/10 candidates that I wasn't explicitly looking for), but I have to admit I like to see a link and like to see at least one project on it of any size and not just a sea of forks with no clear individual contributions. Resumes seem to correlate with coding performance terribly, at least if there's public evidence you can code (I'm not too picky on code quality, that's what reviews are for and drive-by open source reviews are non-existent) I don't have to spend as much effort verifying such in an interview. I'm not looking for rockstars. Using the classic trade ranking system, there are apprentices, journeymen, and masters. Journeymen are essentially interchangeable for most normal tasks starting from scratch, that's what I want to hire and work with most of the time. I can live with a sharp apprentice, especially if the apprentice is pretty skilled in the usual domain we already work in. Since I'm not a master myself, and I can think of no more hostile and futile way of attracting them than standard software interview practices I'm forced to somewhat conform to, I don't try to get them.