6 min read
Estás en una entrevista técnica. Te piden invertir un árbol binario en una llamada mientras tres personas te miran en silencio.
Sabés cómo hacerlo, lo has hecho mil veces, pero con el pulso a 120 y sin tu editor se te traba la cabeza.
Salís pensando “soy un mal programador”.
Lo que en realidad pasó es que ese formato mide tu tolerancia al estrés en una situación artificial, no cómo trabajás un martes cualquiera.
Ahora imaginá estar del otro lado.
Te toca entrevistar y te piden “hacé unas preguntas técnicas”.
Sin rúbrica ni criterios claros, terminás decidiendo por intuición, y la intuición suele favorecer a quienes se parecen a vos.
Las entrevistas técnicas son un problema por los dos lados, y entender ambos te hace mejor candidato y mejor entrevistador.
Parte 1: si sos quien se presenta
Paso 1 — Entendé qué evalúan realmente
Una entrevista técnica suele medir cuatro cosas: conocimientos técnicos, forma de resolver problemas, comunicación, y cómo trabajarías con el equipo. Resolver el problema es solo una parte. Muchos candidatos fallan con la solución correcta porque no explicaron su razonamiento.
Paso 2 — Pensá en voz alta
Narrá lo que estás pensando: “Primero aclaro los requisitos, después considero un enfoque simple y veo si escala”. Si te trabás, quien te entrevista puede ayudarte, pero solo si sabe dónde estás. El silencio no se puede evaluar.
Paso 3 — Hacé preguntas antes de escribir código
¿Qué tamaño tienen los datos? ¿Hay casos borde? ¿Qué pasa con entradas inválidas? Las preguntas muestran criterio de ingeniería. Es lo que hacés en el trabajo real antes de implementar.
Paso 4 — Empezá simple y mejorá
Presentá primero una solución que funcione, aunque no sea óptima, y luego discutí cómo mejorarla. Una solución simple y correcta vale más que una elegante a medias.
Paso 5 — Preparate con práctica real
Resolvé problemas en voz alta, con tiempo limitado, idealmente con otra persona. Ensayá también las preguntas de comportamiento (“contame de un conflicto técnico con un compañero”) con el método STAR (Situation, Task, Action, Result — Situación, Tarea, Acción, Resultado).
Paso 6 — Entrevistá a la empresa también
Preguntá cómo es un día típico, cómo se hacen las revisiones de código, qué pasó en el último incidente, cómo se maneja la deuda técnica. La entrevista es una conversación en dos sentidos y las respuestas te dicen mucho sobre donde vas a trabajar.
Parte 2: si sos quien entrevista
Paso 1 — Definí qué buscás antes de entrevistar
Escribí 4 o 5 competencias concretas para el rol (por ejemplo: diseño de APIs, depuración, comunicación, colaboración). Si no podés decir qué buscás, no vas a poder decidir objetivamente.
Paso 2 — Usá entrevistas estructuradas
Hacé las mismas preguntas a todos los candidatos y evaluá con una rúbrica. Las investigaciones sobre selección de personal, incluida la que Google publicó en su iniciativa re:Work, muestran que las entrevistas estructuradas predicen mejor el desempeño que las improvisadas.
Paso 3 — Elegí problemas parecidos al trabajo real
Un ejercicio de revisar un Pull Request, depurar un servicio con un error, o diseñar un endpoint se parece mucho más al día a día que memorizar algoritmos de grafos. Evalúa lo que importa para el puesto.
Paso 4 — Ayudá al candidato a mostrar lo mejor de sí
Si se traba, dale una pista. Tu objetivo es descubrir qué puede hacer, no encontrar el punto donde se rompe. Una entrevista hostil además espanta a buenos candidatos, que tienen otras ofertas.
Paso 5 — Evaluá por escrito y antes de hablar con otros
Escribí tu evaluación y puntuación antes de la discusión del grupo. Así evitás que la opinión del más veterano influya sobre el resto.
Paso 6 — Dejá feedback útil
Si rechazás, compartí una o dos razones concretas cuando sea posible. Un candidato que aprende algo de tu entrevista habla bien de tu empresa aunque no lo contrates.
Una rúbrica simple para entrevistadores
| Competencia | Señales positivas | Señales de alerta |
|---|---|---|
| Resolución de problemas | Aclara requisitos, divide el problema, prueba su solución | Escribe código de inmediato sin entender el problema |
| Comunicación | Explica sus decisiones, escucha pistas | Silencio prolongado, ignora comentarios |
| Calidad del código | Nombres claros, considera casos borde | Ignora errores y entradas inválidas |
| Colaboración | Acepta feedback, reconoce lo que no sabe | Se pone a la defensiva, culpa a otros por fallos pasados |
El tema de la IA en las entrevistas
Hoy muchos candidatos usan herramientas de inteligencia artificial para programar en su trabajo diario, y muchas empresas todavía no definieron cómo tratarlo en las entrevistas.
Algunas recomendaciones para ambos lados:
- Candidatos: preguntá de antemano si se permite usar IA durante el ejercicio. Si no está permitido, no la uses a escondidas; si sí lo está, mostrá cómo la usás con criterio: verificás lo que genera, entendés el código y corregís los errores. Quien usa la IA sin entender lo que produce queda al descubierto rápido.
- Entrevistadores: definí una política clara y comunicala. Si el trabajo real implica usar IA, evaluar con ella puede ser más representativo. En ese caso lo que importa es el criterio: ¿detecta los errores del código generado? ¿Sabe qué pedir y cómo validar el resultado?
- En ambos casos, las preguntas de por qué (“¿por qué elegiste este enfoque?”) siguen siendo la mejor forma de distinguir comprensión de copiar y pegar.
Conclusión
Haber estado en los dos lados de la mesa te cambia la perspectiva: como candidato, entendés que el nerviosismo no te define; como entrevistador, entendés que tu proceso decide a quién incorporás y cómo se lleva esa experiencia cada persona.
Mejorar en ambos roles es una inversión de carrera, y de cultura de equipo.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
Cracking the Coding Interview — Gayle Laakmann McDowell
Google re:Work — Use structured interviewing: https://rework.withgoogle.com/en/guides/hiring-use-structured-interviewing