Live data from Hacker News

The latest trend for tech interviews: Days of unpaid homework

work.qz.com

241–250 of 1001 posts

Re: The latest trend for tech interviews: Days of unpaid homework

#241
post #231

Earlier quoted context omitted.

What would you prefer? Some sort of rating or ranking system based off of objective standards?

licensing might not be a bad route, similar to a carpenter's license or a bar exam

So, like certifications? Last I heard those are frowned upon in our industry.

Re: The latest trend for tech interviews: Days of unpaid homework

#242
post #218

Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly. Yet, we do. Ok, then what about open source contributions (if they have…

Let me play devil's advocate for a second. Knowing how to write code isn't binary, of course; there's a wide range of skill even among those who have contributed to large production systems. If I hire someone who seems great on paper and turns out to be a dud, then I immediately let them go. It's bad for me, and bad for them. If a 10 hour project-specific coding task reduces mis-hires by 50%+, isn't it better for both parties?

Less automated / efficient hiring practices could also contribute to higher developer salaries, which would in a roundabout way, provide some compensation for what seems like "uncompensated" time spent intensively interviewing.

Re: The latest trend for tech interviews: Days of unpaid homework

#243

Earlier quoted context omitted.

Exactly - a take-home test that will take more than ~2 (maybe 3) hours to complete is unreasonable. And it should be administered only after a preliminary phone screen. I'm willing to give up an evening for a job that appeals to me and that I have a decent chance at landing. I'm not willing to give up all my weekday free time for a week or stay up until 3am. And I won't do either if you're not willing to first invest…

The problem with any take-home test, ESPECIALLY one that you only expect to take 2 hours, is that you hand people an advantage who do have more time to spend on it. That was what stopped us doing it, and started looking at reasonable tests that you can't prepare for, and can't spend more than the allotted time on. So that means we weave the testing into a 1-2 hours interview, and everyone has the same chance. (we als…

I don't love that approach. There are lots of people who can do the work well in a reasonable amount of time but don't test well under intense time pressure.

We do require candidates to use version control and (though we don't tell them so) we review individual commits to understand the candidate's approach and how they use version control, and commit timestamps to see how long implementation took them.

And the volume of candidates who pass both resume review and phone screen in our process is low enough that we're not usually comparing candidates to one another; it's "can you do the job or not". So relative advantages aren't such a big deal.

Re: The latest trend for tech interviews: Days of unpaid homework

#244
post #139

If you're going to expect people to do real work, you need to pay them. This is common in a field like journalism. Want to do a one or two day trial of a reporter? Pay them to write for you! Have them work in a real environment and do real work for publication. If you're not willing to pay people for their time, and it's not an executive position, asking for days of a person's time is asinine. Also, if the homework i…

How do you try to hire people who currently have jobs with strict anti moonlighting policies? (Or maybe the answer is just don't bother, and you can afford shrinking the applicant pool without any big adverse effects)

Those people made poor choices for signing those policies. I personally never sign non-compete agreements. I've also seen agreements where any OSS projects you work on need to get approved. I walked away from that bullshit.

Re: The latest trend for tech interviews: Days of unpaid homework

#245
post #231

Earlier quoted context omitted.

What would you prefer? Some sort of rating or ranking system based off of objective standards?

licensing might not be a bad route, similar to a carpenter's license or a bar exam

We won't get an agreement about the scope of the certification or even what answers are right. Too much change, too much opinions, too little rigor/science.

Re: The latest trend for tech interviews: Days of unpaid homework

#246
post #218

Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly. Yet, we do. Ok, then what about open source contributions (if they have…

As someone who does a lot of interviewing, I tone down the technical stuff as the experience and responsibility level increases. I think a lot of the annoyances you mention still make sense for an entry level position, because there are a lot of folks who actually can't write code who apply for those jobs.

For candidates with many years of experience, obviously they can and have been writing software effectively, so for me it mostly comes down to whether they could work well on a team, interact with clients successfully, and be capable of mentoring juniors.

Re: The latest trend for tech interviews: Days of unpaid homework

#247
post #218

Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly. Yet, we do. Ok, then what about open source contributions (if they have…

The hiring process is a response to the fact that employers cannot trust a single word candidates say about their experience. This isn't paranoia. Literally, most candidates we see cannot code, even when they supposed have a decade or more of industry experience.

If the industry wasn't so full of lying incompetents, it wouldn't be an issue.

Re: The latest trend for tech interviews: Days of unpaid homework

#248
post #231

Earlier quoted context omitted.

What would you prefer? Some sort of rating or ranking system based off of objective standards?

licensing might not be a bad route, similar to a carpenter's license or a bar exam

plenty of garbage lawyers passing bar exams, and law firms don't just check that you've passed the bar and hire you.

Re: The latest trend for tech interviews: Days of unpaid homework

#249

If you're going to expect people to do real work, you need to pay them. This is common in a field like journalism. Want to do a one or two day trial of a reporter? Pay them to write for you! Have them work in a real environment and do real work for publication. If you're not willing to pay people for their time, and it's not an executive position, asking for days of a person's time is asinine. Also, if the homework i…

An offer of payment does not make silly time commitments palatable for me. I already have a job. If I wanted more cash, I'd just moonlight.

If I was being given a code challenge/take-home, I'd be more inclined to do it if it came with payment. Even if it's trivial, like $200. That's a small price to pay in screening and it at least shows the company believes your time is valuable.

Re: The latest trend for tech interviews: Days of unpaid homework

#250
post #218

Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly. Yet, we do. Ok, then what about open source contributions (if they have…

I used to hate it, but have now performed enough interviews of supposedly senior devs with decades of experience.

I've literally seen someone who did firmware for the space shuttle grind for 45 minutes on fizz buzz without making progress. Like, I'd they struggle for ten minutes or so, I take a step back and say "Ok, screw syntax, let's just vaguely talk about what needs to happen and mock up some pseudo code.". Even then, grinding for another half hour with no progress.

Post reply on HN