Note: I originally posted this reply about 2 hours ago and then deleted it. But actually, I think it's worth leaving up.
I really respect Joel Spolsky's accomplishments (I've mentioned him recently in my own comments), but I found the blog post you cited wrong at best and offensive at worst. It perpetuates one of the most frustrating things I experienced while job hunting: the stigma of unemployment.
Even though I voluntarily left my last position, companies looked at my candidacy very skeptically. Things I was told by companies:
- "To be honest, we think you're an entrepreneur just looking to make enough runway to move on to the next thing."
- "Well, we're really impressed with you and you have the technical chops, but we're concerned that you like to think on a higher level and might tire of the daily nitty gritty." (Not true, and basically the same as above.)
- "You did well on your coding interview, but we've got enough candidates in our local area that we've decided to restrict our search to it." (i.e. relocation jitters. Not coincidentally, when I finally found a position, it was in my city.)
There are also people who are competent programmers, but come from strange backgrounds, like the music major-turned-coder who posted the other day. I, personally, am almost entirely self taught, haven't worked with other engineers and have only coded on my own projects (you can see my github if you want). People making hiring decisions are scared for their own jobs: they don't want to be the guy who hires the guy who never had a "real" coding job before. If it doesn't work out, I can see where that would come back on them pretty hard. (Conversely, having worked at Google or Apple is a major bonus for the opposite reason.)
Oh, and plenty of people underperform in on-the-spot coding interviews. Some people are affected much more strongly than others by anxiety. It goes both ways. I've read hiring managers on here gripe that they hired someone who interviewed well but sucked in reality. And my guess is it goes the other way, too.
So I find his assertion that people actively looking for work aren't the ones you want to hire incredibly naive, elitist and just plain wrong.
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. ;-)
To take the other side of that argument, as someone who has seen hundreds of resumes and interviewed hundreds of developers in the past, you do have a challenge in front of you to overcome the "never had a real coding job" stigma. Focus on your strengths when selling yourself (like, being a totally awesome rock star developer who can tackle any challenge).
The stigma is real and you can't fight it on those terms. But you've got other qualities that people want, and you can "win" those interviews if you can get that point across. Make your resume scream "rock star coder".
I really respect Joel Spolsky's accomplishments (I've mentioned him recently in my own comments), but I found the blog post you cited wrong at best and offensive at worst. It perpetuates one of the most frustrating things I experienced while job hunting: the stigma of unemployment.
Even though I voluntarily left my last position, companies looked at my candidacy very skeptically. Things I was told by companies:
- "To be honest, we think you're an entrepreneur just looking to make enough runway to move on to the next thing."
- "Well, we're really impressed with you and you have the technical chops, but we're concerned that you like to think on a higher level and might tire of the daily nitty gritty." (Not true, and basically the same as above.)
- "You did well on your coding interview, but we've got enough candidates in our local area that we've decided to restrict our search to it." (i.e. relocation jitters. Not coincidentally, when I finally found a position, it was in my city.)
There are also people who are competent programmers, but come from strange backgrounds, like the music major-turned-coder who posted the other day. I, personally, am almost entirely self taught, haven't worked with other engineers and have only coded on my own projects (you can see my github if you want). People making hiring decisions are scared for their own jobs: they don't want to be the guy who hires the guy who never had a "real" coding job before. If it doesn't work out, I can see where that would come back on them pretty hard. (Conversely, having worked at Google or Apple is a major bonus for the opposite reason.)
Oh, and plenty of people underperform in on-the-spot coding interviews. Some people are affected much more strongly than others by anxiety. It goes both ways. I've read hiring managers on here gripe that they hired someone who interviewed well but sucked in reality. And my guess is it goes the other way, too.
So I find his assertion that people actively looking for work aren't the ones you want to hire incredibly naive, elitist and just plain wrong.