Hacker News Reader

Comment by donretag | Hacker News Reader

One big issue that a take home assignment is that it removes the ability for the candidate to ask questions. Interviews are two-way streets.

Nowadays, I reject more companies than I interview for based on an initial phone conversation. I have requirements in what I look for in a company and position, and some simple questions help me resolve many of the primary requirements. Given a take home exam, I will have invested hours of my time, before given a chance to screen the company.

Just say no. End the madness.

EDIT: I should add that when I mention a phone conversation, I meant with someone on the dev team, not HR. A take home exam after only an HR phone screen is not acceptable.

View on HN

At my current job (where i've interviewed candidates) we give out a take home assignment, but we explicitly enforce a 2 hour time limit to do it. We felt this was reasonable because combined with an onsite interview and a phone screen, the total amount of time a candidate would spend interviewing for a position is about 8 hours (a typical workday). I'm not against take home assignments per se - but 3 day assignments seems crazy. I can't imagine myself doing that as long as there are other decent jobs out there that don't require it.

I think this is the best approach. You get the opportunity to do exactly what the job expects, without the pressure of having to manage communication with someone breathing down your neck. A savvy employer can extrapolate what you're able to produce over 2 hours to whatever project they'd have you work on.

We've had pretty good luck with it thus far. Generally, it is a good way to chop off the long tail of "not good enough" and bring the better ones onsite.

As you said, we calibrated our general expectation to what we think is reasonable in 2 hours - so we expect "good enough" code, but not perfect code.

I've done homework as a candidate twice, and given it once as part of the hiring team. Every time, it was after an initial phone screen.

When we gave homework, it was to a slate of junior candidates, primarily just out of college. When I did homework, I was unemployed and looking for my first job in tech.

If homework is a good idea ever, those are the circumstances. You have candidates who are hard to evaluate, will get a large benefit from a job offer, and are less likely to have severe time constraints. I wouldn't make it a requirement for all potential hires.

Also a good interviewer WANTS questions from a candidate. They show that you've actually thought about what it would be like to perform the job and understand what sort of environment you thrive in and thus can filter yourself out if you think it's a bad fit. Because you don't want to waste you time starting and then quitting or being fired a few months down the road.

One of the biggest mistakes I see strong technical candidates make in interviews is not asking any questions at all.

What questions, if you don't mind my askibg

work environment, fluidity of assignment, career opportunities, acceptance of suggestion, involvement of developers into the design process, key tools and applications, workflow automation expectations...

there are lot little details that one can ask and will give you back a picture of how the working environment is going to be. here's a good starter list, even if I find it too formulaic and question you need to ask heavily depends on what your role will be: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

also, as an interviewer, if a candidate doesn't ask about the work environment and daily operations I'll take it as a potential sign of the candidate having never reflected on its own craft.

includes dev-ops, pace of development, how and when does code end up in _production_? It is important to ask at least two different people separately because you are likely to get different answers.

Reply on news.ycombinator.com