Entrevistas en tecnología: qué buscan los gerentes de ingeniería

En las entrevistas de tecnología, para puestos de ingeniería de software, TI, datos, DevOps, QA y seguridad, lo que más cuenta es cómo piensas. Un gerente de contratación (hiring manager) quiere verte descomponer un problema, sopesar pros y contras, explicar tu razonamiento con claridad y hacerte responsable del resultado. Conocer un framework específico ayuda, pero rara vez decide la oferta por sí solo.

En Offermic, el entrevistador de tecnología hace el papel de gerente sénior de ingeniería: técnico pero de tono conversacional, e interesado sobre todo en si puedes explicar ideas complejas de forma sencilla. Esta página cubre lo que busca ese tipo de entrevistador y cómo prepararte.

¿Qué buscan los entrevistadores de tecnología?

Hay cinco señales que aparecen una y otra vez:

1. Un enfoque estructurado. Aclaras el problema, planteas hipótesis y las vas descartando en lugar de adivinar.
2. Comunicación clara. Puedes explicarle una decisión técnica a un gerente de producto, no solo a otro ingeniero.
3. Pensar en pros y contras. Nombras las alternativas que descartaste y por qué, por ejemplo consistencia frente a velocidad o construir frente a comprar.
4. Decisiones basadas en datos. Mediste antes y después.
5. Responsabilidad propia. Dices qué hiciste tú, también cuando salió mal.

Los candidatos sólidos, además, piensan a nivel de sistema (cómo afecta un cambio a otros servicios), se preocupan por la mantenibilidad y las pruebas, y hablan de lo que están aprendiendo.

¿Cómo se estructura una entrevista de tecnología?

El perfil de entrevista de tecnología de Offermic se apoya en dos tipos de pregunta: conductuales, sobre proyectos pasados, y conceptuales, sobre cómo abordarías un problema. Una parte menor es situacional, y toda sesión termina con tiempo para tus preguntas.

Tipo de pregunta	Peso en el perfil de tecnología de Offermic	Ejemplo
Conductual	Cerca del 40%	“Háblame de una decisión técnica difícil en la que tuviste que sacrificar algo”.
Conceptual	Cerca del 35%	“¿Qué considerarías al diseñar una estrategia de caché?”
Situacional	Cerca del 15%	“El build falla una hora antes de un lanzamiento. ¿Qué haces?”
Cierre	Cerca del 10%	Tus preguntas para el entrevistador

El perfil evita deliberadamente las preguntas de memoria sobre sintaxis, los acertijos de algoritmos en pizarra y las preguntas sobre los sistemas internos de una empresa. Si necesitas practicar programación en vivo, usa una plataforma dedicada a eso junto con la práctica conversacional.

Preguntas de entrevista comunes en tecnología

Estas salen directamente del perfil del entrevistador de tecnología:

• “Explícame paso a paso cómo abordarías la depuración de un problema en producción que solo ocurre de forma intermitente”. Habla de reproducirlo, de los logs y las métricas, de acotar el alcance y de evitar que se repita.
• “¿Qué factores considerarías al diseñar una estrategia de caché para una aplicación de alto tráfico?”. Cubre la invalidación, la consistencia, la tasa de aciertos y qué pasa cuando la caché falla.
• “Háblame de una ocasión en la que tuviste que tomar una decisión técnica difícil, en la que ganabas algo y perdías algo”. Es una pregunta clásica de una decisión difícil; usa STAR.
• “¿Cómo decides entre construir una solución a la medida y usar una biblioteca o un servicio existente?”. El método PREP te da una estructura.
• “Describe cómo haces las revisiones de código. ¿En qué te fijas y por qué?”

Escenarios para ensayar: una caída en producción que afecta a los usuarios, un desacuerdo técnico con un compañero de equipo, un sistema heredado que hay que modernizar, una vulnerabilidad de seguridad que descubres y un cuello de botella de rendimiento que tienes que encontrar. La página de conflicto con un compañero de equipo cubre a fondo el caso del desacuerdo.

Cómo responder las preguntas de una entrevista de tecnología

Usa el método STAR para las preguntas conductuales. En las conceptuales, piensa en voz alta: di qué supones, enumera las opciones, elige una y explica qué ganas y qué pierdes con ella.

Situación

Tarea

Acción

Resultado

1. Situación

   Respuesta de ejemplo (ingeniero backend de nivel intermedio): la latencia p99 de nuestra API de checkout había ido subiendo hasta rondar los 1.8 segundos en las horas pico de la noche.

2. Tarea

   La investigación estaba a mi cargo y tenía dos semanas antes de una campaña de marketing ya planeada.

3. Acción

   Agregué trazas al endpoint más lento, encontré una consulta N+1 en el resumen del pedido, la reemplacé por una sola consulta con join y agregué una caché de corta duración para los datos de producto. Hice pruebas de carga de los dos cambios antes del despliegue y dejé un feature flag para poder revertir rápido.

4. Resultado

   La latencia p99 bajó a unos 400 ms y se mantuvo así durante toda la campaña. Documenté la configuración de las trazas para que otros equipos pudieran reutilizarla.

Cifras como estas tienen que ser las tuyas. Si no recuerdas el número exacto, da un rango honesto.

Un escenario paso a paso: una caída en producción

Pregunta: “Un viernes por la tarde sale una versión y se dispara la tasa de errores de los usuarios con sesión iniciada. ¿Qué haces?”. Una buena respuesta sigue el método SPAR:

• Situación: Hay usuarios afectados en este momento, así que restablecer el servicio va antes que encontrar la causa. Soporte, el equipo de guardia y quizá los clientes tienen que enterarse.
• Propuesta: Primero estabilizar, después investigar, y comunicar durante todo el proceso.
• Acción: Revisar si el pico de errores coincide con el despliegue; si coincide, revertir o apagar el feature flag. Publicar una actualización de estado, dejar a una sola persona a cargo de la comunicación y conservar los logs para la investigación.
• Resultado: La tasa de errores vuelve a la normalidad en minutos, hay una revisión posincidente sin culpables en pocos días y queda un paso concreto de prevención, como un despliegue canary o una alerta nueva.

A menudo el entrevistador sigue con “¿Y si no se puede revertir?”. Ten lista una segunda opción, como un hotfix detrás de un flag o darle más capacidad a una dependencia.

Lo que hunde una respuesta en una entrevista de tecnología

• Culpar de un problema a un compañero, a otro equipo o al “código heredado” sin describir tu parte.
• Explicaciones que solo otro especialista podría seguir.
• Historias vagas, sin sistema, sin cifras y sin una decisión.
• Tratar las pruebas, la documentación o la revisión de código como una carga inútil.
• Ponerte a la defensiva cuando el entrevistador te cuestiona.
• No tener ninguna historia de fracaso. Prepara una: consulta un error y lo que aprendiste.

Métricas y términos que conviene conocer

Métrica	Qué muestra
Latencia (p50, p99)	Cuánto tardan las solicitudes; p99 es el 1% más lento
Tasa de errores	Proporción de solicitudes que fallan
Uptime / disponibilidad	Proporción del tiempo en que el servicio funciona
Frecuencia de despliegue	Cada cuánto publicas en producción
Tiempo de entrega de cambios (change lead time)	Cuánto tarda un cambio en llegar a producción
MTTR / tiempo de recuperación	Qué tan rápido restableces el servicio después de una falla
Cobertura de código	Proporción del código que ejecutan las pruebas

La frecuencia de despliegue, el tiempo de entrega de cambios y el tiempo de recuperación tras un despliegue fallido están entre las métricas de entrega de software que define el programa de investigación DORA, así que son un vocabulario común que puedes usar con líderes de ingeniería.

Cómo prepararte para una entrevista de tecnología

1. Elige cinco proyectos que conozcas al detalle: una caída o un incidente, una decisión de diseño, un desacuerdo, algo que entregaste bajo presión y un fracaso. La mayoría de las preguntas conductuales se responde con alguno de ellos.
2. Anota las cifras de cada uno: el antes y el después, el tamaño del equipo, los tiempos. Si no lo haces, no las vas a recordar bajo presión.
3. Ensaya en voz alta las respuestas conceptuales. Elige tres problemas comunes, como la depuración, la caché o construir frente a comprar, y explica tu enfoque en menos de tres minutos cada uno. Grabarte te muestra dónde te vas por las ramas.
4. Prepara una versión en lenguaje sencillo de tu proyecto más técnico, como si se lo explicaras a un gerente de producto recién llegado.
5. Prepara preguntas sobre la carga de las guardias, la cultura de revisión de código, cómo se prioriza la deuda técnica y cómo mide el equipo sus entregas. La guía de preguntas para hacer al entrevistador tiene más.

Puestos relacionados y práctica general

Preguntas por puesto: ingeniero de software, desarrollador frontend, analista de datos, científico de datos y gerente de producto. Para practicar en general, empieza por explicar algo complejo y por la guía de preguntas de entrevista conductual.