3 ms·

> I see them the same way as standardized tests: without them, there's no good way to independently evaluate people's abilities How about straight up pay them

by avaer 9y ago

> I see them the same way as standardized tests: without them, there's no good way to independently evaluate people's abilities How about straight up pay them to solve a real problem with you? If they're clearly incompetent, cut it short fast (under an hour). If they're competent, you know that they're competent at the job, not at a whiteboard interview. Yes, I've seen this work at small-medium outfits. > I personally wouldn't want to work with someone who can't extract a path from a DFS What if this person hacks blockchain merkle trees for breakfast, but can't be bothered to regurgitate tangential runtimes of whatever algo you decided to ask about, which they memorized and forgot 10 years ago? I've seen this to be a nontrivial intersection of skills.

frandroid 9y ago
We'd turn on a dime and ask them to tell us about their merkle tree hacking on the white board, and the poke at it. The goal is to get a sense of people's skill, and we need to understand that they're not regurgitating something they've memorized ahead of time. Someone we interviewed last week was hoping for fizzbuzz and couldn't answer an equally simple question!
UncleMeat 9y ago
There is no chance that I can find a problem that I need to solve that I can get a candidate to work on and finish in a day. Too much custom infrastructure and technical background. Too many problems with IP. Any code I have a candidate write will get thrown away. So then why is a whiteboard interview different than a real problem? They don't have access to a developer environment but that's the only major difference. One should be able to reason about running times, not memorize them. If a candidate cannot explain why their implementation of an algorithm they've never worked with is actually quadratic in disguise, for example, then I'd need to babysit their code if they were hired to make sure the system stays efficient.
abeyer 9y ago
> What if this person hacks blockchain merkle trees for breakfast, but can't be bothered to regurgitate tangential runtimes of whatever algo you decided to ask about, which they memorized and forgot 10 years ago? I've seen this to be a nontrivial intersection of skills. But most runtime derivations are pretty basic math and logic. You don't need to memorize a runtime of some algorithm, because if you understand the algorithm and what runtime analysis is about, you can derive it (in an informal hand-wavy way, at least) on the spot on the whiteboard. I wouldn't expect a rigorous derivation of the master theorem during an interview, but being able to reason a bit about worst-case scenarios and the iteration bounds of nested loops or a tree traversal seems like a pretty fundamental skill if you're discussing algorithmic problems.

by avaer 9y ago

frandroid 9y ago

We'd turn on a dime and ask them to tell us about their merkle tree hacking on the white board, and the poke at it. The goal is to get a sense of people's skill, and we need to understand that they're not regurgitating something they've memorized ahead of time. Someone we interviewed last week was hoping for fizzbuzz and couldn't answer an equally simple question!

UncleMeat 9y ago

There is no chance that I can find a problem that I need to solve that I can get a candidate to work on and finish in a day. Too much custom infrastructure and technical background. Too many problems with IP. Any code I have a candidate write will get thrown away. So then why is a whiteboard interview different than a real problem? They don't have access to a developer environment but that's the only major difference. One should be able to reason about running times, not memorize them. If a candidate cannot explain why their implementation of an algorithm they've never worked with is actually quadratic in disguise, for example, then I'd need to babysit their code if they were hired to make sure the system stays efficient.

abeyer 9y ago

> What if this person hacks blockchain merkle trees for breakfast, but can't be bothered to regurgitate tangential runtimes of whatever algo you decided to ask about, which they memorized and forgot 10 years ago? I've seen this to be a nontrivial intersection of skills. But most runtime derivations are pretty basic math and logic. You don't need to memorize a runtime of some algorithm, because if you understand the algorithm and what runtime analysis is about, you can derive it (in an informal hand-wavy way, at least) on the spot on the whiteboard. I wouldn't expect a rigorous derivation of the master theorem during an interview, but being able to reason a bit about worst-case scenarios and the iteration bounds of nested loops or a tree traversal seems like a pretty fundamental skill if you're discussing algorithmic problems.