Use a method that works with different objects

You can use an inheritance class or an interface Personawhere all the common members of all the classes you mention contain it

So you would only have one method CheckIn:

public void CheckIn(Persona persona){

}

For example:

with interface

interface IPersona
{

    string Nombre { get; set; }
    string Apellido { get; set; }
    DateTime FechaIngreso {get; set;}
    //un Largo etc.
}

Note on properties in interfaces

and with a class

   public abstract class Persona { //puede ser abstracta o no
        string Nombre { get; set; }
        string Apellido { get; set; }
        DateTime FechaIngreso {get; set;}

        public void MetodoGenerico(){
        }
   }

Either way you need to reference them in the "children", in your class Directoryou would have to have

public class Director : IPersona //La I es por convención al usar Interfaces

either

public class Director : Persona

Either way you choose, you'll speed up your development a lot.

Sure, what you can do is use Interfaces. The interfaces allow you to establish rules for the classes (attributes and methods that by law they must have). Here is a code example:

public interface ICommonDataBetweenWorkers
    {
        string Name { get; set; }
        string Identifier { get; set; }
    }

 public class Employee : ICommonDataBetweenWorkers
    {
        public string Name { get; set; }

        public string Identifier { get; set; }
    }

    public class Manager : ICommonDataBetweenWorkers
    {
        public string Name { get; set; }

        public string Identifier { get; set; }
    }

    public class Director : ICommonDataBetweenWorkers
    {
        public string Name { get; set; }

        public string Identifier { get; set; }
    }

    public class Company
    {
        public void CheckIn(ICommonDataBetweenWorkers Person)
        {
            Console.WriteLine(Person.Name);
            Console.WriteLine(Person.Identifier);

            if (Person is Manager)
            {
                //Do something
            }
            else if(Person is Director)
            {
                //Do something
            }

            else if(Person is Employee)
            {
                //Do something

            }
            /*
             * No importa si es manager, director o employee. Mientras implementan la interfaz
             * compartirán los mismos miembros.
             */
        }

And when you call your check input method you do it like this:

 static void Main(string[] args)
        {
            Company C = new Company();

           //Cuando sea Employee
            C.CheckIn(new Employee());

            //Cuando sea Manager
            C.CheckIn(new Manager());

            //Cuando sea Director
            C.CheckIn(new Director());

            //Cuando sea otra cosa
            C.CheckIn(new OtherRoleThatYouHave());
        }

based on what you say

They all have data in common (such as personal data). What I would like to make more efficient is to reuse method code for many types of workers

In addition to the option of using interfaces, perhaps it is enough to use some property that gives you the role of your class Person, for example Person.Rol, in addition to there being a type of check by role, for example CheckingType, to group the different roles with similar behavior .

if (Person.Rol.CheckingType == Administrative)
{
//Turno administrativo
}
else if (Person.Rol.CheckingType == Supervisor)
{
//Turno gerentes/supervisores
}
else
{
//Los demás empleados
}

Since you do not specify the code that is inside the CheckIn methods, I will try to answer in the most general way possible:

In the first place, the first thing you should try is to create a worker interface that contains the fields and methods that must be common to all. For example:

public interface IRol
{
    int Id { get; set; }
    int HoraMaximaDeLlegada { get; set; }
}

Then each type of worker can implement these fields and methods

public class Director: IRol
{
    public int Id { get; set; }
    public int HoraMaximaDeLlegada { get; set; } 
}

public class Employee: IRol
{
    public int Id { get; set; }
    public int HoraMaximaDeLlegada { get; set; } 
}

public class Manager: IRol
{
    public int Id { get; set; }
    public int HoraMaximaDeLlegada { get; set; } 
}

In this way assuming for example that we have the following class

public class CheckIn
{
    public int Id { get; set; }
    public int PersonId { get; set; }
    public DateTime FechaCheckIn { get; set; }
    public bool EsTarde { get; set; }
}

Your method could be reduced to:

public class Company
{
    public void CheckIn(IRol person)
    {
        // Acá puedes usar todos los campos disponibles en IRol para realizar la tarea que necesites
        // Ejemplo de implementación
        var now = DateTime.Now;
        var checkIn = new CheckIn
        {
            PersonId = person.Id,
            FechaCheckIn = now,
            EsTarde = now > DateTime.Today.AddHours(person.HoraMaximaDeLlegada)
        };
        //... Hacer algo con ese nuevo checkIn
    }
}

But this is not always possible.

What if you can't modify the classes for some reason so that you can't make them implement the same interface. And even what if the classes don't have the same fields?

This can be fixed with the Adapter pattern

This pattern is used to change the "interface" (term used generically, not like interfaceC#) of the class you need to adapt it to a particular API

Say for example we have the following classes:

public class Director
{
    public int Id { get; set; }
    // Al ser el director no tiene una hora maxima de llegada
}

public class Employee
{
    public int Id { get; set; }
    public int HoraDeEntrada { get; set; } 
}

public class Manager
{
    public int Id { get; set; }
    public int PuedeLlegarHasta { get; set; }
}

In this case we can create an adapter that standardizes the interface

public abstract class BaseRolAdapter : IRol
{
    public int Id { get; set; }
    public abstract int HoraMaximaDeLlegada { get; set; }

    public BaseRolAdapter(int id)
    {
        Id = id;
    }
}

And then we can create a subtype for each Role

public class EmployeeAdapter : BaseRolAdapter
{
    public readonly Employee Employee;

    public override int HoraMaximaDeLlegada
    {
        get { return Employee.HoraDeEntrada; }
        set { Employee.HoraDeEntrada = value; }
    }

    public EmployeeAdapter(Employee person)
        : base(person.Id)
    {
        Employee = person;
    }
}

public class ManagerAdapter : BaseRolAdapter
{
    public readonly Manager Manager;

    public override int HoraMaximaDeLlegada
    {
        get { return Manager.PuedeLlegarHasta; }
        set { Manager.PuedeLlegarHasta = value; }
    }

    public ManagerAdapter(Manager person)
        : base(person.Id)
    {
        Manager = person;
    }
}

public class DirectorAdapter : BaseRolAdapter
{
    public readonly Director Director;

    public override int HoraMaximaDeLlegada
    {
        get { return 24; /* Con esto el Director nunca llegara tarde */ }
        set { }
    }

    public DirectorAdapter(Director person)
        : base(person.Id)
    {
        Director = person;
    }
}

Where each implementation can have its own logic

Then the class Companywould be like this

public class Company
{
    public void CheckIn(BaseRolAdapter person) // o IRol en lugar de BaseRolAdapter  si implementaba la interfaz
    {
        // Acá puedes usar todos los campos disponibles en IRol para realizar la tarea que necesites
        // Ejemplo de implementación
        var now = DateTime.Now;
        var checkIn = new CheckIn
        {
            PersonId = person.Id,
            FechaCheckIn = now,
            EsTarde = now > DateTime.Today.AddHours(person.HoraMaximaDeLlegada)
        };
        //... Hacer algo con ese nuevo checkIn
    }
}

This way you can make the CheckIn method always depend on a single class or interface and not have one for each type of employee.

De todas maneras estas solo son algunas ideas, tu caso puede variar considerablemtente pero la idea es la misma, estandarizar la interfaz para poderla hacer única para todo tipo de clases.

To respect the concepts SOLID, you should not use any if or swith that apply logic according to the person you must validate.

That's why I thought to pose something like this

public abstract class Person {

    public virtual void CheckIn()
    {
        //implementacion por defecto de la validacion
        //usas el "this"" para hacer referencia al objeto
     }

}

public class Director: Person
{

    public override void CheckIn()
    {
        //implementacion para el director
        //usas el this para hacer referencia al objeto
    }

}

public class Employee: Person
{

    public override void CheckIn()
    {
       //implementacion para el empleado
       //usas el this para hacer referencia al objeto
     }

}

public class Manager: Person
{
   //este hace uso de la implementacion base
}

public class Company
{
    public void CheckIn(Person person)
    {
       person.CheckIn();
    }

}

As you will see with inheritance you can make the class implement its concrete validation. would you invoke it like this

Company company = new Company();
company.CheckIn(new Director());

In this case use a virtualto define a base implementation, so you only have to override when necessary, but if you don't want to you could define a method likeabstract

I want to add my answer, although I suggest (like the others) to use an interface on the object, however another option would be the following:

    private void CheckIn(object person)
    {
        if (person is Director)
        {
            // lógica 1
            return;
        }

        if (person is Manager)
        {
            // lógica 2
            return;
        }

        if (person is Employee)
        {
            // lógica 3
            return;
        }

        throw new Exception("No es de un tipo aceptado por la función.")
    }

Greetings and here you have the reference to "is"

También se puede utilizar una definición de una clase con parámetros genéricos

public EmpleadoCompany<T> where T: ICommonDataBetweenWorkers
{
   public metodo1(T empleado1)
   {
      .....
   }

....


}