Hacker News Reader

Comment by lxe | Hacker News Reader

> Have a probationary period

That seems very taxing on the company. I'd rather screen the candidate before committing to anything via interview/coding challenge, etc... The take-home coding challenge seems like a good idea -- less pressure than coding during the interview and allows the interviewer to assess the "real life" performance.

> Ask them to build something – anything!

That's great, but a big part of working at a company is building something that you don't like or don't understand well -- talking to stakeholders, customers, figuring out specs, etc -- something that a good take-home exercise can assess

View on HN

The probationary period seems incredibly stressful for the employee. If I am currently employed I would never switch to a role that uses a probationary period as a significant evaluation step because of the risks of leaving my stable employment, and not passing your probationary period. As an employer I wouldn’t want to limit my selection to people that either are unemployed or have a higher personal risk tolerance to handle such situations.

Exactly. Not to mention younger engineers will probably work 24/7 for 12 weeks while constantly worrying they could be fired tomorrow because they didn't fix some bug fast enough.

Not to mention it eliminates anyone who already has a job from the candidate pool. No company I know would be OK with you also working full time at another company simultaneously.

> That seems very taxing on the company. I'd rather screen the candidate before committing to anything via interview/coding challenge

So having a probationary period is too expensive for the company, but a several hours coding challenge for the developer is a OK?

In my experience when a candidate was a bad fit, it was because of soft skills/personality traits not technical chops (which are much easier to learn than soft skills). Are you screening for soft skills in the coding challenge?

The developer is eventually joining the company, no?

I didn't like spending probably about 5 hours total on coding challenges last time I interviewed, and I've been internally opposing them, but as the candidate who interviewed, I'm much happier having dealt with it once and gotten over it than having probationary employees show up on my team for a week every so often and having to drop what I'm working on to work with them and evaluate them.

> In my experience when a candidate was a bad fit, it was because of soft skills/personality traits not technical chops (which are much easier to learn than soft skills).

This is a good point, and argues in favor of traditional interviewing (establishing a rapport with the candidate etc.) over any sort of "challenge" IMO. I don't think I'll learn more about soft skills in a week than I would in an hour - the complex stuff generally takes several weeks for the new hire to be properly onboarded and contributing, anyway.

Reply on news.ycombinator.com