In fact some companies explicitly prohibit publishing code publicly without requesting special permission.

I don't think candidates should be excluded based on the lack of a github repo.

Its no that difficult to create a github project that can be completed in a weekend. I created the hacker new karma tracker and weedprices.biz in one weekend each.

But would you really make hiring decisions based on either of those projects? Software development is 'relatively' easy when your project is <1000 LOC. It becomes harder as the project grows. And it's the ability to grow the project what you should make the hiring decisions on.

Yeah but judging someone's ability to code by several good <1000LOC projects is probably better than the sorts of coding problems you have time to give someone during a coding interview.

That's actually a good point I have not though of before. I considered your Github account to be the place where you'd show off your l33t sk1llz, as opposed to show off code similar to the code you'd write during interviews.

Sure but then if this becomes a "must have simply to have the opportunity to interview" then it loses all the value it can have to reveal what the person can do. And I do believe some people have no time for this. Having worked at Apple for some time, I guarantee my sparse time, when there was some, was more outside of any coding and still I will never show outside a piece of code I have written in this company. This does not mean the coding skills I have should be considered as good or sufficient, they may or not match the one needed for a position. Having been also in the position to be on the interviewer side, especially in startup, seeing the candidate in person reminds often the deciding point.If some code on github exists, it simply can "speed up" a little this part of the process. Personally I found the "Smart and get things done" book by Spolsky a good read on how to conduct interviews

And I could copy them with minor modifications and claim I designed it all, in only a few minutes.

I agree, but I understand its part of the game played. I have 13 years of IT experience, but still contribute to open source projects on Github, as my day job codebase can't be released/be part of my portfolio.

As soon as things like that become "part of the game" they start losing their signalling value.

Exactly why I cringe at every one of these "my awesome interview tips/tricks/hacks/etc". The very fact that you publicly stated it makes it lose significant value. Most forms of testing are high value until the test becomes the goal, then its worthless. I guess having a handful of hits on their block one afternoon is more valuable to them than a useful hiring signal.

I would wonder why you don't like to release your code publicly, or at least have code samples ready to show. If I asked you for code samples and you didn't have any, I'd ask you to complete some work-at-home tasks, as I mentioned in my previous post. Those code samples would probably be enough.

If you refused to send me code samples, I wouldn't bring you in for an interview.

For example:

1) Work for a company that does not allow you to post code that you write at work (fairly common)

and 2) Don't have time / don't want to spend time on homework for an interview

Combined with: a) Do not code for fun at home

or

b) Code for fun, but in something so completely unrelated that it's not useful (8 bit microcontroller code, say)

or

c) Code for fun, but not seriously with any kind of quality

If you gate your interviews on who has public code repositories, you're missing out on a LOT of qualified people.

1) Not a problem and very understandable. I don't require work-related samples, just code samples in general. 2) Also understandable, but it's really no different than doing it on a whiteboard in my office. Might as well take 30 minutes to write some code in an environment where you're comfortable versus doing it on a whiteboard where you're under pressure, yes?

A would rule you out as a candidate for me. Passion is almost always a requirement. B would be acceptable -- in general, language doesn't matter. It's the ability to write code and explain it that matters. C would be a tossup. If you write crap code for fun, then why would you write better code for real? But I get that. Sometimes I write code for fun just to see if something works, and I never refactor it to make it more efficient or whatever. That's understandable. Again, it's more about the ability to master the basics to begin with.

I can teach you to be a better programmer, provided you understand the basics (which your code samples should demonstrate). I don't have time to teach you the basics (unless I'm specifically hiring an intern or something.)

Also, consider that in my original post, I said this is my process and how I do things. It has worked very well for me so far. I may rule you out, but I'm willing to bet that there are others equally as good (or better) than you that are willing to do what I consider to be far less annoying than the way interviews are conducted now.

I don't want to waste your time -- nor my own time. That's the end game here. By having code samples ready for me, you are eliminating a not insignificant amount of redundancy for both of us.

Sorry, but that's silly. We don't expect doctors to do amateur surgery at home. We don't expect pilots to fly their kids to school in a microlite, and we don't expect lawyers to sue people for fun.

"Codes for fun" is HR-compliant jargon for "20-something, no kids, willing to work unpaid overtime" and it'll be caught out as soon as some "sues for fun" lawyer can be bothered to mount a case.

Asking some one to work for free before you interview them does not give a terribly good signal as to how good you would be as an employer.

I'm not asking you to work for free. I'm asking you to provide code samples. There's a big difference. It's no different than coming into my office and coding on a whiteboard for me.

And for your other argument, I have a full time job but will sometimes take very short term (5-10 hours of work) contracts for interview purposes. Usually this is a last step before getting a job offer, more as a way to gauge whether I'd work well with the team than whether I can code in general.

It doesn't have to be for free. I know someone who would "hire" potential candidates for a 2-week contract, and based their skill on the code they write during that time. If the candidate doesn't end up getting hired afterwards, he still gets paid for his time. It's a win-win.

Doesn't work if you are employed already though.

In the case of my company, if you're not a fan of open source, you wouldn't have a place.