Ir al contenido

El encaje de un desarrollador se puede observar antes de firmar

12 de noviembre de 2026 por
El encaje de un desarrollador se puede observar antes de firmar
Juanita Gomez

El desarrollador que llegó disponible el primer día todavía pregunta qué significa "pedido liberado" en tu operación. Es la tercera vez que alguien del equipo se lo explica. La tarea que le asignaron hace semanas sigue en la misma columna del tablero, y dos de tus mejores ingenieros dedican parte de su día a traducir el negocio.

Su hoja de vida decía lo correcto: el stack, los años de experiencia, las certificaciones. La entrevista técnica salió bien. El encaje de una persona dentro de un equipo vive en otro lugar, y ese lugar se puede observar antes de firmar.


Dónde aparece el costo

El costo de un perfil que no encaja llega como horas senior dedicadas a explicar, como revisiones de código que repiten los mismos comentarios y como un cronograma que se mueve en silencio. El equipo lo absorbe sin nombrarlo, y por eso conviene detectarlo desde la selección.

Cuatro señales observables anticipan ese encaje. Cada una trae una prueba que puedes aplicar en una entrevista o en la primera semana de trabajo.

1. Cómo lee el código que otro escribió

Casi todo el trabajo de un desarrollador dentro de un equipo existente consiste en modificar código ajeno, con convenciones, deuda y decisiones previas que nadie documentó. La lectura de código ajeno es la tarea que mejor anticipa el desempeño en equipo.

La prueba: entrega un módulo real, anonimizado, de 200 a 300 líneas con alguna particularidad heredada, y pide que explique qué hace y por dónde empezaría a cambiarlo. Observa si sigue el flujo de los datos, si identifica efectos secundarios, si pregunta por las pruebas existentes y si respeta las convenciones del módulo antes de proponer reescribirlo.

2. Cómo trabaja con un requerimiento incompleto

Todo requerimiento llega con vacíos. Algunos desarrolladores los llenan con supuestos silenciosos, y el retrabajo aparece semanas después, cuando alguien descubre que la regla implementada difiere de la que el negocio esperaba.

La prueba: plantea un requerimiento con dos vacíos deliberados. Por ejemplo, "calcular la comisión por venta" sin definir qué ocurre con las devoluciones ni con las ventas del último día del mes. Observa si enumera sus supuestos, si ordena las preguntas por impacto, si propone un valor por defecto para avanzar y si deja registrada la decisión.

3. Cómo comunica un retraso

Una estimación es una hipótesis, y todo proyecto la ajusta. El momento y el contenido del aviso revelan al profesional.

La prueba: pídele que cuente una entrega que se complicó. Escucha cuándo avisó, qué información llevó (causa, nueva estimación, opciones) y qué ajustó después. En la primera semana de trabajo, observa cómo reporta su primer bloqueo. Un aviso temprano, con opciones sobre la mesa, le permite al equipo decidir con tiempo.

4. Cuánto negocio hace suyo

Entender la operación del cliente es una competencia técnica. El modelo de datos, las validaciones y los casos borde nacen del conocimiento del negocio: un cierre contable que ocurre el día 25, un pico estacional, una regla de redondeo que contabilidad exige. Cada una de esas particularidades termina convertida en una decisión técnica con consecuencias de negocio.

La prueba: dedica 30 minutos a explicar un proceso real de tu operación y pide que lo relate con sus palabras y señale dónde podría fallar un sistema que lo automatice. Observa si usa el vocabulario del negocio con precisión y si conecta cada decisión técnica con su efecto en la operación, por ejemplo, por qué un proceso debe poder ejecutarse dos veces sin generar una factura duplicada.


Cómo usar las señales

Las señales 1 y 2 se observan en la entrevista. Las 3 y 4 se confirman en la primera semana de trabajo. Califica cada una en tres niveles (ausente, presente con apoyo, presente de forma autónoma) e invita a un ingeniero senior del equipo a la prueba, porque quien va a convivir con el candidato percibe detalles que otro entrevistador pasa por alto.


Cómo lo abordamos en EmasT

En EmasT la selección parte de un criterio técnico específico para cada equipo y continúa con acompañamiento activo durante la integración. Detrás de cada persona hay respaldo técnico del resto del equipo. Con la IA apoyando la ejecución, el especialista dirige el desarrollo y valida cada entrega, y para eso necesita conocer el negocio a fondo.

Por eso, el mejor indicador de encaje suele ser un silencio: la pregunta que el desarrollador ya no necesita hacer, porque la operación empezó a hablar su idioma.

Si hoy estás sumando talento a tu equipo, con gusto comparamos criterios.

El encaje de un desarrollador se puede observar antes de firmar
Juanita Gomez 12 de noviembre de 2026
Compartir
Etiquetas
Archivo