In my company we go one step further: We encourage the candidates to „bring their own code“. Then we let them explain their code, discuss possible issues, extensions and so on. Usually simply from looking at the code style one can infer a lot about the candidates level of skills. Also the candidates are less nervous and are sometimes really enthusiastic explaining their favorite side project. All in all it leads to a quite good interview experience for the candidate, but also for the interviewer.
I have a lot of weekend-ish side project on github (e.g. http://aperocky.com/cellular-automata/), but I also know a lot of capable engineers that does not have that. One of my favorite thing to look at for a candidate are their github, but unfortunately more often than not people don't have it or only CS-X01 repository exists. The interview is in no way affected by this as it is not an indication of weak technical ability.
But if someone does have it, it does get looked at, at least through me.
My bet is that it doesn't work. My experience is that they are assuming that, just like those recruiters and hiring managers that look for “an active github” and swear by that
If you can write software, have you never once encountered a bug in something you use or a tiny feature that would have made your life so much easier + just done it yourself?
I understand not wanting to do a ton of weekend projects and having other hobbies, but it's wild to me to think that being able to do these sorts of things but never doing it happens.
It's sort of like a car mechanic who doesn't fix/tweak his own car.
A car mechanic isn’t evaluated for a job by whether they fix their own car as a successful one may own a luxury car that must be serviced at a specific location.
Since analogies compare dissimilar things with at least one similarity, I think you lost the one similarity and undermined the point you thought you were making
What does a programmer seeing a bug have to do with this conversation? What exactly are you imagining? I’m imagining how silly it would be for me to run a custom version of a chrome extension that wont get any updates just because I didnt like how a feature was implemented, I’m guessing you are imagining something else?
Submit a PR to whatever tool it is you use that fixes the bug so it stops bothering you
Build some small tool to automate a task that you have in your daily life
Write a program based around one of your hobbies that caters to something niche so there's no good tools for it already
Anything of this sort, I guess.
I do a lot of open-source work but it's selfish -- I submit those PR's because they are things I wanted/needed and it would be silly for me to have a fork and try to keep it up to date with master.
Maybe it's different for other people but I constantly run into bugs/missing features in tools I use for both job and personal stuff. If I didn't do this there would be so much I'd have to hack around or flat-out wouldn't be able to do.
Submitting a PR runs into the most random etiquette expectations from a gatekeeping project maintainer that arbitrarily chooses to not merge
It requires a lot more effort and back and forth than you are describing and its disingenuous. I’m glad you’ve had a good experience with it though.
Writing an automation tool often has nothing to do with the experience and acumen required for a job, it could be a mouse motion recording to a bash script. It requires pure happenstance or contrived altruism to do it in a worse language for the task just to say “see look what I did” for a future employer
I think this requires more empathy, not in an “emotional intelligence” sense just in the concept of putting yourself in other people’s shoes and imagining what they encounter instead thinking what you encounter is normal
Would make sense to provide it as an option, and approach candidates without side projects in a different way. I would much rather show up with code I've already written and use that as a starting point for conversation.
