4 ms·

> "have you seen this question before" interviewing I suspect that this was meant to refer to interview questions with an "Aha!" answer, that are unlikely to b

by mundo 10y ago

> "have you seen this question before" interviewing I suspect that this was meant to refer to interview questions with an "Aha!" answer, that are unlikely to be answered correctly by people who don't already know the answer. For example, I think, "How would you detect a cycle in a linked list?" is a bad question because, if the candidate implements Floyd's algorithm on the whiteboard, the likely assumption is that they remembered it, not that they came up with it on the spot.

InclinedPlane 10y ago
Exactly. Questions that have a super optimized answer that's probably non-intuitive and unlikely to be arrived at if you've only spent a few minutes exposed to the problem. These are basically puzzle questions in disguise. In general I think there are two kinds of coding questions that are worth asking. Straightforward implementation based questions that should be solved basically as fast as the candidate can write, assuming they're familiar with the basic techniques. These are in the same vein as fizzbuzz and generally just give you a sense of the techniques the candidate has mastered (basic programming, bit-wise operations, recursion, etc.) The other kind are open ended questions that help show problem solving skills, knowledge of different algorithms and data structures, etc. These sorts of questions don't have the same variance as the secret puzzle questions. The amount of time to throw up a fizzbuzz implementation if you've seen the problem before should be about the same as if you haven't. And the same goes for open ended questions that are more about design, thinking, etc. And of course you always want to factor in the problem of dealing with candidates who are nervous, in an unfamiliar and uncomfortable situation, and not operating at peak performance. You shouldn't expect production quality code for complex problems in those situations, you should be looking for code that gives you data.
- Terr_ 10y ago
  In some ways, the problem is never the question, but how the results are evaluated.
KMag 10y ago
I generally agree that "Aha" questions are bad, but if it's a common problem that people actually re-invent solutions to, it can still be a useful interview question. I personally avoid them, but see a few advantages: 1. If they're not aware of an existing algorithm, it's good to see what they come up with isn't terrible. It's insane the number of times I've seen unbounded time shuffle algorithms in production code. (Repeatedly pick a random element from src, linear scan of dst, and append to dst if not found.) 2. If they know a few famous algorithms, it's much more likely they're aware of the existence of lots of algorithms and are much more likely to Google for the pre-existing algorithm instead of making up something terrible on the spot. 3. A lot of these famous algorithms aren't as difficult to come up with as you'd think. When I first heard of the key schedule biases in RC-4, I thought about it for half an hour and came up with something identical to Fischer-Yates, using the unbalanced Feistel cipher at the core of MD5 (unfortunately, killing the speed advantages of RC4). Years later, when I heard there was a name for the algorithm, I checked Google to see if they had included the back-to-front optimization, and sure enough, what I had come up with was identical to Fischer-Yates.
piedradura 10y ago
in Lisp you use two pointers (a fast and a slow one) to detect a cycle in a linked list. For example http://clhs.lisp.se/Body/f_list_l.htm http://clhs.lisp.se/Body/f_list_l.htm

by mundo 10y ago

InclinedPlane 10y ago

Exactly. Questions that have a super optimized answer that's probably non-intuitive and unlikely to be arrived at if you've only spent a few minutes exposed to the problem. These are basically puzzle questions in disguise. In general I think there are two kinds of coding questions that are worth asking. Straightforward implementation based questions that should be solved basically as fast as the candidate can write, assuming they're familiar with the basic techniques. These are in the same vein as fizzbuzz and generally just give you a sense of the techniques the candidate has mastered (basic programming, bit-wise operations, recursion, etc.) The other kind are open ended questions that help show problem solving skills, knowledge of different algorithms and data structures, etc. These sorts of questions don't have the same variance as the secret puzzle questions. The amount of time to throw up a fizzbuzz implementation if you've seen the problem before should be about the same as if you haven't. And the same goes for open ended questions that are more about design, thinking, etc. And of course you always want to factor in the problem of dealing with candidates who are nervous, in an unfamiliar and uncomfortable situation, and not operating at peak performance. You shouldn't expect production quality code for complex problems in those situations, you should be looking for code that gives you data.

Terr_ 10y ago
In some ways, the problem is never the question, but how the results are evaluated.

KMag 10y ago

I generally agree that "Aha" questions are bad, but if it's a common problem that people actually re-invent solutions to, it can still be a useful interview question. I personally avoid them, but see a few advantages: 1. If they're not aware of an existing algorithm, it's good to see what they come up with isn't terrible. It's insane the number of times I've seen unbounded time shuffle algorithms in production code. (Repeatedly pick a random element from src, linear scan of dst, and append to dst if not found.) 2. If they know a few famous algorithms, it's much more likely they're aware of the existence of lots of algorithms and are much more likely to Google for the pre-existing algorithm instead of making up something terrible on the spot. 3. A lot of these famous algorithms aren't as difficult to come up with as you'd think. When I first heard of the key schedule biases in RC-4, I thought about it for half an hour and came up with something identical to Fischer-Yates, using the unbalanced Feistel cipher at the core of MD5 (unfortunately, killing the speed advantages of RC4). Years later, when I heard there was a name for the algorithm, I checked Google to see if they had included the back-to-front optimization, and sure enough, what I had come up with was identical to Fischer-Yates.

piedradura 10y ago

in Lisp you use two pointers (a fast and a slow one) to detect a cycle in a linked list. For example http://clhs.lisp.se/Body/f_list_l.htm http://clhs.lisp.se/Body/f_list_l.htm