4 ms·

Instead of requiring someone to know a b-tree, how about just teaching it to them in an interview, and then walking through an exercise to see if they get it?

Instead of requiring someone to know a b-tree, how about just teaching it to them in an interview, and then walking through an exercise to see if they get it? That'd be more impressive to me. If someone claims to know what a b-tree, test them on a more advanced concept that builds on using a b-tree that they are unlikely to know. Then teach them that and see if they get it. Make the interview more about working together and capacity to learn, and less about computer science trivia night at the pub with no beer. Your ability to efficiently teach people stuff that you claim is important is a chance to hold yourself accountable for how well you actually know something AND whether it is actually important at all. If an interviewer taught me something I didn't know, and then quizzed me on it, I'd be impressed as heck, and I'd wanna work with that person (if they were not an asshole).

sratner 10y ago
This has worked quite well for me. I tend to ask one of two types of algorithm questions: 1. Pick a simple but relatively obscure data structure, something they are unlikely to have crammed the night before. I always start by asking the candidate if they are familiar with it; the answer is almost universally "no". I then pull out a wikipedia printout and a notepad, and spend 10 minutes explaining it to them, with diagrams. Once they are sure they have understood the basic operations, I ask them to implement one of these basic operation we just walked through. The amount of code here should be ~10 lines; keep on adding simplifying assumptions until it is. 2. Pick a fundamental data structure from a high-level language runtime, something you would use without thinking: python lists, javascript objects, that kind of thing. I emphasise that familiarity with said language is not required, and list some real-world properties and performance characteristics (access speed, iteration, ordering, mutation), as well as common and less-common use cases. I then ask the candidate how they think it is implemented under the hood (i.e., if you wanted these semantics in a language that didn't natively provide them, how would you do it?) I often don't have a full answer myself, so we brainstorm the requirements and implementations together; no code, just open-ended discussion. The best candidates have often emailed me afterwards, having looked up an actual open-source implementation.
- amorphid 10y ago
  Without knowing how well it works, I like this approach. It's thoughtful and engaging. Not perfect, and maybe that's a good thing.
- pshposh 10y ago
  I really like this approach; can I interview with you? :P
Apocryphon 10y ago
Definitely a good idea to decouple rote memorization from the interview process.
OpenDrapery 10y ago
I've had interviewers try to school me on something that I wasn't super well versed on, and my internal thought process was "If I wanted to learn the finer points of xsd, I'd go dig in on my own and learn it. Right now I'm not that interested in you teaching it to me." Maybe not the healthiest attitude ...
dlubarov 10y ago
I do like your suggestion, but > Make the interview more about working together and capacity to learn, and less about computer science trivia night at the pub with no beer. Understanding b-trees is pretty useful. If you work with relational databases, most questions concerning query performance require some understanding of b-trees. I wouldn't ask a candidate to implement b-trees (or a sorting algorithm, or red-black trees, etc.), but asking about their basic properties seems reasonable. Or better yet, asking about the performance of a realistic SQL query which uses a b-tree index.

sratner 10y ago

This has worked quite well for me. I tend to ask one of two types of algorithm questions: 1. Pick a simple but relatively obscure data structure, something they are unlikely to have crammed the night before. I always start by asking the candidate if they are familiar with it; the answer is almost universally "no". I then pull out a wikipedia printout and a notepad, and spend 10 minutes explaining it to them, with diagrams. Once they are sure they have understood the basic operations, I ask them to implement one of these basic operation we just walked through. The amount of code here should be ~10 lines; keep on adding simplifying assumptions until it is. 2. Pick a fundamental data structure from a high-level language runtime, something you would use without thinking: python lists, javascript objects, that kind of thing. I emphasise that familiarity with said language is not required, and list some real-world properties and performance characteristics (access speed, iteration, ordering, mutation), as well as common and less-common use cases. I then ask the candidate how they think it is implemented under the hood (i.e., if you wanted these semantics in a language that didn't natively provide them, how would you do it?) I often don't have a full answer myself, so we brainstorm the requirements and implementations together; no code, just open-ended discussion. The best candidates have often emailed me afterwards, having looked up an actual open-source implementation.

amorphid 10y ago
Without knowing how well it works, I like this approach. It's thoughtful and engaging. Not perfect, and maybe that's a good thing.
pshposh 10y ago
I really like this approach; can I interview with you? :P

Apocryphon 10y ago

Definitely a good idea to decouple rote memorization from the interview process.

OpenDrapery 10y ago

I've had interviewers try to school me on something that I wasn't super well versed on, and my internal thought process was "If I wanted to learn the finer points of xsd, I'd go dig in on my own and learn it. Right now I'm not that interested in you teaching it to me." Maybe not the healthiest attitude ...

dlubarov 10y ago

I do like your suggestion, but > Make the interview more about working together and capacity to learn, and less about computer science trivia night at the pub with no beer. Understanding b-trees is pretty useful. If you work with relational databases, most questions concerning query performance require some understanding of b-trees. I wouldn't ask a candidate to implement b-trees (or a sorting algorithm, or red-black trees, etc.), but asking about their basic properties seems reasonable. Or better yet, asking about the performance of a realistic SQL query which uses a b-tree index.