Hacker News new | ask | show | jobs
by icbat 4019 days ago
> Sadly there's (seemingly) no way to interview people for this ability

In a recent interview, I spent 45 minutes pairing with a current employee. Our goal was to take a (contrived) piece of legacy code, clean it up, and add a new feature to it. I imagine it was a very telling experience for them, and I feel it was more useful than the whiteboarding we'd done before.

Hopefully we as an industry will keep iterating on this sort of interview.

2 comments

Yeah, a combo of a scanning a candidates github projects and some doing some pairing on real code is much better than whiteboarding.
Except not all of us keep our stuff on github.
And some of us use Github as a rubbish bin for half-baked projects and hobby code, and not a resume.
Yeah, that is cool and lets you get a hand on the job and a feel for what you'd be working on, but it makes me a little wary. Doing work for some employer without getting paid is a red flag. It's not a total klaxon blaring, but it does raise eyebrows.
Spending 45 minutes working on "a contrived piece of legacy code" with an employee competent enough to evaluate your effort doesn't sound to me like "doing work" for the employer. I get what you're saying, though... I think if the evaluator were incompetent and you were solving an important problem for them (things that would be pretty obvious), it would be an awful interview. But hey, that's 45 minutes well spent if it shows you for sure that you wouldn't want to work there.
Pairing makes this seem less egregious to me, even if the company is getting some value from the process. In a traditional interview, both you and the interviewer would be spending the same amount of time, and arguably learning less about each other.

Asking for some work to be done off site before an initial on site interview, where the potential employer is getting something of value, would be a much bigger red flag to me, personally.

My policy for this is that we have a pairing exercise that either: (a) is on sample code that the candidate brought, (b) an open source project with the end-goal being a pull request, or (c) a Make Work exercise. I do not want to have a candidate working on our real code precisely because I do not want to have the charge of unpaid work levelled against us.
Well, to get to the point of being interviewed, you had to have some education (either formal or self taught, or both). This involved writing a lot of code (homework assignments, etc) that you didn't get paid for. And you had to write / polish up your resume, again without getting paid for it. And you had to drive to the site without compensation (unless the place is big enough to fly candidates across country for the interview). So why would actually demonstrating your competence raise a red flag? Either they like what you did and you get hired (in which case you are getting paid for the work), or they don't like it, won't use it, and it is no worse than putting a bit of work into a homework assignment that you ended up getting a C on.
A for profit company isn't benefiting from those activities, though. I can easily see a situation where a less than scrupulous company brings in a bunch of candidates to do this in order to get free labor.
I would hardly consider that "work".