Entrevista de programador junior: preguntas, prueba técnica y consejos

En un puesto de programación junior nadie espera que lo sepas todo. Lo que se evalúa es cómo razonas, cómo aprendes y cómo trabajas con otras personas. Saber explicar bien un proyecto propio suele pesar más que memorizar teoría.

Cómo suele ser el proceso

• Una primera entrevista con recursos humanos o con quien selecciona perfiles técnicos: motivación, formación y expectativas.
• Una prueba técnica, que puede ser:
  • un ejercicio para hacer en casa en unos días;
  • live coding: resolver un problema en directo, compartiendo pantalla;
  • un test de conceptos (lenguaje, SQL, Git).
• Una entrevista técnica con el equipo, en la que se comenta la prueba y tus proyectos.

Qué se valora

• Fundamentos: estructuras de datos básicas, lógica, el lenguaje de la oferta.
• Cómo razonas: que expliques lo que haces y por qué, aunque no llegues a la solución perfecta.
• Código legible: nombres claros, funciones pequeñas, algún test.
• Herramientas de equipo: Git, revisiones de código, tickets.
• Ganas de aprender y capacidad de pedir ayuda a tiempo.

La prueba técnica: cómo afrontarla

1. Lee el enunciado dos veces y haz preguntas si algo no está claro.
2. Piensa en voz alta en el live coding: quien te entrevista quiere ver tu razonamiento.
3. Empieza por una solución que funcione y mejórala después.
4. Prueba tu código con un par de casos, incluido algún caso límite.
5. Si es un ejercicio para casa: README con cómo ejecutarlo, decisiones tomadas y qué mejorarías con más tiempo.

Si te atascas, dilo y explica qué estás pensando. Quedarse en silencio es peor que equivocarse.

Preguntas frecuentes y cómo responder

«Háblame de un proyecto del que estés orgulloso u orgullosa»

Elige un proyecto que conozcas a fondo (del bootcamp, del ciclo, de la carrera o personal) y explica el problema, tu papel, las decisiones técnicas y lo que aprendiste. Ten el repositorio a mano.

En el proyecto final del ciclo hicimos una aplicación de reservas para un gimnasio en equipo de tres. Yo me encargué de la API y la base de datos. Al principio las reservas se pisaban cuando dos personas reservaban a la vez la última plaza; lo resolví con una restricción en la base de datos y añadí tests para ese caso. Aprendí que los errores más difíciles aparecen cuando varias cosas pasan a la vez.

«¿Qué haces cuando te atascas con un problema?»

Describe tu proceso: leer el error con calma, reproducirlo, buscar en la documentación, aislar el problema y, si pasa un tiempo razonable, preguntar a alguien explicando qué has probado.

«¿Cómo usas Git en tu día a día?»

Ramas, commits pequeños con mensajes claros, pull requests y cómo resuelves un conflicto. Si has hecho revisiones de código, menciónalo.

«¿Qué estás aprendiendo ahora?»

Ten una respuesta real y concreta. Demuestra curiosidad, mejor si tiene relación con lo que usa la empresa.

Otras preguntas habituales

• «Háblame de ti».
• «¿Qué diferencia hay entre una lista y un diccionario (o un array y un objeto)?».
• «¿Qué es una API REST?».
• «¿Cómo escribirías una consulta SQL para…?».
• «¿Por qué quieres trabajar con nuestro stack?».

Errores que conviene evitar

• Fingir que sabes algo que no sabes. Es mejor decir «no lo he usado, pero lo entiendo así…».
• Proyectos en el CV que no puedes explicar.
• Código de la prueba sin probar o sin instrucciones.
• No preguntar nada sobre el equipo: cómo se revisa el código, cómo es la incorporación, quién te acompañará al principio.

Cómo prepararla

Repasa tu proyecto principal hasta poder explicarlo en dos minutos, practica dos o tres ejercicios en voz alta como si fuera un live coding y prepara preguntas para el final sobre cómo trabaja el equipo.