That whole section needs an alternate. Enough people are NDA etc. bound that you're going to have qualified people who literally can't do this step. Many people don't have large software written in the public domain or do not have anything showable because they don't have access to the source anymore. It'd be awesome if everyone had enterprise level software on GitHub, but that seems an unfair requirement to show technical competency for closed software.
We accept any kind of code, be it a kata made during a workshop or a side project... really we just want to talk about code that the candidate wrote previously. It doesn't need to be large to have interesting tradeoffs made
Why? You already gave the candidate a "take home assignment". That assignment should involve interesting trade-offs. If it doesn't, tweak it until it does. Why not discuss that code?
I'm the kind of guy who still likes to code on the side, at home, for fun, after all these years, but I'm also aware that not everyone is like that. Maybe that's one of your filters -- maybe you're looking for people who prefer coding to be 90% of their lives -- but that would be a big red flag in my book. I've seen too many companies who think that they are entitled to employees who will give them everything for next-to-nothing in return.
Sometimes we do discuss this code if the candidate prefers. But it's still a somewhat "fake" code made for the only purpose to apply at the company. Most people would find it more interesting to discuss code they spent weeks on.
Finally we are not looking for any specific profile, but so far almost every person found a piece of code to share from their career. We don't get thousands of applicants, so maybe we're not seeing the issue just yet. If it turns out to be a problem, we'll change the process :)
>"We accept any kind of code, be it a kata made during a workshop or a side project"
>"But it's still a somewhat "fake" code made for the only purpose to apply at the company"
The code I write for side projects is not "production quality" because I do it for my own entertainment. I would never feel comfortable showing it off in an interview because it doesn't represent me professionally. All of my positions have been strictly closed-source.
Additionally, the code I write for side projects is usually unlike the work I'd be doing professionally. I'm a web developer but most of the side projects I work on are either dinky little video games or open source hardware.
I'll cede that I do find my side projects more interesting to talk about but I generally try and write "high-ish quality code" (not "fake") for the take home interview projects that I've had to do.
As I mentioned in the article, we don't expect the code presented to be "perfect" code. If you've managed to get a side project running very quickly thanks to tradeoffs you've made, it's also interesting. It's really just a way to have a place to discuss choices.
That ignores the class of FOSS people I like to call the "fixers", the ones that will spelunk a code base because they have a problem, find the 10 line fix that fixes their issue and never come back to the project again. Those 10 lines were probably very useful but doesn't show any larger design ability, despite that being a thing the candidate may be very good at, or large enough to garner a gauge on how that person sees code. Also consider the people who have never contributed to open source because they leave their work at the door. This is all your prerogative on how you want to run this, but I was personally put off reading that section, despite having a good idea what you're looking for. out of it
Yes it's true that it doesn't fit all use cases. However I would see looking at a few of the fixes you're talking about as an interesting technical interview.
