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.