Hacker News Reader

Comment by scardine | Hacker News Reader

My companies do something a bit different: we ask people to pick any issue from any opensource project in our tech stack and try to land a patch closing it.

We think this is better then wasting the candidate's time on a toy project - at least the can write off their time on the opensource-karma account.

Also, we can check not only their code but also their communication style and other skills that matter in the real world (projects on our tech stack have a high threshold for documentation, unit tests and other stuff that matters).

We call it "social code challenge" and it is working wonderfully for our recruiting process.

View on HN

I basically like the approach, but I'm a bit wary after playing devils advocate with it for a moment.

A candidate might reasonably assume that they can look better than the other candidates by spending more time on the problem and tackling a larger or more impressive ticket. If you imagine a world where all interviews were like this, candidates could end up working 60 hours a week on these projects in the normal course of job hunting (easier to imagine if you assume that the talent shortage isn't permanent). Probably, since they can see the size of the contributions made by previous candidates, the pressure increases over time as well.

edit: it would be amazing for FOSS in general though. Imagine how much faster GNOME would be if hiring committees required you to write bug fixes for popular projects.

> A candidate might reasonably assume that they can look better than the other candidates by spending more time on the problem

The same is true with a take-home, candidates see the (often underestimated) statement "this should not take more than X hours" and assume they will have a better shot if the invest more than the X hours.

I forgot to mention that we also accept past contributions - in the end the hypothetical candidate can spread this 60 hours investment over any other hiring processes using the same method.

I'm thinking about writing a "social code challenge manifesto".

Many employers coming looking for D programmers to hire have looked at accepted D contributions to the Dlang repository. It's a great way to build one's resume and find great people.

Exactly, many people complain about about not being hired because they lack experience and they can't build experience if they are not hired.

My advice is always "build experience contributing to FOSS projects in your spare time".

We are pushing the envelope and often find bugs or lacking features. I want to hire people that can fix/implement those and send the PRs upstream instead of nagging the project maintainers.

There are no gates in the D community. Anyone can contribute. Of course, for contributions to be merged the bar is pretty high.

Seems like a good approach but beware "any issue" that's really a decoy filed by applicants aware of your hiring process. Unlikely yes, but worth considering, if only to appreciate the initiative behind such ruse.

Love this, especially with evaluating not only code but how well they collaborate. Ideally if the candidate had already submitted such a patch they could just explain it.

Exactly. And it is way easier to fake a resume than fake public reputation. For example, looking at a stackoverflow profile I can tell if someone knows how to ask and how to answer (a good question is 90% of the answer).

[1] https://stackoverflow.com/users/22656/jon-skeet

[2] https://stackoverflow.com/users/444036/paulo-scardine

That’s a really great idea. Only issue is it’s harder to compare between candidates but a little common sense would probably solve That.

This is real smart. I think more company should do this

Reply on news.ycombinator.com