Personas hartas de las entrevistas estilo LeetCode
(nelson.cloud)- Tras dejar Robinhood a finales de noviembre de 2023 por problemas de salud, pasó por varios procesos de contratación y sintió que las evaluaciones al estilo LeetCode no encajan con el trabajo real de ingeniería de software
- Considera que muchas empresas repiten entrevistas similares siguiendo el modelo de las grandes tecnológicas como Google, Facebook/Meta y Amazon
- Critica que, aunque los ingenieros dicen que no hace falta memorizar conocimientos que se pueden buscar, en las entrevistas los preguntan como si fueran un cuestionario, aun cuando no son fáciles de recordar al instante
- Ha vivido tanto éxitos como fracasos en este tipo de entrevistas, y la base de su descontento está más cerca de su experiencia laboral real que de haber fallado
- Añade que, si alguna empresa busca a un ingeniero con experiencia en AWS, Kubernetes y Ruby on Rails y no hace cuestionarios inútiles, puede contactarlo
Dónde chocan las entrevistas estilo LeetCode con el trabajo real
- Tras dejar Robinhood a finales de noviembre de 2023 por motivos de salud, hizo entrevistas con varias empresas
- Aunque los procesos no avanzaron por distintas razones, terminó cansado de las repetidas entrevistas estilo LeetCode
- Considera que este tipo de entrevistas no refleja adecuadamente las responsabilidades reales de la ingeniería de software
- Parece que muchas empresas adoptan este mismo método de evaluación porque es el que usan grandes compañías como Google, Facebook/Meta y Amazon
El choque entre las evaluaciones tipo cuestionario y la experiencia práctica
- Hay ingenieros que suelen decir que no hace falta memorizar conocimientos que se pueden encontrar fácilmente en Google
- Pero en las entrevistas a veces preguntan cosas que se pueden buscar, aunque sean difíciles de recordar en el momento, y eso le parece contradictorio
- No ve una solución clara para este problema, pero sí cree que el problema existe con toda claridad
- Ha experimentado tanto éxitos como fracasos en este tipo de entrevistas, y su postura está más influida por su experiencia profesional previa que por su tasa de fracaso
- Dice que, si alguna empresa necesita un ingeniero de software con experiencia en AWS, Kubernetes y Ruby on Rails y no hace entrevistas tipo cuestionario, puede ponerse en contacto
- También sugiere leer Re-imagining Technical Interviews: Valuing Experience Over Exam Skills
1 comentarios
Opiniones de Hacker News
Entiendo la frustración, pero al final creo que este tipo de entrevistas sí tienen un propósito. Aunque no sean perfectas, son lo bastante útiles y, por lo general, generan más falsos negativos que falsos positivos, lo cual tiene sentido desde el punto de vista de la empresa.
El costo de rechazar a una persona inteligente es bajo, pero si contratas a la persona equivocada, el costo es alto porque hay que evaluarla durante meses, despedirla y volver a contratar. Dicho eso, para el candidato es un proceso extremadamente doloroso, y hasta un gran ingeniero de software puede ponerse nervioso, equivocarse o tener un mal día y fallar algunas veces. Una entrevista no es una evaluación definitiva del valor de una vida; es solo una herramienta burda, así que conviene dejarlo pasar.
Las preguntas “trampa” son tontas, pero hay que ver si el candidato conoce lo básico y, al mismo tiempo, mostrar qué tipo de empresa somos. Por ejemplo, que pregunte “¿puedo modificar los argumentos?” o que diga “no recuerdo si
strlenincluye el byte 0, así que voy a sumar 1; normalmente lo buscaría” es una buena señal. Los problemas eran de un nivel básico, pero no completamente trivial como fizzbuzz, por ejemplo atoi o “barajar un mazo de cartas”. Una de las mejores contrataciones que hicimos cometió un error fundamental, pero cuando le preguntamos si eso funcionaría como esperaba, dijo “soy un maldito idiota” y lo corrigió de inmediato. Quizá ese tono no sea apropiado en una entrevista, pero para nosotros fue una señal muy positiva. En cambio, también hubo un candidato que insistió hasta el final en que era injusto pedirle parsear una cadena y devolver un entero porque ya existía una función de biblioteca, y de hecho parte de nuestro sistema corría en un entorno embebido sin bibliotecas.Ojalá no imitaran esa forma de evaluar primero la memoria, como en los exámenes horribles de la escuela y la universidad. A mí me costaba muchísimo porque no soy bueno para recordar cosas al instante cuando las necesito, y seguro no soy el único. Cuando entrevistaba desarrolladores Android, les hacía preguntas y observaba cómo pensaban, pero no esperaba que todas las respuestas fueran correctas. Después de ver si tenían una comprensión básica de Android, les pedía que hicieran una app pequeña en casa.
Al final, en una contratación en la que hay que cubrir un puesto, cuanto más aumentan los falsos negativos, también aumenta la probabilidad de contratar un falso positivo. En el extremo, si solo hay una persona en el planeta apta para ese trabajo y la rechazas como falso negativo, la única opción que queda es contratar a la persona equivocada.
El problema no es la falta de inteligencia, sino que alguien puede resolver bien problemas de algoritmos sin ser ingeniero de software, o sin tener las capacidades que requiere ese puesto. Trabajo en un equipo donde se contrató mucho mediante entrevistas tipo acertijo; todos son inteligentes, pero no son ingenieros de software, y esa diferencia se nota mucho.
Si alguien los resuelve, es mucho más probable que haya visto el mismo problema, o uno muy parecido, haciendo ejercicios de práctica, que que realmente haya derivado de nuevo la solución óptima.
Una vez tuve una entrevista que me gustó bastante; era en un banco. Me dieron código desordenado escrito a las apuradas, aunque no ofuscado a propósito, y me pidieron refactorizarlo lo mejor posible.
El entrevistador se sentó a mi lado y conversó conmigo durante todo el proceso; en la práctica fue casi programación en pareja guiada por el candidato. Después de entrevistas de LeetCode, se sintió refrescante. Claro, ese banco sabía exactamente qué tecnologías usaba y tenía menos necesidad de medir la capacidad de aprender tecnologías nuevas, así que ese enfoque era posible. Para ellos era más importante saber si uno podía producir código mantenible, poner buenos nombres y comunicarse con sus colegas.
Lo interesante es que a veces personas que casi fallaron en las preguntas básicas resultaban hacerlo tan bien en el code review que se notaba una experiencia profunda. Las entrevistas son una herramienta bastante mala para mostrar la capacidad laboral de una persona, pero si alguien puede mirar los problemas tanto en términos amplios como en detalle, y además programar lo suficientemente bien, en general lo considero un éxito.
Las entrevistas estilo LeetCode probablemente cumplen dos funciones. Primero, son una forma de contener los salarios y la movilidad laboral de los ingenieros de software. Si para cambiarte tienes que estudiar uno o dos meses, ¿quién se cambia fácilmente?
Si tienes mala suerte y te toca un entrevistador que se preparó mucho y te lanza una bomba nivel LeetCode hard, durante un año se te hace difícil volver a postular a esa empresa. Segundo, sirven para ocultar los sesgos del proceso bajo el argumento de que a todos se les dio un objetivo similar y claro. Si eres de la misma escuela, género o raza, aunque te den el mismo problema pueden darte pistas, pasarte errores de sintaxis y, aunque no llegues al enfoque óptimo, darte una evaluación fuerte de contratación por tu “comunicación”. Si alguien no te cae bien, basta con tirarle un problema difícil y quedarse en silencio durante toda la entrevista. Para la empresa es ruido aceptable, pero para la persona es perder una oportunidad de compensación de cientos de miles de dólares. He hecho entrevistas en FAANG y también he sido entrevistador, y vi a gente contratada con estándares bajos, mientras al mismo tiempo excelentes ingenieros perdían oportunidades por preguntas absurdas como árboles de cuadrantes o teoría de números
Si asumimos un entrevistador justo, este método les da una oportunidad de demostrar su habilidad incluso a candidatos cuyo currículum no tiene nombres famosos. Algunas de las oportunidades que obtuve sin tener un título en ciencias de la computación jamás las habría tenido si no fuera por entrevistas de pizarra. Es difícil imaginar una forma de impedir que un entrevistador tuerza deliberadamente el proceso para contratar a un amigo
Muchas empresas tienen bancos de problemas diseñados para ser justos y estar, hasta cierto punto, relacionados con problemas reales. Las empresas donde entrevisté en general eran así, y aunque no fueran exactamente problemas de LeetCode, al final eran problemas de programación aislados, así que los considero estilo LeetCode. Las entrevistas de las empresas que ejecutan bien este método fueron bastante decentes. Las buenas empresas y los buenos entrevistadores miran más que solo el código final, y también califican la decisión de contratación en una escala para reducir el binarismo
En la práctica, solo con fizzbuzz ya se filtraba al 75%. Mucha gente no puede escribir código bajo presión, y también hay quienes sobreviven a la fuerza copiando y pegando. Eso no significa que no puedan hacer nada, sino que son lentos, producen abstracciones raras y consumen mucho tiempo hasta obtener un resultado usable. Y esas personas también discuten igual, porque hay cientos de miles de dólares en juego
Desde el punto de vista de la empresa, es razonable. Quiere empleados sin distracciones y capaces de hacer horas extra
Hay muchas críticas válidas a las prácticas actuales de contratación en tecnología, pero la queja de que “no puedes hacerte extremadamente rico sin vender tu alma” no resulta muy convincente
Al evaluar ingenieros de software, lo importante no es el conocimiento, sino la capacidad de resolver problemas y de construir un modelo mental del problema
Si el candidato nunca vio ese problema antes y el entrevistador entiende qué debe observar, una entrevista de pizarra es una buena forma de evaluar esa capacidad. Pero, como en la ley de Goodhart, cuando una métrica se convierte en el objetivo deja de ser una buena métrica. Personas con poca capacidad de resolución de problemas o de modelado también quieren puestos de software bien pagados, así que se machacan con LeetCode; con el tiempo, cuando esas personas se convierten en entrevistadores, conducen las entrevistas como pruebas de memoria, tal como se las hicieron a ellas. Aun así, dadas las restricciones que tienen las empresas, la necesidad de reducir la pérdida de tiempo de los candidatos y de mantener las rúbricas de evaluación consistentes que le gustan a RR. HH., todavía no he visto que se proponga una mejor forma de entrevistar, y se seguirá usando por un tiempo
Se parece más al trabajo de construir software. LeetCode está demasiado lejos del trabajo real, y el desempeño tiene una correlación demasiado débil con el encaje real
Es una cubeta con fugas, pero la empresa está satisfecha con el estado actual, y los desarrolladores siguen machacándose con LeetCode. No parece que vaya a cambiar pronto, pero por suerte estoy en una situación en la que puedo rechazar este tipo de entrevistas cuando busco un nuevo trabajo
Un amigo dejó de hablar de repente durante una entrevista técnica, se levantó y se fue. La gente de la empresa lo siguió diciendo “¿qué pasa?, ¡lo estás haciendo bien!”, pero él dijo que se había deprimido demasiado y que ya no le interesaba
Para la mayoría debería ser una profesión divertida, así que es triste
Pero hacia la mitad de la entrevista apareció la pizarra, entraron colegas y me pidieron implementar cosas básicas con un plumón. A medida que avanzaba, se volvieron cada vez más hostiles y groseros, hasta que se sintió como acoso ritualizado. Parecía que estaban probando si podía soportar insultos y hostilidad mientras producía resultados técnicamente triviales, así que al final detuve la entrevista y dije: “Ya vi cómo trabajan, así que decidí que no quiero trabajar aquí. Gracias por la oportunidad y lamento que nos hayamos hecho perder el tiempo”. Luego me fui. El CEO me siguió hasta el estacionamiento para preguntarme qué había pasado, y parecía realmente sorprendido de que un candidato pudiera tomar una decisión durante la entrevista. La gente olvida que una entrevista laboral es bidireccional. Desde ese día entendí que tengo derecho a examinar todos los aspectos de una empresa donde podría trabajar y que, si veo algo negativo en el proceso, no tengo por qué transigir. Al día siguiente conocí en una empresa competidora a personas que hasta hoy son buenos amigos y colegas, así que fue la decisión correcta. Este trabajo es divertido, pero si esa diversión se cosecha y se explota como en una granja, no es distinto de otras formas de esclavización
Dije: “Parece que hoy no es mi día y quisiera terminar la entrevista”, y a partir de ahí se esforzaron bastante por hacerme quedar durante el tiempo restante. Creo que si un candidato quiere irse, hay que dejarlo ir
Incluso cinco años después, sigo rechazando este tipo de entrevistas y no quiero volver a pasar por ese proceso. Fui acosado y ridiculizado por gente que trata a las personas como si fueran un juego de patearlas durante una hora, y ya no quiero lidiar con eso.
Como hubo muchas entrevistas de LeetCode sin previo aviso, dejé claro en mis perfiles de LinkedIn [1] y GitHub [2] qué está permitido y qué no. “Tengo una política personal contra toda forma de programación en vivo o pruebas de programación en línea durante las entrevistas, y no disfruto ni participo en programación competitiva. En cambio, con gusto hago tareas de programación offline con objetivos y plazos razonables, y conversaciones técnicas profundas sobre arquitectura y diseño de software y tecnologías relacionadas”.
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
Eso sí, me preocupa que, como se dice que las trampas están muy extendidas en las entrevistas con tareas para hacer, caiga drásticamente la cantidad de empleadores que quieran usarlas.
Haciendo de abogado del diablo, LeetCode se usa para filtrar una o ambas de dos cosas en la contratación de un colaborador individual promedio: si alguien es trabajador, es decir, si estudió muchos problemas, memorizó soluciones y las repite; o si es inteligente, es decir, si aun sin hacer LeetCode conoce los fundamentos y puede sintetizar conocimientos previos para responder preguntas nuevas.
Si no se tiene ninguna información, diría que alguien que no logra pasar un problema de LeetCode tiene más probabilidades de no ser ninguna de las dos cosas. Si el rol requiere programar, creo que debería poder resolver al menos un problema fácil a medio de LeetCode, aunque sea con un poco de guía del entrevistador. En la práctica, las empresas reducen el peso de la capacidad en LeetCode cuanto más senior es el puesto o más especializada es la función a la que se postula. También hay muchas entrevistas de corrección de bugs, diseño de sistemas, comportamiento, tareas, preguntas de cultura general y preguntas específicas del trasfondo; en contrataciones por encima de nivel inicial, LeetCode no lo es todo. No es una herramienta mágica para elegir a los mejores ingenieros, sino apenas otra señal que usa el comité de contratación.
No evalúa la capacidad de ingeniería de llevar algo hasta el final dentro de un presupuesto. En el mejor de los casos es algo periférico y, en el peor, un indicador sustituto de discriminación por edad que favorece a gente más cercana a los 19 años. Quizás por eso a esta industria le cuesta tanto producir software de buena calidad. Una mejor forma sería dar una situación fallida, como una build rota o código que crashea, y pedir que la arreglen. Si alguien puede explorar el sistema, diagnosticar el defecto, encontrar la causa, proponer un parche y ajustarse al estilo de código y comentarios, esa es la persona que realmente se necesita. Podría haber ramas y un tracker de issues; la discusión del bug quizá ya esté en marcha; incluso podría haber un archivo de parche que haya que aplicar manualmente desde un comentario. El parche podría traer un bug nuevo, o ser una trampa que toca un problema parecido pero no relacionado. Podría ser una regresión de un bug cerrado sin pruebas unitarias, y aunque existan pruebas, el candidato podría tener que encontrarlas, o las pruebas mismas podrían estar obsoletas y llenas de bugs. Ese es el trabajo real. Al final, hay una gran diferencia de actitud entre decir “las pruebas unitarias estaban rotas” y decir “no entendí cómo ejecutarlas correctamente, así que seguí adelante”; el jugador de equipo es el segundo.
Por eso, a la inversa, podrías terminar con candidatos que no rinden de forma destacada en su rol actual, pero que invirtieron su energía sobrante en machacar LeetCode.
Con solo unas semanas en un proyecto, una persona inteligente puede obtener las ideas que realmente hacen falta. Los rompecabezas repentinos que plantea LeetCode se parecen más a los crucigramas de las revistas de antes.
La única razón por la que puede hacerlo es porque lo estudió antes.
Si fuera 2022, estaría de acuerdo en que LeetCode no es una herramienta para elegir a los mejores ingenieros, pero en 2024 te filtran mucho más incluso si aciertas el problema, porque no fuiste lo suficientemente rápido o no pudiste resolverlo sin pistas. No soy un genio de LeetCode y tengo demasiado que estudiar; aunque LeetCode representa alrededor del 20% de las entrevistas, no siento que haya empeorado tanto respecto de hace dos años. Lo que pasó es que las expectativas de las empresas se fueron por las nubes, y el ambiente es de querer comprar roles de más de 15 años de experiencia con sueldo de alguien de 5 años.
Un punto interesante que no se menciona mucho sobre las entrevistas estilo LeetCode es que son una especie de rito de iniciación intelectual.
Se ha demostrado varias veces que cuanto más duro es el rito de entrada, mayor es el compromiso de quienes logran entrar al grupo.
Cuando una empresa capitalista contrata programadores, ¿qué le conviene más: “personas inteligentes y parecidas que creen en la respuesta correcta” o “una mezcla aleatoria de personas capacitadas”? Si respondes lo segundo, eres idealista, y esa opinión en realidad no importa. La naturaleza la reemplazará por alguien más inteligente y realista.
En varias entrevistas recientes, les mostré a los candidatos un código de ejemplo y les pedí que lo revisaran. La muestra tenía al menos un bug o problema en cada línea.
Después venía una tarea de modelado, normalmente en pizarrón. También había un ejercicio simple tipo fizzbuzz para ver si un junior realmente podía desempeñarse en un rol junior, y lo usábamos como punto de partida para abrir conversaciones sobre temas como la complejidad en tiempo de ejecución o la distribución de memoria. Según el desempeño del candidato, lo hacíamos de forma muy interactiva; la idea era filtrar a los impostores que de algún modo habían pasado el screening y también percibir en cierta medida el encaje cultural.
Planteo problemas desordenados, como validación de zonas horarias o números telefónicos, y uso un artículo de Wikipedia como especificación. Al terminar, le pregunto por su solución y hacemos una revisión de código. Los mejores seniors simplemente usan una biblioteca. Los buenos candidatos lo implementan por su cuenta, pero pueden explicar los compromisos. Los juniors solo hacen que pasen las pruebas y se detienen ahí.
https://github.com/emilybache/GildedRose-Refactoring-Kata
Dejé que los candidatos lo hicieran en el lenguaje que prefirieran, y fue un filtro muy efectivo.
Una vez entrevisté a un candidato desarrollador que parecía saber mucha teoría, pero fracasó estrepitosamente cuando le pedimos escribir código. No pudo implementar fizzbuzz, y un desarrollador Java Senior no pudo importar HashMap sin buscarlo.
Es parecido a las matemáticas. Para 562 * 1041 lo correcto es usar una calculadora, pero si alguien saca la calculadora para saber cuánto es 3 * 7, uno empieza a dudar de si es experto. Muchas empresas exageran con las entrevistas tipo LeetCode, pero una entrevista de live coding que muestre manipulación de arrays, control de flujo y uso de estructuras de datos básicas revela si existe esa memoria muscular que solo viene de la experiencia. Si para aprobar hay que estudiar algoritmos de recorrido de grafos, probablemente ya es demasiado estilo LeetCode.
Pero en un programa se necesitan varios elementos triviales de ese tipo, y en esa visión del mundo habría que memorizarlos todos. Con 562 * 1041, se espera que sepas el principio del cálculo, es decir, cómo hacerlo. Puedes equivocarte en la cuenta, pero no deberías equivocarte en la idea de la multiplicación larga. En ese contexto, no pasa nada si olvidaste un elemento de las tablas de multiplicar como 3 * 7. Un programador es alguien que organiza el cálculo, no quien lo hace directamente; eso lo hace la computadora. Estoy de acuerdo en que, para un algoritmo de recorrido de grafos, basta con saber dónde encontrar la solución, no hace falta tener todas las soluciones en la mano.
¿En qué situación estas personas tenían que importar manualmente? ¿No tenían IDE?
No estoy seguro de si eso era una sátira de los estereotipos de los entrevistadores.