Las preguntas de entrevista no salen de la nada esa misma mañana. En casi todo proceso estructurado, la persona que te entrevista recibió la misma oferta de trabajo que leíste tú, le dijeron que averiguara si sabes hacer lo que pone ahí, y la dejaron inventarse preguntas a partir de esas líneas. Por eso las preguntas se parecen tanto a los puntos de la lista. Son los puntos de la lista, dados la vuelta.
Lo que convierte una oferta de trabajo en un banco de preguntas disfrazado, si la lees en la dirección correcta. Un requisito se convierte en una pregunta sobre tu experiencia. Una responsabilidad se convierte en un escenario. Una línea sobre el entorno se convierte en una pregunta conductual. Aprende la conversión y la entrevista deja de ser una lotería y pasa a ser un temario.
Abajo tienes las seis reglas de mapeo, un ejemplo resuelto y qué hacer con el resultado. Si prefieres saltarte el paso manual, pega la oferta en el Question Predictor gratuito y obtendrás las veinte preguntas que esa entrevista tiene más probabilidades de hacerte, agrupadas por tipo, con lo que sondea cada una. Sin cuenta, sin email, resultados al instante.
¿De verdad se pueden predecir las preguntas de entrevista a partir de una descripción del puesto?
En su mayor parte, sí. No puedes saber la formulación exacta, pero sí puedes reducir cientos de preguntas posibles a unas veinte, porque el entrevistador trabaja con el mismo documento que tú. Cada requisito, cada responsabilidad y cada línea sobre cultura de esa oferta lleva una pregunta obvia asociada, y los entrevistadores tiran de la obvia mucho más a menudo de lo que los candidatos esperan.
Lo que no puedes predecir es la cola: la pregunta fetiche del entrevistador, la tangente que toma porque algo de tu CV le llamó la atención, el acertijo de algoritmos sacado de un banco compartido. Esa cola es real y también es pequeña. Ten listas las veinte que salen de la oferta y la cola será lo único que improvises, que es un problema completamente distinto.
¿Por qué las ofertas de trabajo predicen las preguntas de forma tan fiable?
Porque la oferta suele ser el primer borrador de la plantilla de evaluación. Un responsable de contratación apunta lo que la persona tiene que hacer, selección lo convierte en un anuncio, y esa misma lista vuelve como los criterios con los que puntúan los entrevistadores. Nadie escribe un conjunto secreto y aparte de requisitos. El documento que usaste para decidir si te presentabas es el que ellos usan para decidir si te contratan.
La contratación estructurada aprieta más esto. Cuando una empresa usa una rúbrica, el entrevistador tiene un formulario con competencias en una columna y hueco para las evidencias al lado de cada una, y su trabajo es salir de la sala con eso relleno. La forma más rápida de conseguirlo es preguntar directamente por cada criterio. Las entrevistas no estructuradas acaban en el mismo sitio por una vía más perezosa: un entrevistador sin nada preparado le echa un vistazo a la oferta cinco minutos antes y pregunta por lo que sea que ponga.
¿Cómo conviertes una descripción del puesto en preguntas de entrevista?
Repasa la oferta línea a línea y aplica seis reglas. Cada tipo de línea se convierte en un tipo de pregunta predecible: los requisitos se convierten en preguntas de experiencia con un sondeo de profundidad detrás, las responsabilidades se convierten en escenarios, el lenguaje sobre el entorno se convierte en preguntas conductuales, los deseables se convierten en sondeos de curiosidad, los temas repetidos se convierten en el centro de gravedad, y los verbos deciden si las preguntas van de hacer o de decidir.
1. Un requisito de la lista se convierte en "cuéntame tu experiencia con X", y luego en un sondeo de profundidad. La línea "más de 4 años de experiencia en backend, idealmente en Python" se convierte en "cuéntame tu experiencia con Python", y luego en "¿cuál es el bug más incómodo que has tenido que rastrear en un servicio en Python?". La primera pregunta comprueba que la afirmación existe. La segunda comprueba que es real, porque cualquiera puede decir cuatro años y solo quien los ha vivido tiene una batallita asociada. Para cada requisito duro, ten un artefacto preparado: algo que construiste, decidiste o arreglaste.
2. Una responsabilidad se convierte en una pregunta de escenario. La línea "responsabilizarte de la fiabilidad de la API de seguimiento, incluida la participación en una rotación de guardias" se convierte en "cuéntame el peor incidente por el que te han llamado estando de guardia, y qué hiciste en los diez primeros minutos". Las responsabilidades describen de qué van a estar llenos tus días, así que los entrevistadores las ponen a prueba pidiéndote que narres un día que ya ocurrió. Una responsabilidad rara vez se convierte en una pregunta de conocimiento; se convierte en una petición de historia, y las historias necesitan detalles concretos.
3. Una línea sobre cultura o entorno se convierte en una pregunta conductual. Son las líneas que los candidatos leen por encima, y están entre los predictores más fiables del documento. "Entorno de ritmo rápido donde los requisitos cambian" se convierte en una pregunta sobre priorización y sobre qué dejaste caer. "Cómodo con la ambigüedad" se convierte en una pregunta sobre una decisión tomada sin el cuadro completo. "Interfuncional" se convierte en una pregunta sobre cómo influyes en gente que no te reporta. La empresa está nombrando la fricción que allí es normal, y los entrevistadores sondean esa fricción.
4. Un "deseable" se convierte en un sondeo de curiosidad y en una oportunidad de enseñar tu velocidad de aprendizaje. La línea "experiencia con Kubernetes o Terraform es un plus" se convierte en "¿has hecho algo con Terraform?", preguntado a la ligera, a menudo cerca del final. También se puntúa a la ligera, y por eso es el sitio más barato de toda la entrevista para ser honesto. Di lo que de verdad has tocado y luego enseña el patrón: la última herramienta desconocida que aprendiste, cuánto tardaste, qué entregaste con ella. Farolear aquí es el peor cambio disponible; lo que ganas es una fracción de punto y lo que pierdes es que todo lo demás que has afirmado quede descontado en silencio.
5. Una palabra o un tema que se repite es el centro de gravedad de la entrevista. Vuelve a leer la oferta con un boli y cuenta sustantivos. Si "escala", "clientes", "precisión de los datos" o "migración" aparecen tres veces o más en secciones distintas, eso no es relleno, eso es lo que no deja dormir al responsable de contratación. Genera varias preguntas en lugar de una, probablemente será el tema de cualquier ejercicio de diseño de sistemas, y es donde una respuesta vaga te sale más cara.
6. Los verbos de seniority te dicen si las preguntas van de hacer o de decidir. Compara "participar en las revisiones de código" con "definir nuestro enfoque de calidad del código". El primero invita a preguntas de ejecución: qué hiciste, cómo, cómo sabes que funcionó. El segundo invita a preguntas de criterio: por qué ese enfoque y no la alternativa, qué sacrificaste, cómo conseguiste que los demás lo aceptaran. Ayudar, apoyar y participar apuntan a hacer. Responsabilizarse, liderar, definir e impulsar apuntan a decidir, y un candidato que responde a una pregunta de decidir con una historia de ejecución suena un nivel demasiado junior.
¿Cómo se ve el mapeo sobre una oferta de trabajo real?
Aquí tienes un extracto de un puesto de backend de nivel medio en una empresa de logística de tamaño medio, escrito como se escriben las ofertas reales y no de la forma ordenada en que suelen escribirse los ejemplos. Cada línea se convierte en algo. La tabla de debajo da la pregunta probable y, más útil todavía, lo que se está sondeando de verdad.
Ingeniero de backend (nivel medio)
- Construir y mantener los servicios en Python que hay detrás de nuestra plataforma de seguimiento de envíos.
- Responsabilizarte de la fiabilidad de la API de seguimiento, incluida la participación en una rotación de guardias.
- Trabajar con el equipo de datos para mantener los feeds de eventos de las transportistas precisos y al día.
- Diseñar y hacer evolucionar nuestros esquemas de PostgreSQL a medida que crece el volumen de envíos.
- Colaborar con producto y operaciones para convertir problemas vagos de almacén en funcionalidades entregadas.
- Participar en las revisiones de código y ayudar a subir el nivel del código base.
Requisitos: Más de 4 años de experiencia en backend, idealmente en Python. SQL sólido, incluido trabajo de rendimiento. Experiencia con colas de mensajes (usamos Kafka). Cómodo en un entorno de ritmo rápido donde los requisitos cambian.
Deseable: haber tocado sistemas de logística o de cadena de suministro; Kubernetes o Terraform.
| Línea de la oferta | La pregunta en la que probablemente se convierte | Qué se está sondeando de verdad |
|---|---|---|
| Construir y mantener servicios en Python | Explícame un servicio en Python que hayas construido de punta a punta | La profundidad de lo que afirmas, y si mantuviste algo el tiempo suficiente como para arrepentirte de una decisión |
| Responsabilizarte de la fiabilidad, rotación de guardias | Cuéntame el peor incidente por el que te han llamado estando de guardia | Si de verdad has llevado el busca, y si culpas a las personas o a los sistemas |
| Trabajar con el equipo de datos en la precisión de los feeds | ¿Cómo detectarías que un feed aguas arriba se ha estropeado? | Instinto para la corrección de los datos, y cómo manejas un problema que no te toca arreglar a ti |
| Diseñar y hacer evolucionar esquemas de PostgreSQL | Cuéntame un cambio de esquema en una tabla que ya era grande | Criterio para migraciones, bloqueos y tiempo de caída, y disposición a planificar una reversión |
| Colaborar con producto y operaciones en problemas vagos de almacén | Cuéntame una vez en que los requisitos eran vagos y tuviste que decidir qué construir | Si replicas o construyes lo que no toca en silencio, y si tratas a la gente de operaciones como usuarios o como tickets |
| Participar en las revisiones de código | ¿Cómo das feedback en un pull request con el que no estás de acuerdo? | El tono cuando hay fricción, y si los estándares sobreviven a la presión del calendario |
| Más de 4 años, idealmente en Python | Tu experiencia con Python, y luego el bug más difícil que hubo en ella | Que la afirmación exista, y luego que sea real |
| SQL sólido y trabajo de rendimiento | Cuéntame una consulta lenta que arreglaste | Si sabes leer un plan de ejecución o solo reescribes consultas a ver si suena la flauta |
| Experiencia con Kafka | Explícame un consumidor que se quedó atrás y qué hiciste | Experiencia real operándolo, porque la documentación se la ha leído todo el mundo |
| Ritmo rápido, requisitos que cambian | Cuéntame una vez en que las prioridades cambiaron a mitad de proyecto | Tus criterios de priorización, y si te quejas |
| Deseable: Kubernetes o Terraform | ¿Has llegado a tocar Terraform? | Honestidad, y a qué velocidad aprendes herramientas que no conoces |
Salen dos cosas. El centro de gravedad es la corrección de los datos con un volumen creciente, porque envíos, feeds, esquemas, colas y escala apuntan a una sola preocupación, y ahí es donde aterrizan varias preguntas. Y los verbos están mezclados: "responsabilizarte" y "diseñar" están junto a "participar", así que el puesto decide sobre la API de seguimiento y simplemente ejecuta en calidad del código. Prepara respuestas de criterio para lo primero y respuestas de ejecución para lo segundo.
¿Cómo priorizas qué preparar?
Prepárate contra temas, no contra preguntas. Veinte preguntas predichas no son veinte respuestas que escribir; son cinco o seis temas con sombreros distintos. Agrupa las preguntas por lo que sondean, elige seis u ocho episodios reales de tu carrera y mapea cada uno a dos o tres temas. Ese mapeo es el truco: bajo presión quieres elegir de un conjunto conocido, no rebuscar en tu memoria desde cero.
Coge el ejemplo de logística. Esas preguntas se reducen a cinco temas: profundidad en el stack que nombran, responsabilidad cuando algo falla, criterio sobre datos y migraciones, trabajo con perfiles no técnicos, y comportamiento cuando las prioridades se mueven. Una buena historia sobre una migración que salió mal sirve a la vez para responsabilidad, criterio y presión, según con qué momento la abras. Escribe el mapeo de historias a temas en una sola página y repasa de ahí, no de la lista de preguntas.
Estructura cada historia con STAR (Situación, Tarea, Acción, Resultado), porque es con lo que puntúan la mayoría de las rúbricas y porque evita que entierres tu contribución bajo tres minutos de contexto. Nuestra guía del método STAR tiene respuestas completas resueltas, y la guía de preguntas conductuales de entrevista cubre las veinte que se repiten sea cual sea el puesto, la capa base sobre la que se apoyan tus preguntas específicas de la oferta. Luego ensaya en voz alta con un cronómetro, porque una historia que sobre el papel parece apretada se estira a cuatro minutos cuando la dices.
¿Qué me van a preguntar en una entrevista?
Con honestidad, nadie puede decirte las preguntas exactas, y quien diga lo contrario te está vendiendo algo. Lo que hace la oferta es recortar el campo a unas veinte preguntas probables, que son las suficientemente pocas como para prepararlas bien. El método es mecánico: convierte cada línea con las seis reglas, ordena por cuántas veces se repite cada tema y prepárate de arriba abajo.
Las veinte se reparten de forma bastante constante. Espera cinco o seis preguntas de experiencia salidas directamente de la lista de requisitos, cada una con un sondeo de profundidad detrás. Espera cuatro o cinco preguntas de escenario a partir de las responsabilidades, que son peticiones de historia y no comprobaciones de conocimiento. Espera cinco o seis preguntas conductuales de las líneas de entorno y cultura, dos o tres sondeos ligeros sobre los deseables, y las dos que salen en prácticamente todas las entrevistas jamás hechas: "háblame de ti" y "por qué este puesto".
Haz la conversión a mano una vez, porque te cambia para siempre la forma de leer las ofertas. Después, ahórrate la hora: pega la oferta en el predictor gratuito y te devuelve las veinte preguntas más probables de esa entrevista, agrupadas por tipo, con una nota sobre qué sondea cada una. Sin cuenta, sin email, resultados al instante. Predice, no sabe, y ese es el planteamiento honesto: un buen mapa de dónde salen las preguntas, no una copia de las notas del entrevistador.
Preguntas frecuentes
¿Puedo predecir las preguntas técnicas a partir de la descripción del puesto?
Los temas sí, los acertijos no. La oferta nombra el stack, los datos y los modos de fallo, lo que predice de forma fiable los enunciados de diseño de sistemas y los sondeos de profundidad específicos del lenguaje. No puede predecir una pregunta de algoritmos, porque esas suelen salir de un banco interno compartido y rara vez tienen relación con el puesto. Prepárate a fondo el stack que nombran y practica algoritmos por separado.
¿Y si la descripción del puesto es vaga?
Una oferta vaga es en sí misma una predicción: las líneas genéricas producen preguntas genéricas, así que espera el set conductual estándar más un repaso amplio de tu CV. Los huecos rellénalos en otro sitio. La página de empleo de la empresa, el trabajo público del equipo, sus publicaciones técnicas recientes, y el reclutador, que normalmente te describirá la estructura de las rondas y quién te va a entrevistar si se lo preguntas.
¿Debería preparar las respuestas palabra por palabra?
No. Las respuestas memorizadas salen planas y se caen en cuanto la pregunta viene formulada de otra manera que la versión que aprendiste. Aprende cada historia como cinco o seis momentos clave con un número al final, y luego dila en voz alta hasta que esos momentos se mantengan en orden bajo presión. Las únicas frases que merece la pena fijar exactamente son la primera y el resultado con el que cierras.