Mi pregunta de programación favorita para hacer a candidatos
Una popular entrada de blog sobre una pregunta “favorita” de entrevista de programación — encontrar “clientes leales” a partir de dos días de registros web — ha desatado un debate sobre qué deberían medir realmente las entrevistas. Los comentaristas discuten el valor de la ambigüedad en el enunciado, la insistencia en evitar soluciones O(n²) y si optimizar algoritmos en memoria es realista frente a simplemente usar SQL o herramientas de shell. Muchos ven el ejercicio como un proxy de habilidades de estructuras de datos y comunicación, mientras que otros lo critican por ser artificioso y por favorecer a personas buenas resolviendo acertijos de pizarra en lugar de quienes construyen sistemas mantenibles y orientados al negocio.
Ambigüedad y “tramposidad” del enunciado
- Muchos ven la especificación de “clientes leales” (especialmente “al menos dos páginas únicas”) como subespecificada o lógicamente ambigua.
- Algunos sostienen que esto refleja especificaciones de producto del mundo real y que pone a prueba la capacidad de detectar ambigüedad y hacer preguntas aclaratorias.
- Otros lo ven como una injusta “lectura de la mente”, especialmente en entrevistas estresantes donde los candidatos pueden temer que preguntar se penalice.
- Hay preocupación de que los entrevistadores sobrestimen lo claramente que han señalado “por favor, hagan preguntas”.
Lo que realmente está evaluando la pregunta
- Quienes la defienden dicen que evalúa:
- Reconocer una mala complejidad asintótica (rechazar el ingenuo O(n²)).
- Uso de estructuras de datos básicas (mapas/conjuntos) y compensaciones entre tiempo y espacio.
- Capacidad para razonar sobre grandes volúmenes de datos y restricciones.
- Los críticos dicen que sobre todo recompensa el reconocimiento de patrones al estilo LeetCode y hablar de Big-O, no habilidades reales como entender requisitos, diseño de sistemas o trabajo con stakeholders.
- Algunos señalan que las soluciones óptimas en memoria son frágiles y están muy acopladas a “exactamente dos días”, lo que perjudica la extensibilidad.
Estilos alternativos de solución (SQL, shell, herramientas)
- Varios lo resolverían con pipelines de shell (sort/uniq/grep/awk) o con una pequeña consulta en SQLite/DB, especialmente para informes de negocio puntuales.
- Debate:
- A favor de DB/shell: más rápido de implementar, más fácil ajustar requisitos, maneja grandes datos mediante ordenación externa/índices.
- A favor de “20 líneas de código”: mantiene mínimas las dependencias; se centra en la comprensión algorítmica.
- Algunos señalan que el problema es esencialmente un join relacional; los planes de ejecución de la base de datos (hash join, merge join) reflejan las soluciones de CS propuestas.
Rendimiento frente a practicidad
- Hay un fuerte desacuerdo sobre “ningún gran ingeniero debería conformarse jamás con O(n²)”.
- Un lado: los algoritmos cuadráticos son minas peligrosas; las mejores alternativas suelen ser igual de simples y deberían ser instintivas.
- El otro lado: para datos puntuales o pequeños, el tiempo del desarrollador y la simplicidad importan más que la asintótica; la optimización prematura es común.
- Varios señalan que las microoptimizaciones ingeniosas (guardar solo 2 páginas, salidas tempranas, etc.) añaden complejidad y reducen la flexibilidad para métricas futuras.
Diseño de entrevistas, sesgo y experiencia del candidato
- Algunos elogian la pregunta por ser simple, reveladora y adecuada incluso para seniors; otros describen la codificación algorítmica en vivo como aburrida, sin alma o “deshumanizadora”.
- Preocupa que este estilo seleccione a:
- Personas cómodas bajo pruebas de alta presión y con sensación adversarial.
- Quienes se han entrenado específicamente en problemas similares.
- Otros abogan por ejercicios colaborativos, estilo programación en pareja, o tareas pequeñas y realistas (por ejemplo, aplicaciones CLI) como mejores señales de efectividad diaria y trabajo en equipo.