Todas las entradas

Tecnología · July 22, 2026 · 13 min de lectura

Cómo contratar a un ingeniero de datos: una guía centrada en las habilidades para 2026

Cómo contratar a un ingeniero de datos sin dejarte engañar por un CV pulido: una guía centrada en las habilidades sobre muestras de trabajo, pipelines, trampas de calidad de datos y fluidez con la IA.

Por Jakir Patel · Founder, Hanzomon

Compartir
Tecnología
En esta página

Esta guía es para responsables de contratación y reclutadores que buscan cubrir un puesto de ingeniería de datos: la persona que construye los pipelines y modela los datos en los que después confía toda tu empresa. Si te equivocas en esta contratación, el fallo es silencioso y caro: paneles que parecen correctos pero mienten, una cifra de ingresos desviada un 4% durante tres semanas, un trabajo nocturno que cuenta el doble cada vez que se reintenta, y analistas que poco a poco dejan de confiar en el almacén de datos y vuelven a sacar sus propios extractos. Un ingeniero de datos flojo no rompe las cosas de forma ruidosa: erosiona lo único que vende un equipo de datos, que es la confianza en los números. Por eso es tan peligroso filtrar para este puesto por pedigrí o por CV con palabras clave coincidentes, y por eso necesitas ver el trabajo real antes de comprometerte.

Qué hace realmente un gran ingeniero de datos

Un modelo mental útil: un analista de datos lee el agua, un ingeniero de datos construye la fontanería. El analista responde preguntas a partir de los datos; el ingeniero se asegura de que los datos que llegan sean correctos, puntuales, bien estructurados y rastreables, para que se pueda confiar en cada respuesta aguas abajo. Cuando la fontanería es buena, nadie piensa en ella; cuando es mala, todo el mundo lo hace, y toda la empresa se ralentiza. Este es un trabajo distinto del de un ingeniero de software o del de un analista, y contratarlo bien significa saber exactamente cómo es el día a día. Un ingeniero de datos sólido:

  • Diseña y mantiene pipelines que mueven y transforman datos de forma fiable, incluso cuando se reprocesa un lote, una fuente llega tarde o un trabajo falla a mitad de camino
  • Modela los datos en esquemas claros, consultables y honestos respecto al grano, para que una fila signifique exactamente una cosa y las uniones no se disparen en silencio
  • Protege la calidad de los datos sin descanso: comprobaciones de nulos, restricciones de unicidad, monitores de frescura, reconciliación contra fuentes de verdad y alertas antes de que lo note el CEO
  • Mantiene el linaje legible: capaz de rastrear cualquier número a través de cada transformación hasta su origen, y explicar por qué puedes confiar en él
  • Trata los pipelines como software: control de versiones, pruebas, revisión de código, transformaciones idempotentes y un rollback sensato, no un montón de tareas cron que nadie se atreve a tocar
  • Colabora con analistas, científicos y equipos de producto para exponer los datos de formas difíciles de usar mal y fáciles de razonar

Las habilidades que de verdad predicen el éxito

Las herramientas cambian sin parar (Spark, dbt, Airflow, Snowflake, lo que esté en auge en 2026), pero las habilidades de fondo que separan a un gran ingeniero de datos de uno simplemente ocupado apenas cambian. Contrata por estas y deja que un ingeniero sólido asimile tu stack concreto. Este es el argumento central de la contratación basada en habilidades: la señal duradera es la capacidad, no una lista de herramientas en un currículum. Los rasgos que de verdad predicen el éxito:

  • SQL fluido e idiomático: funciones de ventana, uniones cuidadosas, un instinto para el grano y para lo que una consulta cuesta realmente a escala
  • Auténtica disciplina de ingeniería de software: idempotencia, pruebas, modularidad y control de versiones, porque un pipeline es código de producción que se ejecuta sin supervisión a las 3 de la madrugada
  • Criterio en el modelado de datos: saber cuándo normalizar, cuándo desnormalizar y cómo diseñar un esquema que sobreviva a los requisitos cambiantes
  • Obsesión por la calidad de los datos: el reflejo de preguntarse '¿cómo sabría si esto estuviera mal?' antes de publicar, y de construir la comprobación que lo responda
  • Claridad de pensamiento sobre el linaje y la procedencia: capaz de razonar sobre de dónde vinieron los datos y por dónde pudo colarse un valor erróneo
  • Temperamento para depurar: sereno, sistemático y guiado por hipótesis cuando un número está mal y podrían tener la culpa cinco sistemas

Dónde falla el filtrado por currículum y entrevista para este puesto

  • Filtrar por empleadores de marca o por palabras clave de herramientas concretas, lo que descarta a ingenieros sólidos y deja pasar a habladores elocuentes
  • Trivialidades de SQL en la pizarra que premian la sintaxis memorizada por encima del criterio de modelado y el pensamiento sobre la calidad
  • Reutilizar un filtro genérico de algoritmos de ingeniería de software que nunca toca pipelines, grano ni linaje
  • Confiar en una narración segura sobre proyectos pasados sin ver nunca a la persona hacer el trabajo real

Un proceso paso a paso para contratar a un ingeniero de datos

1. Define el alcance del puesto antes de escribir una sola palabra de la oferta

Este proceso de seis pasos saca a la luz señal real, se mantiene justo y no lleva seis semanas. Empieza por decidir qué va a asumir realmente esta persona. Un ingeniero de campo verde que levanta un almacén de datos desde cero es una contratación distinta de alguien que mantiene una plataforma madura, o de un ingeniero de analítica que vive sobre todo en dbt y en el modelado. Escribe los tres problemas que resolverá en su primer trimestre y luego construye la oferta y la evaluación en torno a ellos. Una descripción de puesto afilada que nombre problemas reales atrae a personas que quieren resolverlos, y ahuyenta a quienes solo buscan coincidencias de palabras clave.

2. Filtra por habilidades, no por pedigrí

Sustituye la clasificación por currículum por un filtro de habilidades breve y relevante para el puesto desde el principio. Un ejercicio de diez minutos (encontrar el error en una transformación, criticar un esquema, razonar sobre una unión que se dispara) filtra con mucha más precisión que los años de experiencia o un logo conocido, y lo hace antes, sin haber invertido tiempo de entrevista. Además reduce el sesgo: todos reciben la misma tarea, juzgada de la misma manera, y el pedigrí deja de sustituir a la competencia.

3. Evalúa el trabajo real con una muestra de trabajo específica del puesto

Este es el paso de mayor señal, con diferencia. Las pruebas de muestra de trabajo predicen el desempeño en el puesto mejor que casi cualquier otra cosa, porque estás viendo el trabajo real. Para un ingeniero de datos, dale una tarea desordenada y realista, no un juguete. Buenas opciones: entrégale dos fuentes de datos que no coincidan y pídele que las reconcilie y las modele; dale un pipeline que produzca números sutilmente erróneos y pídele que encuentre y corrija la causa; o pon delante de él un conjunto de datos deliberadamente sucio con una trampa de calidad de datos enterrada dentro (claves duplicadas tras un reintento, una zona horaria que desplaza un día entero de eventos, un enum cambiado en silencio) y observa si la detecta. Lo que estás calificando no es solo la corrección; es si interroga los datos antes de confiar en ellos. Fundamenta esto en una evaluación de habilidades del dominio real en lugar de acertijos abstractos.

4. Prueba cómo trabajan con la IA

En 2026, tus ingenieros de datos construirán pipelines con asistentes de IA en el bucle: generando SQL, montando el andamiaje de transformaciones, explicando esquemas desconocidos. Eso cambia lo que deberías evaluar. El riesgo no es que usen IA; es que confíen en ella sin criterio y publiquen una consulta que parece correcta y que en silencio cuenta el doble. Evalúa la fluidez con la IA directamente usando el marco de las 4D (Delegation, Description, Discernment y Diligence), con un peso especial en el Discernment para este puesto: ¿pueden detectar el resultado plausible-pero-erróneo antes de que llegue al almacén de datos? La forma más práctica de observar esto es un AI Sandbox: una tarea realista del puesto con herramientas de IA disponibles, donde ves cómo delegan, verifican y corrigen. Un ingeniero de datos que acepta a ciegas el SQL generado por IA es más peligroso que uno que no tiene ninguna.

En el AI Sandbox, un candidato a ingeniería de datos construye y depura un pipeline con herramientas de IA disponibles, y ves si detecta el SQL plausible-pero-erróneo antes de que corrompa los números.

5. Realiza una entrevista estructurada para el criterio y la colaboración

Usa la entrevista para lo que una muestra de trabajo no puede mostrar fácilmente: cómo razonan sobre los compromisos, cómo gestionan estar equivocados y cómo colaborarán con los analistas y científicos que dependen de ellos. Hazla como una entrevista estructurada (mismas preguntas, misma rúbrica, todos los candidatos) para comparar personas, no sensaciones. Ancla las preguntas en situaciones reales para sondear el criterio situacional: una métrica se desvió, un stakeholder quiere un atajo que rompe el linaje, un backfill debe ejecutarse sin corromper el historial. Buscas a alguien que razone en voz alta, nombre los riesgos y sepa lo que no sabe.

6. Que sea justo y rápido

Un gran ingeniero de datos tiene opciones y no esperará tres semanas a través de cinco rondas. Comprime el proceso a cuatro pasos: filtro de habilidades, muestra de trabajo, una entrevista estructurada y decisión. Adelantar la evaluación de habilidades te permite reducir el tiempo de contratación con IA sin sacrificar rigor, y un proceso ágil y respetuoso protege la experiencia del candidato, que importa más precisamente para las personas sénior que más quieres contratar.

Generated question
Phase 1
Structural rules
Phase 2
AI judge · 5 dimensions
Pass — banked clean
Borderline — human review
Fail — quarantined

A different model judges the maker's output — cross-model review, not a rubber stamp.

Preguntas de entrevista que de verdad funcionan

  • "Una métrica de un panel bajó un 8% de la noche a la mañana sin ningún error. Explícame cómo encontrarías la causa." — quieres una búsqueda sistemática, de la fuente al panel, no una conjetura.
  • "Este trabajo nocturno a veces se ejecuta dos veces. ¿Qué tiene que ser cierto sobre él para que eso sea seguro?" — escucha buscando idempotencia, no evasivas.
  • "Te dan dos sistemas que informan cifras de ingresos distintas. ¿Cómo decides cuál es la correcta?" — instinto de reconciliación y comodidad con 'depende, así es como lo averiguaría'.
  • "¿Normalizarías o desnormalizarías este modelo?" (muestra un esquema real) — la respuesta importa menos que si razonan sobre el grano, los patrones de consulta y el cambio.
  • "Un asistente de IA te entrega una consulta SQL de 40 líneas que devuelve números plausibles. ¿Qué haces antes de confiar en ella?" — Discernment y diligence bajo presión de tiempo.
  • "Cuéntame de alguna vez que tu pipeline entregó un número erróneo a un stakeholder. ¿Qué pasó y qué cambiaste?" — honestidad, responsabilidad y si después construyeron una salvaguarda.

Señales buenas frente a señales de alarma

  • BUENA: Interroga los datos antes de confiar en ellos; comprueba recuentos, nulos y grano sin que se lo pidan
  • BUENA: Razona en voz alta sobre la idempotencia y qué ocurre en un reintento o un backfill
  • BUENA: Puede rastrear un número de principio a fin y explicar por qué es fiable
  • BUENA: Usa herramientas de IA pero verifica su resultado y sabe decir por qué el SQL de la IA estaba mal
  • BUENA: Dice 'no lo sé, así es como lo averiguaría' en lugar de farolear
  • ALARMA: Acepta los datos (o el resultado de la IA) al pie de la letra y salta directamente a escribir consultas
  • ALARMA: Trata los pipelines como scripts, sin pensar en reejecuciones, pruebas ni rollback
  • ALARMA: Sabe enumerar herramientas con soltura pero no puede razonar sobre el grano ni el linaje
  • ALARMA: Publica con seguridad una consulta con un doble recuento silencioso y no lo nota
  • ALARMA: Habla en palabras de moda y se vuelve vago en cuanto le preguntas '¿cómo sabrías si estuviera mal?'

La habilidad central por la que contratas no es escribir pipelines, es ganarse la confianza en los números. Los mejores ingenieros de datos son los que dan por hecho que sus propios datos están mal hasta que demuestran lo contrario, y que construyen las comprobaciones que permiten a todos los demás dejar de preocuparse.

Errores comunes al contratar a un ingeniero de datos

  • Contratar para el stack de herramientas actual en lugar de para las habilidades duraderas: volverás a contratar en dos años cuando cambie el stack
  • Confundir a un buen analista de datos con un ingeniero de datos: leer el agua y construir la fontanería son trabajos distintos
  • Saltarse la muestra de trabajo porque cuesta más construirla que un acertijo: es también el único paso que predice de forma fiable el trabajo
  • Tratar la fluidez con la IA como un sí/no en lugar de evaluar si pueden detectar los errores plausibles de la IA: consulta cómo evaluar la fluidez con la IA
  • Ignorar el coste de los fallos silenciosos: modela aquí el verdadero coste de una mala contratación en confianza erosionada y retrabajo, no solo en salario
  • Llevar un proceso no estructurado y confundir la seguridad con la competencia
Los mejores ingenieros de datos no solo mueven datos: los convierten en algo en lo que toda la empresa puede confiar sin pensarlo. Contrata por ese instinto, obsérvalo en el trabajo real y nunca volverás a publicar un panel precioso construido sobre un número roto.
data engineeringtechnical hiringwork sample testsai fluency
J

Escrito por

Jakir Patel · Founder, Hanzomon

Building H-Evaluate — AI-native, quality-gated hiring assessments. Writes about assessment engineering, hiring integrity and compliance-first AI.

Preguntas frecuentes

¿Cómo se evalúan las habilidades de un ingeniero de datos?

Ponle el trabajo real: una muestra de trabajo específica del puesto en la que diseñe o depure un pipeline, modele un conjunto de datos desordenado o detecte una trampa de calidad de datos. Observa cómo razona sobre el esquema, la idempotencia y los casos límite, no solo si la respuesta final es correcta. Un CV y un acertijo de SQL en la pizarra te dicen mucho menos que ver a alguien reconciliar dos fuentes que no coinciden.

¿Qué habilidades importan más en un ingeniero de datos?

Primero, un SQL sólido y una auténtica disciplina de ingeniería de software; después, el modelado de datos, la fiabilidad de los pipelines y la idempotencia, y un instinto casi obsesivo por la calidad de los datos. Sobre todo, contrata por la claridad de pensamiento sobre el esquema y el linaje: alguien capaz de decirte de dónde salió un número y por qué puedes confiar en él. La familiaridad con las herramientas (Spark, dbt, Airflow) importa menos que estos fundamentos y puede aprenderse sobre la marcha.

¿Qué preguntas de entrevista debería hacerle a un ingeniero de datos?

Haz preguntas que saquen a la luz el criterio ante la ambigüedad: cómo diseñaría un pipeline que deba sobrevivir a un lote reprocesado, cómo depuraría una métrica que se desvió en silencio, o cómo decide entre normalizar y desnormalizar un modelo. Las mejores preguntas describen una situación desordenada y realista y preguntan qué haría y por qué, para luego insistir en los compromisos. Evita las trivialidades sobre sintaxis o el último framework.

Publicaciones relacionadas

Míralo con tu propia descripción de puesto

Únete a la lista de acceso anticipado y observa cómo H-Evaluate crea una evaluación para un puesto real.

Míralo con tu propia descripción de puesto