Abstractions vs Concrete Classes?

I was working on a Banking system, where I would generally have different levels of employees, like "teller", "clerk", "Manager", "Sr. Manager", etc. Since, all of them are employee, so I had created an abstract class Employee that contains all the common Employee behavior and the corresponding states. Now as per DIP we should try to work with abstractions as much as possible. The above mentioned implementation achieves that. However, when we talk about different categories of employees here, each employee would have a specific set of behavior that the other employee doesn't support which leads me to think of creating different interface for uncommon behavior. Therefore I can extend the Employee base class and implement this interface, let's say for Clerk which also possess this uncommon behavior. Something like this,

class Clerk: Employee, IUnCommonBehavior
{
}

My concern was I would be dependent on the concrete class to access all the members of Clerk. Since, if I assign an object of Clerk to Employee, I would be able to access only the members defined within Employee. Similar would be the case, if I assign an object of Clerk to IUnCommonBehavior type variable.

What is generally the best approach in such a scenario? Is there any better way to do this? In such a scenario should is it good to be working with a concrete class?