I have a GitHub repository with toy programs that I write when I learn something. For example, when I read an about an algorithms or data structures, I write up a quick implementation of of it to make sure that it works and I understand it.
I sometimes solve algorithm and data structure puzzles and that gets pushed into the repository.
Would this repository be worth linking on my résumé, or would it actually be a detriment to my chances of getting hired?
I once heard a résumé described as "a balance sheet that shows only your assets but not your liabilities".
Based on this definition, you want to include projects that will be an asset to you in getting the job while leaving out those that might be a liability. This means they should be relevant to the job you are applying for and show off your best work. Even if you consider your code "toy programs" this doesn't means they can't be well structured. Hence, don't include throw-away code or dirty hacks. Keep those in a private repository. And of course you should be able to talk about your programs, the design decisions that went into them etc. I once had a candidate who claimed to have done this awesome project a year before, but then couldn't tell me anything about it. Not so good.
Remember, a resume should be developed with the interviewer in mind, and most people don't want to have to sift through a treatise just to determine if you merit an interview. They want you to provide the most relevant information concerning the position in a concise manner. This requires careful prioritizing of content. I tend to customize my resume by position so-as to best highlight relevant information, and I believe this is a reasonable approach for this particular question.
If you're applying for a low-level, general developer position, then a broad range of programs could be useful. Maybe one of the toy programs illustrates the moment you finally "clicked" with javascript prototypes, or when you studied the your first LISP. These could be beneficial.
However, if you were applying for a position that required you to build compilers for national defense systems, the earlier-stated examples would be of little help to the interviewers. They'd be much more interested in other types of background information (compiler projects you've contributed to/lead, etc.)
All this to say, I would try to gauge the relevance of the toy projects to the current position. If they seem relevant to the current position (e.g., position requires git competency, position requires general predisposition to autonomous learning, etc.), then I would include the repository. Otherwise, there may be more important information that can be highlighted.
Don't put anything on your résumé that you don't feel comfortable having someone examine with a critical eye. Likewise, don't make a potential interviewer have to dig through the repository to have to find the good stuff, you are better off having a small repository with some well written libraries or code snippets then you are having a full blown application.
If you do provide the link to a repository, make sure that there is a clearly defined README file that can point people at the interesting parts of the code that you want to show off as well as a brief overview of exactly why things are the way the are. If you disclose the link early in the hiring process you may not be around to justify your design decisions so a README may be explaining things on your behalf.
One of the benefits of making code available for employers is that you can use it to screen your opportunities.
A job interview is bidirectional; Not only is the employer assessing the candidate, the candidate should also be deciding if they actually want to work for the employer.
When an employer makes an offer without first having actually seen the programmer's work, there's a very good chance that the same process was used before, to hire everyone else. A job seeker should probably be very wary of accepting offers when there is no obvious reason why a non-programmer should have been unable to qualify for the same position (because there surely have been)
Of course, most employers do ask for the candidates to produce some code; and it seems to usually be in the form of "write a function on this whiteboard" or if you're lucky "write a function on this unfamiliar workstation". Though this can do a reasonable job of separating out the candidates that really can't even write "Hello World!", it becomes much less informative about the difference between who can write good code from who can keep their cool in an interview.
And so many (though far from most) employers are eager to also take a look at the kind of code a programmer can produce when they are in their ideal setting, working on what they want to work on, and without any particular guidance.
To make the best of it, it's a good idea to offer the code even before an employer asks for it; If they just aren't interested, find another opportunity. If they are interested, tell them which projects you'd like them to look at and why (and also explain why you don't think some of the other projects are as representative, for instance you were learning the framework out of a book). Then ask them what they thought about what they saw when you next talk to them.
If you think of it as a portfolio then yes, I'd recommend putting that link in your CV. I do.
A resume has exactly one purpose: to advance you to the next stage of the hiring process. Anything that impedes that purpose is a bad idea. As a former hiring manager, I can tell you that the amount of time I had available for any single candidate during the initial screening process did not allow for more than reading the resume and deciding whether to shred it or not. Folks who sent me 7-page resumes (really!) didn't get the attention they desired. Folks who sent me resumes that were primarily URLs didn't either. Later, after I was more-invested in the remaining candidates, perhaps.
A portfolio is a Good Thing. That's especially true in certain aspects of our business, like web design. But except if you're a Graphic Artist, your portfolio shouldn't be your introduction.
