I drew up a few boxes to illustrate table objects (with available time slots for the evening), a table manager (to hold the table objects), customer objects (to associate various customers to tables via their reservations), some API's (e.g. "query the table manager to find an open table to fit a party of X"). As I worked up the diagram, I talked about the various pros and cons to the approaches. When we finished up, they seemed to be very unhappy about the fact I hadn't explicitly called out calendar dates in the reservation system (I had just gone ahead with an assumption that a customer was only going to be thinking about a reservation on one particular day at any time). So this team might have done a thumbs down on me.
Composition means that an object's behaviors are specified by other objects it contains. For instance, a Dragon class might contain a Movement object that specifies flight. Inheritance, as is usually used in OO, means that behavior is specified by an object's position in a class heirarchy. A Dragon would inherit from a FlyingObject class, for instance, and flight behavior would be coded there. Inheritance makes refactoring behavior tricky, because changing a behavior (e.g. a dragon that can fly in SPACE) implies changing that behavior for all objects that inherit from a superclass. With a design based on composition, the space dragon is as simple as creating a new Movement object that details how to move through space.
This problem can be either easy or complicated. Many follow up questions may come. My advice is to keep it simple and improve it later. The fact that the design has to be told at the phone makes it a bit complicated.