3 ms·

Items from a sorted list can be retrieved by a binary search in O(log(n)) time, so a database index is merely a list, sorted by the column being indexed, that p

Items from a sorted list can be retrieved by a binary search in O(log(n)) time, so a database index is merely a list, sorted by the column being indexed, that points back at the original record for each entry. Simple, right? So simple, in fact, that if someone tells you they don't know how a DB index works, you could easily walk them through it and, in doing so, get a much better evaluation of how they think than merely how well they can recite a bit of memorized text-book knowledge. In fact, the only time I ever ask "Can you explain how X works?" type questions in interviews is so that I can specifically exclude asking an interviewee how to walk through the derivation of a concept with which they are already familiar. By that metric, I think your "how a DB index works" question is a great interview question! Your mistake is stopping when they say "no".

agentultra 9y ago
I like your idea. At the Recurse Centre, I've heard, they have a rule that you should never act surprised if someone doesn't know something and instead see it as an opportunity to teach them something cool. I use this on my team but I haven't seen it used in interviews before. I would imagine you either know what data-structures to use for a given data type or you do not... it's a fairly prescriptive question. However if someone could reason by what they do know about how it might work given enough information then it'd be interesting to know what you could learn from them by walking them through the problem. First, obviously if they take a try at it then it shows the person can reason about problems they haven't encountered by using concepts. How much walking do you do for them and what does it tell you about their problem solving capabilities?
- jballanc 9y ago
  Personally, when conducting technical interviews, I try to keep the interviewee right at the limits of their knowledge and ability. It's sort of like standing blindfolded in a room and walking in different directions until you hit a wall to get a sense of the size of the room (don't try this at home). So this often involves starting overly complex, then walking back until you find the interviewee's comfort zone. Let them demonstrate their knowledge for a while (and hopefully gain back some confidence), then push them out to the complexity zone again until they stop answering/start looking uncomfortable again. To give a concrete example of what that would look like with this question (let's call "A" the interviewer and "B" the interviewee): ...(this post has been truncated for your scrolling enjoyment, full version at: https://gist.github.com/jballanc/82cbe551b2b667a1ab72acabc7183d5d https://gist.github.com/jballanc/82cbe551b2b667a1ab72acabc71...)...

agentultra 9y ago

I like your idea. At the Recurse Centre, I've heard, they have a rule that you should never act surprised if someone doesn't know something and instead see it as an opportunity to teach them something cool. I use this on my team but I haven't seen it used in interviews before. I would imagine you either know what data-structures to use for a given data type or you do not... it's a fairly prescriptive question. However if someone could reason by what they do know about how it might work given enough information then it'd be interesting to know what you could learn from them by walking them through the problem. First, obviously if they take a try at it then it shows the person can reason about problems they haven't encountered by using concepts. How much walking do you do for them and what does it tell you about their problem solving capabilities?

jballanc 9y ago
Personally, when conducting technical interviews, I try to keep the interviewee right at the limits of their knowledge and ability. It's sort of like standing blindfolded in a room and walking in different directions until you hit a wall to get a sense of the size of the room (don't try this at home). So this often involves starting overly complex, then walking back until you find the interviewee's comfort zone. Let them demonstrate their knowledge for a while (and hopefully gain back some confidence), then push them out to the complexity zone again until they stop answering/start looking uncomfortable again. To give a concrete example of what that would look like with this question (let's call "A" the interviewer and "B" the interviewee): ...(this post has been truncated for your scrolling enjoyment, full version at: https://gist.github.com/jballanc/82cbe551b2b667a1ab72acabc7183d5d https://gist.github.com/jballanc/82cbe551b2b667a1ab72acabc71...)...