Cómo hacer una entrevista simulada de ingeniero de software

Probablemente ya has resuelto muchos problemas y aun así sientes que no estás listo, y la razón suele ser que resolver el problema por sí solo no es lo que la ronda realmente evalúa. Esta sección separa las tres rondas que usa un proceso de ingeniería de software, porque cada una necesita un tipo de práctica distinto y mezclarlas desperdicia la sesión.

• Codificación. 35 a 45 minutos, uno o dos problemas, pensar en voz alta mientras escribes. El objetivo de la práctica es narrar una solución que todavía estás construyendo.
• Diseño de sistemas. 45 a 60 minutos, una consigna abierta, sin aclaraciones a menos que las pidas. El objetivo de la práctica es acotar el problema antes de diseñarlo.
• Entrevista conductual. 45 minutos de historias de proyectos con repreguntas hostiles. El objetivo de la práctica es sobrevivir a la tercera repregunta sobre una decisión de la que te arrepientes.

Haz solo uno de estos tipos por sesión. Un proceso completo de tres horas se siente productivo pero casi no genera comentarios útiles, porque para la tercera ronda ya estás entrenando el cansancio y no la habilidad. Si buscas el banco de preguntas en lugar del mecanismo, hay una página aparte en el centro de entrevistas simuladas.

Las entrevistas simuladas en solitario fallan de una forma predecible: eliges un problema que sabes resolver, detienes el cronómetro cuando te atascas y terminas sintiéndote bien. Cada una de esas cosas es lo opuesto a las condiciones reales. En su lugar, reproduce las restricciones.

• No elijas tu propio problema. Toma uno de una lista que no hayas leído, o pide que alguien lo elija por ti. Elegir significa elegir algo cómodo.
• Inicia el cronómetro y nunca lo detengas. El tiempo atascado es información. Pausarlo elimina justo la presión que estás practicando.
• Iguala las herramientas. Si la ronda real usa un editor compartido sin autocompletado, sin botón de ejecutar y sin conjunto de pruebas, practica ahí.
• Habla con un cuarto vacío. Se siente absurdo y es la parte de mayor valor. Resolver problemas en silencio entrena una habilidad que nadie evalúa.
• Grábate. Verte a ti mismo es incómodo y te muestra las muletillas, los retrocesos y el minuto en que te quedaste callado.
• Diseña primero sin herramienta de diagramas. Muchas rondas de diseño son solo una llamada de voz y un documento en blanco.

Lo único que una entrevista simulada en solitario no puede ofrecer es la interrupción, y la interrupción es gran parte de lo que hace difícil una ronda real. Un entrevistador de IA puede cubrir justo ese vacío: hace la repregunta mientras estás a mitad de frase y no espera educadamente a que termines. El modo de entrevista simulada ejecuta las rondas de esta manera.

La mayoría termina una entrevista simulada anotando un veredicto general, que resulta inútil una semana después. Recopila observaciones concretas ligadas a un comportamiento que puedas cambiar.

• Tiempo hasta la primera pregunta de aclaración. Si supera los noventa segundos, estás resolviendo el problema equivocado.
• Silencio más largo. Cualquier silencio de más de veinte segundos necesita una frase de relleno hablada.
• ¿Dijiste tu enfoque antes de escribir código? Sí o no, cada vez.
• ¿Cómo te recuperaste al atascarte? Repetiste el problema, probaste un caso más pequeño o te quedaste paralizado.
• ¿La discusión sobre la complejidad fue provocada o espontánea? Lo espontáneo puntúa mejor.
• Para diseño: ¿acotaste antes de dibujar? Primero las restricciones y la escala, después los cuadros.

Una ingeniera backend que se preparaba para un proceso senior hizo doce entrevistas simuladas y las aprobó todas, y luego falló en la ronda real de código tras quedarse callada durante cuatro minutos ante una variante desconocida. Sus entrevistas simuladas nunca habían incluido un problema que no pudiera resolver, así que nunca había practicado lo único que realmente salió mal. Cambió una sola regla, permitiendo problemas por encima de su nivel, y el problema del silencio salió a la luz de inmediato.

No hay un número mágico, y a partir de cierto punto hacer más deja de dar resultado. Un patrón útil es hacer dos o tres simulaciones por tipo de ronda repartidas en dos semanas, y la revisión entre sesiones importa más que las sesiones mismas. Seis simulaciones sin revisión valen menos que tres con notas cuidadosas.

Ten claros los límites. Una entrevista simulada no puede decirte qué problema te tocará, no puede predecir el estilo de tu entrevistador y no sustituye el conocimiento real de la materia. Lo que sí corrige es la capa de la expresión: hablar mientras piensas, acotar antes de construir y recuperarte en voz alta cuando te atascas. Eso se transfiere por completo, y también son cosas que la lectura no puede enseñar.

La práctica y la asistencia en vivo son preguntas distintas con respuestas distintas. El ensayo no genera controversia. La asistencia durante una entrevista real depende del formato y de las reglas del empleador, y las rondas de código con pantalla compartida o supervisadas quedan totalmente fuera de alcance. Los límites, expuestos con honestidad, están en el centro de detectabilidad.