>This assumes that developers' off-work behavior is similar enough to their work behavior that it's a reliable indicator of their workplace performance. Or that developers should comport themselves on their off time to a workplace-level standard.

Actually I hold myself to a higher standard when writing open source - A) because I know everything is open to the world, and B) because I'm not under tight time constraints.

Nonetheless, there's no perfect project, and any employer that looked at a github project and was needlessly, ridiculously picky or made a presumption that there shouldn't ever be mistakes would end up just not hiring anybody at all.

>And if I'm learning a new technology, I'm going to be sloppy. I'm going to make mistakes. That's the very nature of learning-by-doing.

Only idiots expect a perfectionist. Thus if you try to make every commit an exercise in perfection you're only selecting out the idiots.

I'd actually far rather see incremental improvement (in code quality, documentation clarity & commit messages) than sheer perfectionism.

Also bear in mind that no matter how interested the employer is in you, the chances of them taking anything but the most cursory glance at anything beyond HEAD is very small.

Yeah, personal projects could be sloppy, as it's mostly for learning new technology. And it may also be unfair to say that a good programmer always produce clean code, no matter the reason for development.

But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he/she has motivation to do best. If the employer can just ask the candidate for that project, and the candidate can show that project in a public or private repository, this would give really important insights to the employer about the candidate which would be beneficial for that both.

Also, this doesn't mean that the candidates who doesn't have public repository to show have any disadvantage, they are at the same point. Its just that the candidate who is able to provide a project of his choice through public repository would be a few points ahead other candidates.

>But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he has motivation to do best.

For an experienced developer, that would be a workplace project, which you probably could not see. Indeed, it _should_ be a workplace project; would you hire a professional developer whose best work is their personal project?

But if what you're saying is that the mark of an ideal developer is one who has produced a personal-time product of professional quality, where every checkin is to workplace standards, and has developed the project from conception all the way to release, again all on personal time, then what you're asking for is not a developer who also codes as a hobby, but a developer who (at least part of the time) works two actual jobs. One of which they do for free for portfolio development. I don't find that to be a reasonable expectation, even if it would give employers "important insights".

When I was writing this, I actually had only new grads in my mind. You got me there. But, I think this would especially helpful incase of recent graduates. What I am trying to say is that if a candidate can show the life-cycle of some academic/personal project in a public/private manner, it would help the employer make a better decision, which will inturn benefit the candidate.

> But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he/she has motivation to do best.

Were I to have such a project that I could show to people, it would be for a company that I had founded and as such despite my having the ability to show it, I would have absolutely no incentive to do so.

Basically if I had EXACTLY everything you purport to want in an employee I would be entirely unmanageable. Someone who has not only the skill and ability to turn out such a project but the motivation to do so on their own time is probably the definition of a founder. And founders are often terrible employees.

So while you're right that it would theoretically be better for candidates to share their codebases with potential employers, in practice I suspect that it rarely happens.