This is not a problem of choosing an appropriate key, but rather one of database normalization.
Company code, if unique, can be primary key in a company table. Its employees should reside in an employee table, using some unique identifier as primary key.
table company
company_code VARCHAR? PRIMARY KEY,
company name VARCHAR(30),
postal address ...,
etc
table employee
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
fname VARCHAR(30),
lname VARCHAR(30),
company SAME_AS_FOR_company_code_IN_COMPANY_TABLE
etc,
CONSTRAINT employee_of_FK
FOREIGN KEY(company) REFERENCES company(company_code)
As for choosing a primary key. Some people never use anything but an artificial id, others stick to using real data as primary keys when applicable.
Personally I go with an artificial id if all I would otherwise have to use is a string, and I'm guessing your company_code is of type VARCHAR. Integers are easy to use and when looking at data it's immediately apparent that one id differs from another. Indexing integers is also easy for the db, while string indexing may require more bytes for the index.
But if I have a table storing entries in time for a company, event or whatever, and I don't have to deal with multiple entries for any given time, I'd stick with the multi column primary key (company_id, datetime), rather than create an artificial key. Neither way is wrong, it's a matter of personal preference. Although I'm certain you can find people who claims that either one of them is wrong.