La experiencia de ser rechazado en una entrevista con tarea para llevar de Kagi Search

• Se enfatiza la ineficiencia de las take-home assignments en las entrevistas para desarrolladores de software y el problema de la pérdida de tiempo de los candidatos
• Durante el proceso de postulación a Kagi Search, se experimentaron requisitos de tarea excesivamente amplios y ambiguos
• Ante un plan de ejecución concreto propuesto, se vivió la falta de retroalimentación clara por parte del manager y una comunicación ineficiente
• Tras entregar un proyecto desarrollado con gran dedicación, se sintió injusticia por el rechazo sin una razón clara y por cambios en los criterios
• Se comparten alternativas para un mejor proceso de contratación (por ejemplo, revisión de código en tiempo real) y una reflexión crítica sobre las exigencias excesivas en entrevistas con tareas

---

Introducción

• Una take-home assignment es un método de evaluación en entrevistas para desarrolladores de software en el que se le plantea un problema al candidato para que lo implemente en código y lo entregue
• Esta publicación busca señalar la falta de razonabilidad y el problema de desperdicio de tiempo para los candidatos a través de la tarea y la experiencia reales recibidas al postular a Kagi Search, una empresa que se consideraba de buena reputación

Postulación a Kagi Search

• Se envió el currículum para una vacante de desarrollador backend en Kagi Search
• Los requisitos del puesto eran los siguientes
  • Experiencia construyendo sistemas backend
  • Dominio del lenguaje Go
  • Experiencia escalando y manteniendo sistemas backend de gran tamaño
  • Capacidad de colaborar con miembros del equipo, como SRE
  • Comprensión de tecnologías de contenedores como Docker

Instrucciones y requisitos de la tarea de entrevista

• Tras pasar el filtro inicial, se recibió un correo con las instrucciones de la take-home assignment
• Tema de la tarea: "implementar un cliente de correo electrónico minimalista inspirado en la terminal"
  • Se podía elegir entre formato de terminal o aplicación web
  • Funciones básicas para ver y enviar correos
  • Libertad para elegir un backend de correo falso o real (IMAP/POP, etc.)
  • Solo era obligatorio procesar mensajes en plaintext; no hacía falta rich text
  • Entrega del proyecto: repositorio de GitHub, versión desplegada y documentación de instalación
• Había falta de una guía clara y el alcance del proyecto era considerable
• Aun así, debido a la reputación de la empresa, se decidió realizar la tarea

Comunicación con el manager

• Al consultar sobre el alcance claro de la tarea y las funciones adicionales, solo se recibió una respuesta ambigua: “queda a elección del candidato qué más agregar”
• Antes de invertir tiempo y esfuerzo en la tarea, se compartió un plan de ejecución concreto (Proposal) y se pidió respuesta al respecto, pero se avanzó sin recibir retroalimentación especial

Propuesta y planificación de la tarea

• Plan de ejecución:
  • Aplicación web basada en Go
  • Despliegue mediante AWS ECS Fargate y aplicación de SSL
  • Integración con el servicio de envío de correo Postmark
  • Funciones adicionales de inicio de sesión y autenticación
  • Envío, recepción y visualización de correos en la UI
• Justificación de la elección tecnológica:
  • Uso de varias tecnologías relacionadas con un rol backend
  • Construcción de un sistema real utilizando herramientas de Infra-as-Code
  • Implementación de funciones más cercanas a un servicio real, más allá de una simple integración de API
• Elementos principales implementados:
  • Pocketbase (backend/DB), TEMPL (plantillas), Pulumi (IaC), Postmark (servicio de correo)
  • Implementación de paginación, inicio de sesión, etc.
  • Stretch Goal: estabilidad, como respaldo y recuperación de datos
• Conclusión: se presentó con anticipación una explicación suficiente junto con sus fundamentos, y se esperaba una revisión clara y una respuesta al respecto

Respuesta del manager y problemas de comunicación

• Sin una revisión concreta, solo se recibió una respuesta breve: “propuesta interesante”
• No hubo retroalimentación sobre la pertinencia de la propuesta ni solicitudes de mejora
• Desde la perspectiva del candidato, esto se sintió como una falta de respeto hacia el tiempo y el esfuerzo invertidos

Ejecución del proyecto de la tarea

• Se implementó todo lo solicitado y lo propuesto, invirtiendo una semana completa de trabajo a tiempo completo
• También se entregaron un video demo del proyecto, el repositorio de GitHub y documentación detallada

Notificación de rechazo y retroalimentación recibida

• Tras recibir un correo automatizado de rechazo, al pedir retroalimentación se recibió la siguiente respuesta:
  • “Había entregas de candidatos más sólidas”, “la competencia de contratación es intensa”
• Problemas señalados
  1. Si se prefería una solución simple, eso pudo haberse indicado desde el principio
  2. Si la propuesta no era adecuada, se pudo haber dado retroalimentación en ese momento
  3. Incluso después del rechazo, la vacante seguía publicada, por lo que se interpretó no como mera competencia sino como una exigencia de consumo excesivo de tiempo
  4. Después de la entrega del proyecto, los requisitos se endurecieron aún más, por lo que la solución presentada terminó elevando el estándar

Conclusión y reflexión crítica

• Este tipo de práctica es injusta para muchos buscadores de empleo y puede incluso venir acompañada de amenazas reales a su sustento
• Se enfatiza la necesidad de rechazar o cuestionar las exigencias excesivas de tareas no remuneradas
• Existen mejores procesos de contratación, como la revisión de código en tiempo real, para reemplazar tareas tipo proyecto
  • La capacidad real de resolver problemas de desarrollo puede evaluarse mediante revisiones de código asincrónicas o sincrónicas
  • Se señala la brecha entre los problemas estilo Leetcode y las exigencias del trabajo real
• Se hace un llamado a mejorar la cultura de agotamiento de los candidatos y evaluación injusta

Propuestas para un mejor proceso de contratación

• Se presentan alternativas, como la revisión de código en tiempo real, para evaluar con más sentido las capacidades de los desarrolladores
• Se insiste en la necesidad de cambiar de un enfoque centrado en resolver acertijos algorítmicos con temporizador a uno enfocado en la capacidad real y la resolución de problemas

[GN⁺]

Opiniones de Hacker News

• Dejo mi opinión desde una perspectiva honesta de contratador. Personalmente no me gustan las tareas takehome. Este tipo de tareas terminan haciendo perder el tiempo a todos. Si fuera la etapa final del proceso lo entendería, pero usarlas para filtrar postulantes es ineficiente.
  1. Llegaron demasiadas preguntas. Resolver usando el criterio propio en medio de la ambigüedad era parte de la tarea. Con las condiciones dadas, habría bastado con invertir uno o dos días y hacer algo del nivel de un proyecto local sencillo.
  2. La redacción y el compartir la propuesta fue excesivo. Parece que el postulante quería demostrar minuciosidad, pero desde la empresa eso puede verse como algo ineficiente y como pérdida de tiempo.
  3. El resultado final era funcional, pero se invirtió demasiado esfuerzo en la infraestructura y en el acabado. Si al final te rechazan, eso termina siendo tiempo perdido.
  4. Creo que había un requisito de que fuera un cliente de correo inspirado en terminal, pero no pude encontrar esa dirección en el resultado.
     Reconozco la capacidad del postulante y su pasión por el trabajo. Solo quería aportar una opinión desde un ángulo un poco distinto.
  • La actitud del autor del blog me pareció un poco irritante. Solo por el texto da la impresión de que sería difícil trabajar con él, que le costaría tomar decisiones por su cuenta y que necesita lineamientos muy claros. Eso encaja en una gran empresa, pero no en una startup.
    "Desarrollar un cliente de correo inspirado en terminal y hacer una prueba alfa con clientes" es una petición razonable para un ingeniero de una startup en etapa temprana. Aunque haya más especificaciones, gran parte depende del criterio del ingeniero. El postulante parece querer demasiada certeza.
    Que tenga curiosidad de antemano por saber qué retroalimentación dará Kagi después de completar la tarea no es una buena señal. No es una situación en la que puedan dar una respuesta definitiva. Probablemente están evaluando cientos o miles de postulaciones.
  • El autor hizo un buen trabajo, pero implícitamente falló en la condición de "no esforzarse demasiado".
    Si no hacía falta aclarar requisitos, entonces habría sido mejor poner algo como "adivina un número entre 1 y 10" y rechazar a quienes eligieran mal.
    No estoy de acuerdo con rechazar a alguien por dedicarle esfuerzo a la tarea y entregar un buen acabado.
    Este tipo de tarea ambigua, en la práctica, no es más que otra forma de filtrar por "ajuste cultural".
  • Yo creo que el enfoque del postulante de validar sus ideas se parece bastante a cómo se trabaja hoy en ingeniería. Un equipo sano explica el documento de diseño funcional en inglés, obtiene aprobación y luego avanza.
    La cultura de "código primero, retroalimentación después" ha sido de las experiencias más dañinas para mi carrera. Este postulante siguió prácticas modernas de software. (Soy responsable de contratación en una empresa con más de 1000 ingenieros).
  • Como contratador, las tareas takehome que sí me gustan son las que se pueden completar en 30 minutos, tienen criterios de evaluación claros e incluyen espacio para distintos enfoques y análisis de trade-offs.
    A mí también me rechazaron en mi última búsqueda laboral por una tarea takehome amplia, sin saber qué parte era el criterio de evaluación. Desde esa experiencia desarrollé un rechazo muy fuerte hacia este tipo de tareas.
  • Creo que la razón del rechazo fue que la propuesta se volvió demasiado grande. Las instrucciones no pedían una propuesta, y entregar algo tan detallado incluso puede interpretarse como "falta de impulso autónomo". Si pasa eso, la calidad del código deja de importar.
    La empresa habría hecho mejor en no dejar que siguiera perdiendo tiempo y terminar la tarea en ese punto.
  • Es lamentable que hoy en la industria, por no saber definir requisitos, terminen filtrando desarrolladores por su capacidad de leer la mente.
  • También fue un problema que el postulante no cumpliera la fecha límite. Si hay retraso sin explicar una circunstancia especial, ya estás fuera. El objetivo de la tarea era diseñar una solución adecuada dentro del plazo.
  • Sobre el punto 4, lo de la terminal: en la versión completa que compartió el autor sí aparece esa explicación.
  • Este tipo de discusiones siempre es fácil hacerlas viendo el resultado. Incluso con la estrategia opuesta —no confirmar requisitos y solo cumplir lo mínimo— probablemente habría salido igual. En este tipo de situaciones siempre puede aparecer la opinión contraria diciendo que "hacía falta aclarar más activamente los requisitos".
• Al ver el código y luego el video demo, mi impresión fue: sí se tardó bastante en hacer una web app de dos páginas durante una semana.
  Ni siquiera tenía funciones de correo muy básicas (como abrir mensajes), y aunque era una postulación para un puesto de backend, en la práctica usó productos externos como postmark y turso, además de que faltaban funciones básicas (formato de texto plano, visualización, carpetas, etc.).
  Había funciones accesorias como panel de administración y login, pero faltaban incluso estructuras de datos mínimas como un mapa de headers del correo.
  Puede ser un buen ingeniero, pero lo considero inadecuado para ese puesto.
  La propuesta takehome también me pareció demasiado inusual.
  Volví a leer el anuncio original y decía claramente "cliente de correo minimalista inspirado en terminal", además de referencias como aerc, mutt y himalaya. Eso es una falla clara de interpretación de requisitos.
  • Sobre eso de "falla de interpretación de requisitos", me pregunto exactamente qué requisito no se cumplió.
    Se pedía un cliente de correo en terminal o web app, con funciones básicas, y creo que eso sí se cumplió.
    La parte de inspirarse en herramientas de terminal es subjetiva. Si era un puesto de backend, también podría considerarse ineficiente poner tanto énfasis en la UI.
  • Es triste invertir tiempo como postulante y recibir solo un correo de rechazo.
    Si al menos se pudiera obtener retroalimentación, serviría para crecer, pero muchas veces ni eso es realista.
    Por eso generan tantas dudas este tipo de tareas takehome. Tanto postulantes como contratadores necesitan respetar el tiempo del otro.
  • Existe la frase: "Email client can either be in the terminal (i.e. a TUI) or a web app".
• Evaluar con una tarea takehome puede ser útil, pero sí o sí debería tener límite de tiempo.
  Con 2 o 3 horas basta para evaluar a un postulante. Si hubiera habido límite de tiempo, el postulante también habría podido proponer una solución adecuada dentro de ese marco, y habría quedado más claro qué quería la empresa.
  Además, la empresa debería indicar con claridad si "cualquier respuesta está bien" o si "esperan la mejor respuesta posible".
  La intención de una tarea takehome puede variar: pasar una prueba, grado de cumplimiento de la misión, calidad del código, etc.; por eso el postulante puede confundirse.
  • Desde la perspectiva de contratación, creo que la tarea de Kagi es demasiado extensa y poco respetuosa con el tiempo del postulante.
    De hecho, corre el riesgo de filtrar justamente a la gente ocupada, la que no tiene tiempo de sobra.
    En nuestra empresa simplemente ponemos un problema ETL sencillo y damos un límite de 4 horas.
    Incluso orientamos para que no pase nada si no se completa todo, y en el follow-up hacemos revisión de código y tiempo para preguntas.
    La verdadera capacidad se puede detectar en esa reunión posterior.
  • Los postulantes pueden invertir mucho más tiempo del que realmente se les pidió, y me pregunto cómo puede saber eso quien contrata.
    A diferencia de una prueba en vivo, donde todos compiten bajo la misma unidad de tiempo, en una takehome se puede salir perjudicado por la distinta distribución de tiempo de cada persona.
    En ese caso, mejor una sesión de código en vivo de 1 hora. Si postulante e entrevistador invierten el mismo tiempo, ambos respetan mejor el valor del tiempo ajeno.
  • Creo que una revisión en vivo es mucho mejor que live coding. Si se va a hacer live coding, preferiría algo como trabajar 45 minutos en mi laptop por mi cuenta y luego volver para revisarlo.
• Es cierto que la respuesta de la empresa fue poco amable y nada útil, pero en los requisitos sí estaba claramente indicado lo de "inspirado en terminal".
  En el video demo solo se ve una web app bastante común. Se pedía explícitamente inspirarse en clientes de correo de terminal ya existentes como aerc, mutt y himalaya.
  Me pregunto si se me está escapando algo.
  • Habría sido mejor que el correo de rechazo explicara claramente la razón, pero desde el diseño mismo de la tarea ya se pedían de forma directa referencias a clientes de terminal.
    Como la UX propia de los clientes de terminal sigue siendo un área sin una "respuesta correcta", es posible que justo ese punto haya sido uno de los criterios de evaluación.
  • Viendo que el enfoque era Go, hacer un CLI toma menos de 20 líneas, así que me parece cuestionable la decisión de haberse concentrado en desarrollar una GUI web.
  • Está la indicación: "Email client can either be in the terminal (i.e. a TUI) or a web app".
• Hace poco tuve una experiencia similar en una entrevista. Entregué muy bien un proyecto de tarea, pero sin ninguna conversación sobre el proyecto me notificaron el rechazo de inmediato.
  Creo que si se pidió una tarea, debería haber obligatoriamente una reunión de seguimiento.
  Ya usaba Kagi de pago, pero después de esto estoy considerando cerrar mi cuenta.
  Si no tienen tiempo ni siquiera para hablar con el candidato, entonces no deberían pedir la tarea desde el principio.
  • Las tareas takehome exigen bastante esfuerzo no solo al postulante, sino también al entrevistador que las evalúa.
    Después de hacer incluso la revisión, creo que sí existe un derecho a recibir retroalimentación.
    Pero en la práctica, cuando eliges a una sola persona entre decenas de postulantes excelentes, ser rechazado no significa necesariamente "te faltó nivel".
    Incluso legalmente, una respuesta oficial a "¿por qué elegiste a A y rechazaste a B?" muchas veces termina reduciéndose a buscar defectos.
  • Habría sido mejor si la empresa hubiera publicado criterios claros de evaluación o hubiera dado feedback. Considero inaceptable perder tiempo sin retroalimentación tras fallar.
    Varias empresas manejan esto bastante bien.
  • Me pregunto si realmente era una "solución sobresaliente". Parece que ignoró por completo el requisito de un cliente de correo minimalista inspirado en terminal y las referencias relacionadas.
    Cuando el malentendido de requisitos es grande, la discusión misma puede llegar a omitirse.
• Este caso es un ejemplo típico de haber leído mal la intención oculta dentro del texto de la tarea.
  La empresa quería a alguien autónomo y capaz de fijarse sus propios objetivos.
  La ambigüedad estaba ahí para ver la capacidad del postulante de explorar respuestas desde varios ángulos y resolverla.
  • Esa tarea estaba pensada para alguien capaz de proponer una solución lo más simple, ingeniosa y funcional posible.
    Como no todas las personas encajan en una empresa orientada a prototipos, algún candidato probablemente pensó 10 minutos y luego construyó en 60 minutos el mejor resultado posible.
  • En un proyecto de I+D, si solo enfatizas la "minimización", queda ambiguo si buscas un prototipo, algo para usuarios, si hay que cuidar la UX, etc.; al final no deja de ser un juego de adivinar qué valora más quien evalúa.
  • En este tipo de tareas de "interpreta por tu cuenta", incluso puede quedar fuera quien no hizo preguntas adicionales para aclarar requisitos.
    Pero para un desarrollador, la capacidad de hacer esas preguntas es una virtud muy importante. Por eso es inevitable esperar más de este método de contratación y terminar decepcionado.
  • Yo creo que "misreading the subtext" en realidad estaba escrito en el propio enunciado.
  • En educación, culpar solo al estudiante por "no entender" es una conclusión demasiado cómoda.
    En realidad muchas veces el problema es una explicación ambigua.
    Un gran profesor logra que la mayor cantidad posible de gente entienda. Si hay muchos alumnos confundidos, el problema es del autor de la prueba.
    Los universitarios no deberían tener que resolver koans como si fueran monjes zen.
• Como el autor publicó esto directamente, quiero aportar contexto basándome en mi experiencia trabajando en Kagi.
  Antes Vlad evaluaba personalmente a los postulantes, y las tareas eran de este estilo.
  A medida que la empresa creció, parece que ahora otros hacen la evaluación.
  Vlad tiene una inclinación tipo HN y quiere trabajar con postulantes que le parezcan "cool".
  Por ejemplo, si escribes un documento de diseño largo diciendo "voy a usar Galactor y el proyecto está flop-ready", el efecto será totalmente el contrario.
  Cuando piden algo "inspirado en terminal", tienden a esperar detalles reales de apps de terminal, como atajos de teclado y cosas por el estilo.
  Se puede discutir si ese criterio es un buen filtro, pero si entiendes ese contexto y tienes la capacidad de pasar, la tarea probablemente te parecerá fácil.
  Ojalá Kagi comunicara mejor ese contexto. Es una pena el tiempo perdido, pero espero que encuentres una empresa más alineada con tu forma de ser.
  • Muchas empresas buscan gente que piense parecido a ellas mismas.
    Un equipo sin diversidad puede terminar estancado porque todos chocan con la misma pared.
    Creo que este fenómeno es especialmente común en startups, y tiene relación con por qué 9 de cada 10 fracasan.
  • Siento que el problema es que Vlad hace perder demasiado tiempo a demasiada gente en su búsqueda de personas "cool".
    Creo que una tarea que se califica sin criterios claros es injusta.
    Al final no es tan distinta de una tarea implícita de "adivina la respuesta que tengo en mi cabeza".
    Da la impresión de que falta consideración por las personas.
  • Me queda la duda de: "¿de verdad tenía que saber todo esto de antemano?"
    No sé si, en una cultura así, todo el mundo tenía que investigar de forma encubierta para enterarse.
    Incluso para postulantes "no cool" como yo, sería mejor recibir señales claras y poder pasar rápido a buscar otra empresa.
• Tras revisar directamente el código, desde el primer archivo noté comentarios que parecían copiar código de ejemplo sin un propósito claro, explicaciones inconsistentes y expresiones que transmiten falta de atención al detalle.
  Por este tipo de carencias en los detalles, dejaría de revisar ahí mismo.
  • Desplegué la app en mi dominio y no hubo problemas de rendimiento. También resolvía bien aspectos propios de backend como autenticación e infraestructura. Aun así, no estoy de acuerdo con la crítica de que debí prestar más atención a los comentarios del código.
  • El problema central en este caso no es el rechazo en sí, sino que un método de contratación sin guías claras y sin ofrecer siquiera retroalimentación fue completamente irrespetuoso con el tiempo del postulante.
• En DuckDuckGo tuve una experiencia parecida, pero recibí una compensación modesta en todas las etapas de postulación.
  Desde una propuesta de diseño sencilla hasta una tarea de implementación, todo se hacía con un límite de tiempo claro.
  Al final no quedé, y no me dijeron una razón específica.
  Parece que había demasiados postulantes, pero aun así fue una experiencia que me dejó una huella emocional fuerte durante mucho tiempo. Entiendo cómo se siente el OP.
• Hablo desde la perspectiva de entrevistador de ingeniería. Tanto leetcode como takehome consumen mucho tiempo y aportan poca información.
  Pero incluso si yo hubiera sido quien contrata, creo que también habría rechazado al autor.
  Las startups quieren gente que trabaje con rapidez y pragmatismo.
  En el pasado tuve colegas que pasaban días encerrados por su cuenta después de juntar opiniones de los demás, y para entonces los requisitos ya habían cambiado, lo cual no fue bueno para nadie.