If I can't see your work - you're crap

I dislike how this is trying to make this about oppression. In particular, the "or maybe they're female" toss-in is just dumb. Contributing to open source, blogging, and having a code portfolio are all relevant to assessing your competence as a developer. Being female is not.

Whether or not you have a github account and contribute to OSS is something you have control over (unless your previous employer prohibited it - but that's hardly your prospective employer's fault). If you're having trouble finding a job because you don't contribute to open source then... contribute to open source. Make a github account. Find some bugs. Fix them. Submit pull requests. A lot of projects could use the help.

I'm sort of thrilled, actually, that we live in a world where not contributing to open source is enough of a career hindrance that people are complaining about it. That's a trend that I'd like to see continue. I want "you need to have at least a few contributions to FOSS" to be the equivalent of yesterday's "you need at least some kind of bachelor's degree".

As for not having a code portfolio, well, if you're interviewing for a job as a photographer or a graphic artist, and you show up with a resume and a smile, you'll find yourself in much the same position. "Coca-cola really liked my photos" is only going to take you so far. This is a field where you can easily tote your work around, so of course potential employers are going to want to see it.

I feel like the complaint here could easily be applied to other things, like not having a resume or not showing up to the interview in your underwear. What do those things have to do with coding? There could be plenty of great coders who do those things, and you'll miss out on that talent if you don't give them a chance! Stop oppressing them.

That's legitimate, but you could always set up some repos as resume padding anyway.

OP has missed the point spectacularly.

There aren't just two developers in the world, there are hundreds. For those with published commits, I can assess quality of their code myself and see whether they actually know what they're doing within a couple of minutes.

A developer with only a CV is a pig in a poke. They might be a terrific developer, they might just be very good at bullshitting their way up the career ladder. Unless I know that the company they worked for has a very developer-centric culture, I'm probably safe in assuming that the decision to hire and retain that person was made by a non-technical manager. The message they're giving me is essentially "I can code, because someone who can't code says so". I have no way of distinguishing a genuinely talented developer from a bullshitter.

Why should I bother? Why should I spend half a day or more interviewing a candidate who can present no real evidence that they can actually code, when I can have my pick of people whose Github profiles are overflowing with quality commits?

>Unfortunately, this means that what potential employers are seeing is stuff that I've done in my almost non-existent free time, so it's generally unfinished, unpolished projects that had a really simple goal or were for learning a new language/framework. So, it's not necessarily a good indicator of what I produce when I can focus full time on a project.

That is a tricky situation to deal with. On the one hand, you don't want them to think that this is you at your A-game. On the other hand, the naive approach of apologizing in advance is just bad psychology. I don't have experience with presenting this to employers, but in general the best way to frame those kinds of things is to think not in terms of expectations (you actually want expectation high; people see what they expect), but in terms of objective context.

If you say "Here's something I did which really isn't me at my best, but it's what I had time for", then people will expect crap, and that's what they'll see. If you say "This is something I built in my free time", or "This is something I built while I was learning Backbone" (and keep you tone enthusiastic, not apologetic), then people will understand the context in which they should be judging what they see. If they're smart, they'll realize that seeing what you can do when you don't have much time, or when you're on unfamiliar ground, is at least as valuable as seeing what you can do under ideal conditions. If they're not smart, do you want to work for them?

>I've even tried a few times to get tools I've created released as open source, but the general response I get is, "uh, why?" I can understand that the companies see no value in it and in fact may cost them money if there end up being licensing or other legal issues.

That's hard too. It might help if you can come armed with some benefits of releasing something as open source, like the fact that other people will be able to find and fix bugs for your employer, which is basically free labor.

The problem is that a lot of us have lives outside of work, and work is proprietary software. I hit this problem in my latest job search. I had a limited presence on github and a rarely updated blog... if you'd asked me 4 years ago, I'd have nothing. Which doesn't mean I'm not a good coder. It means I have a wife and a family and non-coding hobbies, and I'm not 25 with the ability (or desire) to code until 2am every night. Luckily I had enough of an online presence that I was able to do a weekend coding project to prove to my (now current) employer that I'm worth hiring.

I think it's pretty safe to say that most professional software developers work for companies that do not open source their software. So, the majority of your time coding is hidden away. For anyone with a family, the rest of your time is pretty much taken up. To get work done on side projects, I get up at 5:30am... and haven't been able to do that since the birth of our second child.

Now, I 100% understand why people would hire #2. He/she is a known quantity. The other one, well, who knows? It's famously hard to figure out in an interview who will be a good coder and who will not... and it's incredibly expensive, both in time, opportunity cost, and actual dollars, to hire a bad developer. Not to mention the bad code that might infiltrate your codebase. So, playing it safe with #2 is usually not a bad idea. But, at least give the other guy a chance. If you like him in the phone screen and preliminary interview, give him some coding homework and see how he does.