I wouldn't subclass Employee at all. I'd maybe model it as Employee HAS a PaymentStrategy, which is subclassed with HourlyPaymentStrategy, SalaryPaymentStrategy, etc.
To expand as to why: In statically-typed languages like Java and C#, an object can't change its type once instantiated. So, using inheritance, an hourly employee could never become a salaried employee, whereas, with composition, you could replace his PaymentStrategy property from an instance of HourlyPaymentStrategy with SalaryPaymentStrategy.