AXENTED — Blog Article
Slug: /blog-posts/how-to-interview-nearshore-engineers |
Meta description: La mayoría de las entrevistas técnicas fueron diseñadas para contratación presencial. Para equipos distribuidos, la señal más importante es la calidad de la comunicación asíncrona, no los puntajes de LeetCode. |
Target keywords: entrevistar ingeniero nearshore, entrevista técnica remota, contratar desarrollador nearshore, proceso de contratación ingeniero remoto |
Las entrevistas técnicas remotas tienen un problema de desperdicio. La mayor parte del proceso — el filtro de LeetCode, la pregunta abstracta de diseño de sistemas, la vaga conversación de "culture fit" — fue diseñado para contratación presencial y no se traduce bien a un contexto de equipo distribuido y transfronterizo. La relación señal-ruido es baja y los mejores candidatos suelen autoexcluirse antes de que los veas.
Este es el proceso que hemos refinado ejecutando contrataciones nearshore en equipos de Monterrey, Ciudad de México y LATAM en general.
Para un ingeniero nearshore que se incorpora a un equipo distribuido, la base técnica es necesaria pero no suficiente. Otras dos dimensiones importan al menos tanto y se evalúan mal en la mayoría de los procesos de entrevista: la capacidad de trabajar de forma asíncrona y la capacidad de comunicarse a través de brechas de contexto.
Un ingeniero técnicamente sólido que requiere desbloqueo sincrónico constante es costoso en un equipo distribuido. La sobrecarga de gestionar cada pregunta o decisión a través de diferencias horarias elimina la ventaja de productividad de un engagement nearshore. Lo que necesitas es un ingeniero que pueda sostener un problema, razonarlo de forma independiente, documentar su pensamiento y tomar buenas decisiones con información incompleta. Esas características no aparecen en un test de código.
Reemplaza la llamada inicial con el reclutador por una asignación escrita asíncrona. Envía al candidato una descripción de una página de un problema técnico — algo que tomaría dos o tres horas analizar cuidadosamente — y pídele que responda con un enfoque propuesto. No código. Una explicación escrita de cómo lo pensaría.
Este filtro hace tres cosas: filtra candidatos que no pueden comunicarse por escrito (un verdadero bloqueador para equipos distribuidos), te da una vista previa de cómo razonan ante problemas ambiguos, y revela si hacen preguntas aclaratorias o hacen suposiciones. Los candidatos que responden con buenas preguntas aclaratorias antes de responder suelen ser los que vale la pena continuar evaluando.
La entrevista más predictiva para trabajo en equipo distribuido es una simulación de las condiciones de trabajo reales. Dale al candidato una tarea pequeña y realista — una revisión de código de un pull request de 200 líneas, un ejercicio de depuración en un codebase que tú proporcionas, o una pregunta de diseño técnico con restricciones que reflejen tu producto real. Dale dos horas y acceso a la documentación. Observa cómo lo usa.
El objetivo no es probar si puede resolver el problema sin ayuda. Es observar el proceso: cómo desglosa el problema, qué consulta versus qué ya sabe, cómo maneja el momento en que su primer enfoque no funciona, y cómo documenta lo que hizo. Ese proceso es lo que estás contratando.
Una conversación técnica con un ingeniero senior de tu equipo, estructurada alrededor del output de la simulación. El candidato explica su trabajo, el entrevistador hace preguntas de seguimiento, y ambos lados prueban si pueden comunicarse eficazmente bajo condiciones reales.
Qué buscar: ¿el candidato habla con precisión sobre conceptos técnicos sin que se lo pidan, o usa lenguaje vago que requiere seguimiento para entender? ¿Explica sus compromisos o solo su conclusión? ¿Puede decir "no sé" con claridad cuando no sabe algo?
La mayoría de las llamadas de referencias son inútiles porque hacen preguntas que producen respuestas inútiles. "¿Volvías a trabajar con esta persona?" produce "sí" en el 98% de los casos. La pregunta que produce información útil: "Cuéntame sobre una vez que esta persona cometió un error y cómo lo manejó." Luego escucha con atención.
Los candidatos cuyas referencias reconocen y aprenden de los errores generalmente son los ingenieros que mejoran más rápido. Los candidatos cuyas referencias tienen dificultad para responder esta pregunta generalmente nunca han estado en un entorno donde dar feedback honesto fuera seguro.
El proceso completo descrito arriba toma aproximadamente dos semanas desde el primer contacto hasta la oferta. Las etapas 1 y 2 son asíncronas y no requieren coordinación de calendario. La etapa 3 requiere una reunión de 60 minutos. La etapa 4 requiere una llamada de 30 minutos.
Ese tiempo es más rápido que la mayoría de los procesos de contratación presencial, produce más señales sobre la capacidad de trabajo distribuido y respeta tanto el tiempo del candidato como el tuyo.
%20(1)-2.svg)
