Tell HN: Unpaid home assignments are not ok

[mathverse]

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.

[jerf]

According to the HN gestalt, you shouldn't do a whiteboard interview because that's too unrealistic because nobody programs on a whiteboard, you shouldn't expect programmers to code with their laptop in an interview because that's too much pressure and also unrealistic, you shouldn't expect programmers to be willing to do a take home exam because that's too much work without money (and if people did pay, the complaint would smoothly shift to it not being enough money and still being too much work), and you shouldn't just hire people with the intention of rapidly firing them if they don't work out because that's cruel to uproot them like that if you're just going to fire them. Recruiters are also out because they suck and also drain money out of the transaction for no gain since they bring no value to the process.

Apparently the approved HN method is to arrange the resumes on a dartboard, throw darts at it, and commit up front to hiring whoever you hit unconditionally for at least two years without no possibility of having to fire them. Or something like that.

Setting limits on what you will do is good, and ghosting is bad, certainly.

But in the end, you're going to have to do something unfun to get hired. There's no way around it. I know we'd all love to live in a world where Google one day just logs on to LinkedIn and is so impressed by the sheer brilliance of our awesomeness which just somehow oozes through our listing despite the fact we didn't have to do anything to demonstrate it, as it's also unrealistic to expect programmers to have a lot of publicly-available demonstrations of their skill such as open source projects (forgot to mention that one!), that instead of hitting you with a job interview they just lead with a job offer for their best position, but that's just not going to happen.

[JadoJodo]

The tactic I’ve employed at my company when vetting a candidate is to give them a link to a small code sample (usually a single class or service for backend, some JS/CSS for front end) to review the day before the interview. The code itself will include some obvious issues, some less obvious issues, some language specific opportunities for improvement, etc.

We then walk through their notes (if they made any), and the code sample itself together. I have them make any observations, critiques, suggestions, or other thoughts together with me. This gives me an idea of how they think, what issues they saw, how they would improve things, how familiar they are with the specific language, and coding in general. It also gives an opportunity for some light “conflict” resolution , if I push back on their thoughts.

This has worked really well. Those that don’t do well on the spot can make notes ahead of time (but aren’t expected to spend time coding for hours) and those that are confident can walk through it live.

[cableshaft]

I had a similar interview once. They asked me to bring in a code sample, we discussed what it did and various details around it, then he showed me an actual class in their codebase (printed out), asked me to explain figure out and explain everything it did, and there was also a couple mistakes included in the code for me to find as well.

The guy also asked me a few relatively simple technical questions, then said "Okay I know you can handle the job, let's see what you really know," asked me some really difficult questions, when I said "I don't know" to some he actually spent a few minutes teaching me the concepts.

That same guy was the lead programmer on some famous arcade games, btw. Did a lot of assembly programming back in the day. He had serious technical chops.

Got a job offer the next day. 1 interview, 1 interviewer, a little over 30 minutes spent.

Best interview experience I ever had. If more interviews were like that I wouldn't feel dread every time I felt the urge to switch jobs.

Also if that's all someone of his caliber needed to determine applicant quality, I don't see why everyone else feels the need to go through all this other bullshit.

[phreack]

Yeah I'm baffled why people do such weird random leetcode challenges when this option is so good. At a place where I used to worked they'd give people a couple of class and ERD diagrams with obvious issues and give them about an hour for them to think about and how they'd change things.

It was such a good trigger for discussion and we could easily measure a candidate's fit in moments. Some would just go "yeah this code's perfect" and not argue at all, some would spend ages with irrelevant details, and the couple of people who immediately looked at the diagram and spotted the most glaring OOP issues turned out to be great at their job.

[bambax]

There is a strong argument in favor of this, which is engineers spend more time reading code than writing it. It's a very important skill that whiteboard coding doesn't assess at all.

[dcminter]

That's the kind of thing I'd be fairly happy with as an applicant.

One swift interview process I did included a single short page of code and the invitation to (with pen and paper) review it; I was given some time to think about it on my own and then to talk it over with the technical interviewer.

I liked that one and they had what I thought was an above average quality of developer when I joined. Anecdotal but interesting.

[rubylark]

I really like this strategy. After one god awful experience at a company that led me to quitting after 3 months, I will not work for a company that doesn't show me a snippet of their own code. The whole experience at that terrible job could have been avoided if I could see their coding practices: early returns, gotos everywhere in C++, 7(!) different languages that compile into one >1GB executable over the course of an hour. They only did white boarding questions which told them a lot about me, but told me nothing about them.

I've had 4ish interviews since that job, and all of them gave an on-the-spot code reading assignment to walk through their code to find the bugs. It let me see who has old style coding standards, who takes advantage of modern C++ utilities, and that the interviewers are competent enough to walk through coding examples, too.

[jdthedisciple]

I really like your approach and wish more employers employed it (haHaa). As an applicant I'd certainly appreciate it.

[rapht]

This resembles to what we do in a very different field (finance) at my organisation for positions with less than 10 years of experience-- only the prep is time limited, at our offices,

[lenocinor]

I’ve used a similar interview technique at a previous job and it was great. The candidates and I both generally liked it a lot.

[LocalPCGuy]

We've done this with real-world PRs from our code base (chosen from a project that matches the job they are interviewing for), especially for more senior devs it is good to see how they parse through the code, what they look for, comments they make, and how they communicate.

The one thing I didn't feel just asking for review/discussion accounted well for was their ability to build/add something new to the code, and so we have followed up the code review/discussion with a very specific/small exercise to evaluate the process (architecture, pseudo-code) they'd use to do that, and then discuss that as well.

[willcipriano]

I've had the same experience. Submitted a working code test and crickets. I left it up on my GitHub named "{company name} coding test" and a couple of months later they asked me to take it down beacuse other people were plagiarizing it. Like them, I was concerned with the legal ramifications of providing any sort of contact, so I took no action and didn't respond.

[sidewndr46]

If you ask a candidate to complete such a thing and then they turn in obviously copied work, isn't the author who published it doing the hiring manager a favor?

[roenxi]

A baffling response at many levels. Both by the company (isn't this a great signal not to hire someone for their coding ability? Maybe everyone should put up a decoy solution) and the plagiarists (do they think the company hasn't seen the task before?).

[test1235]

Weird - I had this exact scenario with a contract position working with Sony. I was even rushed to complete the take-home task, after which I was ghosted.

[water8]

Yeah, they were clearly plagiarizing. You should’ve told them to go pound sand

[smcl]

That's an excellent response

[blackoil]

First, Ghosting is a shit move. No reason HR can't send a standard lawyer approved boiler plate rejection mail.

2nd aspect is unpaid take homes. It's complicated. Companies do pay a lot to fly candidates, put them in hotels and feed them for onsite interview. So financially company can afford to pay something. But it adds a moral hazard as you are paying cash irrespective of any expected quality or commitment.

Other thing I would like to highlight is that unlike any other industry, tech. allows people to enter at ease irrespective of the pedigree and credentials. No hospital would hire a physician who has read a lot on the Internet and did some pro-bono help to the neighbourhood kids. So what is the best way to hire isn't very well defined. It could be Leetcode, puzzle problems, take home tests or something else.

[PaywallBuster]

> Companies do pay a lot to fly candidates, put them in hotels and feed them for onsite interview.

I tend to see 1) quick phone call with recruiter 2) please make assignment

in Europe at least

[Ancalagon]

I haven't had an in-person onsite in the ~20 onsites I went to for my last job hunt. I think they're going the way of the dinosaur for technical interviews.

[lbreakjai]

We let the candidates decide: Take-home assignment, pair-programming, or we go through an existing project of theirs, discuss it, and extend it together.

The take-home assignment is short. It shouldn't take more than an hour if you really really want it to be polished, which we heavily insist we do not care about. The overall process is a bit longer, because we then discuss it together.

For the pair programming session, the exercise is picked by a developer that isn't involved in the process, to put candidates and interviewers on equal footing.

Our goal is to be able to give an offer within 48 hours starting at the first contact, and give a feedback, positive or negative, maximum one hour after each stage.

It's a candidates' market. A long and complicated process only ensures you weed out the candidates who have plenty of options. I'd almost be tempted to give a long assignment and consider everything but a firm "Not even in your dreams" as a failure.

[VoodooJuJu]

>Take-home assignment

That's fine, pay me.

>pair-programming

Again, that's fine, pay me.

>go through an existing project of theirs, discuss it, and extend it together

The SaaS's I own and operate are closed-source and I'm not looking to take on any contractors at this time, but I'll let you know if anything opens up.

[jjgreen]

For a 2015 ML job I applied for:

    | We are wondering if you would like to attempt our code challenge (C/C++ or
    | Python). It is a Computer Vision problem which we think can be solved in
    | about 8 hours.
    
    I'm afraid I wouldn't, 8 hours is far too much for a interview
    problem.
    
    However, thanks for considering my application.

[iambateman]

To me, there are three tests to figure out if a home assignment is reasonable…

1. Is it actually giving the employer more confidence or information about your candidacy?

2. Is it within the normal bounds of an interview? If someone asked you to do another 60 minute technical interview, would you?

3. Is the company clearly not trying to use the product of your code challenge?

To be honest, there are a lot of people who can look impressive but turn out to be totally under-skilled at coding. I’m sympathetic to hiring managers who feel like they need to test for that. As long as it’s not a super long exercise, they’re not just hazing you, and they’re not trying to use the results, I think it’s fine.

[Verdex]

Yeah, I think this is reasonable. I had a pre-technical interview "take home" coding challenge, which was just: Reverse a string in whatever programming language you like best.

The technical interview itself drilled down more deeply into my skill level, however I can appreciate that they wanted to have a bare minimum idea that I could actually program before committing more time.

The favor was more than returned when they took me out to lunch in the middle of the technical interview and let me ask as many questions as I liked about the company.

[androa]

I do a lot of interviews for my company. We do coding assignments OR let you bring some code. We just want to talk with you about code that you are very familiar with and confident to talk about.

Almost everyone chooses to do the small coding assignment, because they don't have code to bring.

[androa]

If you get to talking about code (usually after a quick seeding of applications and a 30 minute chat), we will always talk about the code and also give feedback on our impression. So even if you don't make the cut, we hope to provide valuable feedback on why.

[rajasimon]

For personal project there will not be a TDD so coder not willing to share their existing codes. I rather showcase my skills in a new development than say already done one.

[walthamstow]

Counterpoint: as a self-taught SWE with only a degree in economics, I wouldn't have been able to get my first job in the industry without a take-home assignment. It was the only possible way to demonstrate that I was qualified to take the job.

[lr4444lr]

I just don't do them at all. It sets bad terms for the employer / employee relationship IMHO. I realize some devs just aren't that in demand yet and may have to subject themselves to this, but you should do your damndest once you get the job to build the skills not to have to stand for it in your next one.

[AdvancedCarrot]

Indeed. I've offered them before to people who were borderline - i.e. in the interview they didn't really shine but I wanted to give them a chance to redeem themselves. Goes either way really.

[oleg_antonyan]

They are much better than livecoding. I take 8 hour home assignment over 1 hour livecode torture.

[gwd]

At least with live-coding, the company is investing at least as many person-hours as you are -- in my experience 2x as much, since there are normally 2 people doing the evaluation.

[collyw]

I am 50/50 with this. Livecoding is very hit and miss. If the answer comes into your head under the pressure, all good. If it doesn't you look incompetent. Usually it's 50/50 for me. So 2 hours of effort would likely get me pass. 8 hours of assignment should as well, but I have been rejected for ridiculously trivial reasons on take homes as well.

[throwaway43345]

Same here, The take home assignments are easy for me, but I can't seem to manage to break through the live-code / leet-code sections with the guaranteed panic attacks.

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 :)

[kasey_junk]

You encountered 2 problems and neither of them was the take home assignment. The first is that the company ghosted you. That is unacceptable regardless of what your hiring filter is. You’d be just as aggravated if they’d brought you in for 6 hours of interviews and then ghosted you.

The second is they didn’t set expectations (or at least you didn’t tell us if they did). Should you have spent 6 hours on this? How long does it normally take? After the assignment would you be brought in for 6 more hours of interviews or is the assignment the major filter?

At the end of the day, take home assignments are the best filter, the most equitable and the most efficient way to do hiring consideration. Companies (usually the middle managers within them) just don’t have the courage to use them correctly and don’t spend the resources to make them a good filter (they also don’t spend resources on the other job filters so those aren’t good either).

[rrwo]

I have 25+ years of open source software and contributions. If that isn't enough to convince them that I know how to design and write software, then homework won't be enough.

[101008]

I've been in both sides, and what they did to you was horrible. Just last week I had a call with someone who did the take home assigment very badly, but I wanted to give him some feedback and showed him a better solution.

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?

[sumtechguy]

What I find fascinating is that we ended up here. Where doing 2+ hours of work to show 'you can do it'. When the reality is can you get along with them, I have found, is more more important.

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.

[dcminter]

Do pair-programming exercises. When the hiring company is investing a proportionate amount of their time in the process then I'm much more willing to participate.

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.

[collyw]

Ask if they have any code that they would be willing to bring in and discuss.

[cbanek]

I agree completely. These things are ways for companies to waste your time in the interview, and make it harder. Job interviews used to be 1 hour and a handshake. Then a reference check.

Let me tell you why that was better than the current hiring meta.

1) I can learn everything I need to know in an hour with someone. 2 will likely not drastically give me a better idea. 8 hours with someone is not 8 times better, it just doesn't scale like that. So the idea that the more work you give a candidate, or the more interviews, or whatever, the better your hiring practice, it's just not true.

2) People can be very nervous in interviews. It's an intimidating, adversarial environment that has no relation at all to the job or work. It's almost the beginning of the way for the company to treat you as lesser, and they will take advantage of that to screw you these days. As you say, they will just ghost you. They didn't used to do this nearly so much. They'd at least send you a letter, or give you a call.

3) Even if 1 and 2 weren't true, the questions asked in interviews have no relationship with the real job. You just can't ramp up in time, etc. There's too much learning. Picture an intern. They do nothing except take everyone's time for the first month, but it's the rest that matters. Will they get something useful done before they leave? Maybe. But it does take a while to ramp up. So interview questions don't judge job performance.

But we still do it, because people like that tinge of power I guess. That feeling of control in that you can say yes or no to someone, they have to placate you for the job, etc. A lot of interviewers I know act very strange in interviews too, and they don't act that normally.

For the interviewee, it's even worse. You waste your time, you spend a lot of emotional energy, you don't know if you like the people you'd be working with, you don't know really what you'll work on, and no matter what you have to do what your boss says anyway, which can change at any time. Oh and it's "right-to-work" so they can fire you any time for any reason.

It's much more useful to talk to their previous boss or friends or references. Even if they are biased, you can usually tell pretty quick again who is telling you nonsense. At least then you can hear real stories about real situations in the past, rather than useless hypotheticals. But we don't do that anymore because of liability from lawsuits in hiring. Because a lot of companies are actively discriminating. Some are passively doing it, some are trying to do better but are hopeless. So everyone is just covering their ass.

Sounds like a great deal!

[badpun]

I prefer them to whiteboarding. Preparing for whiteboard interviews takes a lot more time.

I will however not accept a take-home coding test before I spoke with the engineering team and saw that they're seriously considering my application (i.e. it looks like I will be a good fit, and they just want to make sure I'm not some fraud who can somehow talk the talk, but can't walk the walk).

[ManVanderHuge]

I actually like take homes as they feel like the best way for me to demonstrate I can code vs a Leetcode question which determines I have grinded or am amazing at mental pretzel puzzles.

What I DO HATE about take homes, is if you complete one, clearly put time into it, and then are refused feedback when you are rejected. If I put 2-10 hours into writing something for you, I at least deserve three sentences on why it wasn't accepted. I know these people are busy, but so am I. Most of us also have jobs, and even if we don't we want to know how to improve.

[pgm8705]

6 hours of work is too much and ghosting is never acceptable, but I'd much rather do a take home assignment that takes a few hours than any sort of in person whiteboard or a screen share coding session. I struggle with where the line is drawn here. If throughout the interview process you spend over an hour talking to various individuals at the company should you also be compensated for that time?

That being said, I've seen cases where the take home assignment is actual company work, in which case I 100% agree you should be paid.

[im_dario]

I did a home assignment that required far more than 6h. The feedback was atrocious, as they just said "not fit". Not a single comment on what they disliked or how could I improve.

Actually, the assignment was "take this shitty service and make it production-ready". It had some pitfalls that I avoided, and I introduced monitoring, automated deployment, API documentation, etc.

There was a bug - a minor misunderstanding that was simple to fix if they gave the feedback and allowed to do a quick fix - but the rest was production-ready.

I had fun doing it, that's why I didn't mind taking time. What I didn't expect was the poor binary feedback with zero content.

From now on, I'm only taking these assignments if they agree to have a feedback session. If not, I won't do anything. I'm close to 20 years of experience and it feels like they treat me like an undergrad (although I have a full Github profile).

[the_only_law]

I had one that was actually simple, took me a trivial amount of time.

Then I got grilled in the interview for not pulling in all sorts of bloat and other bullshit for a single endpoint CRUD app.

[antisthenes]

Making something production-ready is not a take-home assignment, certainly not part of an interview process.

Full stop.

[hyperman1]

Long ago, I had a candidate in an interview for a short term project. The person had an important hole in his knowledge, but seemed OK apart from that. I was afraid learning the knowledge required to fill the hole would take too much time from the short term project.

So I decided to mail a take home assignment. I took about an hour myself to prepare it, the assignment was not work related, it was a completely fictional task. I think it was creating a HTML page of ~50 lines demonstrating the hole could be filled if the person had access to internet and all relevant docs. The person delivered the next work day, did well, and we hired.

I've thought long and hard about this, and decided the assignment was a mistake and I would not do it again (sorry to the person in question). Why? In practice, when listening an hour to a candidate and let them write a minimum of code, you know if you have a complete weirdo who never touched a computer, or someone who is at least basically OK. In this case, it was a short term job, so the blast radius was pretty small even if candidate was bad. For longer term engagements, there is generally a test period and better vetting available. Meanwhile, I was in a position of power over someone else, and while the whole thing seemed minor to me at the time, I later heard the (junior) candidate was worried sick and spent way to much time on the assignment.

An underlying cause for my mistake was the interview situation, which was very bad. Basically, I was in the middle of something else, and a project lead I had never heard of for a project I had never head of asked me to do a technical interview while the candidate I had never heard of was already sitting in a meeting room. Needless to say, I was completely unprepared. There wasn't even a whiteboard in the meeting room. So I basically adjusted by always being prepared for surprise candidates: A list of questions for most common technologies and a template for technically grading candidates were always stashed away in my locker from then on, and the people starting projects would keep us interviewers in the loop when a job would open.