On average, who's going to be better at writing code, the one who has done a side coding project in the past 10 years whilst developing, or the one who hasn't but only worked a job? (assuming everything else is equal) - The one who has more time for side projects might also have more time for work, too. Unfortunately, it does remove good people, since not everything else is equal.

IMHO It's still better than leet-coding questions because most developers don't need to use the skills gained from practicing leetcode when at work, whereas open source contributions and projects are valuable. Also, someone with no time outside work and family would struggle with both leetcode and having side projects.

> On average, who's going to be better at writing code, the one who has done a side coding project in the past 10 years whilst developing, or the one who hasn't but only worked a job?

You’re clearly leading toward the former, but I could just as easily make an argument for the latter.

In my experience, people with edifying jobs (usually because the problems are harder), are less likely to need to scratch the same itch outside of work.

I think requiring side projects not only shrinks the candidate pool, but also leads to adverse selection.

I've hired about 25 developers so far. So far, the 8 developers out of those 25 who had actual side projects (even not production ready and with caveats they told me ahead of time) have ended up being head and shoulders above the others.

Of course, there's not enough data to make a foolproof conclusion but I'd say that so far for me, having side projects that a dev can show is a clear indicator that they are an interesting candidate.

And when counting side projects, I count tools developers make to make their life easier and in my experience even great developers with edifying jobs will have situations where they create some small tools to help make their life easier.

But time is the important part here - a single parent raising two kids is not going to have time to code at home versus a twenty-something year old with no responsibilities and dependants who has an abundance of free time. Selecting in that manner can also end up being a discrimination (those from poorer backgrounds are more likely to need to care for relatives, same goes for women, who on average do ten hours more of unpaid care than men a week)

I just can't understand the worldview differences of some interviewers.

Everyone has a finite amount of time, they have other shit to do. The vast majority people irl just code for work. Are they bad programmers? Of course not.

I would say for the average employer paying an average salary, demanding you to showcase a portfolio of hobby project is plain obnoxious. The interviewer can hope the interviewee does some hobby projects and lives and breathes coding but demanding it as a baseline assessment for an interview is absurd.

For the average programmer when they have absolutely have nothing else to do maybe they will work on their sideprojects which even takes a backseat because they have to keep learning new crap every other week to make sure they are up to date.

> The one who has more time for side projects might also have more time for work, too

So you’re expecting people to work more than 40 hours a week?

You can't really make that comparison between individual developers though as there is just too much variability between jobs and companies. Some people are able to fully invest their creative capacity at their job and there are others that don't because either their job doesn't allow it or they have interests that are distinct from what the job requires.

Everyone in this thread seems to be hung up on sharing code from an employer or 'good code'.

You could clone an open source repo and use that if you're worried. The value isn't the code; it's the conversation.

"Bring your own code" is just meant to put the interviewee at ease because they are already prepared to talk about their own code.

> You could clone an open source repo and use that if you're worried. The value isn't the code; it's the conversation.

Open Source code plagiarism is a major problem and doing random forks/clone of popular repos to up your github cred is a thing and in my opinion it is unethical. Even if the interviewee tells you it is an open source project you will have a hard time distinguishing their code and the code from the original repo.

I think the interviewer should show their own production code and ask the interviewee what they think and what suggestion they have to offer. If you are not comfortable showing your own production code ask the interviewee to explore an open source codebase.

The "Show me what you got" approach puts way too much unjust pressure on a candidate and might force them to chose unethical means just to impress you. Then again if you want be impressed and if it is working so far for you, ignore my whole argument.

Who said th ex interviewee must present 'own' code there?

The conversation can just as well be around a library, product or system that isn't authored or contributed to, by the interviewee.

'What architecture is used here, and what are the down and upsides in this implementation'. 'What would you do different'. 'Which part do you admire, and what don't you like'. Etc.

Don't you think it is implied?

Also why would I voluntarily talk about codebases authored by anyone other than me while having in-depth knowledge about it? Nobody looks under the hood of things that interests them, let alone be critical of it’s design.

Talking about product and system design is something that is vastly different than stand-alone codebase. If you as an interviewer are interested about something you have the capacity of directing the conversation flow toward that. Ask them introductory questions about a product/system, gauge their interest in it then ask their opinion about it.

> Nobody looks under the hood of things that interests them, let alone be critical of it’s design.

Do you honestly believe this?

Many people do this. I do this. It's the best way to learn¹. There are repeating Ask-HN threads requesting for "high quality Open Source Software to learn from" for example.

¹Edit: on second thought: probably not the "best" way. Not for me, anyway. Just a good way.

Folks were responding to "Bring code you've written" which is different from just bringing some code.

> Everyone in this thread seems to be hung up on sharing code from an employer

Probably because you said “Bring code you've written”

I'd still show them my bad code, since I do pretty much the same thing. It would be a good opportunity to show how I'd refactor the side project if I could dedicate more serious time to it.

This is definitely a concern. I've previously worked for e.g. eye bee... and despite having written massive amounts of code in c, java etc, I'm probably violating some major NDA if I show any of that code, or discuss details of a first-in-the-world active-active HA cluster solution in the 90s.

By comparison, my github or personal code would be just a bunch of perl, rexx, sh/bash and python scripts written just to automate some work. I doubt anybody would think those should be cleanly written, highly maintainable, modularised, etc...

" just a bunch of perl, rexx, sh/bash and python scripts written just to automate some work. I doubt anybody would think those should be cleanly written"

I do. Even though my quick and dirty scripts are not always clean either, I still profit from the times when I take some more minutes to document what a certain script does and clean out at least the rough edges.

Otherwise it means rewriting the same thing again and again, which costs more time in the end. Or it means executing something you barely understand yourself anymore, which can be dangerous.