But do they consider it a CS risk or a business-wide risk? Is there any role at CoinBase that isn’t susceptible to insider risk? I would argue they would treat it as a security department / business risk issue and not a CS-only issue.
Onshoring CS and paying some more for that role may result in a net change of 0 risk (eg. The same possibility of a breach over the same time interval).
Would a lower class (for that region) Alabama man have less the susceptibility to insider risk as a middle class (for that region) Philippino man?
Most likely, the company will focus on better segmentation and better adherence to least permissions for all roles.
Also, your logic is clouded by the fact that you know it happened. In all aspects of security/cybersecurity, risk is incredibly difficult to calculate because you have to accurately know how much a counterfactual would cost in order to accurately choose one option over the other.
The global trend is racing to the bottom, so even if they could, every business consultant or MBA would push them to rather put more AI agents instead. Because that's all what matters (to them). Did anybody learn anything out of this? Of course not.
Not trying to be a jerk, but why is that interesting? Am I missing something more than all odd numbers end in 1, and primes by their nature cannot be even(except 2, as you mentioned).
I had 20 something files I wanted it to check and change something. The first 5 or so it did, then the sixth it rightly said everything is correct moving on. It said that for the rest of the 20, the same text over and over.
I checked, and file 6 was the only correct one. It like, learned to just repeat itself after that and did nothing.
I'm not sure how younger folks would feel seeing this...perhaps that it's ugly, less useful, sparse. And they'd be a bit right.
But for me this was a hit of pure nostalgia, flipping item to item. Almost like looking through an old photo album of memories you'd forgotten years back. Thanks Neal for putting it together.
Slightly fun fact - the original Space Jam site stayed intact until 2021!
I got the loop in both desktop Chrome and Firefox, as well as Android Chrome, Brave and Firefox (though these timed out after a few loops, unlike the desktop).
Oh man I forgot all about <frameset> and <frame> tags to create navigation. From the early days before we had dynamic sites or static site generators with templates, we had our browsers do our "templating" for us!
Nice! Never knew that. I wish more companies with popular sites did this. I'm sure it cost them about no money nor time to just shovel it off like this.
If your album is roughly chronological like mine... watching the kids grow up, yourself and your spouse get fatter and grayer....they -do- get more and more depressing :).
My honest feedback below from the perspective of a hirer. I'll start by saying I hate takehome stuff, for exactly reasons like this. It wastes everyone's time. They're fine as a 'last step before hire' thing, but not as a filter.
1 - Too much chatter. Part of the assignment is using judgment and working in ambiguity. I probably would have ran with what was given enough to knock out something small and local in an evening or two. Asking questions is usually fine, they even welcomed it, but seems counter to the original ask.
2 - Writing and sharing a proposal seemed like way overkill. You have to remember that these companies are now getting hundreds if not thousands if not tens of thousands of applicants, that is a lot to deal with if everyone does so. I think it's a bit of a disconnect...you feel like you're going above and beyond and being thorough, they feel like it's being a bit long winded and wasting time.
That probably explains the nonresponse.
3 - The finished product seemed functional, but seemed a bit overkill on the infra and polish. This is probably a good thing to work with you, but ended up wasting a lot of your time if not being selected, which was the case.
4 - Maybe I missed something, but the requirement asked for terminal inspired. I'm not quite sure precisely what they meant by that, but didn't see any possible interpretation of that in the result.
Anyways, hope you don't take it too negatively or personally - you obviously are a talented individual and moreso seem to really care about your work. Just wanted to play a little devil's advocate with a different perspective.
The attitude of the blog writer in their interactions also feels off. Just reading this blog post makes me think that this person is difficult to work with, requires extremely clear guidelines and instructions, and has a hard time making their own decisions. Maybe this is a good fit for a large, established company, but startups have their own needs.
"Create a terminal inspired email client so we can do an alpha test with some customers" is a reasonable ask for an engineer at an early stage startup. Of course, there would be a bit more specification, but a lot of the details would still be up to the engineer. This applicant wants more certainty than they can get.
This is illustrated by the line: "I would like to know what kind of response I could expect from Kagi if I drive it to completion." This is not a great request to make. There's no way they can answer that question, because there is no certainty available. They're probably getting a few hundred or a few thousand more submissions to evaluate.
In your comments history someone replied to a job posting "Just an FYI, if you do a takehome project for William, he won't respond to you (not even with an auto reject)."
Seriously? A candidate puts in a week of work and he can’t be guaranteed a 30 minute discussion?
Nobody is getting a few hundred or few thousand submissions to evaluate. Nobody. If you are getting 1k applicants, at best 50 are asked to do a take-home and even then, not all at once.
If by some miracle 100 people did this to completion at the same time, there should be a notice to the effect that due to high volume, blah blah blah.
…which is totally understandable… if the hiring manager had communicated that. They could’ve easily mailed back “Hi this proposal seems much more detailed than what we need for evaluation, please save yourself some time and energy.”
The author may have had issues (I personally don’t count “need clear instructions” as an issue - edit - I see they didn’t adhere to the TUI prompt), but the hiring manager definitely did.
> …which is totally understandable… if the hiring manager had communicated that.
I agree that the hiring manager could have handled it much better, but as a rule: If at any point during any hiring process you feel like you need to spend even close to a full time week of work on anything without being very explicitly told so, you are wrong.
I am a hiring manager and we do take home homeworks. I fully agree that this is a key piece of communication. I always take the time to tell candidates that although they have as much time as they want, we expect 2-3 hours of effort at most, to be respectful of their time.
Without that, take home problems would seem predatory.
Yes on this: It reminds me of when candidates ask me how they did at the end of the interview. It shows an extreme lack of decorum and empathy. What if you did terribly and I wouldn't hire you in a million years? Do you really want me to tell you that?
There's no good answer and asking a question like that shows real narcissism imo.
Conversely, if you can't handle some straightforward feedback to a candidate that took the time to interview you without violating decorum or hurting their feelings, then how can I expect you to be a good manager or supervisor? How are you possibly going to be able to handle minor personnel conflicts or provide guidance during the training period? It comes across as a complete lack of basic managerial skills.
Okay, but basic interpersonal skills are a prerequisite for anybody in a senior or team lead position, or any position that will involve code reviews.
I'm sympathetic to how awkward it can feel to provide honest feedback to a candidate, but look: we're all people here. I think we forget that sometimes when we're assembling hiring processes. As a candidate, you need some kind of feedback mechanism that allows you to improve even if you're not a good fit for a particular organization. And if you're involved in the hiring process in any way, you ought to be equipped to handle that.
> you need some kind of feedback mechanism that allows you to improve even if you're not a good fit for a particular organization
"Need". That is a strong term. I disagree. It would be nice, but it is not a need.
This topic has been discussed ad nauseam on HN. In most companies, there is specific company policy that prohibits providing feedback to candidates. There is literally no upside for these companies to provide feedback to candidates that they reject (except Fake/Feel-Good Internet Points, only redeemable on HN forums). Really: There is no way around it, no matter how many tears are spilled about it on HN.
This is simply a defense of bad policy couched in unnecessarily dehumanizing language.
There is widespread resentment of this and many other common hiring practices in the tech sector, and that is further impacting both the quality of candidates as well as employee motivation and satisfaction. The upside for companies is higher quality candidates whose first experience with the company is a hiring process that makes the candidate want to work there.
I broadly agree with this being an unfortunate outcome but you do understand that making candidates who failed your interview want to work at your company is fundamentally limited in how much it actually helps you. Yes, yes, I know some of them may come back and pass the next time, or they tell their friends about how you were super nice and gave them great feedback, but this is pretty rare. If you're doing this, you're doing it out of the goodness of your heart, not because it helps your recruiting pipeline. And, even though I agree with the idea of providing feedback, assuming that people will have positive feelings when you tell them why you didn't accept them is misguided. I have friends who I know personally that have gotten interview feedback and not taken it well. Of course I tell them to shut up and stop poisoning the well for everyone else, but the point is that this is largely not the picture you are presenting it as.
Sorry, I wasn't clear. Providing constructive feedback to a candidate is unlikely to have a direct positive impact on the relationship between that specific candidate and that specific company. It's more of ... whatever the opposite of the tragedy of the commons is. A policy that, if improved, would broadly improve the quality of many candidates for many companies.
Companies have been optimizing for candidates that are an immediate ideal cultural and technological fit. They are all competing for candidates that are the idealized developer, with perfect social skills, a brilliant CV, and deep technical experience that is an exact match for whatever the company is doing at the moment.
That's fine and rational and all, but a necessary consequence of this is that that pool is quite small and there are lots of companies competing for those people. Meanwhile, there are a lot of very good candidates who are underemployed because they aren't getting the opportunity or resources needed to become those idealized employees. This is a game theory outcome where both parties are optimizing themselves into a losing position.
I've been employed in this industry, off and on, for a long time. I assure you that companies didn't always behave this way. There has been a clear, obvious, and severe decline in the hiring experience, and these policies are hurting the entire industry.
It's generally socially frowned-upon to go on a couple of dates with someone and then ghost them. It happens, but it's not considered good practice. We recognize that it's cruel but also leads to a more cynical, detached, overall worse dating experience for everyone. Saying "I don't think this will work out, you seem nice but you're not what I'm looking for right now" is difficult and awkward, but it's also a necessary skill that needs to be maintained. Sometimes people don't react well, but that doesn't make it less necessary: it closes a feedback loop that ultimately allows earnest people who are looking for relationships to learn and grow and become better candidates for the next relationship.
> In most companies, there is specific company policy that prohibits providing feedback to candidates. There is literally no upside for these companies to provide feedback to candidates that they reject
This is the long and short of it.
In the US at least, discrimination laws are expansive. You can -very- easily end up saying something that violates this and putting your company at risk, no matter how good hearted you were attempting to be.
How do you "accidentally" end up saying something that implicates you in discrimination on the basis of legally protected characteristics - what are some examples of that?
This has always felt like an excuse used by people who who just don't want to be caught in their own lies when asked to come up with a real, non-discriminatory reason.
The other comments gave good answers. A lot of people think it means saying something horrible and racist or something, but not at all.
As one pointed out, there's a "well you said it was X, but person Y who got hired did that too. And they're a different race or gender or religion, so that leads me to believe discrimination."
There's also you trying to be helpful, saying something along the line of "well you hesitated a bit and sounded unsure in your answers", only to find out they have some disability that caused that and now have admitted you're discriminating based on it.
Maybe you'll say "well, if I had known, I wouldn't have noticed it or cared." And a lot of candidates would likely say as much up front. But they don't have to tell you about it at all. See how that creates a weird dynamic?
Is it common? Probably not. But it obviously happened or else such rules wouldn't exist. It's one of those things that the bad actors ruin it for everybody. Bigots are never going to admit their reasons - good people will. But bad people will always try to take advantage, regardless.
> How do you "accidentally" end up saying something that implicates you in discrimination on the basis of legally protected characteristics - what are some examples of that?
Say you say it was for failure to meet a specific performance standard (because that is the documented reason); then the ex-employee has a starting point for an discrimination claim by looking for evidence that trnds to support the claim that people who differ on some protected-from-discrimination axis who failed to meet that standard were not fired. No reason given, no starting point. In theory, this policy helps make false nuisance claims more work and less likely, but a substantive reason for it is that HR knows that they cannot eliminate all prohibited acts by managers that would create liability, so making it harder to get a starting point for gathering evidence is important to prevent valid claims from materializing. HR policy does not exist to protect employees from unlawful treatment, it exists to protect the company from liability for such treatment. Sometimes thise two interests align, but when it comes to information about firing decisions they do not.
There’s similar things that can be done with other prohibited reasons for dismissal, loke retaliation; but the idea is any information you give makes it easier for them to make a case against you.
This is also, in reverse, why, as a departing employee (whether departing voluntarily or not), you should never participate in an exit interview or, if you must as a condition of some severance or other pay or benefit, never volunteer any information beyond the bare minimum necessary; one significant purpose of such interviews is to document information useful either for potential claims against you or to defend against any potential claims you might have, including those you have not yet discovered, against the company.
I think it's more of a case for legal and HR being conservative and super defensive. Not sure if you've ever handled a contract with an internal lawyer, but in my experience they often go for crazy suggestions that the other side would never accept for the sake of protecting the company as much as possible. Might be the same here - HR/legal being super protective and the hiring manager not caring enough to fight back.
Part of it is, if anything can be taken slightly out of context to imply something discriminatory, there are those who will abuse the system and sue. At a large enough scale this can become a real problem. If the company policy is "never say anything" there's nothing to be taken out of context, reducing the chance of a lawsuit.
I bet you this comes back to insurance, as many things do in the corporate world. Sufficiently large companies probably have insurance coverage for discrimination lawsuits, or at least employment disputes in general. The coverage probably costs less if you have a "no feedback" policy.
Who are you trusting as a technical interviewer if you don't already trust them to give negative feedback internally?
Do you not code review? Are you a rubber stamp "LGTM" shop that should just be pushing to main but cargo culted the ceremony because github has it built in?
I had someone email me after being rejected at the final round of an interview. "Everything seemed to mesh just perfectly, and I'm at a loss to understand."
I broke it down for them. "This was nothing to do with you, and we would have had no objection to hiring you. However, the candidate who beat you out simply had more domain experience in XYZ area" and went on to say "For what it's worth, we had 500+ applications, of which we in-depth reviewed 100 resumes, had 40 first-round interviews, 15 second-round, and three final round."
They emailed me back to express appreciation and that though this didn't work out, it renewed their confidence to know they didn't "mess something up".
Since then, if we're at that point in a process and I'm rejecting you, I'll at least give you something to work with.
This is so important for people to understand, and its why I give people feedback.
People, being humans and prone to pattern seeking, assume that if they didn't get the job, it's something specific they did, or failed to do.
And sometimes, that's true. But for a lot of candidates, it just came down to another candidate being slightly better, or slightly cheaper, or some combination of value markers.
A lot of my interview feedback comes down to "I don't see any reason you wouldn't be a good fit, but we have other interviews and it's going to come down to value."
Some people will take this as me saying "Don't ask for what you're worth," or "we're gonna low-ball your salary." The reality is, we're a business, and if I can produce the same widget with person X or person Y and person X costs 10K less a year, I'm going with person X. Every time.
Yes we want to know. Framing this as an empathy issue when in reality you're just to afraid to be honest or afraid of any kind of conflict IS an empathy issue. At that point they're not a person. They're an annoyance that you want gone immediately.
Don't take this the wrong way, but I deliberately ask how I did because it helps me weed out interviewers who think like this. Not so much "how did I do?" as "now we're close to the end of the interview, do you think we're a good fit for each other?" I give my own feedback and talk honestly about points of friction.
I interview pretty well, but if I go into an interview with a company that wants hungry hustlers and I've spent the whole interview talking about kindness and team spirit, or if you think I don't know enough pl/pgsql to deal with your gnarly legacy backend, or I'm getting the vibe that none of the engineers seem to like working here, then we need to speak honestly about that.
No need. Just walk away. Remember: You are interviewing them, just as they are interviewing you. Any company worth its weight will not allow red flags to leak into the interview process, e.g., "getting the vibe that none of the engineers seem to like working here". So many times, I have reached the final round of an interview process, met the senior manager... and thought: "Barf, I don't want to work for that person. What a waste of my time."
I know I'm interviewing them. That's why we need to talk.
If they wanted to hire me enough to interview me, but at the end of a half-day of interviewing I'm going to walk away without a job, then they need to rewrite their position description so I know not to apply, deal with their morale problem, or directly ask me how much PL/pgSQL I've done. We both stand to benefit from talking about how the interview went.
But you also need to factor in their position in the situation right?
Like suppose they do hate their job. Do you expect them to speak that plainly and honestly to every candidate who asks "So how do you like working here?" and risk getting that posted to the front page of HN?
You're asking them to risk their own livelihood so you get a better signal for your own job search, that doesn't seem like a proportional trade to me.
Obviously I'm not advocating for complete opaqueness, but your interviewer is hardly ever in a good position to part with their true feelings towards questions like "How did I do compared to other candidates? How is it truly working here?"
I've basically almost always given direct and obvious non-answer to the first question: "I cannot tell you right now, because I'll need to write down and collate my thoughts. And I'm not allowed to share feedback directly, so your recruiter will be in touch with the feedback afterwards."
> What if you did terribly and I wouldn't hire you in a million years? Do you really want me to tell you that?
Yes, that sounds like extremely valuable feedback.
Why do you suppose asking a question like that shows narcissism? To me it shows a willingness to infest feedback to improve.
I will add the caveat that if someone asked me that in an interview I would likely give a non-answer because I’m not totally sure what all I’m even allowed to say.
A simple request for feedback is not evidence of narcissism or lack of empathy. Could be anxiety. Could be curiosity. Could be zeal. Could be any number of things. It's certainly not an "extreme lack of decorum" though.
It's okay to avoid giving feedback if you don't want to. I can think of a few ways to answer that question in a neutral or positive fashion to defuse the situation and legally protect the company.
Not to mention there are legal liabilities with sharing interview performance with candidates. "Oh but the interviewers told me I did extremely well on their interviews. Therefore it must be the case that I was rejected because of ${protected attribute X}."
Really?? I always appreciated candidates that would ask that at the end - being willing to step aside from the pretense of professionalism to ask a real question and listen to my answer is a signal to me that this is someone who is willing to be real with me, not pretentious or perfunctory.
I do get what you’re saying, but I disagree, there is a good answer; and as is often the case, it’s an honest one.
> asking a question like that shows real narcissism imo.
Precisely the opposite. Asking for criticism and genuinely being interested in what others think of you with the goal of taking the feedback on board and improving is the polar opposite of typical narcissistic behavior. As far as I'm aware that sort of self-reflection is inherently incompatible with NPD.
In other words, the author did a good job but failed because there was an implicit requirement to not try very hard.
> Part of the assignment is using judgment and working in ambiguity.
If trying to clarify requirements is not what they wanted here, they may as well ask candidates to pick a number between 1 and 10 and reject anyone who guesses wrong.
> overkill on the infra and polish
I know its an opinion, but hard disagree on both. Take home tests are intended to show off your ability. Without specific guidance, how can anyone guess how much showing off is expected?
Polish is only bad if it stops you from delivering. Rejecting something that was delivered for being "too polished" feels like you are saying someone did too good of a job.
---
In my opinion tests with vague requirements like this are more likely to be a different way of rejecting people who are not a "culture fit".
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.
I think it's pretty obvious to figure out how much polish is "too much". This is a business. Engineers time is limited. Was the time you spent on that more valuable than the alternative? I'm leaving the question of what the alternative was ambiguous on purpose.
What they were looking at was not the code, but the attitude. They likely don't want an engineer with a propensity to do too much, unless it's a 100x coder who can do "too much" with a lightning speed. Usually they want he candidate to show the ability to quickly do as much as needed, and not more, and, crucially, to understand how much is needed.
So yes, this is a culture fit test as much (if not more) as a design and coding test. Some people who are great at design and coding would fail it, and it's how this filter is intended to work.
Yes, I needed a ridiculous number, a picture of the coding faculty so strong that writing twice as much code as the task really needs is hardly even noticeable.
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).
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.
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.
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?
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.
I think you might be missing the point of the blog post. The author is frustrated that he followed standard engineering practices (by submitting a proposal for approval). This proposal was perceived to be as accepted and then when they delivered.
The issue isn't his solution is incorrect. The issue is the company's said his solution was correct and then they rejected him anyways.
This is the equivalent of the interviewer telling you the brute force solution on a leetcode is good enough, but then rejecting you after the interview.
no, the company did not say that his solution was correct, that's just what the author thought.
The company said that _the parts he wrote in the doc_ would not negatively affect his scoring. But his doc did not contain many parts that the company cared about - read it yourself, and try to answer the questions like: Will there be a per-email indicator? Is there a "sent mail" folder? How will user be notified of incoming email?
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.
> (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.
As a hirer, the kind of takehome assignment I like to give is one that:
* Can be completed in 30 minutes by a skilled programmer
* Has clear evaluation criteria, both objective and subjective
* Has multiple approaches that require making different tradeoffs
And of course, only give it to some candidates where the result will be make-or-break.
As someone who took one of these broad take-home assignments my last time looking for a job, I failed a the assignment for a job I was overqualified for because I was told I wasn't able to divine what parts of the extremely broad assignment I would be graded on.
I doubt I will be in a position where I get a job that isn't a referral for the rest of my career, but it really turned me off of these kinds of assignments, both taking and giving them.
Very curious: how do you deal with AI answers for those?
While writing my questions (and testing in my teammates), I found that "can be completed in 30 minutes by a skilled programmer" very often means "can be completed almost automatically by AI", and that AI will give explanations too, that interviewer could repeat during code review phase.
Every step in the process is a filter. You can ask them not to use AI and trust, you can ask them what tools they used (including AI) and for what part, you can ask the candidate to screen record them programming their solution and forbid using AI, you can ask them about their solution in a followup interview, etc.
It's kind of up to what you're filtering for, and how much you trust the candidate at that part of the process, and how you follow up after hiring.
I think the huge proposal (after several rounds of questions) was what sunk him. The instructions did not request a proposal, and submitting one, especially one that detailed, conveyed “OP cannot take the initiative and proceed with work without seeking approval beforehand.” The project was about asking a few questions, listing a few assumptions, and giving yourself approval to confidently dive in and build something ambiguous. Maybe I’m wrong, but I don’t think the code mattered after that email was sent. The company should have just ended it there without him wasting his time building the assignment.
That's the blogger's point. The hiring manager saw the proposal, knew that wasn't what he wanted, and then proceeded to waste an entire week of the candidate's time while he was looking for income.
Just to be clear, this wasn't my advice, it was written into the task description -
This project tests your ability not only to code, but to deal with ambiguity and open-endedness
I'm not sure how I feel about that to be honest. On one hand I get what they're shooting for in general by saying that. On the other, they're going to have some preconceived notion of what they want, and it's a bit of luck if you come close to that.
> And don't hesitate to tell us if you have any questions!
I personally have no problem dealing with "ambiguity and open-endedness" (and, in fact, enjoy it!), but my solution to this problem at every job that has had this issue is: talk to people and understand the problem.
Attempting to "mind-read" is the worst solution to ambiguity, and, in practice, nearly always leads to disaster.
The best developers I've worked with have an uncanny knack for reading people's minds. (Of course, they are actually just really good at communicating and predicting what people want. But if you do it well enough it sure seems like mind reading.)
It's not really culture fit. I've used the open ended test before and it was a good filter for "can they walk the walk". Just some basic text processing, but only few people cared to mention error checking, tested Unicode behaviour, included any documentation, etc. It's "will you do the usual things without explicit prompting". (The assignment explicitly said you can call them out as something to do without fully implementing to save time)
>This is two business days later than the two-week mark since you sent me your first email.
With no accompanying personal reason for the delay, it's already a rejection in my books. The objective was to design an appropriate solution within the deadline.
This is the problem. Your guess is different from the author's guess, because nothing is explicitly stated.
For others who did not click the link, the explicit requirements are:
> - Email client can either be in the terminal (i.e. a TUI) or a web app
> - Should have basic email viewing + sending functionality
> - Can use a fake backend (DB, in-memory, etc) or real IMAP/POP/JMAP/etc backend
> - Does not have to handle rich text messages, just plaintext
> Your implementation should take inspiration from existing terminal email tools like aerc, mutt, or even something like himalaya.
It should feel fast and intuitive, and you can choose which email flows you'd like to implement.
The word "keyboard" does not appear. Inspiration from X, Y, and Z is entirely subjective, and you should not be punished for not reading the interviewer's mind.
Is it not clear that every single one of the example apps the spec cites are text-based UIs, as in curses-style, monospace text, and (yes) keyboard-driven?
My takeaway from that is that if you don't make an app that is (quote) "in the terminal (i.e. a TUI)" but choose to make a web app, then it should look at act like a TUI.
What I got from that is "fast and intuitive" is the must have. When you have a choice (backend bit), justify you decision. I'd try to use that to stand out or an additional cool feature. When I have to do such homework, I do the requirements to what I think an above average candidate would, they've seen this a million times, then add 1-2 bits of flair/coolness only a handful of people would do to pique their curiosity and want to ask about the next round
All these things are easy to say in hindsight. However, the same outcome could have happened if the opposite strategy were taken (Don't clarify requirements, do bare minimum); someone could just as easily post a response saying the candidate should have clarified requirements and gone beyond the bare minimum.
If you can't wire a house after 2 weeks of education, they were going to burn your house down anyway (especially if you are using AFCI). It's like one simple and highly redundant 300 page book of information at worst.
I will never understand why electricians are always held to this kind of standard and reverence. Framing my house took 10x the amount of study and learning than it did wiring it, and that included me doing a mains underground power extension and all of the mains meter and breaker.
I have to assume a huge amount of it is national and local regulations, which seem to change every freakin year. I read relevant sections a decade ago re: outlets with no ground(has to be on gfci breaker) and wiring a bathroom(has to be on separate circuit). Now you're apparently not allowed to put outlets on the side of or back of kitchen islands? Just random things like this.
I couldn't imagine having to keep up with all of it. I'd guess many don't...
> Is there Really a difference between welding metal and welding software libraries
I'm not sure this is a serious question, but the two have nothing at all in common. Anyone who says otherwise either has never welded or never used a computer.
Hopefully companies take this as a lesson about bottom dollar outsourcing your CS.
For those amounts, they could afford to have hired regionally local support agents, and paid them well over industry standard...
reply