Entrevista con IA para desarrolladores junior, de bootcamp o en cambio de carrera
Actualizado en noviembre de 2026
Una entrevista con IA pregunta por su experiencia, y cuando esa experiencia es un bootcamp, la universidad, proyectos propios u otra carrera, es fácil quedarse en blanco o empezar pidiendo disculpas. No necesita un cargo de desarrollador para dar una buena respuesta. Necesita un caso real, contado con su contexto, su propia parte, su razonamiento y cómo terminó. Esta guía explica qué cuenta como experiencia, qué preguntan las entrevistas con IA a perfiles junior, dos ejemplos resueltos, cómo usar una carrera anterior como evidencia y cómo practicar gratis en nivel junior.
In English: AI interview prep for junior developers, bootcamp grads and career changers
Esta guía y la práctica para su rol están en español. La inscripción y la página de resultados de Aethel están en inglés, y la entrevista la puede hacer en español: lo elige justo antes de empezar.
Para quién es esta guía
- Egresados de un bootcamp que buscan su primer trabajo como desarrolladores.
- Estudiantes y recién egresados cuya experiencia son materias, una pasantía o una tesis.
- Personas autodidactas con proyectos propios, trabajos como freelancer o contribuciones a código abierto.
- Quienes cambian de carrera: docentes, enfermeras, contadores, personal de logística, comercio o soporte, cualquiera que llega a la programación con trabajo real detrás.
- Desarrolladores en sus primeros dos años que postulan a un puesto junior o a su primer puesto semi senior.
Qué cuenta como experiencia
Un entrevistador necesita un caso que pueda ubicar y sobre el que pueda repreguntar. Todo esto sirve si lo cuenta con la misma forma que cualquier historia de trabajo: dónde fue y de qué tamaño, qué hizo, por qué y cómo terminó.
- Un proyecto en equipo del bootcamp o de la universidad. Diga cuántas personas eran, cuánto duró, qué parte fue suya y una decisión que tomó. Casi todo el valor está en la parte que usted tuvo a cargo.
- Algo real para una persona real. La página de un negocio familiar, un formulario de inscripción para una parroquia, una herramienta para una maestra. Usuarios reales, aunque sean 12, le dan resultados para contar.
- Código abierto. Una contribución que pasó por revisión, aunque sea pequeña, muestra que puede leer código ajeno y aplicar comentarios.
- Una pasantía o una práctica profesional. Aunque sean pocas semanas, le dan un código, un equipo y alguien que revisa su trabajo. Diga qué cambió y qué le enseñó la revisión.
- Su propia app o herramienta. Un proyecto que publicó y mantuvo funcionando vale más que uno que solo corrió en su computadora. Diga quién lo usó y qué se rompió.
- Automatización en un trabajo anterior. Un script, una planilla o una pequeña herramienta que le ahorró tiempo a su equipo es trabajo de ingeniería real, con un antes y un después.
Un proyecto de tutorial que siguió paso a paso es la fuente más débil. Si es lo único que tiene, hable de lo que cambió o agregó más allá del tutorial, y por qué.
Qué preguntan las entrevistas con IA a desarrolladores junior
Un proyecto del que está orgulloso
“Cuénteme de un proyecto que construyó. ¿Qué parte fue suya y qué fue lo más difícil?”
Lo que se escucha: Un proyecto, su propia parte dicha en primera persona, un problema difícil y cómo supo que funcionaba.
Un error que lo trabó
“Describa un error en el que se quedó trabado. ¿Cómo salió adelante?”
Lo que se escucha: Cómo lo acotó, qué probó que no funcionó, a quién o a qué le preguntó, y la causa en una oración.
Aprender algo rápido
“Cuénteme de una vez que tuvo que aprender una herramienta o un lenguaje nuevo en poco tiempo.”
Lo que se escucha: Para qué lo necesitaba, cómo lo aprendió (la documentación, un experimento pequeño, una persona) y el plazo que cumplió o no cumplió.
Comentarios que recibió
“¿Qué comentario sobre su código le cambió la forma de trabajar?”
Lo que se escucha: El comentario tal como fue, por qué tenía razón o en qué parte, y qué hace distinto desde entonces.
Trabajar en equipo
“Cuénteme de un desacuerdo en un proyecto grupal y cómo se resolvió.”
Lo que se escucha: Un desacuerdo real sobre el trabajo, las dos posturas y lo que hizo usted, no quién estaba equivocado.
Su camino hacia la programación
“¿A qué se dedicaba antes, y qué de ese trabajo le sirve para programar?”
Lo que se escucha: Una habilidad o una costumbre concreta de su trabajo anterior, mostrada con un caso y no con una lista de fortalezas.
Algo que todavía no sabe
“¿Cómo encararía una tarea en una parte del sistema que nunca usó?”
Lo que se escucha: Un plan con un primer paso pequeño, cómo comprobaría su trabajo y cuándo pediría ayuda.
Ejemplo resuelto: el proyecto final de un bootcamp para una ferretería
Cada ejemplo muestra una respuesta débil y una fuerte a la misma pregunta. Las líneas "Con las reglas de Aethel" aplican las reglas de calificación publicadas de Aethel, un ejemplo concreto de cómo una entrevista con IA puede evaluar una respuesta.
Pregunta: “Cuénteme de un proyecto que construyó. ¿Qué parte fue suya y qué fue lo más difícil?”
Respuesta débil
“Para el proyecto final del bootcamp hicimos en equipo una tienda en línea para una ferretería. Usamos React, Node y PostgreSQL. Yo trabajé en varias partes, un poco de frontend y un poco de backend. Fue un desafío, pero aprendimos muchísimo y en la presentación final nos felicitaron.”
Por qué es débil: Hay un proyecto, pero ninguna parte es claramente suya, no dice qué fue difícil, y "aprendimos muchísimo" y "nos felicitaron" no son resultados. El entrevistador tiene que adivinar qué sabe hacer usted, y la repregunta obvia, "¿qué parte hizo usted?", empieza de cero.
Con las reglas de Aethel: Situación 1, razonamiento 0, resultado 0: 1 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.
Respuesta fuerte
“Para el proyecto final de mi bootcamp, tres compañeros y yo hicimos el catálogo en línea de una ferretería de barrio en Guadalajara, con unos 2.000 productos. Yo tuve a cargo la búsqueda. Lo difícil fue que los clientes buscaban con palabras que no estaban en el catálogo: en las primeras pruebas, el 35 por ciento de las búsquedas no daba ningún resultado, porque alguien escribía "taquete" y el producto se llamaba "ancla plástica". Revisé las 300 búsquedas sin resultado de esa semana y armé una tabla de sinónimos que el dueño puede editar desde un formulario sencillo. Consideré una búsqueda aproximada que corrige errores de escritura, pero no resolvía el problema de fondo, que eran nombres distintos para lo mismo, y devolvía resultados raros. Escribí 20 pruebas con búsquedas reales. Al terminar el bootcamp, las búsquedas sin resultado habían bajado al 9 por ciento, y el dueño siguió agregando sinónimos por su cuenta.”
Por qué es fuerte: Da el tamaño del equipo en una oración y dedica el resto a la parte que fue suya. El problema difícil sale de clientes reales, el arreglo es una decisión clara con la alternativa que descartó, y el resultado es un número comprobable, más pruebas que cuidan la regla.
Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 2: 6 de 8 puntos, que en la escala fija de Aethel son 87. Un puntaje real puede ser distinto.
Lo que viene después: Repregunta probable: ¿qué pasa si un sinónimo coincide con dos productos distintos? Tener la regla clara, por ejemplo mostrar los dos, es una buena respuesta de nivel junior.
Ejemplo resuelto: una contadora que automatizó la conciliación bancaria
Pregunta: “¿A qué se dedicaba antes, y qué de ese trabajo le sirve para programar?”
Respuesta débil
“Antes trabajé siete años como contadora, pero siempre me gustó la tecnología, así que decidí cambiar de carrera. De mi trabajo anterior traigo responsabilidad, orden y atención al detalle, que creo que son muy importantes para un desarrollador.”
Por qué es débil: Responsabilidad, orden y atención al detalle son cualidades que cualquiera puede decir, sin un caso detrás. Siete años de trabajo real quedan sin usar, y el entrevistador se entera de qué le gusta, no de qué sabe hacer.
Con las reglas de Aethel: Situación 0, razonamiento 0, resultado 0: 0 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.
Respuesta fuerte
“Trabajé siete años como contadora en una empresa de transporte en Bogotá, con unos 400 movimientos bancarios al día. En cada cierre de mes, dos personas pasábamos tres días conciliando a mano los extractos del banco con el sistema contable, y aun así quedaban diferencias sin explicar. Separé las diferencias de un mes y vi que casi todas venían de pagos agrupados: el banco registraba una sola transferencia por varias facturas. Escribí un script en Python que leía los dos archivos, buscaba combinaciones de facturas que sumaran el monto de cada transferencia y dejaba para revisión manual solo lo que no cuadraba. Evalué pedirle al área de sistemas un módulo dentro del software contable, pero la espera era de seis meses y el problema se repetía cada mes. La conciliación pasó de tres días a medio día, las diferencias sin explicar bajaron de unas 60 a 5 por cierre, y el área de tesorería empezó a usar el mismo script. Ese proyecto me llevó a estudiar programación, y conservo la costumbre: busco el patrón en los datos antes de cambiar algo, y compruebo el número después.”
Por qué es fuerte: Trata el trabajo anterior como un caso real: el tamaño, un problema medido, un diagnóstico hecho con datos, una alternativa descartada con su razón y un resultado que otra área adoptó. El final conecta con la programación en una oración honesta, sin disfrazar la contabilidad de ingeniería.
Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 3: 7 de 8 puntos, que en la escala fija de Aethel son 91. Un puntaje real puede ser distinto.
Lo que viene después: Repregunta probable: ¿qué hacía el script cuando dos combinaciones distintas de facturas sumaban el mismo monto? Tener esa regla clara muestra criterio técnico, no solo entusiasmo.
Cómo usar su carrera anterior como evidencia
Si trabajó antes de aprender a programar, ya tiene casos que un entrevistador puede usar. Búsquelos en su trabajo anterior:
- Un proceso que hizo más rápido o más seguro. Una lista de pasos, una plantilla, un horario o una planilla que redujo errores o tiempo. Requiere el mismo criterio que un cambio de código, y tiene un antes y un después.
- Un problema que diagnosticó. Descubrir por qué no cuadraba el inventario, por qué un reporte no sumaba o por qué se perdía información en el cambio de turno es depurar.
- Explicar algo difícil. Dar una clase, capacitar a alguien nuevo o explicarle una factura a un cliente molesto se parece mucho a explicarle un riesgo técnico a alguien que no es ingeniero.
- Trabajar con presión y con reglas. Turnos, plazos, auditorías y normas de seguridad se parecen a los lanzamientos y a las guardias. Diga qué hizo cuando algo salió mal.
Sea honesto: describa lo que hacía en ese trabajo con las palabras de ese trabajo, y después diga en una oración cómo se nota en su trabajo como desarrollador. No disfrace su trabajo anterior de trabajo de software.
Errores comunes en las respuestas de nivel junior
- Empezar pidiendo disculpas. "No tengo experiencia real, pero..." le dice al entrevistador que descuente lo que viene después. Empiece por el caso.
- Contar un tutorial como diseño propio. Si siguió un curso, dígalo, y después hable de la parte que usted cambió. Una repregunta va a encontrar la diferencia de todos modos.
- "Nosotros" de principio a fin. En un proyecto grupal, el entrevistador quiere su parte. Diga "yo" para lo que hizo usted y nombre lo que hicieron sus compañeros.
- Enumerar lo que aprendió. "Aprendí React, Node, SQL y Git" es un temario, no una respuesta. Elija una cosa y muéstrela funcionando en un proyecto.
- Esconder su carrera anterior. Diez años como docente o como enfermera no son un hueco que haya que justificar. Muchas veces ahí está su mejor evidencia de criterio y de comunicación.
- Inflar los números. Los números pequeños sirven: 12 personas que lo probaron, 40 pedidos por semana, 3 compañeros. Una escala inventada se cae en la primera repregunta.
Números que conviene tener a mano, aunque sean pequeños
- Cuántas personas usaron lo que construyó, aunque fueran 12 compañeros o un solo negocio
- Cuánto duró el proyecto y cuántas personas trabajaron en él
- Pruebas que escribió, errores que cerró o contribuciones que se aceptaron
- Tiempo o errores que ahorró una herramienta o un cambio, antes y después
- El tamaño de los datos: filas, productos, registros o archivos
- De un trabajo anterior: las personas, turnos, pedidos, alumnos o el presupuesto que tenía a cargo
Practique gratis en nivel junior
La página de práctica en español tiene un nivel junior para cada rol de desarrollo, pensado para hasta 2 años de experiencia, un bootcamp o un cambio de carrera. Elija su rol, escriba una respuesta a cada pregunta y lea la revisión rápida después de cada una. Es gratis, no necesita cuenta, no se guarda nada y no es un puntaje.
Preguntas de perfiles junior y de quienes cambian de carrera
¿Un proyecto de bootcamp cuenta como experiencia?
Para un puesto junior, sí, si lo cuenta como un caso: el proyecto, el equipo, su parte, una decisión y cómo terminó. Diga que fue un proyecto del bootcamp. Lo que lo debilita es la vaguedad, no el lugar donde lo hizo.
¿Conviene mencionar mi carrera anterior en una entrevista de desarrollo?
Sí, en pocas palabras y con un caso. Una historia de su trabajo anterior que muestre cómo resuelve problemas o cómo explica las cosas suele pesar más que un segundo proyecto de programación.
Mi proyecto fue en equipo. ¿Cómo hablo de él sin atribuirme todo?
Diga en una oración cuántos eran y qué hicieron los demás, y dedique el resto de la respuesta a su parte. "Éramos cuatro; yo tuve a cargo la búsqueda y las pruebas" es honesto y específico.
Mi proyecto nunca tuvo usuarios reales. ¿Qué digo como resultado?
Use lo que se puede comprobar: pruebas que pasan, una página que carga en menos de un segundo, un error que ya no ocurre, el comentario de quien revisó su código. Diga con claridad que no tuvo usuarios reales, y qué mediría si los tuviera.
¿Puedo hacer la entrevista de Aethel sin haber trabajado como desarrollador, y en español?
Sí. La entrevista de Aethel es gratuita, dura unos 15 minutos y pregunta por su propio trabajo, que puede ser un proyecto, la universidad o una carrera anterior. La puede hacer en español: lo elige justo antes de empezar. Sus reglas de calificación publicadas evalúan el caso que usted cuenta (la situación, su razonamiento y el resultado) con una escala igual para todos, y una respuesta de menos de 8 palabras no cuenta como respuesta.
Más guías
- Entrevista con IA para desarrolladores backend
- Entrevista con IA para desarrolladores frontend
- Entrevista con IA para desarrolladores full-stack
- Entrevista con IA para ciencia de datos y machine learning
- Entrevista con IA para ingenieros de DevOps y SRE
- Entrevista con IA para desarrolladores iOS y Android
Empiece por la guía general: Cómo prepararse para una entrevista técnica con IA.