// Create a context variable that inherits from a parent, and sets the value "test".
// Create a context key for the theme.
ctx, err := getEmails(pb, e)
First line is very weird, unrelated to the task. Maybe copy-paste from a sample in a blog post? Anyway not paying attention to leave it in.
Wording in the second line is not consistent with third.
I’d stop my review there. Lack of attention to detail. Author does not demonstrate an ability to think clearly.
The problem in the story is not that the candidate was rejected but that the process is largely disrespectful by asking for a lot of unpaid time to implement some project without clear guidelines or giving valuable feedback.
The author wasted a significant amount of his own time, and the hiring manager’s time with all the questions, the proposal, etc.
Even after asking for all this clarity, he failed to do what was originally asked. If asking for all those details, you have to at least do the basics of what was asked.
He failed on multiple fronts here, and even wrote an entire blog post without realizing it. It seems like Kagi did the right thing by not hiring him, if we’re being brutally honest. If he would re-read the original ask with a fresh set of eyes, then look at his final product and all the communication, the feedback should go without saying. When someone misses the mark by that much, it’s takes a lot of effort to try and say it nicely to soften the blow, as a company would want to do. Multiply this by however many people applied, and there just aren’t enough hours in the day.
Now that he’s written this blog post, I wonder if he’ll have more trouble even getting past the first gate of hiring processes, as other companies won’t want to sign on to have a blog post trying to drag them through the mud over a rejection. That shows more questionable judgement.
> The author wasted a significant amount of his own time, and the hiring manager’s time with all the questions, the proposal, etc.
Maybe if the hiring manager didn't want their time wasted they shouldn't be using a stupid take-home prompt? Frankly everything I've seen here indicates that I would never work for Kagi and would actively encourage people to never work there.
Yes, I agree. You cannot implement arduous processes and then complain about how arduous they are.
A week long take home exam with no discussion after the fact is absolutely unbelievable. It's so disrespectful to the candidates time.
I don't care if the exam wasn't supposed to take a week, or if they get 1 million exams, or if their hiring manager only works 1 hour a day. If that's the case, then they shouldn't be doing this type of test. If you can't handle the heat, get out of the kitchen.
I don’t see where the hiring manager was unprofessional. He responded to the questions/proposal without giving the author an unfair advantage, and he responded to the message after getting rejection. The author wasn’t ghosted or ignored, and has closure, which is more than a lot of people get.
Had the hiring manager given detailed feedback, it would have ended up in the blog post, and then they would need to revamp their process, as anyone reading would get additional information they weren’t intended to have.
I’ve also seen situations like this where the person never stops responding and seems to try and turn a rejection into a long term mentorship opportunity. The author seems like they might have those tendencies and keeping to standard boilerplate responses helps avoid that. It’s not overly personal, but I don’t think I’d call it unprofessional. The author simply misunderstood the assignment at a foundational level and is trying to shift the blame for that onto the hiring manager… when that was exactly what they were testing for.
I deployed the app to my own domain and the functionality was without flaws. It took me forever. Included extra features typical of a backend role such as authentication and Infrastructure as Code. My efforts led to an empty rejection email.
And you are telling me that I should have spent extra time on my code comments?
Agree that mark phase is the expensive bit.
Disagree that it’s not worth reducing short-lived allocations. I spend a lot of time analyzing Go program performance, and reducing bytes allocated per second is always beneficial.
+1. In particular []byte slice allocations are often a significant driver of GC pace while also being relatively easy to optimize (e.g. via sync.Pool reuse).
Your message applies to one particular Go compiler from Google.
But since you mention gcc and llvm, it is also possible to use them to compile Go. Each implementation has different trade-offs in quality of generated code, runtime and language features.
Okay, I heard this argument enough times to know it's unreasonable but feel free to prove me wrong :)
We have this go-attention library which seems like a perfect candidate for an alternate compiler. How do I get Go compiled to reasonably good, autovectorized result here?
I know that both GCC and LLVM back-ends exist. Now, why do you think neither is used anywhere? (well, the LLVM one seems very new so it will need time regardless)
Also, it is not gogcc, it is gccgo. You may try to handwave away this but the above is legitimate criticism of very real Go weaknesses as observed on the example of this library
you're not wrong, but i don't think that you're presenting the argument in a way that is going to be well received.
hopefully both gccgo and any llvm backed implementations eventually mature to production grade. I think the thing that'll hold them back is that the toolchain is (by definition) completely different. 'go build .' is pretty nice.
the biggest value they bring is that unclear parts of the specification=be brought to light and clarified.
