I think without more view of the forest, as it were, I'm finding difficult as a reader to understand the type of analysis you're hoping to get out of your interviewees.
Would you agree that one interpretation of your thesis is to have interviewees be able to adress the "why" behind a given implementation? Your reply suggests that it's not the implementation specifics that you're after, but that was the understanding I got out of the original article.
> I just want them to recognize that when they compare using a hash table to other alternatives, that looking up items in a hash table has a performance cost.
As you obviously know, looking up items in a hash table has exactly a constant performance cost (amortizing the cost of a resize, and accounting for load factor, etc.), making it an attractive solution in cases where you need a lookup. I'm curious if your point is that the interviewee is missing that nasty c constant in front of the big o, (e.g. computing a hash for an item or the cost of a resize is impractical, say) or if the issue is that they are just missing something big picture and fundamental given the problem statement.
The former really speaks of "losing the tree for the forest", as in the person black-boxed something they needed to open up, whereas the latter strikes me as more of a lack of conceptual reasoning.
Thanks for your time! I noticed I was downvoted, so apologies if my inquiry frustrates or upset you.
I think the author was trying to show us how smart he was, not only in areas of codez (intimate knowledge of hash table) but also in areas of businessing (something called 'liquidity trap'). We should all hold him in high regard, because he only hires A players and had kicked many non-hashtable saavy B players (180+ in all) to the curb.
First of all, thanks for replying!
I think without more view of the forest, as it were, I'm finding difficult as a reader to understand the type of analysis you're hoping to get out of your interviewees.
Would you agree that one interpretation of your thesis is to have interviewees be able to adress the "why" behind a given implementation? Your reply suggests that it's not the implementation specifics that you're after, but that was the understanding I got out of the original article.
> I just want them to recognize that when they compare using a hash table to other alternatives, that looking up items in a hash table has a performance cost.
As you obviously know, looking up items in a hash table has exactly a constant performance cost (amortizing the cost of a resize, and accounting for load factor, etc.), making it an attractive solution in cases where you need a lookup. I'm curious if your point is that the interviewee is missing that nasty c constant in front of the big o, (e.g. computing a hash for an item or the cost of a resize is impractical, say) or if the issue is that they are just missing something big picture and fundamental given the problem statement.
The former really speaks of "losing the tree for the forest", as in the person black-boxed something they needed to open up, whereas the latter strikes me as more of a lack of conceptual reasoning.
Thanks for your time! I noticed I was downvoted, so apologies if my inquiry frustrates or upset you.