Give and explain your opinion of your colleague's idea.
Your colleague's idea comes up short. To be able to know when arriving customers should be turned away, you need to know when the current customers leave (or, more accurately, haven't left). Without knowing how many empty tables there are, you can't accurately turn away arriving customers.
Although a few answers came close to the problem of unjustified data culling, most of the answers to this question were far more elaborate than they needed to be and, while not wrong, missed the point. Answers on these quizzes are usually one or two small, logical steps away from the question; if you find yourself giving answers that require elaborate leaps of reasoning, you should probably stop, calm down, and try again, starting from the problem.
Briefly describe (no code) a scheme to avoid both these issues when deleting. For full credit your scheme should delete in constant time (at least theoretically).
The easiest way to avoid the problems associated with deleting from the event list is to avoid deleting from the event list by keeping a second list of delete requests. As events are pulled off the event list, they can be compared to delete requests and tossed if there's a match. Because it's an unordered list that's only inserted into, searched, and deleted from, the delete list can be managed as a hash table, which provides (theoretical) constant-time access.
"delete in constant time (at least theoretically)" was the clue here; the only common data structure with that property is some form of hash table. A few answers picked up on this, but didn't combine hash tables with the event list to give constant-time deletes (one answer replaced the event list with a hash table, which is difficult to do because the event list needs to maintain trigger-time order).
This page last modified on 22 February 2005.