As someone who used to be very pro-self-taught programmers, I changed my mind after actually working with some (and having to maintain the code of others). Most of the ones I've run into have holes in core skills that are taught as part of a CS degree, like threading, pass-by-reference vs pass-by-value, DB normalization, separation of concerns, basic optimization, etc... To be fair a lot of CS grads haves holes too (including me), but at least you can assume some sort of base to work from. I'll never forget the blank stare from one of my self-taught coworkers when I tried to explain that it was a bad idea to try to do a full parse of a Turing-complete language with just regexes. He seriously thought that if he just tweaked his regexes a little more it would work.
Also, working on code in a team is very different from working on personal projects alone. It adds in a whole bunch of things that aren't necessary on personal projects. You don't just need to know how to use a VCS but how to use it in a way that won't cause headaches for your coworkers. You need to know how to write code that people other than you can read and maintain it. In many cases you may be responsible for drawing out requirements from users. You need to communicate effectively with the rest of the team. None of these skills are exercised or put on display by your typical github repo.
So, personally, I can see why someone would be very hesitant to hire a self-taught programmer with no experience. If someone has a degree and a little job experience, you know they at least know enough to pass their courses and survive in a team environment. With the unknown guy, you need to do some very rigorous testing to make sure you're not getting a dud. A lot of companies might not have the resources to do that.
I appreciate the thoughtful response and I don't really disagree with you on any of this. In fact, if I were interviewing for positions, I'm not sure I'd handle it any other way -- it's human nature to choose the "safe" option -- but that doesn't make it right or optimal. But it's also taken to an extreme: I have a BS in CompSci (from 12 years ago), but "never been a professional coder" almost always outweighed everything like a fat kid on a see-saw. It's a double-whammy: not only are they looking at self-taughts harder, self-taughts are naturally going to be less comfortable with best practices, lingo and other general experience they'd pick up in a month's time on the job.
In trying to put my thoughts into words here, I found it easier to whip up some pie graphs instead.
Damn! I forgot to include "Do you have exp with the company's stack?". Oh well. That's more about getting the interview in the first place, so I guess it's ok.
Why is it a bad idea to parse a Turing-complete language using regex expressions? I have implemented the XScript language from Age Of Mythology and AOE3 with that approach; it seems to be quite efficient and flexible, is there something I should look out for?
(This comment is pretty informal; if you want to know more, look up terms like "context-free grammar", "Parsing Expression Grammar", "Backus-Naur Form", "regular language", or even "formal language theory".)
The problem is not "Turing-complete" (roughly, "can express arbitrarily complex stuff"), but "context-free" (roughly, "you can parse without considering what you've seen so far").
For instance, Brainfuck is Turing-complete (in the "Turing tarpit" sense) but really easy to turn into tokens (in fact, an informal approach may not even distinguish between "+" and "the token 'increment'"). Even realistic languages like C can be parsed without using anything much more advanced than regexes (you need some ugly kludges to support typedefs, and you should pretty much ignore newlines; one would typically use something more like yacc, but that's still not a very sophisticated tool.)
On the other hand, XML or HTML (which are not Turing-complete, and, informally, "not that expressive") are pretty much impossible to usefully parse without extensively considering context - <a><b /><c /><d /></a> gives and <e><d /></e> are "very different <d />'s".
I don't know XScript, but regexes may be a completely viable approach. In fact, if your current approach works, it's likely good enough - it requires some theoretical background to express why you can't parse HTML with regexes, but you'll run into lots of trouble if you try (leading to stuff like http://stackoverflow.com/questions/1732348/regex-match-open-...). Of course, there's value in finding out your approach won't work before you've spent weeks of effort. ;-)
Also, working on code in a team is very different from working on personal projects alone. It adds in a whole bunch of things that aren't necessary on personal projects. You don't just need to know how to use a VCS but how to use it in a way that won't cause headaches for your coworkers. You need to know how to write code that people other than you can read and maintain it. In many cases you may be responsible for drawing out requirements from users. You need to communicate effectively with the rest of the team. None of these skills are exercised or put on display by your typical github repo.
So, personally, I can see why someone would be very hesitant to hire a self-taught programmer with no experience. If someone has a degree and a little job experience, you know they at least know enough to pass their courses and survive in a team environment. With the unknown guy, you need to do some very rigorous testing to make sure you're not getting a dud. A lot of companies might not have the resources to do that.