La prueba de Codility: qué mide realmente tu puntuación

De qué está realmente compuesta la puntuación

Cada tarea se evalúa en dos ejes diferentes, y se informan por separado.

• Correctness — la proporción de casos de prueba ocultos en los que tu salida coincide con la esperada. Cada tarea ejecuta al menos seis casos evaluados, y tu puntuación es el porcentaje de los que pasan. Los ejemplos mostrados en el enunciado son demostraciones, no casos evaluados.
• Performance — si la solución se mantiene dentro de los límites de tiempo y memoria a medida que crece la entrada. Esto solo se aplica a tareas donde la escalabilidad forma parte de la puntuación, y se evalúa incluso cuando todas tus respuestas son correctas.

Ese segundo eje es el que la gente no tiene en cuenta. Un bucle O(n²) correcto en una tarea diseñada para O(n log n) devuelve la respuesta correcta en cada caso que termina, pero aún así pierde la mayor parte de los puntos de rendimiento, porque los casos grandes se agotan.

Lee las restricciones como un presupuesto de complejidad

El bloque de restricciones no es decoración. Es la tarea indicándote qué complejidad aceptará, y es lo más útil de la página.

• N hasta 100.000 o más — cualquier algoritmo cuadrático se agotará. Se te pide ordenar, usar un hash map, dos punteros o una prefix sum.
• N hasta unos pocos miles — O(n²) suele estar bien, y buscar algo más ingenioso te cuesta tiempo que necesitarás en otro lado.
• Valores hasta 2 mil millones — la tarea te indica que un acumulador de 32 bits se desbordará. En un lenguaje donde eso importa, aquí también importa.

Calcula la complejidad objetivo antes de escribir una sola línea. En una prueba evaluada automáticamente no hay nadie que otorgue puntos por un buen instinto que nunca implementaste.

A dónde van realmente los puntos

Tres patrones explican la mayor parte de la puntuación perdida, y ninguno tiene que ver con la capacidad algorítmica.

• Casos límite que nadie probó. Entrada vacía, un solo elemento, todos los elementos iguales, los valores mínimo y máximo permitidos. Estos son exactamente los casos ocultos, porque son los más baratos de escribir.
• Error de off-by-one en el límite. Los rangos inclusivos frente a los exclusivos cuestan más puntos de Codility que cualquier estructura de datos.
• Quedarse sin tiempo en la tarea tres. El temporizador cubre todo el test, no cada tarea. Una persona que deja un brute force funcional en cada tarea suele superar a quien tiene una solución perfecta y dos en blanco.

El crédito parcial es real, así que úsalo

Como la puntuación es un porcentaje de los casos, un brute force honesto vale mucho más que un editor vacío. La secuencia que obtiene la mejor puntuación bajo presión de tiempo es casi siempre la misma: escribe la solución obvia, envíala, luego optimízala y envíala de nuevo. Primero acumulas los puntos y después los mejoras.

Si sabes que tu solución es demasiado lenta y no puedes arreglarla, déjala. Una entrega que supera el tiempo límite en los casos grandes sigue recogiendo todos los casos pequeños y medianos que supera.

Los últimos diez minutos

Deja de escribir código nuevo. Ejecuta cada tarea una vez con una entrada vacía, una vez con un solo elemento y una vez con el valor máximo que permiten las restricciones. Esa pasada consigue más puntos que un cuarto intento en la tarea difícil, y lleva tres minutos.

Una cosa más que es mejor saber antes que descubrir después: la plataforma registra lo que ocurre en la pestaña, incluidos los cambios de foco y los bloques pegados, y el empleador ve ese resumen junto a tu puntuación. Planifica tu test como algo que haces sentado y terminas, no como algo que armas a partir de otras ventanas.

Cómo ayuda la aplicación aquí

Sigue leyendo