Evaluación de competencias
Evaluación de competencias de Ingeniero de Datos
El CV de un ingeniero de datos te dice qué herramientas ha tocado; no puede decirte si los números que llegan a tu almacén son correctos. Dos candidatos que listan el mismo stack pueden diferir enormemente en cómo razonan sobre la granularidad, la idempotencia y dónde podría haber entrado un valor incorrecto. Un ingeniero de datos débil falla silenciosamente: un trabajo nocturno cuenta doble en un reintento, una métrica se desvía y los analistas dejan lentamente de confiar en los números. Filtrar por palabras clave y pedigree pasa por alto exactamente el criterio que previene eso.
El objetivo no es un puzzle de SQL en pizarra. Es una muestra relevante para el puesto del trabajo real: reconciliar dos fuentes que discrepan, detectar una trampa de calidad de datos en un dataset sucio, razonar sobre un pipeline que debe sobrevivir a un lote reprocesado. H-Evaluate genera esa evaluación a partir de tu descripción de puesto —generación por puesto, de modo que ningún candidato haya ensayado las preguntas— y califica a todos los candidatos con la misma rúbrica.
Qué evaluar
Las competencias que predicen el desempeño en este puesto, asignadas a los cinco pilares de contratación.
Pipeline y consultas en un entorno en vivo
Diseñar o depurar un pipeline real y escribir SQL contra un dataset desordenado: haciendo joins, filtrando y razonando sobre idempotencia, en lugar de responder trivialidades sobre sintaxis de forma abstracta.
Modelado de datos y profundidad en SQL
SQL fluido e idiomático y criterio de modelado: cuándo normalizar, cuándo desnormalizar y cómo diseñar un esquema que mantenga la honestidad sobre la granularidad a medida que cambian los requisitos.
Razonamiento sobre calidad de datos
El reflejo de preguntar '¿cómo sabría si esto fuera incorrecto?' antes de confiar en un resultado: detectar claves duplicadas, cambios de zona horaria y deriva silenciosa, y razonar sobre el linaje de un número hasta su origen.
Criterio bajo ambigüedad
Cómo gestiona un candidato escenarios realistas: una métrica que cayó silenciosamente durante la noche, un backfill que no debe corromper el historial, una parte interesada que quiere un atajo que rompe el linaje.
Colaboración con consumidores de datos
Cómo explican los trade-offs, admiten lo que no saben y se asocian con los analistas y científicos que dependen de los datos que exponen y que usarían mal un esquema mal modelado.
Fluidez en IA
Usar asistentes de IA para andamiar transformaciones y SQL, pero verificar el resultado: detectar la consulta plausible pero incorrecta que silenciosamente cuenta doble antes de que llegue al almacén.
Cómo estructurar la evaluación
- 1Prefiere una muestra de trabajo específica para el puesto —reconciliar dos fuentes en desacuerdo o depurar un pipeline que produce números sutilmente incorrectos— sobre un puzzle de SQL en pizarra.
- 2Incorpora deliberadamente una trampa de calidad de datos en la muestra: una clave duplicada tras un reintento, un cambio de zona horaria, un enum que cambió silenciosamente, y observa quién lo detecta sin indicárselo.
- 3Ajusta la dificultad y la ponderación al nivel: construir un almacén desde cero y mantener una plataforma madura son contrataciones distintas.
- 4Da a los candidatos las herramientas que usarían en el puesto, incluidos asistentes de IA, y evalúa si verifican el resultado.
- 5Califica a todos los candidatos con la misma rúbrica para que se comparen la granularidad, el linaje y el razonamiento de calidad, no solo si la consulta final se ejecuta.
Señales que predicen el éxito
- +Interroga los datos antes de confiar en ellos: comprueba recuentos, nulos y granularidad sin que se lo pidan
- +Razona en voz alta sobre idempotencia y qué ocurre en un reintento o backfill
- +Puede trazar un número de extremo a extremo y explicar por qué es confiable
- +Usa herramientas de IA pero verifica su SQL y puede decir exactamente por qué el resultado era incorrecto
Señales de alerta
- –Acepta datos o resultado de IA al pie de la letra y salta directamente a escribir consultas
- –Trata los pipelines como scripts: sin pensar en reejecuciones, pruebas o rollback
- –Lista herramientas con fluidez pero no puede razonar sobre granularidad o linaje
- –Publica confiadamente una consulta con un doble conteo silencioso y no lo nota
Evaluación frente a entrevista
Una entrevista premia una narrativa segura sobre pipelines pasados; raramente revela si alguien realmente interroga un dataset antes de confiar en él. Una muestra de trabajo lo muestra directamente: observas si detectan la trampa de calidad de datos o no. Usa la evaluación para reunir esa evidencia y luego la entrevista para lo que una muestra no puede mostrar fácilmente: cómo razonan sobre trade-offs, gestionan estar equivocados y se asocian con los analistas que dependen de ellos.
Evaluación de competencias
Configura esta evaluación por puesto y seniority
Observa cómo cambia el énfasis en tiempo real al cambiar el puesto y el nivel — sin registro.
Lecturas relacionadas
Cómo contratar a un ingeniero de datos: guía basada en competencias para 2026
Cómo contratar a un ingeniero de datos sin dejarte engañar por un CV impecable: una guía basada en competencias sobre pruebas de trabajo, pipelines, trampas de calidad de datos y AI Fluency.
Pruebas de muestra de trabajo: la forma más predictiva de contratar
Las pruebas de muestra de trabajo miden lo que un candidato puede hacer realmente y predicen el rendimiento laboral mejor que los currículums o las entrevistas. Cómo diseñarlas y puntuarlas bien.
Evaluación de competencias de dominio: ¿pueden hacer el trabajo?
Una evaluación de competencias de dominio mide el trabajo en sí, no un indicador. Cómo las preguntas generadas por puesto y de forma sistemática evalúan la competencia real de manera justa entre candidatos.
Preguntas frecuentes
¿Cómo se evalúa a un ingeniero de datos?
Dales el trabajo real: una muestra específica para el puesto donde diseñan o depuran un pipeline, modelan un dataset desordenado o detectan una trampa de calidad de datos. Observa cómo razonan sobre esquemas, idempotencia y casos límite, no solo si la respuesta final es correcta. Reconciliar dos fuentes que discrepan te dice mucho más que un puzzle de SQL en pizarra o un CV con palabras clave coincidentes.
¿Qué habilidades debe cubrir una evaluación de ingeniero de datos?
SQL fluido y disciplina genuina de ingeniería de software primero, luego modelado de datos, fiabilidad de pipelines e idempotencia, y un instinto casi obsesivo por la calidad de datos. Pondera el razonamiento sobre linaje con gran peso: alguien que pueda decirte de dónde viene un número y por qué puedes confiar en él. La familiaridad con herramientas como Spark, dbt o Airflow importa menos y es aprendible en el puesto.
¿Es suficiente una prueba de SQL para contratar a un ingeniero de datos?
No. La fluidez en SQL es necesaria pero no suficiente. La habilidad más difícil y más predictiva es el criterio de calidad de datos: notar una clave duplicada tras un reintento, cuestionar una métrica que se desvió, razonar sobre granularidad. Evalúa ambas, y valora si el candidato interroga los datos antes de confiar en ellos, no solo si la consulta se ejecuta.
¿Cómo se comprueba si un ingeniero de datos usa bien la IA?
Ejecuta la evaluación en un entorno donde los asistentes de IA estén disponibles de verdad y observa cómo los usa el candidato. El riesgo no es que usen IA: es que confíen en ella de forma acrítica y publiquen una consulta de aspecto plausible que silenciosamente cuenta doble. Pondera el discernimiento: ¿pueden detectar el resultado incorrecto antes de que llegue al almacén?