4 ms·
IMHO, the author's approach of validating his ideas mirrors modern engineering workflows. Coders don't spend hours independently coding an MR and then getting f
by itake 1y ago
IMHO, the author's approach of validating his ideas mirrors modern engineering workflows. Coders don't spend hours independently coding an MR and then getting feedback from prod, tech leads, QA, and UX after the feature is "finished."
Work environments that "code first, review later" have been some of the most toxic in my career. It really sucks when you spend days building a feature only to find its not wanted. Which is why explaining the feature in English and getting approvals is the industry standard for shipping projects.
This candidate followed modern software practices that healthy workplaces follow.
(I'm also a hiring manager at a 1k+ engineer company).
- silisili 1y agoI 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.
- theamk 1y agoDepends 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.
- wyclif 1y agoI 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.
- carlosjobim 1y agoYou (and others) have misunderstood it completely. The deadline is one week, this doesn't necessarily mean you should work on it for one week.
- itake 1y agoIt'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.
- carlosjobim 1y agoYou'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.
- itake 1y agoI 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?
- carlosjobim 1y agoIf you're the interviewer you will invite both people to the next round of interviews.
- nine_k 1y ago> 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.
- throwaway2037 1y ago> (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.
- itake 1y agoI 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.
- porridgeraisin 1y ago> FANGA Only ever heard it referred to as FAANG before
- saagarjha 1y agoI'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.
- abraxas 1y ago> 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!