(I'm very late to this discussion, so I may try this question another time).
But I've been thinking about the marginal value of each additional technical question. In other words, how much additional relevant information do you get about a candidate increase with each increasing level of difficulty?
For instance, suppose you ask fizzbuzz and the candidate has an easy time of it. Then you ask about building/searching a binary tree, which the developer manages, but only after fumbling round a bit. Then you get into finding cycles in linked lists or graphs, and the developer takes a crack at it, but would need to look it up. Or maybe the developer gets it, and the interviewer ask about finding all permutations of a string...
How much more do you learn by going from fizzbuzz to binary trees. How much more do you get by asking about cycles in linked lists? And so on…
Just for the record, I can't stand technical interviews, and I dislike them so much that I'm considerably less inclined to apply for and interview for new jobs because I feel that I've studied for my data structures and algorithms midterm one time too many. I just don't want to re-load merge sort into short term memory again.
However, in spite of all this, I'm still somewhat sympathetic to interviewers[1]. The truth is, if you really don't have a lot of direct evidence about a developer, you truly are at risk of hiring someone who can't code.
[1] My problem with silicon valley hiring practices isn't that they have a process that leads to a high false negative rate. They should do what they feel is best for their company. My problem is that they do this while complaining about a critical shortage of developers so severe that it endangers the entire tech economy.
But I've been thinking about the marginal value of each additional technical question. In other words, how much additional relevant information do you get about a candidate increase with each increasing level of difficulty?
For instance, suppose you ask fizzbuzz and the candidate has an easy time of it. Then you ask about building/searching a binary tree, which the developer manages, but only after fumbling round a bit. Then you get into finding cycles in linked lists or graphs, and the developer takes a crack at it, but would need to look it up. Or maybe the developer gets it, and the interviewer ask about finding all permutations of a string...
How much more do you learn by going from fizzbuzz to binary trees. How much more do you get by asking about cycles in linked lists? And so on…
Just for the record, I can't stand technical interviews, and I dislike them so much that I'm considerably less inclined to apply for and interview for new jobs because I feel that I've studied for my data structures and algorithms midterm one time too many. I just don't want to re-load merge sort into short term memory again.
However, in spite of all this, I'm still somewhat sympathetic to interviewers[1]. The truth is, if you really don't have a lot of direct evidence about a developer, you truly are at risk of hiring someone who can't code.
[1] My problem with silicon valley hiring practices isn't that they have a process that leads to a high false negative rate. They should do what they feel is best for their company. My problem is that they do this while complaining about a critical shortage of developers so severe that it endangers the entire tech economy.