4 ms·

> useless tests These tests aren't useless. Tons of candidates have never seen a REPL before and are totally unable to solve even a trivial coding assignment.

> useless tests These tests aren't useless. Tons of candidates have never seen a REPL before and are totally unable to solve even a trivial coding assignment. I suppose your company is too clever to waste their time on such useless tests? Who at your firm wastes hours interviewing candidates who have no ability to code?

StavrosK 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        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 9y ago
        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.

StavrosK 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        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.