The other day in a meetup related to Hacktoberfest, a beginner programmer asked what would be more valuable: creating a pet project or OSS contribution. If I were a hiring manager, I’d prefer the latter, ability to do an independent job is of big value. With pet projects, especially when there is a chance to copy&paste solutions, you won’t be able to assess such quality.
It depends where they are in their journey. The right answer is "both" because each implies different skills.<p>Working on someone else's code base, and contributing value to it, is probably what your job will entail. So demonstrating profiency in that area is no bad thing. Being able to articulate that goal, and the lessons gained from achieving it will certainly help in an interview.<p>Bonus points if you strike up communication with the author and get their input on what they would like done. Communication skills are critically important in any new-job context.<p>Aside: willingness to write docs and tests while learning a new system will both improve your understanding, And improve your skills at the same time.<p>Building your own project shows a different set of skills. Identifying a problem (even if its only a problem to you), scoping that problem (avoiding endless feature creep), executing the solution and so on are all great in an interview.<p>Again, while this is great, articulating it in an interview is where the value lies. Be honest about the challenges, what you learned, what you would change. Too many programmers think getting their first job is based on programming skill. Of course that's a big part of it, but a bigger part is communication skill.
It doesn't matter. As someone involved in hiring decisions for developers, all we cared about was whether the candidate did something for himself or not. Because if he does, in our experience they're much better developers. Candidates who don't usually only take on the job for the benefits, but don't actually have any interest in the craft.
Both would be good. My experience working on open source projects involved months of working with the maintainers and community to reach consensus on designs and implementation details. That is a very useful skill, but you aren't going to get that on a pet project. On a pet project however, you'll get to see what they can do when they move fast which will give you better insight into their engineering capabilities.
Sure FOSS proves their ability to work in a team, but you also have to consider that, generally, FOSS contributions will be less impressive due to the limitations of working in a group - in a long term project all the cool stuff is usually done and you need to get approval for big changes. That means your FOSS work is more likely to be stuff like bug fixes, UX changes, maybe a new export format.<p>Then compare that to a pet project where there are no limitations apart from what you’re capable of, so I think naturally people will be driven towards that so that they can do whatever their vision is.
Personally, I could accomplish a lot more things across a broad category of technology doing a side project than OSS.<p>I love the FOSS community and pushing things to better a project is great. However, if it’s not something I’m deeply invested in, OSS can be very time consuming, just like a regular job.<p>If you were the hiring manager, I would expect you to have the skills to objectively evaluate the value of a project on a CV whether it be FOSS or pet.
Either is fine IMO. I'd personally be more interested to have the person walk through their decision process than seeing the end result. Always fascinating to have someone explain it. If they copied and pasted it and hadn't been forthcoming it'll be obvious once the discussion gets to the meatier parts.
I hope one day we can accept that there's a tiny bit more nuance to hiring developers than "x good y bad". Or maybe one day, with AI, writing software will become so simple that "x good y bad" will actually be a reasonable way to evaluate a dev.
I'm a "both" person, but for hiring, this absolutely shouldn't be a requirement? Not everyone has time available - or inclination - to work on side projects or Open Source, so should be hired based on their work in their working hours