[wink]

This sounds horrible. And I say this as someone who's been contributing to open source since.. like 15 years? What does meaningful even mean? I sometimes spend hours and days trying to reproduce and triage a bug, not even talking about fixing it. How is any reasonably sized open source project different than a closed source inhouse code base (ok, usually the docs are better or exist at all) - do they really expect people to spend multiple working days on a job interview?

If you as an interviewee happen to find the proposed projects interesting or be contributing anyway, it's actually quite awesome, but even a big open source advocate this hiring method doesn't really seem practicable to me.

[tetraodonpuffer]

> do they really expect people to spend multiple working days on a job interview?

if you read the article they say their previous interviewing practice was homework that took about a week to do (described as "high effort") so it does seem they are looking for substantial contributions.

From the perspective of spending a week on an ad-hoc coding effort vs a week on an open source contribution I can definitely see the value, especially considering that it seems it's up to you what you do (you are submitting your "this is what I did" together with your application and not "I want to apply"/"fix these github issues") which also means you can decide the effort level and most important when you spend it.

Reading the article it seems nothing prevents you from working on this for 3-4 weekends and then applying, which seems completely reasonable and honestly not a bad way to go at it. It really seems a win-win-win: for the company, they get to evaluate you as a candidate, for you, you have a meaningful contribution for your resume even if the application doesn't work, and for the open source ecosystem as a whole, which gets some bugs fixed or features added

I mean, these days to interview you'd still spend several weekends refreshing algorithms and practicing so as long as this is the whole of the technical interview and not just the initial part plus a day of whiteboard algorithm quizzes it'd be a nice alternative.

I am less sure about the "cooking together" part of the hiring process, but if that's the culture they want to foster I guess that's their prerogative, on the other hand I do believe this should be stated up front and not be a surprise, given how not everybody would be willing or able to partecipate due to dietary restrictions and preferences.

[timgdelisle]

Dietary restrictions and preferences 100% welcome! Grew up with a celiac sibling and one of our team members is vegetarian. Similarly to design, in food, restrictions lead to creativity! (Founder of the company)

[tetraodonpuffer]

thanks for chiming in and clarifying, best of luck with your hiring! as I was saying I definitely think it's a net positive for everybody to harness your interviewees' effort to improve open source packages that you care about as opposed to just wasting it on contrived exercises not benefiting anybody.

[timgdelisle]

There's also the fact that if more companies adopt this approach candidates could technically do a single open source challenge to apply to multiple companies :)

[wink]

Well they framed it as being better. I don't necessarily disagree on that part, but from a time investment pov.. doesn't sound better at all.

[timgdelisle]

The previous challenges were too time consuming. That's why we switched to this approach.

We intentionally left the prompt ambiguous in terms of what a meaningful contribution is. A meaningful contribution can be anything that the candidate justifies as meaningful. A single, really well thought out method contributed to a library that the candidate uses often can be all it takes.

When we assess the candidate we take into account the full package. Senior engineers with an extensive portfolio and multiple open source contributions aren't help to the same volume as someone who's fresh out of school with little experience.

[slyzmud]

For me it sounds awesome, what do you prefer: working on one real problem in an open source project or working on a fictional white board problem?

Think it lilke this: if you do a whiteboard interview, you have to solve the a problem each time you go to a new interview (loosing time in a problem nobody cares). But if you solve a problem in an open source project you can show it to every company you want to apply (and a lot of people will benefit from your contribution).

I would love this model to be more wildly used.