Cómo se van los noventa minutos

La prueba no se pierde por no saber pandas. Se pierde por gastar cincuenta minutos en la exploración y ocho en el modelo. Un presupuesto que funciona para un examen de 100 puntos donde el modelo vale 30–40:

Minutos	Qué
0–8	Leer todo el enunciado. Cada defecto está enunciado como una regla. Anotar qué tarea depende de cuál.
8–20	Cargar, coercionar tipos, contar lo que falta. Asegurar las tareas tempranas.
20–45	Limpieza y features, calificando sobre la marcha.
45–75	El modelo. Un pipeline, hiperparámetros de fábrica, después features.
75–90	Releer el enunciado contra las respuestas: tipos de retorno, número de filas, orden del archivo.

Dos cosas valen más que cualquier tuning:

Calificar temprano y seguido. Es gratis. Enterarse en el minuto 70 de que el loader botó filas es la forma cara.
Nunca deduplicar el archivo de scoring. Cada tarea de modelo comprueba que devolviste una predicción por fila del holdout, en el orden del archivo. Es la forma más común de sacar cero en una tarea que ya estaba resuelta.

Casos visibles versus la nota

CodeSignal muestra dos cosas: unos pocos tests de ejemplo que puedes correr cuando quieras, y un conjunto oculto que decide la nota. El drill tiene ambos. Los casos visibles son frames de cuatro filas con una respuesta calculada a mano, una idea por caso (-1 cuenta como faltante; 04/03/2026 es el 4 de marzo; un lote medido dos veces es un lote). Un fallo imprime la entrada, la salida esperada, lo que devolviste y una frase de por qué está mal. Nunca tocan los CSV del día, así que pasarlos todos significa «bien en el ejemplo que pude comprobar a mano» y nada más. Calificar es el conjunto oculto: el examen entero, contra el ledger del día.

Por qué se puede confiar en el corrector

Un ledger, no una segunda implementación. El generador anota los ids de cada corrupción que inyecta y las comprobaciones leen ese registro. Un corrector que recalculara isna().sum() para calificar tu isna().sum() coincidiría con una referencia equivocada de la misma manera; éste no puede.
Una referencia que saca 100. make ds-test califica el reference.py de cada proyecto contra su propio examen. Si una tarea no se puede responder como está redactada, la suite se pone roja.
Baselines que deben fallar. Cada tarea de modelo nombra las respuestas perezosas que existe para vencer — predecir la tasa base, una regresión logística sobre las columnas que ya eran numéricas, un promedio tienda×SKU — y la suite falla si alguna supera el umbral. Sin eso, los números de los enunciados serían decoración.

La nota es la fracción de sub-comprobaciones que pasaron, así que cuatro de seis reglas de limpieza es cuatro sextos, no un juicio. Una función que lanza una excepción es una sub-comprobación fallida con la excepción y el número de línea en tu archivo, no un corrector caído.

Lo que hay dentro de cada proyecto

Archivo	Qué es
`brief.md`	El enunciado. Léelo entero antes de escribir nada.
`cases.md`	Los casos visibles: la entrada de juguete de cada función y la salida que debe dar.
`data/*.csv`	El archivo de entrenamiento y el holdout a puntuar.
`solution.py`	Stubs con las firmas exactas que llama el corrector. Es el archivo que se edita.
`report.json`	La última nota, tarea por tarea.

La clave de respuestas nunca se escribe en el workspace. Calificar reconstruye el dataset desde la semilla, así que el registro de lo que se corrompió sólo existe dentro del proceso que califica.

Código de honor

Nada de esto es material de la prueba. Cada dataset lo genera código de este repositorio a partir de una semilla, cada enunciado se escribió para este repositorio, y ninguna pregunta, dataset ni solución de CodeSignal se reproduce ni se parafrasea. Los proyectos entrenan las tres habilidades nombradas — EDA, limpieza y preprocesamiento, modelado predictivo — como lo haría cualquier ejercicio de libro. Durante la prueba, ni este sitio ni ninguna IA generativa: es la regla, y el reflejo que se entrena es no necesitarlos.