Preguntas estratégicas para hacerle al reclutador al final de la entrevista

I. La entrevista como evaluación bidireccional

Cuando llega el momento clásico de "¿tienes alguna pregunta para nosotros?", muchos candidatos lo tratan como un trámite de cortesía. Es un error estratégico. Ese cierre de la conversación es, en realidad, la única ventana estructurada que un profesional de la ingeniería de software tiene para auditar, en tiempo real, la organización a la que podría incorporarse. Un currículum bien redactado y una preparación técnica sólida abren la puerta, pero las preguntas del cierre determinan si conviene cruzarla.

El objetivo de este artículo es ofrecer un repertorio de preguntas —agrupadas en tres bloques diagnósticos: cultura de equipo, deuda técnica y expectativas reales del rol— que permitan despejar incógnitas que rara vez se resuelven durante la fase de evaluación técnica. Cada bloque se apoya en marcos de investigación consolidados: el estudio Project Aristotle de Google, la encuesta Q12 de Gallup, el marco de deuda técnica de Martin Fowler y la literatura de gestión de ingeniería representada por obras como The Manager's Path de Camille Fournier y An Elegant Puzzle de Will Larson.

II. Diagnóstico de la dinámica de equipo y cultura laboral

A. Seguridad psicológica y gestión del error: de la culpa al aprendizaje

Uno de los indicadores más reveladores de la salud de un equipo técnico es cómo responde a los incidentes. John Allspaw, cofundador de Adaptive Capacity Labs y ex CTO de Etsy, popularizó el concepto de blameless postmortem: dado que los sistemas complejos fallan de manera inevitable, la pregunta relevante no es "¿quién cometió el error?" sino "¿qué condiciones del sistema permitieron que ocurriera?" [11]. Allspaw insiste en que los facilitadores de estas revisiones deben evitar la pregunta "¿por qué?" repetida en cadena, porque conduce a la especulación, al sesgo retrospectivo y a la búsqueda de un culpable; en su lugar, propone reconstruir descripciones ricas de lo ocurrido, incluyendo los detalles que cada participante daba por sentado [11].

Preguntar directamente por esta práctica en la entrevista es una forma eficaz de sondear la madurez operativa del equipo. Algunas formulaciones útiles:

• "¿Cómo fue el último incidente de producción que tuvieron y qué se hizo después de resolverlo?"
• "¿Realizan postmortems sin buscar culpables? ¿Puedes describir cómo se estructura esa reunión?"
• "¿Qué pasó la última vez que alguien del equipo cometió un error significativo?"

Respuestas vagas o defensivas —o la ausencia total de un proceso de revisión— suelen anticipar una cultura donde el error se castiga en lugar de convertirse en aprendizaje institucional.

B. Los cinco factores de Project Aristotle

Entre 2012 y 2016, el equipo de People Analytics de Google llevó a cabo la investigación conocida como Project Aristotle, cuyo hallazgo central fue que la composición individual de un equipo importa menos que la manera en que sus miembros interactúan entre sí [4][5]. Tras estudiar 180 equipos, los investigadores identificaron cinco factores, ordenados por prioridad de impacto [5]:

1. Seguridad psicológica: la creencia de que se puede expresar una idea, admitir un error o hacer una pregunta sin temor a represalias.
2. Confiabilidad (dependability): la certeza de que los compañeros entregarán trabajo de calidad a tiempo.
3. Estructura y claridad: roles, planes y metas bien definidos.
4. Significado (meaning): un sentido de propósito personal en el trabajo.
5. Impacto: la percepción de que el trabajo realmente marca una diferencia.

Resulta interesante que Google descartó, como factores relevantes, la ubicación conjunta del equipo, la toma de decisiones por consenso, la extroversión de sus integrantes, el desempeño individual, el tamaño del equipo o la antigüedad de sus miembros [5]. Esto significa que preguntas sobre "quiénes son las personas del equipo" tienen menos valor predictivo que preguntas sobre "cómo trabajan juntas". Ejemplos de preguntas alineadas con este marco:

• "¿Cómo describirías el nivel de confianza para plantear desacuerdos técnicos dentro del equipo?"
• "¿Qué mecanismo usan para asegurarse de que cada persona entienda lo que se espera de su rol en cada proyecto?"
• "¿Cómo se conecta el trabajo diario del equipo con el impacto que tiene en el negocio o en los usuarios finales?"

C. Señales de compromiso según el Q12 de Gallup

Desde la década de 1950, el equipo de Gallup —liderado inicialmente por Don Clifton— ha investigado los factores que explican el compromiso laboral y su relación con el desempeño [3]. El resultado es la encuesta Q12, un instrumento de doce elementos que mide desde necesidades básicas ("tengo los materiales y el equipo que necesito para hacer bien mi trabajo", "sé lo que se espera de mí") hasta necesidades de crecimiento ("en el último año he tenido oportunidades de aprender y crecer", "en los últimos seis meses alguien me ha hablado sobre mi progreso") [2]. Gallup ha estudiado a más de 3,3 millones de trabajadores en más de 100.000 equipos y encuentra que los equipos con mayor compromiso superan a los de menor compromiso en métricas como productividad (hasta un 14-18% más), rentabilidad (23% más) y bienestar (70% más), además de registrar un 21-51% menos de rotación de personal según el contexto [2].

Trasladar estos elementos a preguntas de entrevista permite estimar, de forma indirecta, si el equipo objetivo puntuaría alto en este instrumento:

• "¿Con qué frecuencia recibe el equipo reconocimiento por el trabajo bien hecho?"
• "¿Cómo se comunican las expectativas de cada rol cuando alguien se incorpora?" (una respuesta sólida aquí suele reflejarse en un proceso de onboarding técnico bien estructurado)
• "¿Qué oportunidades de aprendizaje ha tenido el equipo en el último año?"

III. Radiografía de la arquitectura y la deuda técnica

A. El cuadrante de Martin Fowler

Ningún candidato a un puesto de ingeniería debería aceptar una oferta sin entender la naturaleza de la deuda técnica que heredará. Martin Fowler propuso en 2009 un marco que sigue vigente: la deuda técnica se puede clasificar según dos ejes, deliberada vs. inadvertida y prudente vs. temeraria [6][8]. Esto da lugar a cuatro cuadrantes [6][7]:

• Prudente y deliberada: el equipo conoce el atajo que toma y planifica pagarlo después, como una hipoteca asumida conscientemente para lograr un lanzamiento a tiempo [6][7].
• Prudente e inadvertida: el equipo entrega software de calidad, pero solo después de terminarlo comprende cuál habría sido el diseño óptimo; Fowler la considera inevitable incluso en los mejores equipos [6].
• Temeraria y deliberada: se cortan esquinas sabiendo que existen mejores prácticas, sin plan de repago; es la más peligrosa porque no se registra ni se rastrea [6][7].
• Temeraria e inadvertida: el equipo carece del conocimiento para reconocer que está generando deuda [7].

Preguntar por esta clasificación demuestra madurez técnica y obliga al entrevistador a ser específico:

• "¿La deuda técnica actual del equipo fue una decisión deliberada para llegar a un lanzamiento, o se ha ido acumulando sin un plan explícito?"
• "¿Tienen algún registro o backlog donde se documenten los atajos tomados y cuándo planean pagarlos?"

B. Costo recurrente vs. deuda pasiva

No toda la deuda técnica se comporta igual. Arthur Johnston propone una distinción útil, inspirada también en la metáfora financiera: algunas deudas exigen "pagos periódicos" —esfuerzo repetido cada vez que se realiza una tarea—, mientras que otras permanecen pasivas hasta que algo obliga a tocarlas [1]. El ejemplo canónico es la automatización: si compilar el proyecto no está reducido a un solo paso, cada compilación manual es un pago recurrente de intereses; lo mismo ocurre con la gestión de servidores cuando no se usan herramientas como Puppet o Chef para automatizar cambios repetitivos [1]. Johnston sugiere una heurística práctica: cualquier tarea técnica que se repita con una frecuencia de dos semanas o menos normalmente justifica su automatización [1].

Además, la deuda técnica acumula "interés" con el tiempo: cuanto más tarda el equipo en abordar un problema, más caro resulta, no solo por la pérdida de contexto del desarrollador original, sino porque otros sistemas empiezan a depender de la solución deficiente, lo que la va "fosilizando" [1]. Preguntas recomendadas:

• "¿Qué parte del pipeline de build, pruebas o despliegue sigue siendo manual?"
• "¿Qué tan automatizada está la gestión de infraestructura del equipo?"
• "Si tuvieran dos semanas libres de features, ¿qué deuda técnica atacarían primero y por qué?"

C. Estrategias de pago: convivencia con código heredado

Martin Fowler recomienda pagar la deuda de forma gradual, priorizando el código que se modifica con frecuencia, precisamente porque ahí es donde los "intereses" se vuelven más costosos; el código defectuoso pero estable puede dejarse en paz [8]. En un análisis posterior sobre los cuellos de botella de las empresas en fase de escalamiento (scaleups), Fowler describe dos escenarios extremos observados en clientes de Thoughtworks: una startup que construye un MVP de baja calidad técnica y nunca lo reconstruye, quedando paralizada por la deuda acumulada; y otra que sobre-diseña su arquitectura desde el día uno, sacrificando velocidad de entrega sin llegar a necesitar esa escalabilidad [10]. El equilibrio entre inversión técnica y velocidad de entrega de producto es, según Fowler, el reto central de cualquier organización en crecimiento [10].

Will Larson, autor de An Elegant Puzzle, resume esta tensión con una fórmula memorable citada por un lector del libro: si el equipo se está quedando atrás, se añade gente; si está "pisando agua" sin avanzar, se paga deuda técnica [9]. Preguntas útiles para esta sección, especialmente relevantes si el rol implica trabajar con stacks backend heredados o en migración:

• "¿Qué porcentaje del tiempo del equipo se dedica a mantenimiento de sistemas heredados frente a desarrollo de nuevas funcionalidades?"
• "¿Hay planes de reescritura o migración en curso? ¿Qué motivó esa decisión?"
• "¿Cómo deciden qué deuda técnica pagar primero cuando compite con la presión de entrega?"

IV. Expectativas reales del rol y desarrollo profesional

A. La relación con el mánager y la cadencia de feedback

Camille Fournier, en The Manager's Path, subraya que las reuniones 1:1 tienen dos propósitos centrales: construir conexión humana y ofrecer un espacio regular y privado de conversación que no debería convertirse en una simple reunión de estatus [12]. Fournier advierte que el peor tipo de gestión no es necesariamente el que microgestiona cada paso, sino también el "descuido benigno" —ignorar al reporte hasta que este pide ayuda— cuando existen alternativas mucho mejores, como un manager que se preocupa activamente por el crecimiento de su gente [12]. También señala que la retroalimentación tardía es peor que ninguna: cuanto antes se conocen los malos hábitos, más fácil es corregirlos, y lo mismo aplica al reconocimiento del buen desempeño [12].

Preguntas orientadas a esta dimensión permiten distinguir un manager presente de uno ausente:

• "¿Cómo son típicamente las reuniones 1:1 con mi futuro manager? ¿Qué agenda suelen seguir?"
• "¿Con qué frecuencia se da feedback fuera del ciclo formal de evaluación de desempeño?"
• "¿Cómo maneja el equipo el reconocimiento del trabajo bien hecho en el día a día?"

B. Claridad de responsabilidades y proyectos de crecimiento (stretch projects)

Fournier también destaca el rol del manager en la clarificación del puesto dentro de la empresa y en la identificación de "stretch projects": tareas que exceden ligeramente la zona de confort actual del profesional y que le permiten aprender y crecer [12]. Advierte, además, que el crecimiento profesional en ingeniería no se limita a dominar nuevas tecnologías: los líderes técnicos más sólidos desarrollan también habilidades de comunicación, gestión de proyectos y sentido de producto [12]. Esta perspectiva complementa la ruta de crecimiento técnico descrita para quienes se inician como desarrolladores backend y aspiran a roles de mayor responsabilidad.

Preguntas recomendadas para esta última área:

• "¿Cómo se identifican y asignan los proyectos de crecimiento (stretch projects) dentro del equipo?"
• "¿Qué se espera de mí en los primeros tres, seis y doce meses en este puesto?"
• "¿Cómo ha ayudado el equipo a alguien a prepararse para una promoción recientemente?"

V. Conclusión: interpretar las respuestas para decidir con información real

El valor de estas preguntas no reside únicamente en obtener respuestas favorables, sino en observar la calidad y la honestidad de las respuestas mismas. Un entrevistador que reconoce abiertamente zonas de deuda técnica temeraria, que describe con naturalidad cómo funcionan sus postmortems sin culpables, o que puede citar ejemplos concretos de reuniones 1:1 productivas, está revelando —lo sepa o no— el nivel de madurez organizacional del equipo. Por el contrario, la vaguedad, la actitud defensiva o el silencio ante preguntas directas sobre deuda técnica o gestión de errores suelen ser señales de alerta tan valiosas como cualquier respuesta explícita.

Combinar los cinco factores de Project Aristotle, los doce elementos del Q12 de Gallup, el cuadrante de deuda técnica de Fowler y los principios de gestión descritos por Fournier y Larson convierte el cierre de la entrevista en una auditoría estructurada, no en un mero gesto de cortesía. Al final, decidir si un rol conviene profesionalmente no debería depender solo de la oferta salarial o del prestigio de la empresa, sino de la evidencia recopilada, pregunta por pregunta, sobre cómo trabaja realmente ese equipo.

Fuentes Oficiales y Referencias Consultadas

• gallup.com - gallup.com
• gallup.com - gallup.com
• rework.withgoogle.com - rework.withgoogle.com