4 ms·

I came here to make the same comment (pardon the pun.) This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag.

by bhntr3 10y ago

I came here to make the same comment (pardon the pun.) This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag. He also says to write the most efficient code possible. Then doesn't. See the comments at the end of the post. Overall, I think what this shows is that as an interviewee, the best thing you can do is try to get an idea of the interviewer's expectations as quickly as possible. People love saying here that it's not a test scenario. But it is. The interviewer has a preconceived notion of what you should and shouldn't do and you need to meet that notion. As an interviewer, recognize it's easy to think you're smarter than the other person when you already know the answer. Don't be pompous. Don't assume you know better. Try to set expectations very clearly. Try to really listen to the interviewee and understand why they're making the choices they are. Personally, I would be frustrated by this interview. I feel like this article is a thin justification of a lot of standard interview practices that don't actually work. It and his further comments take a condescending tone that makes me worry he wouldn't be open to approaches he hasn't seen. Reminds me of a time an interviewer basically gave up on an interview because I told him there were O(N) algorithms for sorting strings with a fixed alphabet. He said "Best case sorting is O(nlogn)" and I could hear in his voice that for him the interview was over. I knew what radix sort was but in the moment I couldn't actually explain or implement it without looking it up and things just went downhill from there.

tamana 10y ago
You might get have done better if you remembered the criterion correctly. Almost every data type used in computing is represented by non-fixed-length strings over a fixed alphabet (usually {0,1}). Radix sort is O(n) in log(dictionary size) which is only a useful bound when the data set is larger than the dictionary (this is a severe but not fatal requirement. Some datasets have many duplicate values, and anyway in practice log(n) factors in real world systems are practically constant factors: an 1log(n) algorithm will be slower than a 100(1) algorithm.) You can misstate a theorem, or forget the proof, OK, but doing both is poor form.
- bhntr3 10y ago
  You're right. I misstated it here and was clearly lying when I said I understood it. Another good tip for interviewees: If you don't really understand something well enough to explain it, sometimes it's better not to bring it up than to introduce it and look silly. Sucks. But you're more likely to lose points than gain them for just kind of knowing something exists. Also applies to hacker news comments ;)

by bhntr3 10y ago

tamana 10y ago

You might get have done better if you remembered the criterion correctly. Almost every data type used in computing is represented by non-fixed-length strings over a fixed alphabet (usually {0,1}). Radix sort is O(n) in log(dictionary size) which is only a useful bound when the data set is larger than the dictionary (this is a severe but not fatal requirement. Some datasets have many duplicate values, and anyway in practice log(n) factors in real world systems are practically constant factors: an 1log(n) algorithm will be slower than a 100(1) algorithm.) You can misstate a theorem, or forget the proof, OK, but doing both is poor form.

bhntr3 10y ago
You're right. I misstated it here and was clearly lying when I said I understood it. Another good tip for interviewees: If you don't really understand something well enough to explain it, sometimes it's better not to bring it up than to introduce it and look silly. Sucks. But you're more likely to lose points than gain them for just kind of knowing something exists. Also applies to hacker news comments ;)