La experiencia de un desarrollador rechazado en una entrevista con tarea para Kagi Search
(bloggeroo.dev)- En el proceso de contratación de backend de Kagi Search, un desarrollador implementó un cliente de correo con estilo de terminal durante aproximadamente una semana a tiempo completo, pero fue rechazado después de entregarlo sin una entrevista de seguimiento
- La tarea estaba abierta en cuanto a implementación, permitiendo elegir entre TUI o app web, consulta y envío básico de correos, backend falso o IMAP/POP/JMAP, por lo que el postulante tenía que decidir por su cuenta el alcance de la implementación y los criterios de evaluación
- El postulante envió por adelantado un plan detallado que incluía una app web en Go, AWS ECS Fargate, SSL, Postmark, login, Pulumi, Pocketbase, TEMPL y más, pero Kagi no le informó criterios concretos para aprobar
- Tras el rechazo, al pedir retroalimentación solo recibió la respuesta de que hubo “entregas más simples y más sólidas”, además de que en esta etapa normalmente no proporcionan feedback individual
- Esta experiencia muestra que las entrevistas con tareas no pagadas y los acertijos de programación con límite de tiempo pueden terminar evaluando más el tiempo disponible y las condiciones de vida del postulante que su capacidad real de ingeniería
Postulación y recepción de la tarea
- El postulante envió su CV para un rol de backend en Kagi Search, y el resumen del puesto incluía las siguientes capacidades
- Experiencia construyendo sistemas backend
- Dominio de Go
- Comprensión de escalado y mantenimiento de sistemas backend
- Capacidad de colaborar con SRE y otros miembros del equipo
- Comprensión de tecnologías de contenerización como Docker
- Después recibió un correo de Kagi pidiéndole completar la Kagi Developer Assessment como siguiente etapa
- La URL de la tarea fue enviada por HackMD
- El mensaje indicaba que, una vez terminada, si se ponía en contacto la revisarían y, si pasaba, discutirían su enfoque y solución en una entrevista posterior
Requisitos de la tarea y criterios de evaluación abiertos
- El objetivo de la tarea era crear un “cliente de correo mínimo con estilo de terminal”
- Las condiciones de implementación estaban relativamente abiertas
- El cliente de correo podía implementarse como TUI de terminal o como app web
- Se requerían funciones básicas de consulta y envío de correos
- Se podía usar un backend falso (DB, en memoria, etc.) o un backend real de IMAP/POP/JMAP
- No era necesario manejar mensajes con formato enriquecido; solo texto plano
- Se indicaba que se evaluaría no solo la capacidad de programar, sino también la habilidad para lidiar con ambigüedad y problemas abiertos necesaria en proyectos de I+D como los de Kagi Labs
- Las condiciones del entregable eran las siguientes
- Implementarlo de una manera que demostrara sus capacidades como desarrollador
- Subir el proyecto terminado a un repositorio de GitHub y desplegarlo en algún lugar para que pudiera probarse fácilmente
- Escribir en el README cómo configurarlo
Comunicación con reclutamiento
- El postulante consideró que los requisitos eran demasiado amplios y envió preguntas a la persona de reclutamiento
- La respuesta fue que había muchos candidatos, y que algunos implementaban solo lo básico mientras que otros agregaban funciones extra, documentación excelente, explicación de decisiones, demo desplegada e incluso planes futuros
- Cuando preguntó qué funciones adicionales serían bien valoradas, la respuesta fue que “eso en sí mismo es parte de la evaluación”, y que querían ver qué extras se le ocurrían al candidato
- El postulante decidió entonces redactar y enviar por adelantado un plan detallado de implementación para todo el entregable antes de empezar a programar
- Esperaba que, si la propuesta era bien recibida, eso lo acercara a una entrevista telefónica o incluso a una oferta
- Más adelante, al ver el resultado, concluyó que ese esfuerzo por alinear condiciones de antemano no tuvo mucho peso para reclutamiento
La implementación propuesta por el postulante
- El eje de la propuesta era un cliente de correo basado en una app web en Go
- Desplegado en AWS
- Usando ECS Fargate
- Con SSL/HTTPS
- Integrado con un proveedor de envío de correo
- Autenticación mediante pantalla de login
- Envío de correos mediante formularios
- Visualización de correos entrantes en la UI
- En la propuesta indicó como fecha de entrega el domingo 30 de marzo al final del día, es decir, dos días hábiles después del punto de las dos semanas desde el correo inicial
- Las elecciones técnicas fueron las siguientes
- Backend en Go: uso de Pocketbase y TEMPL
- Infraestructura como código: uso de Pulumi con el SDK de TypeScript
- Proveedor de correo: uso de Postmark
- UI: paginación de correos salientes y entrantes, pantalla de login y 2 cuentas de demo
- Los motivos de estas decisiones apuntaban a mostrar de forma amplia el rol y el alcance de la evaluación
- Aunque era un rol de backend, agregar frontend web podía mostrar amplitud en tecnologías web
- La base de datos era relevante para un rol backend
- El despliegue en AWS y la infraestructura como código se conectaban con discusiones sobre IaC, Docker, redes y resiliencia
- Un servicio de correo como Postmark mantenía la funcionalidad mientras reducía la complejidad de integrar IMAP/POP
- El postulante preguntó “qué tipo de reacción podía esperar de Kagi si lo completaba”, pero la respuesta se limitó a algo como “suena muy interesante y esperamos la entrega”
Entrega y rechazo
- El postulante afirmó que implementó todo lo que había propuesto, y que el trabajo completo le tomó una semana a tiempo completo
- Subió una demo de la aplicación web a YouTube y publicó el código en GitHub junto con la documentación
- Después de recibir un correo automático de rechazo, pidió feedback y Kagi respondió lo siguiente
- En esta etapa normalmente no proporcionan retroalimentación
- Hubo entregas más simples y más sólidas, por lo que decidieron continuar con esos candidatos
- Había mucho interés y muchas postulaciones para cada posición, por lo que el proceso era muy competitivo
- Le pidieron seguir revisando futuras vacantes y volver a postular
Dudas que quedaron después del rechazo
- El postulante considera que, si querían una “solución más simple”, podían haberlo dicho cuando envió la propuesta el 18 de marzo
- También cree que, si la solución no encajaba con el rol, eso igualmente podía haberse evaluado en esa etapa de propuesta del 18 de marzo
- Escribe que, al 13 de mayo, había pasado un mes y medio desde el rechazo y la vacante seguía publicada
- Reconoce que la empresa podría estar cubriendo varios roles con el mismo anuncio
- Aun así, concluye que no parecía una competencia del tipo “el puesto del ganador ya estaba ocupado”
- Señala además que en las instrucciones originales de la tarea el despliegue de la demo era algo deseable pero no obligatorio, pero que después de su entrega la guía cambió y pasó a exigir el despliegue como requisito estricto
Propuesta de un mejor método de selección
- El postulante critica las tareas no pagadas por ser una carga importante para quienes buscan empleo, especialmente para quienes están desempleados y ven disminuir sus ahorros
- También se muestra negativo frente a las entrevistas estilo LeetCode
- Cuenta que recientemente, en un rol basado en Clojure, le tocó resolver el problema de “coin change” y que en 50 minutos logró pasar aproximadamente la mitad de las pruebas, pero no le alcanzó el tiempo para implementar la parte de backtracking
- Como alternativa propone una revisión de código en vivo
- Considera que puede hacerse tanto de forma asíncrona como síncrona
- Permite conversar sobre problemas y temas de proyectos reales de software
- Puede revelar mejor el conocimiento de un ingeniero de software con experiencia
- No se opone por completo al live coding en sí, pero considera que la capacidad de resolver knapsack en 50 minutos está lejos del trabajo cotidiano de ingeniería
- Recomienda rechazar roles que exijan este tipo de trabajo no pagado, a menos que la situación sea desesperada
1 comentarios
Opiniones en Hacker News
Desde la perspectiva de quien contrata, no me gustan las pruebas tipo tarea por estas razones. Hacen perder tiempo a todos y pueden estar bien como última etapa justo antes de contratar, pero no son adecuadas como filtro
Aun así, la capacidad y la sinceridad se ven claras; solo estoy haciendo de abogado del diablo desde otra perspectiva
“Crear un cliente de email con estilo de terminal que pueda probarse en alfa con algunos clientes” es un pedido razonable para un ingeniero en una startup temprana, y los detalles inevitablemente quedan en manos del ingeniero
En particular, la pregunta “quisiera saber qué reacción podría esperar de Kagi si avanzo hasta completarlo” no fue buena. Cuando hay que revisar cientos o miles de entregas, no hay forma de dar una respuesta segura
Si intentar aclarar los requisitos es una conducta no deseada, no es muy distinto a pedir que elijan un número entre 1 y 10 y eliminar a quienes se equivoquen
Una prueba tipo tarea busca demostrar capacidad, pero si no hay orientación concreta, ¿cómo se supone que alguien acierte hasta qué punto debe demostrarla?
El exceso de acabado solo es malo cuando impide entregar; rechazar a alguien por “pulirlo demasiado” se siente como descartarlo por hacer el trabajo demasiado bien
Este tipo de prueba ambigua termina pareciéndose más a otra forma de filtrar personas bajo el argumento de que no encajan con la cultura
Los entornos de “primero construir y después revisar” fueron de los más tóxicos en mi carrera, y lo peor es dedicar días a crear una funcionalidad para luego enterarte de que nadie la quería
Por eso, describir una funcionalidad por escrito y obtener aprobación es casi un estándar de la industria para lanzar proyectos, y este postulante siguió prácticas de software que adoptaría una organización sana
Así lo veo también como gerente de contratación en una empresa con más de mil ingenieros
Por supuesto, solo deberían darse a postulantes para quienes el resultado pueda definir si pasan o no
En mi última búsqueda laboral recibí una tarea así de amplia y, aunque era un puesto para el que estaba sobrecalificado, me rechazaron porque no podía adivinar qué partes iban a evaluar
Es poco probable que en adelante consiga trabajo por una vía que no sea una recomendación, pero quedé con mucha resistencia tanto a recibir como a asignar este tipo de tareas
Esta tarea buscaba ver si podía hacer algunas preguntas, anotar supuestos y lanzarse con confianza a construir algo ambiguo
Probablemente, después de ese email el código ya no importaba mucho, y la empresa debió haber terminado el proceso en ese punto para que el postulante no perdiera tiempo implementando la tarea
Al ver el código y el video demo, mi primera impresión fue: “Le tomó una semana hacer una app web de dos páginas, y faltan incluso las funciones de email más básicas, como abrir un mensaje”
Al revisar los requisitos, esta persona se postuló para “Email Backend Engineer”, pero para el backend real de email usó productos de terceros como Postmark y Turso
Faltan elementos básicos como formato de email en texto plano, vista de mensajes, carpetas, al menos bandeja de entrada y enviados; en cambio, incluye funciones opcionales como pantalla de login, página de administración y un framework backend
En la base de datos del backend ni siquiera hay un mapa de headers de email
Puede ser un gran ingeniero, pero no parece encajar en este puesto específico, y yo también lo habría rechazado
Al ver el anuncio original, el título era “The project is to build a minimal, terminal-inspired email client”, y especificaba que se inspirara en herramientas de email de terminal existentes como aerc, mutt y himalaya
Esto parece un caso de no haber leído bien los requisitos, así que lo veo como no contratables
Parece que cumplió ambas cosas de manera suficiente
Inspirarse en herramientas existentes es algo subjetivo, y en una tarea para un puesto de backend quizá no pensó que dedicar tiempo a la interfaz de usuario fuera la mejor forma de demostrar sus habilidades
Entiendo que no siempre es realista si el reclutador revisa a cientos de personas para un puesto popular, pero justamente por eso las pruebas tipo tarea son malas
Un postulante puede desperdiciar horas de su vida sin obtener nada a cambio, así que ambas partes deberían respetar el tiempo de la otra
Entiendo que la respuesta haya sido muy breve y poco útil, pero los requisitos decían claramente que había que crear un cliente de correo inspirado en la terminal.
Al ver el video compartido https://www.youtube.com/watch?v=yY1sVXMkP_o, parece una app web de correo común, sin nada particularmente inspirado en una terminal.
Si querían una TUI real o una app web, es muy probable que incluso la app web tuviera que tener estilo de terminal.
En la sección “Inspiration” de los requisitos completos se especifica “inspirarse en herramientas de correo de terminal existentes como aerc, mutt, himalaya”.
Aun así, el prompt mencionaba explícitamente otros clientes de terminal como inspiración.
Además, el requisito de que fuera un cliente de terminal cambia mucho lo que se evalúa. La UI web para correo es un terreno conocido desde hace mucho, pero la experiencia de usuario de un cliente de terminal todavía no es un ámbito completamente “resuelto”.
Es muy probable que la rúbrica tuviera un peso importante en decisiones de diseño de clientes de terminal que la entrega del candidato no abordó en absoluto.
Las evaluaciones con tarea pueden tener valor dentro de un proceso de entrevista, pero necesariamente necesitan un límite de tiempo. Con 2 o 3 horas se puede obtener toda la información necesaria; más que eso se acerca a filtrar solo a juniors sin personas a cargo, hobbies ni responsabilidades.
Si la hubieran limitado a 3 horas, en el peor de los casos el candidato habría perdido solo 3 horas; y, en el caso más probable, habría presentado una propuesta o solución totalmente distinta, acorde a ese tiempo.
El candidato también debería confirmar si “quieren cualquier respuesta o quieren una buena respuesta”.
Algunas tareas solo miran si se pasa un conjunto de tests y no les importa el enfoque, mientras que otras prefieren mejor código aunque cumpla solo el 80% de los requisitos. He visto candidatos equivocarse al juzgar ambos casos.
Este tipo de tareas filtra a quienes pueden desperdiciar mucho tiempo en el proyecto y probablemente hace que la gente ocupada —es decir, la gente que uno querría— la deje pasar.
Cuando contrato por habilidades de ingeniería de datos, doy una tarea ETL simple: extraer datos de un archivo ZIP, transformarlos y cargarlos en cualquier base de datos.
Dejo algunas partes ambiguas y en el dataset incluyo elementos ocultos, como valores null inesperados o CSV mal formateados, para ver la capacidad de ejecución.
La limito a 4 horas, pero no había dado indicaciones sobre qué hacer si falta tiempo; es una buena sugerencia.
Luego, en una llamada, revisamos el código juntos y hago preguntas como “¿qué pasaría si el dataset no entra completo en memoria?”, para explorar mejoras, y ahí está la evaluación técnica real.
Como no hay garantía de que todos los candidatos hayan usado la misma cantidad de tiempo, se vuelve un problema de teoría de juegos, y el candidato casi siempre sale perjudicado de alguna forma.
En muchos casos, la respuesta correcta es dedicar más tiempo a crear una solución muy pulida, aunque no demasiado pulida, y luego fingir que se respetó el límite.
Incluso 3 horas es mucho tiempo para un candidato que ni siquiera sabe si podrá hablar con la siguiente persona.
En una entrevista de 1 hora se puede hacer un ejercicio de programación y garantizar que el candidato no desperdicie tiempo extra.
Si el candidato quiere, se le puede permitir enviar después una versión mejorada, y normalmente en ese punto ya se ha evaluado bien su capacidad, así que se le puede decir “hazlo si quieres, pero ya pasaste”.
Mantener igual la inversión de tiempo del candidato y del entrevistador hace que respete el tiempo del candidato igual que respeto el mío.
Si un responsable de contratación no respeta el tiempo de los candidatos, parece poco probable que respete el tiempo de sus empleados.
Últimamente entrevisté en varios lugares y mi experiencia fue muy parecida a esta. Presenté una solución excelente para la tarea, pero me rechazaron sin ninguna discusión sobre el resultado.
Como alguien que ha gestionado varias veces procesos con tareas desde el lado de contratación, creo que si le pides a alguien que haga una tarea en casa, necesariamente tienes que conversar sobre el código.
Si recibes una tarea de este tipo, recomiendo firmemente confirmar que habrá una conversación posterior sin importar el resultado de la evaluación; si no aceptan, no hagas la “tarea”.
Sinceramente, muchos equipos de contratación tienen un nivel bajo, así que implementar una buena solución puede incluso jugar en contra. Puedes quedar fuera por la frustrante razón de que el equipo de contratación no está a ese nivel.
Fui usuario temprano de Kagi, pero por esto estoy considerando cancelar mi cuenta. Si no tienen tiempo para hablar con el candidato, no deberían pedirle trabajo desde el principio.
Las tareas requieren bastante esfuerzo no solo del candidato, sino también de quienes las administran y del equipo de contratación; si revisaron el proyecto, es razonable esperar feedback o una respuesta cuando se solicita.
Pero también está la realidad: si hay 20 candidatos excelentes para un puesto, muchas personas capaces serán rechazadas. Eso no significa que fueran deficientes o que “fallaran”.
Si legalmente tienes que explicar por qué contrataste a A y no a B, es difícil decir “los dos eran excelentes, pero elegimos a uno”, y creo que eso suele terminar en buscar defectos que no existen.
He visto mucho ese enfoque en la cultura corporativa estadounidense, y Kagi tiene sede en Palo Alto.
Está bien no pasar una tarea, pero es difícil aceptar que desperdicien el tiempo de alguien sin devolverle nada.
Muchas empresas, incluidas startups populares, manejan esto bien.
El resultado no se parece mucho a un “cliente de correo mínimo con estilo de terminal”, y parece haber ignorado por completo las herramientas propuestas como inspiración.
Si malinterpretó los requisitos de forma tan marcada, yo tampoco habría dedicado tiempo a debatirlo.
Este es un caso típico de haber leído mal el contexto implícito. La empresa quería a alguien capaz de crear de forma independiente su propio trabajo y sus propios objetivos.
La ambigüedad de la tarea no era para interrogar por correo con múltiples emails, sino un lienzo en blanco para recibir una consigna bastante amplia, explorar por cuenta propia el espacio del problema y mostrar cómo se construye un resultado.
Es muy parecido a cuando trabajas en una universidad y ves a un estudiante que no entendió la tarea recibir una calificación inesperada y quejarse.
No es común encontrar a alguien que, en una situación de entrevista donde quiere impresionar, se atreva a actuar “con pereza”.
Si una empresa tiene un enfoque de lanzamientos experimentales rápidos y centrado en prototipos, algunas personas simplemente no encajan, y eso es malo para todos.
Probablemente algún candidato se tomó 10 minutos para pensar qué podía hacer en 60 minutos, lo montó como un pequeño backend en Go usando autenticación HTTP y un formulario, y lo envió con un correo breve. Es muy posible que una persona así se viera mucho mejor en el proceso.
No se puede saber si esto es un prototipo descartable, algo que verán usuarios reales, algo por lo que te van a criticar si la experiencia de usuario está incompleta, o si solo quieren ver “algo”.
Al final se convierte en un ejercicio de adivinar los gustos del revisor.
A la inversa, también habrá gente rechazada por no insistir en aclarar los requisitos, cuando eso es una virtud importante en un ingeniero.
La vida no es justa, pero uno espera más de los responsables de contratación, y por eso termina decepcionándose una y otra vez.
También puede ser que el estudiante no pudiera leer la mente y que malinterpretara la consigna porque estaba pésimamente redactada.
Un buen docente es alguien que logra que la mayor cantidad posible de estudiantes entienda; uno malo es lo contrario.
Con los mejores docentes, nunca hacía falta cuestionar la calificación porque los criterios de evaluación eran transparentes desde el principio.
Si muchos estudiantes están confundidos, el denominador común puede ser el docente.
Que un monje budista aprenda resolviendo acertijos crípticos llamados kōan no significa que haya que aplicar el mismo método a estudiantes universitarios que pagan matrícula.
Como parece que el autor lo publicó directamente, voy a explicar el contexto de la reacción que recibió. Trabajé antes en Kagi y pasé por una prueba take-home similar.
En ese momento la empresa era muy pequeña, Vlad revisaba personalmente a los candidatos y usaba este tipo de proyectos take-home. Ahora la empresa creció y quizá ya no los vea directamente, pero la esencia parece similar.
Si hablas con Vlad, es casi el arquetipo de comentarista de Hacker News, y la entrevista se siente más como una comprobación de ambiente para ver si “pareces una persona razonable”.
Para él, escribir un documento de diseño largo diciendo “voy a usar Galactor, hacerlo florp-ready y fleemearlo” es exactamente lo opuesto a verse cool.
Si la tarea es un “cliente de correo con estilo de terminal”, un proyecto casi perfecto sería algo que tenga atajos de teclado para todas las funciones y explique en un párrafo que no tarda más de 2 ms en dibujar un frame.
Es posible que el entrevistador haya pensado que el candidato tenía una mentalidad demasiado enterprise para trabajar en Kagi.
Por supuesto, si este método de selección es bueno o no es otro tema. Vlad quiere gente que piense como él, y este tipo de entrevistas tiene muchos problemas discutidos e investigados desde hace tiempo.
Dicho eso, si uno entiende eso y puede darse el lujo de pasar por ese proceso, la tarea sí tiene sentido. Kagi podría haber comunicado mejor este punto.
Es una lástima que hayas perdido tanto tiempo, pero espero que encuentres un lugar que encaje mejor con tu forma de trabajar.
Para aportar nuevas perspectivas a un problema se necesita diversidad de pensamiento. Si todos piensan de la misma forma, cuando una persona se atasca, es probable que todos se atasquen.
Parece un problema común en startups, y quizá sea una señal que explica por qué 9 de cada 10 startups fracasan.
Eso no es lo mismo que evaluar capacidad. Aquí hay que sacar una puntuación alta en métricas que no te informan para poder pasar.
No es muy distinto de poner una tarea diciendo “programa cualquier cosa, porque tienes que manejar bien la ambigüedad”, cuando en realidad quieres que adivinen lo que tienes en la cabeza.
Es una forma muy poco considerada de tratar a la gente, y tampoco da una buena señal sobre Vlad como persona.
¿Tengo que revisar las redes sociales de la gente de la empresa para descubrir eso?
Si al final dejé suficientemente claro que no soy cool y aun así me dijeron “sigue adelante” para satisfacer su curiosidad, espero que los traten del mismo modo en que tratan a los demás.
Gracias por la explicación y no hay mala intención. Pero ojalá hubiera visto antes un comentario así.
De ahora en adelante, sería bueno clasificar los trabajos con “take-home” como trabajos para chicos cool. Así los ingenieros aburridos pero con experiencia podemos presionar a las empresas para que cambien sus métodos si realmente quieren nuestro trabajo.
Si una empresa no cambia, se puede inferir qué tipo de empresa es la que “ofrece” ese puesto.
Revisé el código para ver cómo lo vería si fuera el revisor.
Me habría detenido aquí, en el primer archivo que abrí: https://github.com/Sleepful/mymail/blob/main/app/router/page...
El primer comentario es muy raro porque no tiene relación con la tarea y parece copiado de un ejemplo de blog. En cualquier caso, dejarlo así muestra falta de cuidado.
La redacción de la segunda línea no es coherente con la tercera.
Habría detenido la revisión ahí. Es falta de atención al detalle y no demuestra capacidad de pensar con claridad.
Y lo que recibí fue un correo de rechazo vacío.
En esa situación, me cuesta estar de acuerdo con que debería haber dedicado más tiempo a los comentarios del código.
Quiero decirlo como entrevistador de ingeniería: no me gusta ni LeetCode ni las pruebas con tarea. Ambas toman mucho tiempo y aportan poca información.
Aun así, en este caso es muy probable que hubiera rechazado al autor. Kagi Search es una startup, y en lugares así normalmente buscan optimistas pragmáticos que se muevan rápido y puedan equilibrar profundidad y amplitud.
Una vez tuve un colega que recopiló los inputs, se encerró varios días para crear una solución y, cuando salió, los requisitos ya habían cambiado. No fue una experiencia agradable para nadie.
Detesto de verdad los procesos con tarea.
La frase “este proyecto no solo prueba tu capacidad de programar, sino también tu habilidad para lidiar con la ambigüedad y problemas abiertos” en la práctica suena como que a) la tarea está tan mal diseñada que ni siquiera hicieron una rúbrica de evaluación, o b) el entorno de trabajo es tan caótico que no definen con claridad ninguna especificación ni requisito.
Además, las instrucciones “demuestra tus habilidades técnicas” y “entrega una solución práctica y funcional” se contradicen entre sí. Una buena solución simple no es vistosa.
Que alguien pueda hacer una solicitud HTTP y una pantalla básica de edición CRUD no dice casi nada. Las herramientas de IA también pueden generar eso rápidamente con una calidad bastante decente.
Lo que quiero ver es cómo implementa un ingeniero lógica de negocio incómoda.
Quiero ver si termina en un millón de
ifanidados y comentarios de “aquí hay dragones”, o si encuentra patrones adecuados y produce código legible y razonable.Eso es mucho más valioso en el trabajo real, da una señal más fuerte en entrevista, es más difícil que la IA acierte y toma menos tiempo.
Crear una buena solución simple también puede ser una forma de demostrar habilidad.
Creo que esa es una gran parte del rol de un ingeniero de software sénior.
Puede que este formato no sea la mejor manera de probar eso, pero “queremos ver si puedes manejar la ambigüedad” no significa que todo sea ambiguo.
Puede significar que todo debe pasar por un proceso que va de “requisitos ambiguos” a “especificaciones claras”.