This is a form of tight coupling. Virtually all design tutorials advocate loose coupling. Putting yourself in the best position to reuse object types is one reason. Keeping the interface of each object functionally separate is another.
Knowing what Employees and Companies do in your application will do make shed more light. Something as simple as a hashtable, where each Employee is a key and each Company a value. Something more sophisticated such as a Composite pattern, where each Company represents its Employees by both membership and responsibilities over other Employees...it's a question of attributes you want to emphasize that I think will guide you along further.
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
Micheal is right. The first thing we need to think about is "what behaviour does a company object in my system? What about Employee?"
Then we can decide about wether Employee actually needs to know about its company, and if so how.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus