Banco de preguntas de entrevista

Explícame el equilibrio entre sesgo y varianza y cómo se nota en un proyecto real.

Define cada término en una frase y luego ánclalos en una decisión concreta: por ejemplo, elegiste un modelo de gradient boosting menos profundo porque el error de validación subía con la profundidad mientras el de entrenamiento seguía bajando. Cierra con cómo lo diagnosticaste (curvas de aprendizaje, la brecha en la validación cruzada) en lugar de recitar teoría.

¿Cómo tratas los datos faltantes en un conjunto de datos?

Muestra un proceso de decisión, no un único truco: primero cuantifica cuántos datos faltan y si faltan al azar (MCAR/MAR/MNAR), y después elige el remedio adecuado: eliminar, imputar (media/mediana, basado en modelos) o tratar la propia ausencia como una variable más. Menciona la fuga de datos (leakage): los parámetros de imputación deben ajustarse solo con la partición de entrenamiento.

¿Cómo evalúas un modelo de machine learning más allá de la exactitud?

Elige las métricas según lo que le cuestan los errores al negocio: precisión/recall y PR-AUC con clases desbalanceadas, calibración cuando las probabilidades alimentan decisiones y una comparación con una línea base (la clase mayoritaria, la heurística actual). Las respuestas sólidas añaden un análisis por segmentos: el rendimiento de cada segmento, no solo la cifra global.

Cuéntame una ocasión en la que tu análisis llevó a una decisión de negocio real.

Usa el método STAR con cifras: qué estaba en juego, qué hiciste distinto del enfoque obvio y el resultado medido (“el modelo de churn priorizó el 20% de las cuentas y el gasto en retención bajó un 15%”). Los entrevistadores indagan en el seguimiento: di cómo supiste que el impacto era causal (holdout, prueba A/B, diff-in-diff).

¿Cómo explicarías un modelo complejo a partes interesadas sin perfil técnico?

Demuéstralo, no lo describas: elige un modelo y tradúcelo en el momento (“el modelo puntúa a cada cliente como una puntuación de crédito; estos tres factores son los que más la mueven”). Menciona herramientas que de verdad usas: resúmenes de SHAP convertidos en factores explicados en lenguaje sencillo, o un memorando de decisión de una página en lugar de un notebook.

¿Cómo abordas la detección de anomalías en un conjunto de datos grande?

Plantéalo así: primero define qué es “normal” (estacionalidad, segmentos) y luego elige un método según haya etiquetas o no: umbrales estadísticos o isolation forests cuando no hay etiquetas, modelos supervisados cuando los incidentes están etiquetados. Explica cómo controlas el margen de falsos positivos, porque la fatiga de alertas acaba con estos sistemas.

¿Cómo diseñas y analizas una prueba A/B?

Cubre todo el recorrido: hipótesis y métrica principal fijadas de antemano, análisis de potencia para dimensionar la muestra, una unidad de aleatorización elegida para evitar interferencias y una regla de parada registrada por adelantado. Lo que demuestra un nivel sénior son los modos de fallo (mirar los resultados antes de tiempo, las comparaciones múltiples, el efecto novedad) y un ejemplo en el que el resultado de una prueba te sorprendió.

Cuéntame paso a paso cómo haces la ingeniería de variables.

Apóyalo en un proyecto: cómo el conocimiento del dominio te sugirió variables candidatas, cómo trataste las categóricas y el tiempo (target encoding, lags, ventanas) y cómo validaste que una variable se ganaba su sitio (importancia más ablación, no intuiciones). Menciona las comprobaciones de fuga de datos: las variables calculadas con información del futuro son el clásico asesino silencioso.

¿Cuándo recurres a SQL y cuándo a Python o R?

Muestra un reparto pragmático: SQL para extraer, unir y agregar en el origen (llevar el cálculo al data warehouse), y Python/R cuando necesitas estadística, modelado o gráficos. Las mejores respuestas mencionan mover trabajo de uno a otro a propósito (“hago el prototipo en pandas y luego devuelvo los groupby pesados a SQL”) en lugar de casarse con una herramienta.

¿Cómo supervisas un modelo en producción?

Nombra las tres capas: la salud del servicio (latencia, errores), la deriva de los datos (las distribuciones de entrada frente a las de entrenamiento) y la degradación del rendimiento (las predicciones frente a la verdad de referencia, que llega con retraso). Di qué dispara un reentrenamiento y a quién se avisa. Una historia concreta (“nuestro modelo de fraude se degradó después de que un cambio de producto alterara las variables”) es mejor que una lista de la compra de herramientas de supervisión.

Los usuarios activos diarios de nuestra app han bajado. ¿Cómo lo investigarías?

Primero, la estructura: aclara la magnitud y el periodo, descarta errores de medición y luego segmenta (plataforma, región, cohorte, canal de adquisición) para aislar dónde está la caída. Solo entonces plantea hipótesis sobre las causas: un lanzamiento, una pausa en marketing, la estacionalidad, un competidor. Termina con la prueba más rápida que podría refutar tu hipótesis, no con una lista de todo.

¿Cómo priorizas las funcionalidades en la hoja de ruta de un producto?

Menciona un framework (RICE, impacto/esfuerzo), pero muestra enseguida sus límites: las puntuaciones esconden supuestos, así que explica cómo los pones a prueba (evidencia de usuarios para el alcance, spikes de ingeniería para el esfuerzo). Las respuestas sólidas incluyen algo a lo que dijiste que no a propósito y la razón estratégica.

Cuéntame una decisión de producto en la que los datos y la intuición no coincidían.

Esta pregunta pone a prueba tu criterio. Elige un caso real: la métrica decía una cosa y las señales cualitativas otra; explica en cuál confiaste y por qué (la métrica era un indicador indirecto, la muestra estaba sesgada, el largo plazo frente al corto). El final creíble es lo que hiciste para resolver el conflicto: un experimento barato, no un salto de fe.

¿Cómo mides el éxito de un producto después de lanzarlo?

Vincula las métricas al objetivo del lanzamiento: adopción (tasa de activación), profundidad de uso (frecuencia, curva de retención) y resultado de negocio (ingresos, gastos). Distingue entre indicadores adelantados y retrasados, fija un punto de revisión antes del lanzamiento y di qué resultado te haría dar marcha atrás: comprometerte de antemano es lo que separa el rigor de las justificaciones a posteriori.

¿Qué haces con una petición de funcionalidad que choca con tu visión de producto?

Muestra respeto y firmeza a la vez: indaga en el problema de fondo (la petición es una solución propuesta, no la necesidad), cuantifica a quién más le pasa y, o bien resuelves la necesidad de una forma coherente con la visión, o bien explicas qué equilibrio estás protegiendo. Escala con opciones y una recomendación, nunca con un no rotundo.

¿Cómo mantienes alineados a los equipos de ingeniería y de negocio?

Los mecanismos concretos ganan a los tópicos: una única fuente de verdad escrita para las prioridades, ingenieros en las llamadas de discovery para que el contexto llegue pronto y traducir en ambas direcciones (las peticiones de negocio planteadas como problemas de usuario, las restricciones técnicas planteadas como decisiones de alcance y plazo). Da un ejemplo en el que la alineación se rompió y qué cambiaste.

¿Qué métricas definirías para un producto completamente nuevo?

Estructúralo por ciclo de vida: una métrica North Star ligada al valor entregado y luego métricas de apoyo a lo largo del embudo: adquisición, activación (define con precisión el momento “ajá”), retención y una métrica de control (guardrail) que detecte si estás maquillando las demás. Explica por qué excluyes las métricas de vanidad (descargas, páginas vistas) y cómo cambia el conjunto tras alcanzar el product-market fit.

Estima el tamaño de mercado de este producto.

La cifra importa menos que el andamiaje: explica tu enfoque (top-down a partir de la población o bottom-up a partir del uso), enuncia los supuestos en voz alta, mantén la aritmética sencilla y contrasta el resultado con una referencia conocida. Termina diciendo qué supuesto mueve más la respuesta: es la parte que los entrevistadores evalúan de verdad.

Elige un producto que te parezca mal diseñado. ¿Cómo lo mejorarías?

Elige algo que uses de verdad, no el producto del entrevistador. Haz el diagnóstico con un framework (quién es el usuario, para qué trabajo lo “contrata”, dónde falla), propón uno o dos cambios concretos y define la métrica que demostraría que la mejora funcionó. Una crítica sin métrica de éxito suena a gusto personal, no a pensamiento de producto.

¿Cómo comunicas los requisitos a los ingenieros?

Describe tu documento escrito (PRD, one-pager) y lo que deja fijado: el problema, el usuario, las métricas de éxito y las restricciones, dejando a propósito el “cómo” en manos de ingeniería. Menciona los ciclos de feedback a su alrededor: una revisión de arranque en la que los ingenieros le buscan los fallos y unos criterios de aceptación tan concretos que “terminado” no sea motivo de debate.

Háblame de una campaña de marketing de éxito que hayas dirigido.

Estructura: objetivo → insight sobre la audiencia → elección de canal → resultado con atribución. Lo que te diferencia es el insight (“vimos que los registros se disparaban desde búsquedas comparativas, así que creamos contenido comparativo”) y la honestidad sobre lo que harías distinto. Una historia de campaña sin grupo de control ni línea base suena a adorno.

¿Cómo mides la eficacia de una campaña?

Describe el embudo que instrumentaste: alcance → interacción → conversión → retención/LTV, con el KPI principal fijado antes del lanzamiento. Aborda la atribución de frente (disciplina con los UTM, regiones de control, pruebas de incrementalidad frente a último clic): nombrar los límites de tu medición es lo que buscan los entrevistadores sénior.

¿Cómo haces la segmentación de mercado y la selección de públicos objetivo?

Repasa una segmentación real: los datos con los que agrupaste (los de comportamiento ganan a los demográficos), cómo validaste que los segmentos eran accionables (un mensaje, canal o precio distinto los movía de verdad) y cómo cambió el gasto con esa segmentación. Evita las respuestas de manual de 4 cuadrantes sin ningún conjunto de datos detrás.

¿Qué herramientas y plataformas de marketing digital usas, y por qué esas?

Agrúpalas por la tarea que resuelven en lugar de enumerar logotipos: analítica (GA4 + una herramienta de analítica de producto), SEO (Search Console + una herramienta de posiciones y palabras clave), automatización/CRM y pruebas de creatividades. Para cada una, una frase sobre una decisión que la herramienta cambió de verdad: las herramientas que no puedes vincular a una decisión suenan a relleno del currículum.

¿Cómo usas los datos para optimizar una campaña que no está rindiendo?

Muestra el orden del diagnóstico: primero verifica el tracking y luego descompón el embudo para encontrar la etapa rota (CTR bien pero conversión baja → la landing page, no el anuncio). Describe una prueba estructurada que hiciste (audiencia, creatividad u oferta: una sola variable), el resultado y los criterios de cancelación que fijaste de antemano.

¿Cómo has optimizado contenidos para buscadores (SEO)?

Demuestra el ciclo completo: investigación de palabras clave e intención de búsqueda, contenido alineado con la intención (no relleno de palabras clave), higiene técnica (títulos, enlaces internos, velocidad de carga) y la evolución medida de impresiones y posiciones a lo largo de los meses. Sumas puntos si cuentas lo que no funcionó: las historias de SEO con solo éxitos suenan prestadas.

¿Cómo repartes el presupuesto entre marketing de marca y marketing de resultados?

Demuestra que entiendes la tensión: el marketing de resultados es medible y de ciclo corto; la marca se acumula con el tiempo, pero se resiste a la atribución. Basa tu reparto en la etapa de la empresa y en los cálculos de recuperación de la inversión (en fase inicial, sobre todo resultados hasta que el CAC se estabiliza; después, reequilibrar a medida que los canales se saturan). Explica cómo medirías la marca de todos modos: volumen de búsquedas, tráfico directo, pruebas geográficas de incrementalidad.

¿Cómo construirías una estrategia de contenidos desde cero?

Expón la secuencia: primero investigación de la audiencia y de la intención de búsqueda, una arquitectura de temas enfocada (unos pocos pilares, no cincuenta artículos dispersos), un ritmo de producción que puedas sostener, la distribución integrada en cada pieza y un ciclo de medición que elimine lo que no funciona. Lo que marca la diferencia es la lógica de priorización (por qué estos temas primero), no la lista de canales.

Tienes $10k para el lanzamiento de un producto. ¿A qué los destinas?

Resiste la tentación de gastarlo todo en anuncios. Las respuestas sólidas reparten en función del objetivo: una parte para la calidad de las creatividades y de la landing page, un presupuesto de pruebas en dos o tres canales con criterios de cancelación explícitos y una reserva para apostar fuerte por el ganador. Muestra los cálculos por canal (CPC esperado → conversiones) y qué harías distinto con $100k.

¿Cómo serían tus primeros 90 días en este puesto?

Estructúralo en tercios: aprender (auditar los embudos, reunirte con ventas y producto, leer los datos antes de cambiar nada), victorias rápidas (una o dos mejoras con impacto visible, a menudo la higiene del tracking o una página que rinde poco) y después un plan con responsables y métricas. Esta pregunta filtra por criterio y humildad; llegar con un manual rígido no transmite ninguna de las dos cosas.

Explícame paso a paso un análisis de flujos de caja descontados (DCF).

Repasa la mecánica en orden: proyectar los flujos de caja libres, elegir una tasa de descuento (el WACC y cómo lo construiste), calcular el valor terminal (por crecimiento o por múltiplo de salida), descontar y sumar. Después demuestra criterio: a qué supuesto es más sensible la valoración y cómo la contrastas con múltiplos. La mecánica sin análisis de sensibilidad suena a memorizada.

¿Cómo analizas los estados financieros para evaluar la salud de una empresa?

Conecta los tres estados en lugar de enumerar ratios: la tendencia de la rentabilidad (estado de resultados), la conversión en caja (flujo de caja frente a beneficio neto; que diverjan es la clásica señal de alarma) y el apalancamiento y la liquidez (balance general). Nombra los 3–4 ratios con los que realmente empiezas y una ocasión en la que un ratio contaba una historia engañosa.

Háblame de tu experiencia con presupuestos y previsiones.

Describe el calendario del que eras responsable (presupuesto anual, previsión continua o rolling forecast), tu método (basarte en los impulsores del negocio es mejor que extrapolar partida por partida) y la precisión: los análisis de desviaciones que hiciste, el mayor error y el cambio de proceso que provocó. Los entrevistadores indagan si tus previsiones alimentaban decisiones reales o solo presentaciones.

Cuéntame un problema de negocio complejo que hayas analizado. ¿Cuál fue tu proceso?

Elige un problema con ambigüedad real. Muestra la estructura: define la pregunta con precisión, descomponla en factores, reúne datos (y trata sus lagunas con honestidad), pon a prueba la hipótesis principal y llega a una recomendación que alguien llevó a la práctica. La frase que debes ganarte: “esto es lo que habría hecho mal sin los datos”.

¿Cómo te aseguras de que tus análisis sean precisos y fiables?

Enumera hábitos concretos: concilia los totales con una fuente independiente, incorpora comprobaciones de coherencia a los modelos (cuadres, pruebas de orden de magnitud), versiona y documenta los supuestos, y pide a otra persona que intente romper tu modelo antes de entregarlo. Admitir un error que detectaste tarde (y la comprobación que añadiste) funciona mejor que afirmar que nunca te equivocas.

¿Qué herramientas usas para analizar y cómo eliges cuál usar?

Adapta la herramienta a la tarea: Excel para los modelos que otros deben auditar, SQL para extraer y transformar los datos en el origen, Python/R cuando el análisis necesita estadística o automatización, y BI (Tableau/Power BI) para vistas recurrentes de autoservicio. Una historia de migración (“pasé un informe semanal de Excel a SQL + dashboard y ahorré N horas”) lo demuestra.

Descríbeme la consulta SQL más compleja que hayas escrito.

Elige una con estructura de verdad (CTE de varios pasos, funciones de ventana o una deduplicación complicada) y cuenta qué pregunta de negocio respondía, no solo la sintaxis. Explica una decisión de rendimiento (por qué filtraste pronto, qué te supuso el orden de los joins) y cómo comprobaste que era correcta frente a un total conocido. La complejidad sin verificación es una señal de alarma, no algo de lo que presumir.

Explícame paso a paso un análisis de desviaciones que hayas hecho.

Muestra disciplina al descomponer: real frente a presupuesto, desglosado en precio/volumen/mix (o los factores equivalentes de tu ámbito), aislando la contribución de cada uno. Después, la capa de criterio: qué desviaciones eran ruido y cuáles señal, y qué decisión cambió gracias al análisis. Termina con cómo el proceso mejoró el siguiente ciclo de previsión.

¿Cómo construyes un dashboard de KPI que los directivos usen de verdad?

Empieza por las decisiones, no por los datos: pregunta a tu público cuáles son las tres preguntas que se hacen cada semana, ponlas arriba con objetivos y tendencias, y deja todo lo demás para los niveles de detalle. Menciona la parte operativa: la frescura de los datos, un único responsable por cada definición de métrica y eliminar los gráficos que nadie abre. La adopción es la métrica de éxito del propio dashboard.

Cuéntame una ocasión en la que tu análisis estaba equivocado.

Elige un error con consecuencias, explica cómo se coló (un join mal hecho, sesgo de supervivencia, un supuesto desactualizado) y, que es lo que se evalúa, cómo se detectó y qué comprobación existe ahora gracias a él. Asumir el fallo e institucionalizar la solución transmite seniority; afirmar que nunca has entregado una cifra errónea transmite falta de autocrítica.

Háblame de ti.

Presente → pasado → futuro, en 90 segundos: a qué te dedicas ahora (una línea con su alcance), las dos o tres experiencias que te dieron la habilidad que necesita este puesto y por qué este puesto es el siguiente paso lógico. Adapta la parte central a la descripción del puesto; no recites tu currículum en orden cronológico.

Escribe la tuya a partir de tu currículum con el generador gratuito →

Cuéntame una ocasión en la que fracasaste.

Elige un fracaso real con consecuencias reales (no “trabajo demasiado”), asume tu parte concreta de responsabilidad y dedica la mayor parte de la respuesta al sistema que cambiaste después. El entrevistador comprueba si conviertes los fracasos en procesos: termina con un éxito posterior que se apoyó en el nuevo proceso.

Háblame de un conflicto con un compañero de trabajo y de cómo lo resolviste.

Que sea un desacuerdo profesional, no un drama personal. Muestra que primero buscaste entender sus razones, encontraste el objetivo común y pasaste a un mecanismo para resolverlo (datos, una prueba, escalar una decisión bien planteada). Nunca conviertas a la otra persona en la villana: los entrevistadores se imaginan en el lugar de ese compañero.

¿Por qué quieres trabajar aquí?

Dos capas: algo concreto de la empresa que solo podrías saber si has investigado (la dirección del producto, un lanzamiento, un artículo de su blog de ingeniería), conectado con tu propia trayectoria. Los elogios genéricos (“una cultura estupenda”) delatan a quien envía candidaturas en masa; lo concreto lo es todo.

Cuéntame una ocasión en la que lideraste sin tener autoridad formal.

Elige una situación entre varios equipos: viste el hueco, lograste la alineación facilitando los objetivos de los demás (no escalando a la primera) y entregaste un resultado cuantificable. Esta pregunta mide tu capacidad de influencia: la mecánica de CÓMO persuadiste importa más que el resultado.

¿Dónde te ves dentro de cinco años?

Muestra una dirección sin un guion rígido: la capacidad que quieres profundizar, el alcance al que quieres crecer y cómo este puesto suma en esa dirección. Las empresas están evaluando el riesgo de que te vayas y tu autoconocimiento, no una predicción exacta del organigrama.

¿Cuál es tu mayor debilidad?

Elige una debilidad real que no te descalifique (no una virtud disfrazada de defecto) y dedica dos tercios de la respuesta a cómo la gestionas: el hábito o proceso concreto que construiste a su alrededor y una señal medible de que funciona. La pregunta evalúa tu autoconocimiento y tu forma de mejorar; “soy perfeccionista” falla en las dos cosas.

Cuéntame una ocasión en la que no estuviste de acuerdo con tu jefe.

Muestra un desacuerdo productivo: discrepaste en el fondo, defendiste tu postura con pruebas en privado y luego, saliera como saliera, te comprometiste por completo con la decisión. Incluye un caso en el que te equivocaste y lo reconociste. Los entrevistadores buscan a la vez firmeza y capacidad de aprender; las historias con un villano no funcionan.

Háblame de una vez en la que tuviste que entregar algo con un plazo muy ajustado.

Lo que se evalúa es tu capacidad de recortar el alcance, no las heroicidades. Explica cómo te quedaste con lo esencial, comunicaste pronto lo que se sacrificaba y entregaste lo que importaba, y después qué arreglaste. Las historias de noches sin dormir sin una decisión de priorización dentro suenan a mala planificación, no a dedicación.

¿Por qué quieres dejar tu trabajo actual?

Mira hacia delante: una frase honesta y neutral sobre el límite que encontraste (alcance, crecimiento, rumbo) y luego pasa a lo que este puesto te ofrece y el actual no puede darte. Nunca hables mal de tu empleador: el entrevistador traslada lo que digas a cómo hablarás algún día de su empresa. No pases de treinta segundos.

Explícame un sistema que hayas diseñado de principio a fin. ¿Qué cambiarías hoy?

Empieza por la restricción que marcó el diseño (el patrón de tráfico, el presupuesto de latencia, el tamaño del equipo, el plazo), no por la lista de tecnologías. La señal de seniority es algo que se rompió en producción y lo que te enseñó, además de un límite concreto que hoy trazarías de otra forma.

Háblame del bug más difícil que hayas tenido que depurar.

El valor está en el método, no en el síntoma: cómo acotaste el problema (bisect, logs, una forma fiable de reproducirlo) y qué suposición resultó ser falsa. Termina con lo que cambiaste para que ese tipo de bug salga a la luz antes la próxima vez.

¿Cómo decides entre lanzar rápido y construirlo bien?

Responde con una disyuntiva real que hayas resuelto y la prueba de reversibilidad que aplicaste: una decisión sin vuelta atrás (one-way door) merece la semana extra; una reversible, normalmente no. Di si la limpieza que prometiste llegó a hacerse: admitir que no es más creíble que fingir.

Descríbeme una revisión de código en la que no estuvieras de acuerdo con el autor.

Demuestra que separas el gusto personal del fondo. Apela a algo externo (un tipo de bug, un contrato, un benchmark) en lugar de a tus preferencias, y di cómo se cerró el desacuerdo: con un test que lo zanjó, con una sesión de programación en pareja o cediendo tú.

¿Cómo abordas las pruebas de un código que no escribiste tú?

Primero, tests de caracterización para fijar el comportamiento actual; después, cobertura en las rutas que de verdad conllevan riesgo. Di qué decidiste NO probar: tratar la cobertura como un presupuesto y no como un objetivo es la respuesta de alguien con experiencia.

Cuéntame un incidente en producción del que te hiciste cargo.

Da la cronología con reloj en mano: detección, mitigación, causa raíz, prevención. Los entrevistadores se fijan en si contuviste el daño antes de entender del todo la causa (que suele ser el orden correcto) y en una medida preventiva que llegó a implementarse.

¿Cómo evitas que una refactorización grande se estanque?

Explica cómo mantienes el código desplegable en cada paso: migrar una parte detrás de una interfaz de separación (seam), ejecutar ambas rutas y eliminar la antigua. Nombra la métrica que te indicó que funcionaba y la pieza que dejaste sin migrar a propósito.

¿Con qué decisión técnica de tu equipo no estás de acuerdo?

Elige una real y expón la otra postura con justicia, incluido por qué el equipo la eligió. Terminar con el experimento que zanjaría la cuestión funciona mejor que mostrarte seguro.

¿Cómo validas un conjunto de datos que nunca has visto?

Da la lista de comprobaciones que de verdad aplicas: recuento de filas frente a la fuente, unicidad de las claves, cobertura de fechas, perfil de nulos y valores atípicos y, por último, conciliación con una cifra en la que alguien ya confía. La habilidad real está en lo que haces cuando la conciliación falla, así que explica esa parte en voz alta.

Una métrica de un dashboard cae un 20% de un día para otro. Cuéntame qué haces en la primera hora.

Revisa la instrumentación antes que el negocio: un fallo del pipeline y una caída real se ven idénticos en un gráfico. Después segmenta (plataforma, región, usuarios nuevos frente a recurrentes) y crúzalo con el calendario de lanzamientos y campañas. Plantear primero la hipótesis de un error de tracking es lo que delata la experiencia.

¿Cómo decides qué métrica debería importarle a un equipo?

Vincúlala a una decisión que vaya a cambiar. Una buena respuesta nombra la métrica, la forma en que se puede manipular y la métrica de control (guardrail) que la acompaña para que nadie optimice el negocio hasta meterlo en un callejón sin salida.

Cuéntame alguna vez en la que tu análisis hizo cambiar de opinión a alguien.

Usa el método STAR y no quites la resistencia de la historia: quién no estaba de acuerdo, qué evidencia concreta le hizo cambiar y qué habrías hecho si no hubiera funcionado. Un análisis que no encontró ninguna fricción rara vez importó.

¿Cómo le explicas la incertidumbre estadística a una parte interesada sin perfil técnico?

Tradúcela al lenguaje de las decisiones (más o menos qué rango de resultados cabe esperar y qué harías en cada extremo) en lugar de poner un p-valor en una diapositiva. Di explícitamente qué significaría un resultado nulo para el plan.

Una consulta que antes tardaba segundos ahora tarda minutos. ¿Qué haces?

Lee el plan de ejecución antes de reescribir nada: filtra pronto, indexa las columnas por las que filtras, reduce filas antes de los joins y materializa lo que se ejecuta a diario. Menciona el caso en que la solución correcta estaba antes, en el modelo del data warehouse, y no en la consulta.

¿Qué haces con una petición que los datos no pueden responder?

Dilo pronto y luego ofrece la pregunta más cercana que los datos sí pueden responder, junto con lo que costaría responder la de verdad: instrumentación, una encuesta, un grupo de control (holdout). El error típico aquí es entregar en silencio un indicador sustituto engañoso.

Háblame de un informe que creaste y que nadie usó.

Responde con honestidad y luego haz el diagnóstico: no tenía responsable, la frecuencia era la equivocada o respondía a una pregunta por la que nadie es evaluado. La mejor versión termina con lo que eliminaste o con qué lo sustituiste.

Cuéntame un proyecto que se retrasó. ¿Qué hiciste?

Di cuándo lo supiste, a quién se lo dijiste y qué recortaste. Escalar pronto y con opciones es mejor que los actos heroicos al final, y los entrevistadores están atentos a cuál de las dos cosas hiciste.

¿Cómo haces un informe de estado que la gente lea de verdad?

Primero las decisiones, luego los riesgos con responsables y fechas, y después lo que ha cambiado desde la última vez. Di cómo lo mantienes honesto cuando las noticias son malas: un estado que está en verde hasta que pasa a rojo enseña a la gente a ignorarlo.

Dos equipos necesitan al mismo ingeniero en el próximo sprint. ¿Qué haces?

Lleva la disyuntiva a quien decide las prioridades, con cada opción valorada en fechas y no en adjetivos. Evita la no-respuesta de hablar con ambas partes y esperar que se resuelva solo.

¿Cómo gestionas a una parte interesada que no para de ampliar el alcance?

Haz visible la disyuntiva en lugar de negarte: “sí, y esta es la nueva fecha; ¿qué prefieres?”. Menciona el registro de cambios por escrito que evita que se repita la misma conversación.

Descríbeme un riesgo que detectaste antes de que se convirtiera en un problema.

Importa cómo lo encontraste: un mapa de dependencias, un pre-mortem o un ingeniero callado al que le diste la confianza para hablar. Después, la mitigación y lo que costó.

¿Cómo sabes si un proyecto va de verdad según lo previsto?

Prioriza los indicadores adelantados (dependencias abiertas, tiempo de espera de las revisiones, cambios constantes de alcance) frente a los colores de estado, y señala que una demo que funciona vale más que un porcentaje de avance.

Cuéntame alguna vez en la que tuviste que dar malas noticias a la dirección.

Estructura: titular, causa, opciones y lo que cuesta cada una, y tu recomendación. Di cómo evitaste enterrarlo en la diapositiva catorce.

¿Cómo cierras un proyecto?

Criterios de aceptación verificados, un responsable designado para el trabajo que continúa y una retrospectiva que cambió exactamente una cosa. Los proyectos que nunca se cierran son la forma en que los equipos acumulan trabajo invisible.

Cuéntame una venta que perdiste y por qué.

Nombra el motivo real en lugar del precio, que suele ser el síntoma. La versión creíble termina con lo que cambiaste en tu forma de calificar oportunidades para que no se repita la misma pérdida.

¿Cómo calificas una oportunidad?

Usa tu metodología como una lista de comprobación, no como un guion: quién firma, qué se rompe si no hacen nada y qué fecha obliga a tomar una decisión. Di qué oportunidades descartaste y cuánto tiempo te devolvió eso.

Un cliente potencial deja de responder después de una demo muy buena. ¿Qué haces?

Da por hecho que cambiaron sus prioridades, no que es mala educación. Describe cómo abres una segunda vía de contacto con otra parte interesada (multi-threading), un contacto que aporte algo de verdad y el cierre honesto: preguntar si das el tema por cerrado suele conseguir una respuesta.

¿Cómo respondes cuando te dicen que tu producto es demasiado caro?

Replantéalo frente a lo que les cuesta seguir como están, cuantificado con sus propias cifras, y nunca hagas un descuento sin pedir algo a cambio. Mencionar una venta a la que renunciaste lo hace creíble.

Háblame de tu negociación más difícil.

Separa su postura de su interés y luego di qué concesión intercambiaste y cuál rechazaste. Los entrevistadores quieren saber si protegiste la relación y el margen.

¿Cómo construyes un pipeline en un territorio completamente nuevo?

Segmenta, elige el nicho donde ganas más rápido y luego planifica la secuencia de contactos. Da tus cifras reales (contactos, tasa de respuesta, reuniones), porque las respuestas vagas sobre actividad suenan a no respuesta.

¿Cómo son tus primeros 30 días con un producto nuevo?

Revisa las últimas cinco ventas ganadas y perdidas, aprende el momento de la demo que siempre funciona y busca un aliado técnico. Di qué serías capaz de hacer sin ayuda al llegar al día 30.

Cuéntame una previsión de ventas en la que te equivocaste.

Explica cómo separas lo comprometido (commit) del mejor escenario (best case), a qué señal le diste demasiado peso y qué disciplina añadiste después. La honestidad en las previsiones es la mayor parte del trabajo.

Cuéntame una vez en la que recuperaste a un cliente muy molesto.

Reconoce el problema, asume los plazos y luego di qué cambió realmente: una corrección, una compensación, un proceso. Lo que más les importa a los entrevistadores es el seguimiento una vez apagado el incendio.

¿Cómo priorizas cuando tienes cinco tickets y todos son urgentes?

Impacto multiplicado por alcance, contrastado con los compromisos contractuales. Di a quién avisaste de los que dejaste para después, porque bajar prioridades en silencio es lo que convierte una cola de tickets en una queja.

Un cliente pide una funcionalidad que nunca se va a desarrollar. ¿Qué le dices?

Habla claro en lugar de dar falsas esperanzas y luego resuelve la necesidad de fondo con lo que ya existe. Regístralo junto con su impacto en el negocio para que el equipo de producto vea el patrón y no un simple deseo.

¿Cómo detectas una cuenta que está a punto de darse de baja?

Caída del uso a nivel de administrador, la marcha de tu principal defensor en la cuenta (champion), un cambio de tono en los tickets, revisiones a las que no se presentan. Luego describe una intervención que funcionó de verdad y otra que no.

Descríbeme una ocasión en la que te enfrentaste a tu propia empresa para defender a un cliente.

Explica el argumento que planteaste internamente y las pruebas que aportaste, además de lo que le prometiste al cliente mientras no se resolvía. No prometer nada que no dependiera de ti es la versión madura.

¿Cómo organizas una reunión de revisión que el cliente valore?

Empieza por los resultados por los que se evalúa al cliente, no por tu lista de funcionalidades. Lleva una recomendación y una petición: una reunión sin petición es solo un informe de estado.

Cuéntame un error que te hizo perder la confianza de un cliente.

Qué le dijiste, con qué rapidez y qué cambiaste en el proceso después. La rapidez con la que lo comunicaste es toda la respuesta.

¿Cómo gestionas un problema que no puedes resolver hoy?

Una estimación honesta de cuándo estará resuelto (o la honestidad de admitir que no la tienes), una solución provisional y una frecuencia de seguimiento acordada que cumples. Las cuentas se pierden por el silencio mucho más a menudo que por los bugs.

Háblame de una decisión de diseño en la que te equivocaste.

Di cómo te diste cuenta (investigación, analítica, la cola de soporte), qué cambiaste y con qué rapidez. Las historias de portafolio en las que nunca falla nada suenan a ficción.

¿Cómo decides qué investigar antes de diseñar?

Elige la suposición más arriesgada y adapta el método a ella: cinco entrevistas para un porqué, analítica para un cuántos, una encuesta para una distribución. Di qué habrías lanzado sin esa investigación.

Una parte interesada quiere algo que perjudica la usabilidad. ¿Qué haces?

Reformula su objetivo, propón una alternativa que lo cumpla y ofrece una prueba barata en lugar de un debate sobre gustos. Di a quién lo escalas si el desacuerdo persiste.

¿Cómo gestionas el feedback en una sesión de crítica de diseño?

Separa la reacción del diagnóstico y pregunta por el problema, no por la solución que te proponen. Describe cómo llevas una sesión de crítica cuando eres tú quien da el feedback.

¿Cómo mides si un diseño ha funcionado?

Combina una métrica de comportamiento con una medida de éxito en la tarea o de esfuerzo, y di qué harías si la cifra se moviera por el motivo equivocado: más clics no siempre es mejor.

Cuéntame alguna vez en la que diseñaste con una restricción técnica muy dura.

Nombra la restricción, las opciones a las que renunciaste y en qué invertiste a propósito el margen que te quedaba. En las restricciones es donde el entrevistador ve tus prioridades.

¿Cómo evitas que un sistema de diseño se convierta en una camisa de fuerza?

Reglas sobre cuándo se permite salirse de él, una vía de contribución que de verdad se usa y una auditoría que detecta las desviaciones antes de que se conviertan en un segundo sistema.

¿Qué significa la accesibilidad en tu trabajo del día a día?

Da ejemplos concretos: contraste, orden del foco, tamaño de los elementos táctiles, etiquetas que pueda usar un lector de pantalla y algo que detectaste en una revisión el mes pasado. Un compromiso vago es la señal de que no se está haciendo.