2 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Al ejecutar repetidamente el agente de contratación ATS open source de HackerRank con la misma hoja de vida y el mismo comando, el puntaje osciló entre 66 y 99 puntos, y con un corte de 85 puntos el 65% de las ejecuciones quedó descartado
  • La herramienta parsea hojas de vida en PDF y llama 6 veces al LLM para estructurar datos básicos, experiencia, educación, habilidades, proyectos y premios; luego suma información de GitHub y evalúa con 100 puntos + 20 puntos de bonificación
  • Las habilidades técnicas fueron casi constantes, con 8/10 puntos en 98 de 100 ejecuciones, pero la evaluación de proyectos mostró gran variabilidad, alternando entre “falta complejidad arquitectónica” y “muestra despliegue real”
  • No solo quedó no determinismo con el modelo predeterminado gemma3:4b y temperature 0.1, sino también con temperature 0; incluso al cambiar a Gemini, con un corte de 60 puntos se produjo una tasa de rechazo del 28%
  • La sección de experiencia obtuvo 25/25 puntos incluso con una hoja de vida antigua que solo tenía una pasantía, por lo que la puntuación con LLM puede terminar siendo un filtro basado en la suerte más que una forma de distinguir la calidad de los candidatos

La misma hoja de vida recibe un puntaje distinto cada vez

  • hiring-agent, el ATS open source de HackerRank, se convirtió en objeto de prueba después de llamar la atención en LinkedIn y Reddit
  • En la primera ejecución obtuvo 90/100 puntos y, tras eliminar una instrucción de salida para depuración, al volver a ejecutarlo con la misma hoja de vida y el mismo comando obtuvo 74/100 puntos
  • Al desactivar DEVELOPMENT_MODE y repetir la ejecución 100 veces, el rango de puntajes se amplió de 66 a 99 puntos
  • Si el criterio de aprobación de una empresa fuera 85 puntos, la misma hoja de vida quedaría descartada con una probabilidad del 65%

Pipeline de evaluación y estructura de puntuación

  • La herramienta parsea una hoja de vida en PDF a texto y luego llama varias veces al LLM para estructurar la información del candidato
    • Datos básicos
    • Experiencia
    • Educación
    • Habilidades
    • Proyectos
    • Premios
  • Escanea el perfil de GitHub y los repositorios principales, agrega esa información como contexto adicional e introduce toda la información de una vez en la evaluación del LLM
  • El modelo predeterminado es gemma3:4b, ejecutado localmente, con temperature configurada en 0.1
  • El puntaje es sobre 100 puntos, con hasta 20 puntos de bonificación adicionales
    • Contribuciones open source: 35 puntos
    • Proyectos personales: 30 puntos
    • Experiencia laboral: 25 puntos
    • Habilidades técnicas: 10 puntos
    • Experiencia en startups, sitio de portafolio, blog técnico, etc.: hasta 20 puntos de bonificación

Secciones consistentes y secciones inestables

  • Las habilidades técnicas fueron casi consistentes: en 98 de 100 ejecuciones dieron 8/10 puntos
    • La presencia de tecnologías como React se parece más a una checklist, por lo que hay poco margen para el juicio subjetivo del LLM
  • En cambio, la sección de proyectos varió mucho según la ejecución
    • En algunas ejecuciones, los proyectos fueron evaluados como “falta complejidad arquitectónica”
    • En otras, fueron evaluados como “muestra despliegue real”
  • Temperature 0.1 es una configuración baja, pero el problema no desaparece al bajarla a 0
  • En un issue de GitHub abierto en octubre de 2025, incluso con temperature 0, seis ejecuciones consecutivas dieron puntajes distintos: 27, 34, 32, 34, 34, 30

La inestabilidad persiste incluso cambiando de modelo

  • Dado que gemma3:4b es un modelo local, también se verificó el impacto del modelo
  • Al usar Gemini, la distribución de puntajes se estrechó a 48~64 puntos
  • Pero si el corte es de 60 puntos, el candidato queda descartado con una probabilidad del 28%, independientemente del contenido de su hoja de vida
  • El puntaje de open source se volvió más consistente, pero el puntaje de proyectos siguió oscilando mucho

El problema opuesto del puntaje de experiencia: consistente, pero inútil

  • La sección de experiencia dio 25/25 puntos en todas las ejecuciones
  • Incluso en el caso de una hoja de vida antigua con una sola pasantía, recibió 25/25 puntos
  • La sección Production del prompt de evaluación tiene solo dos líneas
    • Analizar trabajo real, pasantías y experiencia en producción en las secciones work y volunteer
    • Considerar adicionalmente roles de fundador, cofundador o ingeniero inicial en una startup
  • No hay criterios, ejemplos ni puntos de referencia para separar 15 puntos de 25 puntos
  • Como resultado, una pasantía de un ingeniero junior, un principal engineer con 10 años de experiencia en sistemas distribuidos y la hoja de vida usada en la prueba pueden recibir todos 25/25 puntos

Riesgos prácticos en el screening de hojas de vida

  • Usar un LLM para parsear una hoja de vida en datos estructurados o verificar si menciona Python es un caso de uso relativamente adecuado
  • Pedirle que determine si la experiencia de un candidato vale 18 o 24 puntos produce un resultado más cercano a un vibe-check
  • La estructura en la que open source y proyectos combinados representan el 65% del peso también puede distorsionar las decisiones de contratación
    • Podría valorar más a un candidato con 2 pasantías y un proyecto open source que a un ingeniero con 30 años de experiencia que creó S3
    • Un ingeniero que haya realizado trabajo importante que no quedó en GitHub podría perder más de la mitad del puntaje
  • Los ingenieros con autoridad para introducir herramientas de IA en el screening de hojas de vida deben tener cuidado: una herramienta que no distingue calidad puede convertirse simplemente en un mecanismo para filtrar candidatos

Correcciones

  • En la línea 1 de la plantilla resume_evaluation_criteria.jinja aparece “Software Intern”
  • Esa frase no está documentada y no se referencia en ningún otro lugar del repositorio
  • La misma plantilla luego otorga bonificaciones a roles de fundador, cofundador o ingeniero inicial en una startup
  • Incluso al volver a ejecutarlo introduciendo explícitamente un prompt de Senior SWE, el resultado fue el mismo, y las dimensiones de puntuación funcionan independientemente del nivel del puesto

1 comentarios

 
GN⁺ 4 시간 전
Opiniones de Hacker News
  • Sorprende cuánta gente no sabe que un LLM funciona como un proceso puramente probabilístico, así que se agradecen textos profundos como este
    Estoy buscando trabajo y quizá esta sea la razón por la que hoy es tan difícil conseguir una respuesta. Da la impresión de que el CV simplemente se arroja a algún agujero negro de LLM, y nadie sabe realmente cómo funciona
    La explicación del texto sobre “temperature 0.1 — un valor bajo que supuestamente empuja al modelo hacia una salida determinista” no es precisa. temperature no es un interruptor de determinismo, sino un valor que afecta la distribución de muestreo; solo la hace más picuda, pero sigue siendo una distribución

    • En teoría, temperature 0 puede volver determinista a un LLM
      Dicho con más rigor, temperature 0 en sí no existe. Matemáticamente, a medida que la temperature se acerca a 0, la distribución se vuelve cada vez más picuda, la muestra más probable se acerca casi al infinito y el resto se acerca casi a 0
      En las implementaciones reales, temperature=0 no usa la misma fórmula que para valores distintos de 0, sino que elige la muestra más común en una rama separada con if para evitar dividir entre 0
      Aun así, por el procesamiento por lotes o por errores de punto flotante según la implementación, muchas veces la propia distribución de probabilidad cambia entre ejecuciones, y como resultado también cambia la muestra
    • Toda la comprensión de texto es, en esencia, un problema de razonamiento bajo incertidumbre. No siempre se puede tener certeza de a qué “witch” se refiere alguien, y sin importar qué proceso de contratación se use, la persona contratada puede terminar teniendo éxito o fracasando
      Dos personas pueden mirar el mismo CV y llegar a la misma conclusión, y dos pacientes con los mismos síntomas y la misma presentación clínica pueden tener enfermedades distintas
      No me convence mucho la explicación de que la vieja IA murió principalmente por el costo de mantener bases de conocimiento; más bien creo que el problema central fue la ausencia de un marco general de razonamiento capaz de manejar la incertidumbre
      Personalmente, siempre sentí como una broma recurrente eso de que Spock dijera cosas como “Capitán, la probabilidad de sobrevivir a esta misión es del 21%”. Desde una perspectiva bayesiana, también hay una distribución de probabilidad sobre la distribución de probabilidad, así que algo como “la probabilidad de sobrevivir a esta misión es β(5,1)” estaría más cerca de ser correcto
      En ese sentido, tampoco sería tan raro meter el CV 100 veces en esa máquina y mirar la distribución de probabilidad de los puntajes
      [1] Dicho eso, también soy el tipo de demente que se queda acostado en la cama ordenando imágenes en una tablet hasta que se le descompone el sistema visual
    • Para ser claros, temperature 0 sí es determinista, y para una entrada completamente idéntica produce la misma salida con cualquier elección de semilla
      Eso sí, si es MoE, las entradas duplicadas también tienen que ser idénticas dentro de todo el lote. Los vecinos dentro del batch pueden afectar la selección de expertos
      El kernel tiene que ser determinista, y en modelos de razonamiento no debe haber interruptores de nivel de esfuerzo a nivel sistema que respondan, por ejemplo, a la carga total del clúster
      En conclusión, en la infraestructura cloud tradicional probablemente ni temperature 0 sea determinista, pero en inferencia en el edge sí puede ser bastante estable y determinista
      Sobre decir que 0.1 es “más determinista”, me parece un resumen bastante razonable. ¿No termina muestreando mucho más seguido “la respuesta de temperature 0” con temperature 0.1 que con temperature 0.9?
    • Tengo varios colegas autoproclamados expertos en IA que repiten esto como si fuera evangelio
      He escuchado incontables veces eso de “si quieres resultados consistentes, pon la temperature en 0
    • Una distribución en la que toda la masa de probabilidad se concentra en un solo resultado es determinista, así que, en principio, poner la temperature en 0 debería producir una salida determinista
      Hay varias razones por las que eso podría no pasar, pero creo que, en el caso de ejecutar un modelo local como hizo el autor, esas razones no aplican del mismo modo
  • Si se combina la tendencia de la IA a “preferir” código hecho por IA con otros sesgos, es muy probable que este enfoque viole de varias maneras las leyes antidiscriminación de la UE y sea altamente ilegal
    Creo que, en general, puede permitirse descartar currículums al azar porque hay demasiados. Pero tendría que ser realmente aleatorio e independiente del contenido del currículum
    En la IA, la aleatoriedad no es independiente de la evaluación real del currículum, así que no aplica
    En general, no se puede garantizar que la IA no aplique sesgos sistemáticos, y de hecho hay muchas señales de que probablemente sí lo haga
    A las personas se les puede entrenar e instruir para que ignoren los sesgos. Claro, eso tampoco funciona de manera confiable, pero al menos crea una estructura en la que la responsabilidad por sesgos ilegales se delega al reclutador que desobedeció las instrucciones
    En cambio, cuando se usa IA, sin importar qué se le haya indicado, la responsabilidad recae en el usuario. Incluso puede “mostrarse o demostrarse” técnicamente que cierta IA está fuertemente sesgada en un contexto específico. Técnicamente también es posible con un empleado humano, pero en la práctica casi nunca es factible
    Al final, el riesgo legal se desplaza desde un nivel “individual y en gran medida negable” hacia el terreno de los sesgos sistemáticos demostrables. En otras palabras, si se sabe que usas IA en contratación, la gente puede atacarlo legalmente de forma sistemática

    • Todo se correlaciona con todo [1]
      Es decir, incluso solo desde el punto de vista matemático, es muy probable que esto se correlacione de alguna manera con raza, género y otros grupos protegidos en EE. UU.
      Por eso también podría volverse ilegal en EE. UU. con una buena demanda. Ni siquiera hace falta ganarla; basta con resistir lo suficiente en tribunales para que otras empresas tengan miedo de usar esto
      Yo no querría ser el demandado que tenga que demostrar que mi filtro de IA cumple por completo con todas las normas de contratación. Sería una pesadilla
      [1]: https://gwern.net/everything
    • No hay ningún problema con filtrar currículums de una manera totalmente aleatoria e independiente del contenido
      Tomar el cuarto currículum del montón y ofrecerle el trabajo a esa persona sería una forma tonta, pero completamente justa, de tomar una decisión de contratación
      Pero la IA es muy buena para detectar sesgos, así que no sorprendería que, al pedirle que filtre currículums, termine usando como criterio elementos que jamás deberían ser criterios absolutos, como el nombre del candidato
      Podría pasar que todos los currículums que dicen haber corregido un typo en un gran proyecto open source pasen, mientras que los currículums que solo mencionan proyectos propios sean rechazados con 60% de probabilidad. Entonces terminarías perdiendo a más buenos candidatos que malos
    • No estoy tan seguro de que sea tan fácil demostrar que esto viola los requisitos de no discriminación en el empleo, como los de la Council Directive 2000/78/EC
      Estoy de acuerdo en que, al funcionar como una máquina de apuestas irracional, puede producir efectos de discriminación indirecta no deseados. Pero probablemente no sea tan fácil demostrar que discrimina por “religión o creencias, discapacidad, edad u orientación sexual”. Es posible, pero los abogados tendrían que trabajar mucho para probarlo en tribunales
      La parte más interesante es la EU AI Act. Esta parte todavía no entra en vigor hasta el 2 de diciembre de 2027, pero los sistemas de IA usados en contratación o selección de personas naturales, especialmente los usados para colocar anuncios de reclutamiento dirigidos, analizar y filtrar solicitudes, o evaluar candidatos, son claramente sistemas de IA de alto riesgo
      Eso no significa que estén prohibidos, pero más adelante los LLM podrían quedar excluidos de los casos de uso de IA de alto riesgo. Esto se debe a que podrían entrar sin excepciones en el Article 6
      Como todavía no se han publicado los estándares, no tengo idea de cómo podría cumplirse la siguiente parte del Article 10 al usar LLM para este tipo de tareas
      “(f) examinar los posibles sesgos que puedan afectar la salud y seguridad de las personas, afectar negativamente sus derechos fundamentales, o derivar en discriminación prohibida por la legislación de la UE, especialmente cuando los datos de salida influyen en la entrada de operaciones futuras
      (g) adoptar medidas adecuadas para detectar, prevenir y mitigar los posibles sesgos identificados conforme a (f)”
      Por ahora, me parece técnicamente imposible con un LLM general, incluso si el proveedor del modelo cooperara por completo. Tal vez los modelos pequeños sí permitan una auditoría significativa
      La EU AI Act podría terminar excluyendo de los casos de uso de alto riesgo del Annex III todos esos enfoques de vibe coding de “usamos LLM, pero realmente no sabemos por qué”, y eso parece razonable
      https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
    • En general es ilegal bajo el Article 22 del GDPR
      “El interesado tendrá derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos sobre él o le afecte significativamente de modo similar”
      Es difícil que apliquen las excepciones del 22(2). Es complicado alegar que sea realmente necesario, y en contextos laborales el consentimiento casi nunca es válido. Podría ser posible si lo permite una ley específica de la UE o de un Estado miembro, pero eso requeriría una base jurídica aparte
  • A estas alturas, hasta podrían adoptar el chiste de “como no queremos contratar a alguien con mala suerte, cerramos los ojos y tiramos la mitad de los currículums”

    • En el pasado, una importante facultad de medicina del Reino Unido, Barts and The London School of Medicine and Dentistry, es decir, parte de Queen Mary University of London, llegó a introducir la selección aleatoria entre postulantes calificados
      Este método favorecía a estudiantes calificados de contextos menos acomodados, frente a quienes tenían tiempo y recursos para explotar los criterios cada vez más complejos de evaluación manual de currículums de aquella época
      Se organizó una campaña del tipo “¿van a elegir a futuros médicos por sorteo?”, y al final el sistema de lotería fue eliminado silenciosamente
    • La cantidad total de suerte en la vida de una persona es constante
      La mitad restante de los candidatos ya gastó parte de su suerte en este proceso de selección, así que en promedio tendrá menos suerte que la mitad descartada
    • Más importante aún, normalmente hay muchos más postulantes calificados que puestos disponibles
      Durante las últimas décadas, la formación y la educación se han expandido enormemente, así que los buscadores de empleo han seguido aumentando, pero la creación de puestos no ha ido al mismo ritmo
    • El filtrado de currículums con LLM puede ser un síntoma de un problema más grande
      Cuando decenas de candidatos se aglomeran por una sola vacante, el empleador puede filtrar currículums de manera desastrosa o tirar la mitad y aun así terminar eligiendo a alguien calificado
  • “Tengo un 65% de probabilidad de quedar fuera. Exactamente el mismo currículum, distinta suerte”: para alguien que ha operado pipelines de contratación para puestos técnicos en los últimos años, la verdad es que eso es un número excelente
    No me gusta decirlo de manera objetiva, pero es cierto
    ¿Un 35% de probabilidad de pasar personal técnico a la siguiente etapa sin esfuerzo? Incluso metiendo preguntas de filtrado específicas del dominio, he visto más de 100 postulantes por hora. Eso significa que salen 35 postulantes “filtrados” por hora
    ¿Se filtraron candidatos válidos? Sí. ¿Aun así terminas con un pool de candidatos 35 veces más grande de lo necesario? Por desgracia, también sí
    Hay tantísimos postulantes que, cuando la IA no interviene, la probabilidad de pasar a la siguiente etapa en realidad baja muchísimo más. Si no postulaste de inmediato, y además no postulaste usando un bot de IA, tienes a más de 50 personas delante y algún líder técnico agotado tendrá que llegar a tu currículum algún día
    Hay una razón por la que existe el bono por referidos

    • Entonces sí tengo un sistema de prefiltrado para vender
      Gracias a tecnología de punta, solo deja pasar al mejor 1%* de las postulaciones
      *según nuestras métricas propietarias, privadas y no deterministas, que podrían o no ser Math.random
    • ¿De verdad? ¿O más bien hay un 65% de probabilidad de que el currículum sea ignorado antes de que lo vea un solo ser humano, de modo que el pipeline de contratación también reduce en esa misma proporción la probabilidad de captar candidatos calificados?
      Un filtro que reduzca el flujo de currículums solo sirve si esa reducción se correlaciona con la calidad. Si no, solo alarga el proceso de contratación o termina obligándote a bajar innecesariamente tu estándar de contratación
    • La solución lógica es que el candidato cambie un poco su información de contacto y postule varias veces
      Algo como “John Schmidt”, “John J. Schmidt”, “John J. J. Schmidt”, “John Jacob J. Schmidt”, “J. J. Jingleheimer Schmidt”
    • Si no hay un requisito de precisión, entonces basta con pasar aleatoriamente al 35% de los postulantes a la siguiente etapa
      Si los primeros 50 que postularon son todos bots, ¿por qué estás leyendo currículums en orden de postulación?
  • Lo más preocupante es que, si otros sistemas funcionan como este ATS, parece que están evaluando con factores que descartan en masa a candidatos bastante decentes o buenos
    Por ejemplo, le asigna 65 puntos a una combinación de proyectos personales y contribuciones a open source. Eso puede estar bien si la tecnología es tu único interés y no tienes familia, personas dependientes, ni un segundo o tercer trabajo
    Pero si tienes хотя бы una de esas cosas, parece que tus probabilidades quedan enormemente en desventaja
    Me hace preguntarme cuántos de estos sistemas están diseñados para favorecer a personas con dinero que, aparte de ir a la universidad o tener un solo empleo en la industria que quieren, no tienen nada más de qué preocuparse y pueden obsesionarse con la tecnología casi al nivel de un interés especial

    • La sobrevaloración de proyectos personales y proyectos open source es preocupante y mala
      En mi caso, por ejemplo, casi no hago proyectos personales fuera del trabajo. Toda mi experiencia real programando ha sido lo que hice para empleadores en horario laboral
      Mis hobbies están en áreas cercanas a la tecnología, como impresión 3D, hardware/Arduino y fotografía, pero no soy de los que crean y suben un montón de proyectos a GitHub
      Tampoco haría jamás apps CRUD o SaaS falsas para enseñárselas a un posible empleador. Es una pérdida de tiempo
      Deliberadamente no construí nada de esa presencia online. Mi GitHub no tiene repositorios públicos y no escribo blog
      Esta tendencia también se ha extendido al lado de operaciones/administración de sistemas donde trabajo, y ahí es incluso peor. Obviamente no subí un montón de scripts específicos de mi entorno a mi GitHub, pero ¿por qué tendría que hacerlo? No significan nada para alguien que no trabaja en mi equipo en la empresa actual
  • La palabra determinismo tiene un efecto casi mágico de torcer cualquier texto online que toca
    En cuanto aparece esa palabra, casi puedes garantizar que la conversación se va a ir por el camino equivocado. Aun así, esta vez sí se trata del determinismo real de que la misma entrada dé la misma salida, no de otras cosas irrelevantes y fuera de tema
    El determinismo importa para la reproducibilidad, pero en este caso, ¿de verdad quieres que la salida sea reproducible? Volver determinista la salida de un LLM es relativamente trivial. Si usas batching, usa kernels invariantes al batch y pon la temperature en 0, o mejor no hagas eso porque el muestreo aleatorio existe por una razón; mejor aún, fija la seed. En algunos sistemas eso ya es posible
    Pero eso no hace que el resultado sea más útil. Solo oculta el hecho de que el agente en realidad no está seguro. Mira el rango de puntajes. Igual no estaría prediciendo nada, solo estaría dando siempre el mismo puntaje. ¿De verdad quieres eso?
    Lo que está pasando aquí es que se está dando muy poca información y se espera una respuesta con implicaciones demasiado amplias a partir de un solo currículum que es casi puro ruido
    Es un error básico de diseño, independientemente de si se usa o no un LLM. Todas las encuestas, exámenes, leyes y sistemas de votación son extremadamente sensibles al framing porque operan con muy poca información. La diferencia es que, a diferencia de esta cosa, no existen en el vacío

    • La no determinación no significa que no se pueda llegar de forma estable a la salida correcta. Claro, a veces sí puede significar eso
      Los algoritmos de Las Vegas son no deterministas, pero 100% correctos. La compensación es que el tiempo para llegar a la respuesta puede variar mucho
      El error aquí no es haber usado un sistema no determinista. En cierto sentido, el error podría ser haberlo usado demasiado poco. Revaluar el mismo currículum 5 veces y ver que la varianza de puntajes es alta es una señal más útil que evaluarlo una sola vez
    • Es bien sabido que jueces y examinadores humanos tampoco son tan deterministas como quisiéramos
      Todos han oído que en la hora antes del almuerzo salen sentencias más severas
    • La no determinación también puede ser una función, no un bug
      Si quieres evitar que la gente optimice para adaptarse al proceso de filtrado, necesitas cierto grado de no determinación
      Por ejemplo, en vez de cortar exactamente en el top 100, puedes hacer que la probabilidad de pasar el filtro aumente exponencialmente para candidatos mejores
      Entonces vale menos la pena atacar el proceso de filtrado al estilo de Goodhart. La probabilidad casi no aumenta y hay muchas mejores formas de gastar ese tiempo
  • Si el modelo base es gemma3:4b, entonces es un modelo muy pequeño
    Ningún LLM será un juez perfecto y repetible, pero conectar un modelo de 4B a un sistema así es casi como enchufarle un generador de números aleatorios
    Todo el experimento da la impresión de que alguien quería hacer un proyecto ATS de código abierto, armó un ATS con vibe coding y lo dejó apenas en el punto en que pasaban las pruebas

    • Incluso este tipo de modelo puede servir para problemas pequeños si se usa bien
      Probablemente haya formas de analizar currículums que sí funcionen bien con este modelo. Pero no con algo tipo “oye, montón de chatarra, ¿qué proyectos hizo esta persona?”
      Harían falta extracción, organización, quizá comparación vía OCR y limpieza adicional, varias rondas de análisis con LLM por señal, clasificadores, etc.
      Nada de eso tiene que usar necesariamente un modelo grande. Con uno grande quizá mejore un poco, pero como el contexto es muy limitado, si se usa correctamente incluso un modelo así puede funcionar bien
  • Probé el ATS yo mismo y tuve una experiencia rara parecida
    No pudo encontrar mi perfil de GitHub, así que me dio una puntuación en los 70, y luego tampoco pareció gustarle algunas bibliotecas de Ruby conocidas que hice
    Después de ejecutarlo varias veces empezó a reconocerlo de forma más o menos adecuada, pero siempre me descontaba puntos por la educación formal
    Esto da asco

    • Tuve una experiencia parecida. En una ejecución me dio como 65 puntos porque no le gustó que no hubiera contribuciones de código abierto
      Tampoco detectó certificaciones ni premios. Probé aplicar algunos PR con propuestas de mejora de la gente (https://github.com/Zem-0/hiring-agent) y sí ayudó, pero en general este ATS está muy sesgado hacia personas con grandes contribuciones de código abierto en GitHub
  • Siempre me ha sorprendido que las empresas tecnológicas paguen más de 300 mil dólares porque es difícil encontrar buenos ingenieros, pero al mismo tiempo los reclutadores trabajen sin apoyo y además cada quien tenga una idea totalmente distinta de lo que es un “buen candidato”
    El ATS manda más del 50% de los currículums a un agujero negro por heurísticas de filtrado basura, el equipo de contratación eligió ese ATS por cosas como la integración con Google Gmail, y nadie del equipo de ingeniería ni de datos revisó la tecnología de filtrado de ese ATS

  • Lo probé con mi currículum y somehow me dio puntos extra por GSoC
    BONUS POINTS: 5.0
    ------------------------------
    Google Summer of Code (GSoC) participation: +5
    Pero yo nunca participé en GSoC, ni tampoco dice eso en mi currículum