To walk in off the street and convince folks you've got the chops, talk intelligently and articulately about the things you've done, the how, the why, the tradeoffs and considerations and consequently talk to them about what their working on and ask those questions or intuit answers or, problems is a very hard skill to acquire.

When I started out, sure, I could write code. Decent code, and was willing to spend a lot of time writing a lot of it. Still, and as I like to describe it, I was a coder and not an "engineer"[0]. Knowing how to bang out Python scripts, or setup a Rails app, or some Hibernate entities is fine and probably a pre-requisite but the soft-skills of knowing how to operate within an organization are also incredibly important.

When you're fresh and starting off with no real experience, passion is about the best you can demonstrate at which point you can hope the folks on the other-side of the table are able to recognize that, and willing to take a risk. For all they know, you're a petulant little shit who can't hack it on the job site.

[0] - I still feel weird calling myself that since I know "real" engineers, but that's my title...

That's the point. If a candidate can't concisely state how they solved a problem or the effect of their having done so, then they likely didn't solve a problem in the first place.

The barrier to entry represented by using Github is incredibly low, so that isn't a differentiator between people in most cases. What was _accomplished_ by all those pull requests and managed repositories?

> Link them to patches accepted by open source projects? IRC conversations and emails? :) (now harder with all that slack thing)

In many cases, those are just about the least worthwhile thing you can do to convince a potential employer. Employers are busy, almost always busier than the candidates who are looking for a job. Make things easier for the employer, not harder.

Which is, you know, the modal case.