> Oh wow, how do you prompt the interviewees?
Back when I was still doing this, I used to start the interview like this:
- given: a non-uniform, finite, frequency table with actual observations of some real-world phenomenon (and if that's too generic, just tell the candidate you've thrown a dice a million time an recorded the outcomes).
- given: a uniform pseudo random number generator
- please design a pseudo random number generator that will, if sampled for long enough, produce the same distribution (non generic version: RNG that statistically behave like the dice).
Unfortunately, a non-negligible proportion of candidates fail to produce any solution at all :(
Decent candidates quickly produce the standard: "build the CDF once and then at sample time, draw a uniform number in the correct range and walk the CDF until we're above that random number, return the bucket where that occurred"
I then ask for time and space complexity for the sampling phase.
Slightly better than average candidate notice that the CDF is naturally sorted and can be binary searched.
I then ask those if they can improve what we have to a O(1) solution (independent of the size of the histogram).
The top 20% candidates usually manage to put their intuition at work: from the fact that O(1) almost always implies a simple table lookup, they come up with the: "build a very large array, where the index of each bucket B of the histogram is replicated histo[B] times and then sample uniformly from it".
We then discuss when this algorithm is/isn't practical.
The candidates that get to this point within ~15mn can then be gently walked towards redesigning the alias method using some hints.
The starting hint goes like this: what if you were to completely ignore the fact that the histogram is not uniform, and just stubbornly sample from it, can you quantify how much of a mistake you would make ?
The second hint is: for some buckets, picking them will be an overshoot, and for some we will undershoot. Explain when that is.
The third hint: say we picked a bucket that's chosen too often, can we decide to only keep it some of the time (as in: with some carefully chosen probability)
The fourth hint: and if we decide not keep it, why waste the dice throw, why not pick another, carefully chosen bucket
etc ...
The nice property of this question is: it's very gradual, starting with a problem most people with a CS degree should be able to solve, then going to a solution that's less standard and requires more than base regurgitation of CS lessons, to finally get to what I consider to be (at the risk of repeating myself) the non-trivial state of the art solution to the problem.
The point where the candidate start to struggle gives you a nice reading on their strength.
And there's the rare few new grads that would vaguely recall having seen the alias method and could rebuild it cleanly on the white board from scratch and without help. These rare occurrences were very enjoyable.