Hacker News Reader

Comment by nugget | Hacker News Reader

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.

View on HN

> If a 10 hour project-specific coding task reduces mis-hires by 50%+, isn't it better for both parties?

Does this fully replace the onsite? If I'm fully employed, interviewing with three or four places, and expected to take a day off and visit each of them, adding another full day of work on top of each is a big hurdle.

To keep going with the devil's advocate: If one of your competitors says "ok based on your initial chat with the director, we're gonna bring you straight to onsite" and you say "do this ten hour problem" guess which I'm going to favor? A hiring manager confident in his ability (probably learned through trial and error) to sniff out bullshit is a positive signal to me, the candidate. Intense homework tells me one of two things: they have way too many candidates for the role and there isn't enough data to screen by hand (this makes sense for seasonal stuff like entry-level, not so much elsewhere IMO), or they don't really have a solid picture of how to interview. And in the latter case, that probably means if someone else on the team or in the company suggests a bad but speciously-attractive technical design, they're also going to be unable to call that out.

I cannot agree enough. I'm okay with most of the interviewing practices out there, but there has to be some kind of balance between the company's needs and mine.

One of the most mind-boggling interviewing processes I've been through went like this:

1. Write a program that satisfies the given requirements. Be sure to use the specified design pattern they explicitly requested. Include a suite of unit tests and instructions for building and running the program. Do this within one week.

2. Phone call with the team to discuss your program. Explain why you did certain things in a certain way. Discuss the design patterns you used, especially the one they requested.

3. A "coffee meeting" with some of the team members to discuss the cultural fit. They described their culture and the environment, and also talked about what I looked for in a job, my motivations and what I would do in certain hypothetical situations.

4. Full day of on-site interviews.

The reason I call it mind-boggling is because this process wasn't outlined beforehand, so that last step came as a total surprise; at that point, I had assumed they had enough information to decide. When I explained that I couldn't accommodate them within a week at least due to my current job, their proposed solution was to instead do two half-day interview rounds after normal working hours. This is where I decided to politely drop them, not so much because they wanted to make me go through an interview loop after a full day's work, but because they were going to make their employees do that, too. I was already concerned about the adversarial nature of their work culture -- anyone can nominate anyone else to be fired because "they don't belong there" -- and this just convinced me that I wouldn't fit in there.

The moral of the story is: your interview practices send a very strong message about your company. Be careful what that message is.

Interviews should be an hour tops on site and 30 mins tops on the phone.

Wow, there are so many red flags there. You made the right decision to drop out.

"anyone can nominate anyone else to be fired because "they don't belong there""

Wow. Reality show style office management, anyone?

It sounds like their signalling on culture achieved the right thing for everyone involved. I wouldn’t want to go anywhere near that company.

>If I hire someone who seems great on paper and turns out to be a dud, then I immediately let them go.

If you keep hiring duds, you shouldn't be allowed to hire people. In spite of what the headhunter firms and cookie-cutter websites would have you believe, interviewing and hiring is a skill, not a punchlist.

>If a 10 hour project-specific coding task reduces mis-hires by 50%+, isn't it better for both parties?

Only if you pay me for my ten hours. Otherwise, you've already indicated that you and your company don't value me or my time.

I've hired about 50 full-time w2 on-site developers over the last decade and maybe 3 or 4 of them were total duds (due to extreme mis-representation of technical skills) once employed. I'm not sure how this ratio compares to others but it certainly seems to be an issue that the industry talks about, so I'd be surprised if it were ultra rare.

> Only if you pay me for my ten hours. Otherwise, you've already indicated that you and your company don't value me or my time.

My favorite way to hire is short term consulting project into full time position. Not every candidate is willing or able to do this, but it has produced the highest success rate in terms of hiring signals. By the way, this underscores that it's not a money problem - hiring the wrong person is a lot more expensive than paying five candidates to produce something meaningful (and find the best one of the five).

I agree with your approach. As a junior developer I got my big break by agreeing to join as an hourly contractor while I proved myself, with the hope of being brought on full time should my performance be sufficient. Lucky for me, the company was not lying and they brought me on and the rest is history. We all have heard those horror stories about companies who claim to do the contract-to-hire thing but have no intention to make good on the promise, so this is a risky path for the candidate.

That's pretty good, I know people who've had worse results.

Some of them were former coworkers who leaned very heavily on algorithm problems and whiteboarding because they were terrified of people who couldn't code at all (though wouldn't that be the easiest kind to let go?). But they still missed sometimes. Both on people who'd studied purely for algorithm questions and got through, despite having little practical ability; and on people who could knock out a task but had no ability to reason about its place in a larger system, so created more work for others than they contributed themselves.

>If a 10 hour project-specific coding task reduces mis-hires by 50%+, isn't it better for both parties?

In theory, yes, and that's why they're popular. But you're missing that:

1) The candidate has to do this for each job they apply for.

2) There's no investment on your end, and I have no idea whether you're just going to ignore it after I'm done.

Reply on news.ycombinator.com