The HM answered, it was just not what the author wanted:
> That is part of the assessment itself, see what kind of extra features you can come up if any
It seems like the author wanted to hear something more like "ok, here’s a list of things we want you to implement, and here’s mock-ups for the UI, and here’s the API spec you can follow". How I’m reading the HM’s response is - I should spend a few minutes trying out the email clients they mentioned or watching videos on them, and come up with a list of their features. Apply my own judgement to say which ones are most important and roughly estimate the time it will take to implement a PoC for the assignment. At this point you could take that to the HM and say "hey, I think I can do X, Y, Z features within the timeframe. I’d like to have W, U, V, features in the client but I think they’re less important and I won’t have time. Since this is a backend position I will focus on the API and the client will be a thin wrapper around that. Does that sound good?". They will probably say yes and maybe throw in a "when you do X feature think about users that have 100k unread emails in their inbox", and you’ll get a gold star for "dealing with ambiguity". If I was the HM I would expect some amount of back and forth like this. Since the guidelines are so broad you can focus in on the areas you are most familiar with and keep the rest super simple. As far as we know the author sent the one email on March 18 including a lot of details about what dependencies they were going to use but no product or clarifying questions after that, which the HM might have happily answered. They also both went past the deadline set by the company AND their own self-imposed later deadline from their own proposal.
At the end of the day this is a startup and so it makes sense that what they’re looking for is someone who can work independently. They won’t have a PM to come up with the spec and list of requirements for you every time, and an architect who hands you the perfect software design, and they need you to be able to apply your own judgement and look ahead so that if you are designing their backend and 6 months down the line users ask for drafts support, you don’t come back with "sorry I didn’t account for drafts in my data model because no one told me, we can’t support that without redoing the whole thing".
It sounds like this actually worked fine as a filter for both the author and the company, just that the author realized too late in the process that this was not the work environment they were looking for. A phone screen or whatever else would've just been additional time spent for both the company and the author. I also don't think it's the company's fault that the author put in a "full work week" of hours, as far as we can tell that was never the expectation.
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
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.
IME that is certainly the norm in many European countries. Where I'm from the labels usually say the full price and then the tax rate next to it, e.g. "120 EUR incl. 20% VAT" meaning the actual product is 100 EUR and the 20% VAT is already included in the 120 EUR price
I just timed it, my personal Mac takes 10s to the login screen and then 4 seconds to the desktop after putting in my password. My work Mac takes 3+ min. All of the endpoint monitoring stuff they put on there really takes its toll.
My windows gaming PC starts up in about 30s from a cold boot (though it's not encrypted...), so I would at least put the personal Mac and the Windows machine in the same ballpark. I couldn't have told you which one is faster without timing it. The work machine laptop is clearly noticeably slower.
Adobe is the worst offender. I just checked and I have no less than 8 Adobe processes running on my macOS machine, without any Adobe apps running, and with all of the settings to run in the background or sync stuff turned off. I even have a script to nuke all of the services they install that I run every once in a while, but they just come back after a while. It's literally malware. If Photoshop and Lightroom weren't the best at what they do I'd be gone, but sadly they are.
I just checked mine and I have about 250k emails sitting in my personal laptop's mailbox, no issues there. It might be dependent on the provider - I know at work where we use Exchange I get occasional slowdowns but I'm not sure whether that's due to Mail.app, due to Exchange, due to our dear endpoint security software taking its sweet time checking whatever I'm doing, or any combination of these. I probably have a couple million emails in my work laptop's mailbox though. Often the "Rebuild Mailbox" function fixes any problems for me, at least for a while.
The iPhone one regularly just doesn't search properly for me though. I'll search for the exact subject or contents of a message and just won't be able to find it, then when I go to my laptop and type in the exact same terms it finds it instantly.
AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving account
Right, you can go to cloudtrail and probably get it, but I have definitely ran into things like service says you do not have access to resource or it does not exist - randomly providing the account some other tangentially related permission magically fixes it, I've found sometimes trying the UI and the API will give different errors to help, and neither is particularly more useful than the others.
Look in to the AWS IAM “service description files” aka SDF. Thats exposed via the console Policy Builder or Policy Evaluator logic. The SDF _should_ encode all the context (eg resource attributes, principal metadat) that goes in to the authz decision. The most common opaque issue youll see is where one action has other required resources/actions. Eg a single action attaching an ebs volume requires permission on both instance and volume and _maybe_ kms key with permissions across those services.
Except that the article said that the HOA needed to change the rules before that forced the couple to change what they were doing. The only thing that was called out as being against the rules was them keeping chickens in their backyard
That figure is in the above link as well: $1,705. So, yes, only one and half times more than the median bachelor degree holder. What is sadly absent from the report is the median weekly income of those who own a Ferrari. I expect that gap is even smaller.
Maybe people need to add deliberate traps on their websites. You could imagine a provider like Cloudflare injecting a randomly generated code phrase into thousands of sites and making sure to attribute it under a strict license, that is invisible so that no human sees it, and changes every few days. Presumably LLMs would learn this phrase and later be able to repeat it - getting a sufficiently high hit rate should be proof that they used illegitimately obtained data. Kinda like back in the old days when map makers included fake towns, rivers and so on in their maps so that if others copied it they could tell
> That is part of the assessment itself, see what kind of extra features you can come up if any
It seems like the author wanted to hear something more like "ok, here’s a list of things we want you to implement, and here’s mock-ups for the UI, and here’s the API spec you can follow". How I’m reading the HM’s response is - I should spend a few minutes trying out the email clients they mentioned or watching videos on them, and come up with a list of their features. Apply my own judgement to say which ones are most important and roughly estimate the time it will take to implement a PoC for the assignment. At this point you could take that to the HM and say "hey, I think I can do X, Y, Z features within the timeframe. I’d like to have W, U, V, features in the client but I think they’re less important and I won’t have time. Since this is a backend position I will focus on the API and the client will be a thin wrapper around that. Does that sound good?". They will probably say yes and maybe throw in a "when you do X feature think about users that have 100k unread emails in their inbox", and you’ll get a gold star for "dealing with ambiguity". If I was the HM I would expect some amount of back and forth like this. Since the guidelines are so broad you can focus in on the areas you are most familiar with and keep the rest super simple. As far as we know the author sent the one email on March 18 including a lot of details about what dependencies they were going to use but no product or clarifying questions after that, which the HM might have happily answered. They also both went past the deadline set by the company AND their own self-imposed later deadline from their own proposal.
At the end of the day this is a startup and so it makes sense that what they’re looking for is someone who can work independently. They won’t have a PM to come up with the spec and list of requirements for you every time, and an architect who hands you the perfect software design, and they need you to be able to apply your own judgement and look ahead so that if you are designing their backend and 6 months down the line users ask for drafts support, you don’t come back with "sorry I didn’t account for drafts in my data model because no one told me, we can’t support that without redoing the whole thing".
It sounds like this actually worked fine as a filter for both the author and the company, just that the author realized too late in the process that this was not the work environment they were looking for. A phone screen or whatever else would've just been additional time spent for both the company and the author. I also don't think it's the company's fault that the author put in a "full work week" of hours, as far as we can tell that was never the expectation.