Hacker News Reader

Comment by LordFast | Hacker News Reader

I've personally seen no correlation between people who can solve problems and program when watched by another person versus people who can solve problems and program when left alone with a real problem, and ample of time to noodle on and resolve it on their own.

The same is true for writers: most are likely not to be interested and/or able to do their best work when watched over the shoulder by another person.

The /real/ question is this: should software be like a factory job? If so, let's clearly acknowledge it and define it, so that people can set their expectations and self-select accordingly.

View on HN

> I've personally seen no correlation between people who can solve problems and program when watched by another person versus people who can solve problems and program when left alone with a real problem, and ample of time to noodle on and resolve it on their own.

At most of my companies, we tried moving exclusively to take-home interview problems for this reason. Short problems that could be solved in 2-4 hours of time, as benchmarked against current employees during daytime hours.

Inevitably, some candidates hated this so vocally that they'd ghost us, or some times even take to social media to lambaste us for trying to take away from their free time. Or we had people refusing to do the toy problem (not real work, same test for all candidates) unless we paid them hundreds of dollars to compensate their time.

It didn't matter how much we tried to explain that the entire purpose of the take-home problem was to grant flexibility to the candidate. A large number of candidates vocally hated any interview technique that didn't involve company employees giving 1:1 interview time to them.

We just filtered those candidates out of the pipeline, but I walked away with a clear understanding that interview practices will never make everyone happy.

If in typical work settings people work in groups to solve work problems, then in typical interview setting interviewer should also work in group with interviewee in order to have relevant estimate of interviewee performance?

Such collaborative interview setup also addresses interviewee concern that interviewer may not value interviewee time.

Take-home test is my preferred method, but

- only after I had a face to face (can be on skype, but not on phone) interview with a hiring manager/engineer, so I know I really want to work for that company. Job ads usually not very useful determinating that (Interview should work both ways.)

- Not used as a prescreening. It should prove that I really know what I'm talking about. Otherwise, maybe I'm just wasting my time (See above)

- No more than 2-4 hour (we agree on that)

- We review my code. It's good for both of us. I get feedback, the Interview gets more inside why I did what and if I really write the code. (Optional, but prefered)

> Or we had people refusing to do the toy problem (not real work, same test for all candidates) unless we paid them hundreds of dollars to compensate their time.

It's otherwise billable time, don't see why you'd have a hard time respecting that from a candidate.

> "It's otherwise billable time, don't see why you'd have a hard time respecting that from a candidate."

Sure, as long as the business gets to deduct the cost of the interviewers' time from that. Not gonna work out in favor of the candidate but respect is a two-way street.

After all, once the candidate (or a candidate, anyway) joins the team, it's their billable time being spent reviewing and interviewing other candidates too.

> Sure, as long as the business gets to deduct the cost of the interviewers' time from that.

They can at tax time, whereas an employee can't. If an employer requests work from someone, they should pay them.

"interview practices will never make everyone happy."

This is true, but it's not a problem. The problem would be everybody using the same interviewing practices.

Me, I think complaints about spending a few hours on an assignment are ridiculous. All the alternatives are much, much more objectionable to me. The main fallback I have is a contract or temp position, which means my "interview assignment" takes months.

>The /real/ question is this: should software be a factory job?

It has all of it: creative jobs, theoretical jobs, and factory-like jobs. White collar and blue collar jobs at the same time.

What we suck at is admitting which jobs are which types and assigning the labor accordingly (as well as setting targets).

> What we suck at is admitting which jobs are which types and assigning the labor accordingly (as well as setting targets).

Huh, never thought about it that way. That's a very useful perspective. I will start incorporating it going forward.

Side note: Most of us work with our hands. We don't think of it that way. But if you break a finger, you'll find out in a hurry that you work with your hands.

The interesting thing is even the FAANG's have work that you might consider factory work, ie changing the tax rate when the customer is Danish and their head office is in Angola and the advert is displayed in Greenland.

Possibly this sort of thing is the majority of the work although not having worked for them I don't really know.

I'd also add that by saying modern factory work is quite different from Henry Ford's day, at least in developed economies. There aren't many factory jobs in the West you can get without a qualification.

Reply on news.ycombinator.com