La entrevista para un puesto junior de desarrollo genera una ansiedad particular: la sensación de que en cualquier momento llega la pregunta que deja al descubierto lo que falta saber. Esa ansiedad parte de un malentendido. Nadie espera que un junior sepa todo; se espera que razone, que aprenda rápido y que sea honesto sobre sus límites.
Esta guía explica qué se evalúa de verdad, qué preguntas técnicas y de comportamiento aparecen con más frecuencia, y cómo manejar dos momentos definitorios: el "no lo sé" y los proyectos propios.
En esta guía
Qué se evalúa de verdad en un junior
Contratar un junior es una inversión: la empresa sabe que los primeros meses son de formación. Por eso el entrevistador no busca conocimiento enciclopédico sino tres señales de que la inversión va a rendir.
La primera es el razonamiento: frente a un problema nuevo, importa más el camino que la respuesta. La segunda es la capacidad de aprendizaje: qué aprendió la persona por su cuenta y cómo investiga cuando se traba. La tercera es la honestidad técnica: un junior que dice "no lo sé" y muestra cómo lo averiguaría es contratable; uno que inventa respuestas es un riesgo, porque va a inventar también en el trabajo.
Las preguntas técnicas típicas
Los temas varían según el stack, pero el patrón se repite entre empresas:
| Tema | Pregunta típica | Qué evalúa |
|---|---|---|
| Fundamentos del lenguaje | "¿Qué diferencia hay entre una lista y un diccionario?" | Si la base es sólida o se aprendió copiando fragmentos |
| Lógica y estructuras de datos | Un ejercicio corto, resuelto en voz alta | El razonamiento, no la solución óptima |
| Git y trabajo en equipo | "¿Cómo resolvés un conflicto de merge?" | Si la persona puede sumarse a un flujo real desde la primera semana |
| Bases de datos y APIs | Una consulta SQL simple, qué es una API REST | Comprensión del sistema completo, no solo del fragmento programado |
| El propio código | "¿Por qué lo resolviste así?" | Si entiende su código o lo copió, filtro frecuente en tiempos de IA |
En puestos junior los ejercicios suelen ser simples a propósito: lo observado es el proceso, no la velocidad. Frente a cualquier consigna técnica conviene repetir el enunciado con palabras propias y plantear el enfoque antes de ejecutarlo.
Pensar en voz alta no es opcional: es el producto que se evalúa. Un candidato que se queda en silencio dos minutos y da la respuesta correcta puntúa peor que uno que narra su razonamiento, se equivoca y se corrige.
Las preguntas de comportamiento
La mitad no técnica de la entrevista pesa más de lo que los candidatos junior suponen. Las clásicas del formato general (presentación, motivación, fortalezas y debilidades) están en la guía de preguntas frecuentes de entrevista; estas son las del perfil:
- "¿Cómo aprendiste a programar?" No hay respuesta incorrecta (universidad, bootcamp, autodidacta), pero sí una estructura fuerte: qué se eligió aprender, por qué, y qué se construyó con eso.
- "Contame de un bug que te costó resolver." Evalúa método de debugging y tolerancia a la frustración. La respuesta fuerte narra el proceso: qué se probó, cómo se aisló el problema y qué enseñó.
- "¿Qué hacés cuando te trabás con algo que no sale?" Evalúa autonomía con criterio. "Nunca pido ayuda" es tan mala respuesta como "pregunto enseguida".
- "¿Qué tecnología estás aprendiendo ahora?" Mide si el aprendizaje sigue activo, la señal número uno del perfil junior que rinde.
Cómo responder "no lo sé" bien
En una entrevista junior llegan preguntas sin respuesta, a veces puestas a propósito para ver la reacción. Una fórmula de tres pasos convierte ese momento en un punto a favor: admitir sin rodeos, acercarse con lo que sí se sabe, y explicar cómo se averiguaría.
"No trabajé con Redis, así que no quiero inventar. Sé que es una base de datos en memoria y que se usa mucho para caché, así que asumo que la ventaja es la velocidad de lectura. Si lo necesitara en un proyecto, empezaría por la documentación oficial y armaría una prueba chica antes de tocar nada real."
Esa respuesta muestra honestidad, base para razonar y método de aprendizaje: las tres señales que la entrevista busca. La alternativa (improvisar una definición) falla siempre, porque el entrevistador conoce la respuesta y la repregunta llega.
Cómo hablar de proyectos propios
Sin experiencia laboral, los proyectos son la experiencia. De cada proyecto del portfolio hay que poder contar cuatro cosas: qué problema resuelve, qué decisiones técnicas hubo, qué fue lo más difícil y qué se haría distinto hoy. Esa última es la favorita de los entrevistadores, porque mide autocrítica técnica.
Dos proyectos defendibles en profundidad valen más que seis tutoriales apenas modificados. Si un proyecto tiene usuarios reales, aunque sean diez, ese dato va primero. Los mismos proyectos deben estar bien contados en el papel: la guía de CV sin experiencia explica cómo presentarlos con formato de logros.
Errores frecuentes del junior en entrevista
- Inventar cuando no se sabe. El error más caro: la repregunta lo expone y arrastra la credibilidad del resto.
- Resolver en silencio. El razonamiento no narrado no existe para el entrevistador.
- No poder explicar el propio portfolio. Señal de código copiado sin digerir.
- Disculparse de más. Empezar cada respuesta con "seguro está mal, pero..." erosiona la impresión general.
- Llegar sin preguntas propias. Preguntar por el stack, el code review o cómo se acompaña a los juniors demuestra criterio.
- No ensayar la parte hablada. Explicar código en voz alta se entrena; una entrevista simulada con IA permite practicar preguntas del rol en el simulador de entrevista antes de la real.
Preguntas frecuentes
¿Qué preguntan en una entrevista para programador junior?
Fundamentos del lenguaje principal, estructuras de datos básicas, Git, alguna consulta SQL o concepto de API, y preguntas de comportamiento: cómo se aprendió a programar, un bug difícil, qué se hace al trabarse. Si hay portfolio, preguntas sobre las decisiones de ese código.
¿Hay que saber resolver algoritmos complejos para un puesto junior?
En la mayoría de los puestos junior, no. Los ejercicios suelen ser de lógica simple y lo evaluado es el razonamiento en voz alta, no la solución óptima. Las excepciones, algunas empresas grandes con procesos competitivos, se anticipan en el aviso.
¿Qué pasa si no se sabe la respuesta a una pregunta técnica?
Es esperable y hasta forma parte del diseño de la entrevista. La respuesta correcta tiene tres pasos: admitirlo sin rodeos, aportar lo que sí se sabe y explicar cómo se averiguaría. Inventar una respuesta es el único camino descalificante.
¿Cuántos proyectos conviene tener en el portfolio?
Dos o tres que se puedan defender en profundidad: qué problema resuelven, qué decisiones técnicas tienen detrás, qué fue lo difícil y qué se cambiaría hoy. Superan a cualquier lista de tutoriales replicados.
¿Cómo se practica una entrevista técnica junior?
En voz alta, que es como ocurre la real: explicar un proyecto propio a otra persona, narrar el razonamiento de un ejercicio simple mientras se resuelve y ensayar las preguntas de comportamiento con un simulador que repregunte.