Comment by JamesVI | Hacker News Reader

Comment by JamesVI | Hacker News Reader

Variations on the theme of "have them do a paid project for you" surface here every so often. The problem is that a large number of job seekers currently have a job (everyone keeps telling them it is easier to get a job while you have a job). Even qualified, competent programmers will find it hard to accept the risk of being dropped at the conclusion of the short project (and if you no-one ever gets dropped, what is the point of the project besides giving you a warm and fuzzy?)

Fact is, you have to do everything up to that 'mini project' then just go with your gut and hire/no hire. If they underperform in the role you need to either change the role, try and train them up or let them go.

This trial period is just a way of pushing the risk of a bad hiring decision back onto the candidate and allowing the manager to avoid the discomfort of actually firing someone (although telling the candidate that the project didn't work out is functionally the same thing).

Yes, I think this is the main problem with the idea: it doesn't make sense for someone who already has a job to do a trial job.

That's why I think you already do see it with one large category of tech job-seekers where that isn't a problem: students. Tech companies hire student interns for a summer effectively as a trial period, and both sides often like that arrangement.

Yeah, I think it's a nice solution but it only works in very narrow circumstances.

Once I was given a much smaller, unpaid task as part of the interview process. It wasn't a puzzle or trick, but something actually useful. All told it took me a couple of hours one evening. You might be thinking, "How much can you learn about someone from such a small task?" It depends on the task, of course. Mine was typical network code, with a couple of non-obvious but absolutely real-world edge cases. I spent time making sure my comments were great, and then wrote a man page. I think they learned some important things about me, and on my end it was an easily paid investment.

Yeah, something small is probably okay. I know that I've invested more than that preparing to interview for a new job (brushing up rusty skills, revising algorithms I don't use but interviewers love to ask about). The author talked about hiring people for weeks. I think that is too long.

We've been using something like this but centered around concurrency rather than networking. It works out great, you get to compare across many candidates how they handle the tricky parts, if they understand the standard vocabulary of concurrency, what their coding style is like and if they understand basic C++.

One thing we noticed was that there is small handful of mistakes that many candidates tend to make. The ones that note the existence of a mistake or work around them skillfully are typically the best.

This trial period is just a way of pushing the risk of a bad hiring decision back onto the candidate and allowing the manager to avoid the discomfort of actually firing someone (although telling the candidate that the project didn't work out is functionally the same thing).

It is tough firing people. But that doesn't mean it can be avoided.

And this is a good time to remind everyone: Firing an employee doesn't mean the employee failed. It means that everyone (including the company and everyone else involved) also failed. Such a failure in an organization should be a time of reflection for everyone; to think about and talk about what worked, what didn't, and what everyone can do better next time.

The author suggests to pay a candidate for the trail project, which makes it a reasonable deal for the candidate.

To do something small, you don't need to quit a job, just dedicate few evenings and weekends and earn some extra cash.

This method can be beneficial for candidates, that can get to know potential employers much better, and avoid ones that look interesting only on job ads.

The author specifically recommends hiring someone for weeks. Maybe he meant a couple of weekends, but it doesn't read that way. I agree that something small - evenings and weekends - might work. Of course, you and your team need to be prepared to come into work at those times too, in order to make this a bidirectional experience.

Reply on news.ycombinator.com