I'm a tech lead who does interviews and makes hiring decisions for Rails developers, and I completely understand your sentiment, but I encourage you to push past that and publish anyhow.
More published code is better than less published code irrespective of quality, because it tells me that you're engaged and devoted to your craft, and it gives me a sense of what projects and technologies you're interested in and have been exposed to. Additionally, publishing code gives me a way to see your progression through the craft, and to get a sense of not only how developed you are as a programmer, but how you're growing.
A junior programmer who shows growth and improvement is a much better hire than a junior who is competent but shows no growth. When I hire people, I want to hire people who will grow into strong senior developers over their career, which means that I'm primarily looking for ability to learn and grow rather than a specific buzzword checklist. Hiring a junior comes with the expectation that I'm going to have to train and hand-hold them, but I want to hire a junior who will progress out of that stage, and will be able to start taking care of those things for new hires down the road.
Publishing code on Github doesn't mean that you're asking other people to use it; it just means you're publishing it. A Github profile on a resume is a +1 for me; a Github account with a lot of forks is another +1, an account with original code is yet another +1, and an account with original code that other people use is the big cherry on top. In all cases, though, I'd rather see an active account filled with "noobish" or "messy" code than an empty account.
I'm curious about GitHub and the code you review. Like many, I can hate my own code and sometimes feel that it will be used against me in a hiring process. So I guess what I'm asking is how much does it count against a potential hire that they have bad code and/or bad ideas on GitHub?
> More published code is better than less published code irrespective of quality
This is the path I try to walk. I'd rather put something out there than nothing at all.
Crudely speaking, no code < bad code < good code. However, what I tend to be interested in is curiosity and improvement in the case of a junior programmer. One technique I've seen that's worked well with me is for the applicant to list their 3 favorite repos on their resume, which guides me towards looking at them, rather than just poking around randomly at the "bad stuff".
As an interviewer, I don't care that you've written bad code in the past (any developer who says he hasn't is lying). I do care that you have written code up to the standard of the job I'm hiring for (which is going to be quite lenient for a junior position), but I'm mostly going to be looking for cues demonstrating improvement and curiosity. The more technologies, languages, and concepts you touch, the better. To me, your Github profile is a showcase of your interests first and foremost.
I'm much less interested in hiring someone for their hard skills than I am for their potential. I can hire outsource hard skills for pennies on the dollar; what I want are people who can become proactive owners of the projects they're on, not just code monkeys who turn specs into code. For example, one guy I hired saw that we were looking for a dev with front-end chops, so he re-coded his resume with backbone.js just to show off a bit. This caught my attention, not because of his ability to write Javascript, but because his proactive solution to the question of "how do I get this company to hire me?" told me that he was the kind of person I wanted to work with, not just that he had a specific skillset that I could hire.
Thank you for an informative response! I'm gonna keep this in mind when I start applying for jobs. Currently I spend evenings and weekends programming and learning on my own.
More published code is better than less published code irrespective of quality, because it tells me that you're engaged and devoted to your craft, and it gives me a sense of what projects and technologies you're interested in and have been exposed to. Additionally, publishing code gives me a way to see your progression through the craft, and to get a sense of not only how developed you are as a programmer, but how you're growing.
A junior programmer who shows growth and improvement is a much better hire than a junior who is competent but shows no growth. When I hire people, I want to hire people who will grow into strong senior developers over their career, which means that I'm primarily looking for ability to learn and grow rather than a specific buzzword checklist. Hiring a junior comes with the expectation that I'm going to have to train and hand-hold them, but I want to hire a junior who will progress out of that stage, and will be able to start taking care of those things for new hires down the road.
Publishing code on Github doesn't mean that you're asking other people to use it; it just means you're publishing it. A Github profile on a resume is a +1 for me; a Github account with a lot of forks is another +1, an account with original code is yet another +1, and an account with original code that other people use is the big cherry on top. In all cases, though, I'd rather see an active account filled with "noobish" or "messy" code than an empty account.