I've worked at large companies and I've worked at small ones (disclaimer: including Kagi, long ago). When I was at Google I wrote design docs for basically everything. The company I'm at has fewer than ten people. I rarely write design docs. This isn't because the workplace is any less healthy, but because there are fundamentally fewer people I need to communicate my changes to, and they have more context of what I'm doing.

Process is healthy at large companies, because they move slowly and communicating your changes often becomes far more important than the actual code that needs to be written. Kagi is a small company. It does not make sense to cargo-cult practices from a company a hundred times larger.

I found myself thinking the same thing - perhaps came from a bigger/more established company. Reminded me of the PRD/ERD process. And that's not necessarily bad.

But from my experience, the two types look at each other like the other is insane. If you write up an ERD at a scrappy 6 person startup, everyone is going to think you waste time.

Conversely, if you join a larger team with established processes and begin flinging code at the wall unabated, people are going to think you're reckless and possibly inexperienced.

Depends on a place.

I've worked in places with very strong product management, where every single detail must be approved by a PM. I've also worked in places where engineer has a lot of autonomy - "John from FOO dept is spending too much time wrangling the daily data updates. Can you help him, here is his email? Our higher-ups allocated two weeks for that, but we can extend this if needed." - and from then on, you are in full control of the design and implementation, subject to your team's rules (because no one wants a system with bus factor of 1).

For me, I've found that the latter places are much nicer to work in. The interview question seem to focus on latter situation too.

I don't know about everyone else, but as a dev who is currently looking for a job I simply cannot afford to devote a week of unpaid work to each application. It's not sustainable to say the least. Especially when I'm told by some people that getting rejected means I didn't spend enough time on the solution.

You (and others) have misunderstood it completely. The deadline is one week, this doesn't necessarily mean you should work on it for one week.

It's game theory.

If the next guy puts in 10 hours, and you only put in 1 hour, assuming equal skill. Which project will be more polished?

If you are high skill and only work 1 hour on the project, but a newbie puts in 10 hours with ChatGPT's help, I'd be the newbie would have a pretty competitive project to the skilled 1 hour candidate.

You're not supposed to deliver a polished project, you're supposed to show what you can do and what you know. You can also document your process if you want, to let them know it only took you X hours to get to the solution you are presenting.

I had an interview once where they gave you 1.5 hours to code Tetris in ruby. I completed the core requirements and 1-2 extra requirements.

The person that got the offer coded 1-2 more extra features than I could in that time. What am I supposed to tell the interviewer?

"You're not supposed to get a polished project?"

If you're the interviewer, are you going to hire the guy that did just was asked or you are going to hire the guy that worked nights and weekends to get the perfect project delivered to you beyond what was asked?

If you're the interviewer you will invite both people to the next round of interviews.

If you have 2 equally qualified candidates, then who do you pick?

And yet the over engineered solution that somehow took a week to complete fell completely flat. I'd guarantee that Kagi has hired developers through this process who only spent a couple hours on it. If I was working on this, I wouldn't have gone beyond three hours. It would have actually been a console app and I would have done something like integrate your unread mail count in your terminal prompt as some "bonus" demonstrating additional thought in the space.

I've worked with IMAP and POP libraries before so am familiar with the fundamentals for building a client and libraries in many languages make this part of the integration very straightforward. Couple that with a "modern" CLI library this should come together very quickly. And I would not have included half a dozen cloud services for a terminal like email client. The project submitted completely missed the mark and they still have no idea why.

If I wanted to create something by meticulously planning out every detail and spoon feeding them to a code monkey with no creative input I'd just use an LLM or outsource to India where you've got to spell out every little detail and still get questionable results back. I've had to do that plenty of times and I don't want to work like that. I want to work with other professionals who can run with a concept and deliver good results without constant oversight and micromanagement. That's clearly not the author of the blog post.

> Coders don't spend hours independently coding

Exactly. The position they are hiring for is not that of a coder; coding is just one of the skills the position requires, maybe not even the most important.

> when you spend days building a feature only to find its not wanted.

lol, this makes me very old school but I suffered jobs where that was the outcome of months if not years of my work!

    > (I'm also a hiring manager at a 1k+ engineer company).

I'm not a hiring manager, and I have worked at five different companies with at least 10K engineers. All of them were "code first, review later". All five companies were very profitable and technology was a core component to their commercial success.

I can’t speak for your specific jobs, but my understanding is this is standard practice at FANGA: write an RFC or Eng Spec. Get it approved. Code it up.

When I worked at unprofitable, small startups, a lot of mental energy was lost due to miscommunications before the MR review process. Eg an engineer would be tasked to complete a project, but misunderstood a critical component and only after n-days of work was this identified and corrected.

> FANGA

Only ever heard it referred to as FAANG before