Hacker News Reader

Comment by MeetingsBrowser | Hacker News Reader

In other words, the author did a good job but failed because there was an implicit requirement to not try very hard.

> Part of the assignment is using judgment and working in ambiguity.

If trying to clarify requirements is not what they wanted here, they may as well ask candidates to pick a number between 1 and 10 and reject anyone who guesses wrong.

> overkill on the infra and polish

I know its an opinion, but hard disagree on both. Take home tests are intended to show off your ability. Without specific guidance, how can anyone guess how much showing off is expected?

Polish is only bad if it stops you from delivering. Rejecting something that was delivered for being "too polished" feels like you are saying someone did too good of a job.

---

In my opinion tests with vague requirements like this are more likely to be a different way of rejecting people who are not a "culture fit".

View on HN

The author did a bunch of things that were irrelevant to the product (deploying to Fargate using Pulumi) while not delivering on the basic features that they were asked for ("terminal inspired email client"). If you watch the video it’s a super basic web app that has nothing to do with the TUI apps Kagi named you should use as inspiration. There’s no drafts. No CC or BCC field. No folders or labels (including sent or trash!). No replies. No threads. No shortcuts. There’s not even an indication of whether an email has been read or not. In terms of features it is very very very barebones, and I’m sure if you asked a few users all or most of these would be table stakes. Yes we can agree that "terminal inspired" is very open to interpretation, but spend a few minutes using the apps they gave as reference and you should be able to come up with a long list of features besides "send & receive email", which is the main thing they demonstrated. I get this is a short challenge, so pick a handful of things that are quick to implement and focus on those (like unread markers). You can even say this is a backend position so the UI shouldn’t matter, so then just implement them in the backend and make the simplest UI for it you can! They certainly "delivered" a product but I would not call it polished, and I would not confidently say this was a "culture fit" rejection - I see plenty of other reasons

> but I would not call it polished

The hiring manager above thought it was too polished, but you think it is not polished enough.

> There’s no drafts. No CC or BCC field. No folders or labels (including sent or trash!). No replies. No threads. No shortcuts. There’s not even an indication of whether an email has been read or not. In terms of features it is very very very barebones

None of these were asked for. Your guess as to what the true requirements are completely different from the authors, and others in this comment section.

Everyone seems to have different opinions on why the author failed. No one should have their time wasted on a take home test destined to be rejected because they guessed wrong.

And in this case, the author explicitly asked if they were on the right track before spending time on the test. Kagi had the opportunity to reject early or nudge the author back in the expected direction. Instead they wasted everyone's time.

I don't see how this can be interpreted in a positive way.

The candidate here focused on the wrong things, causing it to be overly focused in some areas while ignoring the main task which revolved around creating an interface inspired by a specifically listed set of terminal mail applications. So, yes it was both polished and unpolished simultaneously.

I think it's pretty obvious to figure out how much polish is "too much". This is a business. Engineers time is limited. Was the time you spent on that more valuable than the alternative? I'm leaving the question of what the alternative was ambiguous on purpose.

> Was the time you spent on that more valuable than the alternative?

In this case the alternative was applying to better companies, so I guess in a way the author really did fail the test.

What they were looking at was not the code, but the attitude. They likely don't want an engineer with a propensity to do too much, unless it's a 100x coder who can do "too much" with a lightning speed. Usually they want he candidate to show the ability to quickly do as much as needed, and not more, and, crucially, to understand how much is needed.

So yes, this is a culture fit test as much (if not more) as a design and coding test. Some people who are great at design and coding would fail it, and it's how this filter is intended to work.

Sorry for the humorous reply (I know this isn't Reddit), but this part gave me a good laugh:

    > unless it's a 100x coder who can do "too much" with a lightning speed

I see you there. Raising the bar from 10x to 100x!?

Yes, I needed a ridiculous number, a picture of the coding faculty so strong that writing twice as much code as the task really needs is hardly even noticeable.

Reply on news.ycombinator.com