Hacker News Reader

Comment by bad_user | Hacker News Reader

Giving a candidate a "take-home assignment" is actually the most disrespectful of the options listed.

Unless you're an awesome company, with really cool projects and offering me a jaw dropping salary and benefits, then no, I'm not going to do free work for you. Even if you are an awesome company, people probably have to actually work for you to see that, so no, I'm not going to do free work for you.

I'd rather spend those hours doing work that I expose on GitHub.

> in-person assignment where they have several hours to complete a smallish design-and-build task

That's another proxy that's as useful (or as useless) as a coding exercise.

View on HN

I don't know what kind of homework assignments those companies give but I can't even imagine how something a candidate could code in a few hours could have internal use. It takes days for even new hires to start contributing useful projects, let alone a never-before seen candidate without knowledge or access to the codebase and internal systems.

The homeworks are mainly a time saving device on one hand, where they replace an hour of phone screen time for an engineer with hopefully less than 30 minutes of grading. For the candidate, they may take a couple of hours instead of 1, but they also allow for a more relaxed setting with use of IDEs, Google, etc. and no interviewer watching the typing and tapping their foot.

"Free work" in this case doesn't necessarily mean "free work which is useful to the company" it just means doing similar things to what I'm payed to do normally for free with no benefit to myself.

I've gotten complaints from companies where I've done homework assignments for interviews that it didn't seem like I put enough effort in and my reply has always been that I get payed good money to do this stuff at work, they're getting the left over hours in the evening when I'm of course not performing at my peak. If they want work-level quality they should pay me for the assignment.

That's fine, I'm happy to hire someone who is dedicated, passionate, and loves coding enough to to a quick assignment. Its not free work, its a demonstration of skill.

In fact, we just hired someone who did that, and her assignment came back better than expected. At first we were so-so on her due to potential lack of experience, but the assignment (and her projects on her personal site) showed us were wrong.

>Its not free work, its a demonstration of skill.

Was it paid? If not, then it's free work. Call it whatever you want, in my experience the people talking about passion the most are those that are just looking to pay the least they possibly can.

Why not call it an audition?

Until we have established a name (track record) for ourselves, and/or have a number of respected people vouch for us, we are called on to demonstrate our skills, just as musicians and actors are.

In principle, I think this is reasonable, especially since there are reportedly many fakers and exaggerators applying for jobs.

In practice, it appears that there are so many shoddy auditions that we must endure when looking for a job, that it becomes almost a full-time waste of time. This is unreasonable, methinks.

The problem will become serious when nearly every company that is hiring runs a low-quality dog and pony show in which we must perform, or not be hired. We can already see an analogous issue in the ubiquitous presence of objectionable binding mandatory arbitration clauses in seemingly every contract we sign nowadays.

If you were hiring a musician, and you asked them to perform an audition. Would you accept the response, "Sorry, I don't work for free."

"Well do you have any recordings you can show me instead?" "No, I do other things with my free time. I don't work outside of work."

Auditions don't usually take several hours, do they?

That's another reason the "audition"/side project analogy doesn't work. I'm a musician. When you audition for a band, it's a matter of walking in, plugging in or setting up, and playing a few songs with the band.

If the musician is any good compared to the people they've already auditioned, many times you won't play another song. The band will hire you on the spot.

When you hire someone to fix your roof, do you make them build you a doghouse first to prove they know carpentry?

If I owned a carpentry company, and I was trying to hire a carpenter, yes, I would ask them to build me something. Maybe not a dog house, but a bird house. You don't think that would be reasonable? "If you want us to hire you as a carpenter, prove to us you can build a bird house first." That seems totally reasonable to me.

If I hire them to fix my roof and they leave a huge hole in it, I am expected to sue them and wait for a few years to recoup my losses (while having a huge hole in the roof).

I think I prefer the coding test.

So you are admitting you are bad about making decisions about people? Luckily you have something empirical because you are no good at judging someone. Thanks for admitting that, the first step is accepting you are no good at evaluating people.

Ha, but seriously, I hate take home assignments.

> So you are admitting you are bad about making decisions about people? Luckily you have something empirical because you are no good at judging someone.

This is almost entirely the point of take home assignments. In fact, this is almost word for word what my response would be to anyone who doesn't like take home assignments!

> Thanks for admitting that, the first step is accepting you are no good at evaluating people.

Step two is admitting that, in general, evaluating people using non-empirical means is an enterprise fraught with peril.

I largely agree, but I have had one experience that opens a tiny bit of wiggle room for such assignments. During a phone interview with hiring manager, he asked me if I had experience with X, Y, or Z open source projects (all relevant to the team). I told him that I did not, but that I'm always eager to learn new things. He asked me to pick one of them and 'build something' that uses it (no more specific than that). I instantly recoiled at the idea, but I didn't verbalize it. I went along with it. I decided to take the 'when given a lemon...' point of view and build something that was of interest to me.

A few weeks later I came onsite for in-person interview. I brought up the assignment and was able to use it to show my interest and capability of quickly learning and putting something to use. I really believe it worked to my advantage.

If the assignment were to implement something very specific I would not have done it. In my case the assignment was so completely open-ended and was able to convince myself that it wasn't a 'work for free' situation.

You can actually achieve a happy medium between the two. About 2 years ago I interviewed with one of the large SF-based enterprise companies. They emailed me a cool little assignment (parse a text file that describes dependencies and build a graph, output install manifest) and asked me to send back a solution in an hour and half. An engineer was available to call on the phone to answer any questions, but otherwise I was left alone to code in peace, with no screen sharing or other kinds of watching as I coded.

It's probably the best phone screen/coding assignment experience I've ever had. No pressure from someone looking over your shoulder, but limited in time and scope, so I didn't spend all day working on it.

> I'm not going to do free work for you.

It's kinda funny that so many people have this attitude, when, as a salaried employee, we likely have all done more than a standard 40-hour work week on occasion (or habitually), without extra compensation.

Do you also consider time spent prepping for an interview (brushing up on algorithms, learning about the company, researching interview questions, whatever) as "doing free work"?

I just really don't get this attitude. It's not "work", it's a evaluation. And it's an evaluation that actually displays skills relevant to the job, unlike many other approaches.

Most people already do not like brushing up for algorithms. Learning abou the company should take 20 minutes at most. When these assignments take hours of your time with little to no feedback (from my experience), it feels like busy work.

Depends who you're hiring. Early career devs with a lot more time than prospects, and who have already spend a good portion of that time working for free on exercises and toy projects in the name of learning, might not have a folio of work to prove their skills. Crusty HN regulars probably prefer to chuck a github profile around, or provide samples of work in some other way. I don't think it's one size fits all.

> I'm not going to do free work for you

Our industry could follow after the restaurant industry and implement stages/trialing. You come in and work a full day. If you get the job that days pay shows up on your first paycheck, if not they send you out the door with a check.

That does not work for anyone who currently has a job, unless your current employer has extremely lax moonlighting policies.

True, but a paid short-term contract to do an actual task for the company would work. Knock out a small feature during the night/weekend. Keep it something contained and relatively straight-forward. If they can get it done, it demonstrates the candidate's ability to parse your codebase (so they are learning something they'd need for the job anyway) and they have contributed.

I think most companies just don't want to take the time to set this kind of thing up. Easier to just pass on people that won't do the requisite song and dance.

No it still wouldn't work for someone with a current job. That's a huge risk if you're responsible for supporting a family. If you quit and the new job doesn't work out, then you're kinda hosed.

Its a good idea but speaking as a non-citizen on a work Visa such kind of work would technically be illegal for me to do.

Doesn't really work for any larger scale product, it's unlikely that any candidate will be productive in their first day. Sure they could build something separate but then the value for the company probably diminishes. Unlike serving dishes the process of making software differs quite a lot between workplaces.

That's not entirely true. The way kitchens are set up/configured, what goes into dishes, how stations are set up, etc can change quite a bit from place to place. Additionally there's usually kitchen slang/words for most items on the menu which need to learned.

Also I've had many dev interns at my company, it takes work on my end to enable them to be productive quickly, but it's not impossible. Maybe you need to write some skeleton code for them to fill out and unit test, maybe you need to document things well and spilt up your tasks well, but you absolutely can have some one come in and be productive day one.

In fact my interview was a college hire group interview, we were given a laptop with skeleton code in multiple languages, a problem to solve with fixed inputs. The problems were similar to what you'd likely encounter for whiteboard coding, except I got to be left alone with a computer, the internet, and my editor of choice to write actual code to solve the problem.

> so no, I'm not going to do free work for you.

My current employer, when hiring me, said "Have you ever looked at the Firefox codebase? No? Good. Here, take this Firefox bug. Fix it by Monday, or at least analyze the root cause, and let's talk about it during the interview".

Needless to say, they had no interest in Firefox per se. It was just a cool open-source project, and a good way to give me "actual work" while making it plainly obvious that it wasn't for their own benefit/ they weren't looking for "free code via tech interviews"

Reply on news.ycombinator.com