"Amusement Park" has to be one of the worst headline choices here. So these people are amused by building killing machines? They are amused that their work is directly related to death & destruction? They are monsters if so.
I hoped someone had hijacked that name for an actual "amusement park for engineers", coincidentally hitting all the right key words, but in terms of trademark protections occupying a completely unrelated commercial domain. Would be really, really funny if Anduril (not the amusement park) sales and marketing folks would have to append "not the amusement park", when speaking about Anduril (not the amusement park).
The first two points directly contradict each other, too. Learning a tool should have the outcome that one is productive with it. If getting to "productive" is non-trivial, then learning the tool is non-trivial.
> The perception of privacy is just as important as the technical details that make something actually private. I try very seldom to call for anyone to be fired, but I think whoever authorized this movie ad through Wallet push notifications ought to be canned.
Spot on. Look at it this way: would SJ have allowed this to happen? Absolutely not. And if it somehow had happened while he were still there, he would've unquestionably (and quickly) fired the responsible parties.
> The black hole universe also offers a new perspective on our place in the cosmos. In this framework, our entire observable universe lies inside the interior of a black hole formed in some larger “parent” universe.
Does it also follow that black holes in our universe contain universes internally, beyond their event horizons?! Seems like it should. Mind-blowing.
> One such example would be to do a live code review. This could be done asynchronously or synchronously. It could allow actually talking through topics and issues that relate to the challenges in a real software project. This would allow to surface much more of the knowledge in an experienced software engineer.
From my understanding of the post, this was the initial screening phase as it was in response to OP's application. In other words, this is what every candidate who passes the application screen (the weakest one) is sent.
Let's say they have 100 candidates for this role. A proper code review here should take ~45 minutes to an hour. Even 15% of the candidates requesting a full code review - regardless of synchronicity - represents a 11.25-to-15 hour time commitment from the hiring team. For the initial screen. That is asinine. No proper organization would accept such a large time sink for so few candidates at this phase.
As I've said already multiple times in this thread, OP very clearly does not understand the asynchronous relationship at play here, and then based much of their interactions & interpretations on this misunderstanding.
> A little intuition and empathy can tell you that they probably are not going to spend many hours reviewing a complex submission, so the project should optimize for demonstrability of code quality, not completeness.
> "I would like to know what kind of response I could expect..." - This is also established from the beginning: you can expect either a "Looks good, let's do some interviews" or a "Sorry, not interested," based on the code you submit. They can't narrow down the choices prior to your submission, because they're grading your submission, not your proposal document with an extensive list of details that they already told you they're mostly ambivalent to.
Absolutely spot on, and you ID it later with "Main character syndrome", but it is so very clear from this post's tone & content that OP expected a symmetric outlay of effort & focus from the company's side. They thought they were the main character.
That's a fundamental misunderstanding that seems to have predicated a lot of their ultimate response: they feel as if they were entitled to much more effort from the company than they received. Such is often the case with strong entitlement, it's nearly impossible for the person suffering it to see it.
Building a concrete, working, minimum-viable solution from ambiguous requirements: that's the point of the exercise. That's what hiring managers want in candidates because those candidates end up being good at building a concrete, working solutions from ambiguous requirements. Which is every software project ever. Although the AI Age has unquestionably changed the efficacy of this kind of candidate screening, that is orthogonal to this discussion. For many years it has been one of the most-effective ways to screen for the ability to build concrete, working solutions from ambiguous requirements. Which is every software project ever. So it's no surprise it persists.
Yes, software is full of ambiguities but there are methods we use to handle them. OP emailed an outline wanting feedback, as any team player would do to iron out ambiguities, and received a meaningless reply. I think it's safe to say companies don't want their engineers going into a corner never to be seen again for 2 weeks, which is what this interview process recreates.
OP's proposal was only describing irrelevant stuff (the backend technologies) and was completely silent on on stuff that mattered (demonstrating how actual RFC822 email works, mutt-inspired UI). It was therefore accepted without comments, as there were no "substance" to comment on.
That is often a problem with proposals/design docs in general. In the real job, if proposal is actually required, it would be sent it back with "please add details on UX and how you are going to store email headers". In this case, the proposal was explicitly _not_ required though, so interviewers did not want to ask for more details on the optional document. They checked what was written there, found no problems, and approved it.
I think what has happened is the author has no idea what "email backend" was, so he just decided to ignore that part and build the only backend he knew, web-app backend. And those terms are pretty different. The "email backend" is the service which actually stores and transfers email, in the author's case it was turso + postman.
So from the interviewer's standpoint, author was asking about few details of implementation, like "can I use third-party service for email storage?"; and the response was of course "yes, you can" (because assignment was pretty clear that backend does not need to be advanced or even present, and that it's UI that matters)
I guess the question worked as intended, and filtered out candidate who cannot even read the simple requirements.
(The amount of effort was disproportional though, but I am not sure how to solve this in take-home context without discriminating against people who have busy schedules and/or work slowly)
OP didn't take into account the (great) asymmetry between themselves and the hiring manager, then built an entire lament on that. Dealing with this job req is likely just one of many day-to-day responsibilities the HM has and frankly I'm impressed they responded with three whole sentences. One method we can use to handle such ambiguity is to "make your best judgement" based on your skills, knowledge and experience (things that are tested for in the hiring process, incidentally), because often you may not get the answer you want or expect if any at all.
They explicitly asked for a minimal, terminal-inspired email client for their Email Backend Engineer role. OP built a ton of infrastructure, created a generic web app that has no semblance of terminal inspiration as far as I can tell, and outsourced the backend to third party APIs.
Concrete and working? Technically, yes. This would have been an excellent submission for a different assignment and role. But it doesn't seem to suit the specifications for this one.
Not what was expected of them. I included "minimum-viable" in my original reply for a specific reason: to counter OP's lament that they lost out to a simpler solution.
If you are asked to implement X and instead you take extra time and come back with X+Y+Z, what have you done? Wasted time e.g. money. Companies really hate wasting money.
So if in your candidate project you demonstrate a propensity for bike-shedding any task, that's gonna be a big red flag.
