[StavrosK]

If someone has never seen a REPL before, it'll take us less than 90 minutes to figure it out, so we don't tend to waste applicants' time with those.

Going through someone's Github (or any other project they feel is worthy of sharing) and asking them questions about why they made the decisions they made has been orders of magnitude more illuminating than asking them to come up with an algorithm for solving the subset sum problem without Googling.

[nilkn]

But now your process is heavily biased against folks whose work has primarily been for their current employer, and they don't have any reasonable side projects to walk you through.

[StavrosK]

How so? It's not like I say "oh, that's too bad then, sorry". It just takes longer to interview those candidates because we don't have that shortcut.

[nilkn]

My fear would be that you wouldn't have a rigorous, well-tuned process for those folks, so there could be a lot of noise or randomness in their evaluations. And it could be very hard for you to compare them with the folks with extensive GitHub portfolios and resumes.

[StavrosK]

Perhaps, but what's the alternative? Don't look at anyone's OSS projects (and lose a LOT of valuable information) because it would put the people who don't have any at a disadvantage?

[acdha]

I think the main thing would be consciously correcting for that: the real value is asking about design decisions — it's my favorite technique — and just making sure that it's fully normalized that not everyone has those out in the open.

It's still easy to spot the liars — e.g. I've interviewed people who worked at the NSA and even they could talk about the skills they used, just not which projects or data — and the process of deciding which things to talk about is a pretty good way to explore their communications style, too.

[StavrosK]

Yes, that's what I generally tend to do. I present them with a scenario or a problem and have them walk me through how they'd solve it and what their tradeoffs would be.