Hacker News new | past | comments | ask | show | jobs | submit login

Why are you looking for jobs if you are too busy to spend 90 minutes of effort on applying for that job?

Maybe the whole point of the test is not how well you do, but how you react to being asked to do something you feel is beneath you...

> Why are you looking for jobs if you are too busy to spend 90 minutes of effort on applying for that job?

I didn't say I'm too busy to apply, I said I'm too busy to spend 90 minutes on useless tests.

> but how you react to being asked to do something you feel is beneath you...

You know what a great test for that would be? Ask the applicant to wash your car.

> useless tests

These tests aren't useless. Tons of candidates have never seen a REPL before and are totally unable to solve even a trivial coding assignment.

I suppose your company is too clever to waste their time on such useless tests? Who at your firm wastes hours interviewing candidates who have no ability to code?

If someone has never seen a REPL before, it'll take us less than 90 minutes to figure it out, so we don't tend to waste applicants' time with those.

Going through someone's Github (or any other project they feel is worthy of sharing) and asking them questions about why they made the decisions they made has been orders of magnitude more illuminating than asking them to come up with an algorithm for solving the subset sum problem without Googling.

But now your process is heavily biased against folks whose work has primarily been for their current employer, and they don't have any reasonable side projects to walk you through.

How so? It's not like I say "oh, that's too bad then, sorry". It just takes longer to interview those candidates because we don't have that shortcut.

My fear would be that you wouldn't have a rigorous, well-tuned process for those folks, so there could be a lot of noise or randomness in their evaluations. And it could be very hard for you to compare them with the folks with extensive GitHub portfolios and resumes.

Perhaps, but what's the alternative? Don't look at anyone's OSS projects (and lose a LOT of valuable information) because it would put the people who don't have any at a disadvantage?

I think the main thing would be consciously correcting for that: the real value is asking about design decisions — it's my favorite technique — and just making sure that it's fully normalized that not everyone has those out in the open.

It's still easy to spot the liars — e.g. I've interviewed people who worked at the NSA and even they could talk about the skills they used, just not which projects or data — and the process of deciding which things to talk about is a pretty good way to explore their communications style, too.

Yes, that's what I generally tend to do. I present them with a scenario or a problem and have them walk me through how they'd solve it and what their tradeoffs would be.

Well, washing cars turned out to be the point for The Karate Kid... and humility before technique. I agree that few employers will be like Mr.Miyagi though ;

Ah, but Daniel was training, not interviewing :P

It's a kids' movie. But the point was humility before the art. Always in training. Shoot, Mr. m practiced teaching better by tending tiny metaphorical bonsai trees and catching flies with chopsticks, so he was not above being a student in training himself. I'm not saying it is everyone's philosophy or should be- it just cracked me up- the car washing reference- not to say that I disagree that these tests are more a sign of an employer I would not work for. Hey- someone removed the car wash analogy I was responding to! I thought it was funny. I think swe should push back against this kind of treatment when it's worth it to them. It is insulting.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact