I failed a take-home assignment from Kagi Search

Original Article ↗ Hacker News Discussion ↗

Take‑home assignments: time, scope, and fairness

  • Many commenters dislike take‑homes, especially when unbounded in time and effort; they argue they mainly select for desperation and free time, not skill.
  • Strong view that assignments must be time‑boxed (2–4 hours) with clear expectations; otherwise candidates predictably over‑invest and get burned.
  • Several say unpaid multi‑day work is disrespectful and structurally abusive, especially when followed by a template rejection and no discussion.
  • Some argue take‑homes should be paid by law or company policy; that would force fewer, better‑designed assessments and real review.

Kagi’s specific process and communication

  • The brief explicitly says it tests ability to “deal with ambiguity and open‑endedness,” which some see as reasonable for a startup / R&D role.
  • Others say the ambiguity plus lack of responsiveness during a “week‑long unpaid endeavor” is unprofessional and indistinguishable from bad management.
  • Many criticize the hiring manager’s minimal replies and failure to either redirect the candidate’s proposal or early‑reject to avoid wasted effort.
  • Some defend the manager: at scale, they can’t coach each candidate, and reviewing a mid‑way spec would be unfair or outside the intended test.

Assessment of the candidate’s solution

  • A large group feels the candidate “missed the brief”:
    • The assignment was to build a minimal, terminal‑inspired email client, explicitly citing mutt/aerc‑style TUIs.
    • The submission was a generic web app with lots of cloud infra, outsourced email backend, and very thin email features.
    • Critics say this shows poor requirement reading, over‑engineering, and focusing on the wrong things (Fargate/Pulumi over core UX and email flows).
  • Others counter that the requirements are genuinely ambiguous (e.g., what exactly “terminal‑inspired” or “simple” entails), and that if the proposal was off, this should have been said before a week of work.

Ambiguity vs clarification style

  • Split views on the candidate’s many questions and detailed proposal:
    • Some see this as healthy, “real‑world” requirements engineering and a sign of seniority.
    • Others see it as need for hand‑holding and misreading a prompt that explicitly wants independent judgment under ambiguity.

Alternatives and broader context

  • Many propose alternatives: short, focused coding tasks with live discussion; code‑review interviews; or small paid projects.
  • Several note that with AI able to do boilerplate UI/CRUD, open‑ended take‑homes give even less reliable signal today.
  • Under current “buyers’ market” conditions, some recommend refusing such assignments; others say they simply can’t afford to.