3 ms·

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 a

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...)...

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...)...