6 ms·
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
by silisili 1y ago
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.
- Tiberium 1y agoRegarding 4 - in the full version shared by the author at https://archive.md/A95Ju https://archive.md/A95Ju there is info on what they meant by "terminal-inspired"
- minikomi 1y agoIt seems they wanted "keyboard driven", "fast/light", "quickly interactive" The youtube video provided by the OP seems more "web-app", "click driven". For contrast: * The OP's submission: https://www.youtube.com/watch?v=yY1sVXMkP_o https://www.youtube.com/watch?v=yY1sVXMkP_o * Someone interacting with aerc: https://youtu.be/kpAwwgnZUxg?t=308 https://youtu.be/kpAwwgnZUxg?t=308 * Someone interacting with mutt: https://youtu.be/C35NRp42bEQ https://youtu.be/C35NRp42bEQ
- MeetingsBrowser 1y ago> It seems they wanted 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.
- stephen_g 1y agoIs 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.
- Rastonbury 1y agoWhat 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
- brudgers 1y agoReading the brief, the simplest thing that might work is: 1. Spin up an EC2. 2. Install Himalaya. 3. Do some configuration. Code quality and a sound engineering approach are there. Personal touches aren’t. Though they look for them, absent domain knowledge they probably don’t want to see them. Himalaya has documentation and a Github already. No need to invent the wheel. Won’t take an unreasonable amount of time. And looks like a first iteration of a tool.
- MeetingsBrowser 1y agoIn 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".
- deleted 1y ago[deleted]
- _dark_matter_ 1y agoI 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.
- MeetingsBrowser 1y ago> Was the time you spent on that more valuable than the alternative? In this case the alternative was applying to better companies, so I guess in a way the author really did fail the test.
- deleted 1y ago[deleted]
- nine_k 1y agoWhat 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.
- wkcheng 1y agoThe 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.
- dclowd9901 1y agoYes 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.
- thaumaturgy 1y agoConversely, 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.
- theamk 1y agoSupervisors/manages don't usually do coding interviews though, especially in bigger orgs. There is usually a separate interview stage with some sort of manager, and those usually have no coding.
- linotype 1y ago> Part of the assignment is using judgment and working in ambiguity. I love that the industry has become so poor at gathering requirements that devs are now effectively filtered for their ability to mind read.
- silisili 1y agoJust 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.
- linotype 1y agoThat’s also where it helps to be a mind reader. :)
- crystal_revenge 1y agoWhat about: > 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.
- accidc 1y agoWithin the article, he details his attempts to get clarity/feedback and the response of the hiring manager is as vague as it gets
- brudgers 1y agoThe way to deal with ambiguity and open endedness is by limiting scope and sticking to the unambiguous. When the client can play with that, the scope can be expanded and additional features can be described. What they want is someone they can work with. Take home tests are about cultural fit too.
- llmthrow103 1y agoAs 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.
- theamk 1y agoVery 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.
- throwaway2037 1y agoHoly crap. That was exactly my same reaction. Only thirty mins to complete? Sheesh: Vibe code that!
- llmthrow103 1y agoEvery 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.
- Fire-Dragon-DoL 1y ago
- itake 1y agoIMHO, 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.
- ryandrake 1y agoI 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.
- lern_too_spel 1y agoThat'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.
- roncesvalles 1y agoWhat do you want the HM to say? "Actually, don't bother anymore, you've already failed"?
- yablak 1y agothat's what the OP wanted.
- MeetingsBrowser 1y agoyes. "Please don't spend a week implementing this proposal". Early reject or give some indication that the scope should be much smaller.
- 4b11b4 1y agoI also read that proposal and thought: "it's over".
- Terretta 1y agoThe proposal itself was almost certainly written by an LLM, rather than by someone familiar with the tools that ChatGTP came up with for him.
- roncesvalles 1y agoAlso, he missed the deadline. >Delivery date: Sunday EOD March 30, >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.
- cosmotic 1y agoAll 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.