Hacker News Reader

Comment by psychometry | Hacker News Reader

It's an effective strategy from the employer's side, but what about the applicant who is asked to spend hours on some test for every job he/she applies for? Are you paying these applicants for the time they spend jumping through these hoops?

And if your "technical grilling" fails to identify strong candidates, you're obviously asking the wrong questions or, at the very least, not asking the right ones.

View on HN

As a candidate, I'd much rather they ask; I find that companies that don't ask for code are almost by definition unlikely to ask the right questions. If you must screen candidates for skillset, the less you have to rely on a proxy for that skillset the better off you are. As an employer, I find code samples irreplaceable, and I'm comfortable screening out candidates who decline to take the challenge out of principle or limited time.

I agree, but the OP does raise a good point that employers need to manage how long it will take to answer the questions for a qualified applicant.

I would rather spend hours on some test than be judged on a whiteboard problem, or any other problem which has nothing to do with programming on an actual computer that has an internet connection.

For the most part I don't complain if asked for an hour (or less) worth of work. I mean, I probably spend more time researching the company, working on the cover letter, replying to communications, and scheduling follow-ups. I'd much rather spend an hour at home with resources I know, than an hour in a room with a whiteboard.

The technical grilling was the thing that the people with apparently-strong CVs weren't passing.

Your objection is a fair one, but having come into the company through the process I describe I am fond of how it let me (a) show that I could actually do the stuff I claimed to be able to (b) show my thought processes and how I would deal with having received a box in this condition. So I was quite pleased to do it as a candidate. Certainly less of a waste of time than a clashing interview.

Its not hoop jumping to ask a candidate to directly demonstrate how they would go about doing the actual job they're applying for. If you were interviewing a cook would you hire them having never tasted their work? I doubt it.

The way I do this is the real coding test is only administered to final candidates. That's a bit kinder since only a few people with a serious shot at the position end up having to commit the extra time and since we observe the whole process (and discuss) it doesn't waste tons of our time either. Whiteboard and discussion can reveal a lot but IMO there's nothing so revealing as actually watching someone work.

As an aside I would much rather be interviewed this way than at a whiteboard. At least for me there's a certain amount of my programming skill that's nonverbal and flows easier for me at a keyboard.

> If you were interviewing a cook would you hire them having never tasted their work? I doubt it.

A cook is someone who can be hired with very little experience. A chef is someone who is trained professionally. And plenty of chefs are hired without a "taste test" based on their academic and employment history.

They're hired on a provisional basis, true, but they are paid while they prove themselves.

I was paid for a days work, when after the initial interview to test that I knew some really basic programming (think Fizz-buzz, but slightly more interesting), they brought me in to solve a real problem in their app. And I did, and they hired me. It was quite brilliant, actually, and they paid me for the days work at a decent rate. I was impressed.

Nobody puts a gun to applicant's head and forces him to take a test, so... Business is not for people to have jobs but to make profit.

The point is that you'll only get applicants up to a certain level. Once an applicant has enough skill and knows it, and also values his time, he'll take one look at your 14 hour challenge and laugh.

So in the end you're only hurting yourself because you'll mostly get naive and easily manipulated people who are fine for the lower ranks but absolute poison once they move up. That's if they don't wise up and leave first, costing you time and effort to find and train replacements and scramble to rediscover and distribute the lost knowledge they left with.

But then again, such a long duration challenge is already very telling of the company culture. If you can't respect other peoples' time, then your company is already on shaky footing.

But the process described in the post above is clearly about proficiency, so a challenge is not supposed to last 14 hours. ;) And I admit you have a point. The thing is, people really have well-looking CVs and they can't code BFS in Python. Probably balancing of 'technical grilling' is a hard to master skill in and of itself.

The test I describe should take an hour or two - it's a test of "can you actually do these things your CV claims you can?" Which is nontrivial, but I enjoyed taking it (fix a broken thing!) and feel fine about giving it to others.

>"can you actually do these things your CV claims you can?"

Yeah but how many questions must you ask before you are certain? Otherwise you're rolling the dice that the candidate has simply seen that problem before but has terrible habits otherwise.

Reduce the time required and you risk more false positives. Increase the time required, and you risk the skilled ignoring you.

Since I think companies are overall hurting themselves with hypersensitivity to false positives, I vote for the former.

he'll take one look at your 14 hour challenge and laugh

These things shouldn't be designed to take 14 hours. They should be designed to take one, maybe two or three . . . if you know what you're doing.

One of the other posters took so long because he didn't know what he was doing. Well, perhaps that is an uncharitable way to say it, but you know what I mean. :)

I once has one that was designed to take ~20 hours, and was given a week to do it. Needless to say, I didn't get that job.

Reply on news.ycombinator.com