A minor heresy: If you're doing it right, there won't be a coding challenge at the job interview. For that matter, there probably won't be a job interview, at least not in any recognizable sense of the term.
I mean, the author is entirely right: skilled devs can write their own ticket in this market. So, um, let's start doing that.
I also continue to think that "I have code on Github" is believed to be a career enhancer not because this is actually true but because it is something that is convenient to engineers to practice. In real life, the people whose decisions matter a) often can't read code and b) almost always have better uses of their time than reading code from someone who is, statistically, not likely to be hired.
I mean, the author is entirely right: skilled devs can write their own ticket in this market. So, um, let's start doing that.
I also continue to think that "I have code on Github" is believed to be a career enhancer not because this is actually true but because it is something that is convenient to engineers to practice
For what it's worth...
A while back Seth Godin wrote something about resumes being irrelevant, and a lot of stuff about "personal branding," blah, blah, blah. It wasn't without controversy, although I don't remember if it was discussed here on HN or not.
Anyway, here's an anecdotal data point for ya. I took Seth's stuff to heart. Since then I've made it a point to do things like giving talks at Tri-JUG, Tri-LUG, RTP Semantic Web Meetup, etc. And I do have code on Github (and a few other places) and I do network a lot and a lot of people know who I am and what I do.
Net result? When I got laid off from my then $dayjob about 2 weeks ago, I made 2 phone calls in my car on the way home from the office, and essentially had a new job lined up within 2 hours. No resume, no interview, etc. Somebody knew my reputation and when I said "I'm available" the answer was basically "Oh hell yeah, we want you."
I did eventually send in a resume and do an interview, but it was really just a formality to satisfy their HR process.
Also, they pointedly told me that I could skip even the formality of their coding test, because "you have code online we can look at."
So yeah, my experience is, if you do the right things, and are good at what you do, you can avoid a lot of the bullshit that's usually associated with hiring.
Thanks for the feedback. I live in the Triangle too. There's plenty of demand for developers here, with decent average salaries, but not great. So merely getting another job is no great feat. What I'd like to know is, was it worth it monitarily or do you think you could have got a similar job in a couple weeks without all the networking?
Well, even without the networking and stuff, I'm reasonably sure I would have eventually found something, yeah. The open questions, to me, are "how much longer would it have taken?" and "would it have paid as well?"
But my point was more that I was able to shortcut a lot of the usual rigmarole that it takes to get hired. And to the extent that I did go through any of it, it was obviously just a formality and there was no pressure or whatever, like you might normally expect. It's also just a nice ego boost to know you're wanted enough to where you can lose one job and have another lined up in a few hours.
"In real life, the people whose decisions matter a) often can't read code and b) almost always have better uses of their time than reading code from someone who is, statistically, not likely to be hired."
The person who can't read code shouldn't be deciding the technical merits of a candidate. If that's happening, your hiring process is broken.
Furthermore, your hiring process should be designed such that you can weed out the majority long before the in-person interview occurs. Steps in the hiring process should be scheduled such that the more time consuming parts come later.
I google any candidate who has made it to an actual in-person interview. If they have a github page, I look inside to see what they've done. It helps tremendously if the candidate tells me which projects they are most proud of. What's nice about this approach is it gives us something to talk about that the candidate is passionate about.
It's only when the candidate has nothing to show off that things move towards a more "traditional" interview, with dry coding and design questions.
I mean, the author is entirely right: skilled devs can write their own ticket in this market. So, um, let's start doing that.
I also continue to think that "I have code on Github" is believed to be a career enhancer not because this is actually true but because it is something that is convenient to engineers to practice. In real life, the people whose decisions matter a) often can't read code and b) almost always have better uses of their time than reading code from someone who is, statistically, not likely to be hired.