A pattern for abstract classes?

I had a conversation with a coworker today in which he described his answer to a "When should you use abstract classes instead of interfaces?" interview question. I would have just answered "never" but his answer gave an example in which a Manager (class) inherited from Employee (abstract class) and I suppose if there is a use case for the nasty abstract classes in C# that might be it. In this paradigm there are many types of employees but each employee has to have a distinct role. There are no generic employee employees. An employee would have some generic employee machinery however perhaps creating the need to keep some common methods in one place.