It's often hard to ask relevant questions that will fit into the time allotted for an interview. Your DB schema example is a good one - it shows that the candidate can design (and to a lesser extent, implement) an application. Your example (I'm assuming) is missing strong algorithmic problem solving however. It would be good to have an additional question to test this kind of knowledge.
It's also important to realize that most technical interviews are really about weeding out bad candidates than finding good ones.
It may also be necessary to have questions general enough that any given candidate stands a chance at solving it. If a candidate doesn't have SQL experience your example would be bad (assuming the company didn't require SQL experience).
This is why you see questions like "implement a binary tree." Any competent programmer should be able to implement a binary tree. If they have never seen a binary tree before, they are simple enough to describe in 5 minutes.
I once asked a candidate to implement a trie. He had never heard of a trie before so I drew one on the whiteboard and briefly explained it. He asked me a few questions and then proceeded to implement one. We then discussed the pros and cons of different methods to store the nodes (vector, list, map). It showed me that, given a spec, he could code a data structure and the following discussion showed me he understood memory and time constraints.
Good points, but, how many interviewers would severely penalize someone for not even knowing what a binary tree was? I think explaining the tree and asking for an implementation could be a fair question, but only if the question assumes that the implementation is the important bit.
Also a good point. I'd be surprised if a programmer didn't know what a binary tree was and would certainly consider it a warning sign. I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything). However I'm willing to be proven wrong and if they were able to implement one I would be pleasantly surprised.
Of course, I can only speak for myself. I'm sure many programmers would immediately write them off.
I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything).
That's a pretty glaring assumption, especially since it's subject to empirical verification. It also contains an assumption of its own -- that all programming needs a heavyweight familiarity with algorithms. There's a lot of programming contexts where the productive programmer just uses a hash so the mental bandwidth can be devoted to something else.
(FWIW, I do sometimes wish those programmers knew a little more about algorithms.)
I agree that it is a glaring assumption, and perhaps is "culturally" biased. Someone programming in Perl or Python, would probably be very familiar with the built in data structures (hashmaps, dictionaries) but may not be familiar with others.
And this is exactly why I would give the programmer the benefit of the doubt. If they are able to implement a binary tree then I wouldn't hold it against them (and I hope most other programmers would extend the same courtesy).
However I have never met a programmer who did not know what a binary tree was.
It's also important to realize that most technical interviews are really about weeding out bad candidates than finding good ones.
It may also be necessary to have questions general enough that any given candidate stands a chance at solving it. If a candidate doesn't have SQL experience your example would be bad (assuming the company didn't require SQL experience).
This is why you see questions like "implement a binary tree." Any competent programmer should be able to implement a binary tree. If they have never seen a binary tree before, they are simple enough to describe in 5 minutes.
I once asked a candidate to implement a trie. He had never heard of a trie before so I drew one on the whiteboard and briefly explained it. He asked me a few questions and then proceeded to implement one. We then discussed the pros and cons of different methods to store the nodes (vector, list, map). It showed me that, given a spec, he could code a data structure and the following discussion showed me he understood memory and time constraints.