Tell HN: Unpaid home assignments are not ok
I’ve just been ghosted by a company after finishing a 2kloc home assignment.
It took me about 6h to develop and iron out the edge cases.
My take away from this is that:
I will not do take home assignments for free if they take more than 1h of my time.
469 comments
[ 2.6 ms ] story [ 364 ms ] threadDepending on the tweak it can also make the most basic of applicants fail to find matches entirely e.g. ask for a “YcomBinator” instead of a “FizzBuzz”.
That's way faster than writing unpaid working code and shows you're competent AND efficient.
Otherwise I’d write to them and tell them that you have an issue. Chase a bit, presumably you don’t know the reason for the ghosting.
Having said that they could be ghosting you because they are assholes. There are unfortunately a lot of inconsiderate assholes in tech.
Asking someone to do so much work for you and dismiss them is a dick move in any culture.
"Not texting back" would be the equivalent of a company simply not following up after you'd submitted your resume; I'm sure OP wouldn't have complained about that. This is more like, the girl texts you back, said, "I'll consider going on a date with you if you do this 8-hour thing for me", you did the 8-hour thing, and then she didn't contact you after that -- yes, that's basic failure of decency.
As a company, you can't really provide feedback on why people failed the test. Hell of a lot of people will get defensive and get into arguments with you that you don't have time for.
I agree however that one should at least tell you you are being rejected instead of ghosting you. That's just bad manners.
I find this to be a bullshit cop-out. You can always ghost them after providing initial feedback if you don't want to engage in arguments.
If the hiring process requires 2 minutes of the company's time for every 1 hour of yours they are pretty much guaranteed to waste your time.
I've made exceptions to this rule before for what I thought were good reasons and deeply regretted it every single time. I no longer believe there are exceptions.
If it were a ship building company asking you to do 6 months of ship building business logic to get a job that would be different, for example.
I'd skip the shenanigans and look elsewhere. I think "thanks, but no thanks" is a good response in this case.
That being said, if you want to avoid having a large imbalance in risk/reward, I would suggest talking compensation before agreeing to submit yourself to a large time investment. At least that way you know why you are putting in the time investment that comes with take home assignments. There's nothing worse that putting in a significant effort into the interview process only to discover your compensation expectations would never be met.
Kids on Blind are doing 200+ leetcode problems before starting their interview loops. How many hours is that?
You’re basically just choosing to forget about all the prep needed to ace a DP problem on the spot.
Lucky for me, landed a role that had checked my github profile and answered some questions, which was sufficient to convince them. No waterboarding required :)
Nonetheless, I can't think of a better solution for this. Hiring someone is a big commitment (for both parts), so I want to be completely sure that I am hiring the right person. How do you that? How do you measure the quality of the other person in an area such as IT where it's so easy to lie about knowledge and experience?
It's much the same vein as that Canonical recruitment questionnaire that was doing the rounds a while ago - if you want to sit with me (virtually or IRL) and ask me questions, that's fine. If you want me to submit an essay that takes me hours to write then you're going to have to be offering me something I cannot possibly get elsewhere!
In the end it's about mutual respect.
Secondly, some candidates get very nervous/anxious when they have to answer code in an interview and can't show they real knowledge, etc. Pair programming hasn't worked for me because you get a lot of false negatives that are hard to distinguish from the real false.
To your second point - any hiring exercise is going to be stressful for the candidate. False negatives are better than false positives (for the hiring party). If you're certain that this is going to cost you too many good candidates, then you're going to have to find some other way to demonstrate good faith up front - offer to pay them, offer to host them on your premises, something like that.
The original fizz buzz type test was to weed out the fakers. It is something most people with a bit of skill can pull off. But as an industry we did what engineers do. We over think it. We blow it way out of the bounds of what it should do. We ended up with enterprise style fizz buzz testing as a filter. Honestly, at this point you really can not expect more. But can they bash out any code, can they read code (and understand it), are they cool with your 'culture'. There are 2 things you do not want on your team, a jerk (they can usually hide it in a few hours of interview), or someone who does not 'get it' (they can become help vampires). But I will take a dozen help vampires over a jerk every day of the week.
It is not like most people are going to 'hit the ground running'. In many places it takes a few weeks just to figure out who to talk to so you can check in code, or get your computer setup correctly. I have yet to come into a job and not have to wait on getting a computer (first day), then a few days of getting access to everything. Let alone beginning to comprehend the problem they are trying to solve.
Almost everyone chooses to do the small coding assignment, because they don't have code to bring.
There is a real treasure trove of things to talk about.
Questions like: - Why is it like Y? - What is good and bad about Y? - Why do you think X would be better? - Why did you end up doing Y instead of X? - How would you approach changing it to X?
Discussions like these on both a macro and micro level is very valuable.
If you are doing it because you don't believe someone's ability, you should either pay them or be honest and say you don't believe their experience, in which case it is up to you whether you want to do it for free or not.
I find the ghosting unforgiveable though, I can't understand somebody being in contact and you simply not replying even if to say "sorry, we aren't taking you". Are people so insecure, they don't know how to reply without sounding aggressive/opening themselves up to lawsuits or something?
I don't think it's a question of fairness at all. It's certainly inconvenient and the longer the test the more likely I am to dismiss it off hand but a couple hours is ok, more than that needs good justification. If a company is offering me a salary thats 90th percentile or above then I don't see the problem with having to jump through some (reasonable) hoops.
The ghosting part is unquestionably rude though and any such company should be named and shamed so that people can avoid them if they want.
Even then, if something can be done in 1 hour, it can probably be done better in 2-3 hours or more. It takes time to show your best work. That's why many companies that do take-homes claim that their process takes only a couple of hours (but in reality it doesn't).
I then time myself doing it.
I figure that means the applicant time commitment is under 2 hours, which seems not too bad.
Is a prospective employer supposed to suss this out entirely through verbal questions?
I've also had interviews which just talk about work I've done before. Most industries only need that, and I'm coming around to those being the more valuable questions.
Yes
It's really not that hard to ask questions that evaluate a candidate's ability without devolving into trivia
Programming is merely logical thought converted into a terse form that a computer can execute
Ask how to solve a problem; ask what needs to be considered to solve it; ask what corner cases does the initial answer not cover; ask for something like a confidence interval on how likely you think errors will happen (and how you plan to respond to them); ask how the program needs to change when you convert it from a cgi-bin/ C program to Ruby or PHP or Go; ask how a solution looks different in any two of the languages the candidate knows/likes
Would you only hire a surgeon after they demonstrate an appendectomy? Would you hire a mechanic only after they demonstrate building a transmission from spare parts?
I think these tests are a good way to have people without previous experience or formal education prove themselves. If you have skills, but no credentials, no public Git[la|hu]b, and no experience, you can still prove yourself with one of these programming tests. However, once someone has a year or so of experience or has finished formal education, the decision should be based on their credentials and the interview, not some kind of demonstration.
It's still silly to expect to have to work for you for free. You can discuss technical topics (design experience, programming language preferences, etc.) without doing a whole exercise. Honestly, it's insulting that people will ask you to come in for an interview and basically tell you that they don't believe what you've put on your resume and start quizzing you to confirm that you know what you claim you know.
I invest 6h of my time as a highly paid engineer to do a home assignment and at best I receive a reply "sorry we found a candidate that's a better fit?".
That's what's unacceptable.
Additionally, software development seems to be the only area where the candidates get bent out of shape being expected to prove they know what they're doing. Take home tests are bad and have to be confined to an hour. Whiteboard interviews are bad and don't accurately model the day-to-day. Leetcode is bad because it's 10x harder than anything you'll work on. How exactly do we expect someone to get a sense of our skill at programming if we eschew every opportunity to... program for them to review? The exception might be extremely well-known people who have extensive public histories on GitHub or something similar, but by definition they're in the minority and 99.9% of companies don't need someone of that caliber.
I interviewed with a health tech startup and they had a good way to do it. We set up a time ahead of time when I'd be given access to the repo. 90 minutes later the interviewer was going to clone the repo and whatever was there was what he was going to look at. This was after a previous ~hour long interview where we did the "tell me about your experience" rigamarole that some developers seem to think should be enough to get them any job.
FYI—Graphic Designers have been “bent out of shape” over spec work in hiring for ages.
https://en.wikipedia.org/wiki/Speculative_work
At least in my experience, people in most fields aren't expected to do free work to show they know what they're doing. In general, past jobs, references, and portfolios tend to be used.
Yeah, let's fail someone who cares about showing their best self for an interview and takes pride in the craftsmanship of their code because we asked them to spend no time on it and probably get something that doesn't even work.
Not to mention there are probably other candidates that are taking just as long but not mentioning how long it takes them when turning it in, so the employer might start having an unreasonable expectation of the quality of work that can be done in 1.5-2 hours based on other applicants, and if you actually do follow instructions and only put that time in, you're likely going to be compared unfavorably against those other applicants.
Only way to properly enforce that limited time is to bring someone in to take a test in person, which is what my last company did (I barely passed and watched hundreds of people get brought in and not pass in the years since...in fact I saw only a handful of people pass that stupid test, part of the reason we never hired anyone, even though we needed to).
Your last point isn't true at all, it doesn't need to be in person it just needs to be coordinated. I mention one real-life example of this that worked out very well at the end of the comment you're replying to.