But in a review between myself and the company cofounders, one sticking point kept coming up: Not enough relevant development experience. We were trying to build a core front end team that had an existing passion for mobile/tablet, and Dan was a square peg in that round hole.
It's hard to comment accurately without knowing much more about both sides involved here, but generally speaking, rejecting a (skilled+proven) developer who's willing to learn a new technology because he doesn't have experience in it is just...a mistake.
I certainly won't disagree that the rejection was a mistake (since admitting that mistake is the whole idea of the post).
However, it is worth noting that when we rejected Dan, we rejected a skilled developer. We did not reject a (skilled+proven) developer as you asserted.
Our mistake was in failing to see past Dan's relative inexperience in the areas that mattered to us. We knew he was skilled, but we were unsure how well his raw talent would translate to our product needs at the time. In other words, he was not "proven" in the ways that mattered to us.
Obviously, Dan has now developed enough of the social proof needed to be classified as (skilled+proven), but I think he would be the first to say that his skillset last year was very different than it is now.
Many companies regularly pass on very good people who simply don't fit an immediate defined need. I think this is a common mistake, and one that isn't just made by corporate HR drones and technical recruiters. Part of the goal of this post was drawing attention to how common this mistake is.
"Many companies regularly pass on very good people who simply don't fit an immediate defined need. I think this is a common mistake, and one that isn't just made by corporate HR drones and technical recruiters. Part of the goal of this post was drawing attention to how common this mistake is."
There are always stories going around, maybe true, maybe urban legends about how, for example, IBM could had an opportunity to buy Xerox and could have owned the copier market (which was a really big deal at one point). People talk about how a company passes on an opportunity and, after the fact, what a mistake it was.
What the stories never mention is how many ideas they passed up that never amounted to anything. They only focus on the mistake they made.
You can't hire everyone and you used your best judgment given what you needed and what you saw. If 42floors hadn't written the blog post and it hadn't appeared on HN this situation with Dan wouldn't mean anything to you you wouldn't even know about it.
Actually, I think you made the right call to reject him during your initial interview (based on your telling), and you second-guessing it simply because another company is publicly kissing his ass is worrying. Your reasoning is sound to turn him down, and you don't have to hire everybody; the rest of your comment basically reinforces that point.
I, personally, know three people in college who have turned out Web apps, iPad games, and even Linux drivers for underrepresented hardware. I think their accomplishments are great, and for every Dan Shipper I bet there's six or seven people not getting the same milk and honey publicly. This hero worship on HN is tiring, and that you're buying into it (and second-guessing your hiring decision!) is just wrong. It's bad for your company to admit it publicly, too, because you're too easily bandwagoned.
You made a decision. Own it, and don't give in to the flavor of the week that HN is lauding.
I dunno. I think you're taking this post a little too seriously. Seems like the OP wanted to give a shout out to a friendly professional acquaintance whose name was making waves in the ecosystem. In doing so he also made a point that you do have to pass on people you think interviewed well.
Changing your mind about a decision at the time based on how little experience Dan Shipper had at the time much, much later after he gained experience is not "wise".
I agree. "Not enough relevant development experience." is an answer that I would expect from an HR drone, not someone interested in hiring the best and brightest.
No, it doesn't. Sometimes you have to choose between investing a shitload of money into training someone in the platform that you have, or hiring someone who won't require as much time to ramp up. Never underestimate how much of an investment is required to train someone on a platform; what if it doesn't work out? You've just trained someone partially who can't work for you.
No one 'trained me' on Ruby on Rails as I transitioned out of working on the MS stack for the past 11 years. I learned that stuff myself.
After 4 mos using RoR on one small project, I worked to get my foot in the door for a sit down at a startup looking for their first engineering hire. They wanted someone with 3+ years experience. After seeing some of my code and doing a sample project for them (learning the basics of Sinatra/DataMapper/OAuth/FBGraphAPI to crack a problem they had a need for in a weekend), the CTO said I pretty much blew away many people he's seen who've had such experience, and in the end I was the one to say no to moving forward after the interview process.
If you're looking at people who 'need' to be trained then you're looking at the wrong people. You're looking for people who can crack the more meta-problem of actually learning shit quickly and subsequenty getting shit done quickly.
Well, all else being equal, you're going to get more out of a hire who knows how to work with the technology you're using. If I have a choice between someone who can learn quickly and someone who can learn quickly and already knows what I need him to know, I'm going to pick the latter.
What are the boundary conditions here? I'm a young developer (23) who's made over half a million USD$ from web apps while in school - would many companies be interested in hiring even with programming languages I have little to no experience with?
The startup I work for would! Assuming, at least, that you have experience in a couple moderately dissimilar languages (e.g. not only Java) it's really not a big deal. It's important to have someone who is a real expert on a language you're using, but most people can just be good at it, and you can get good at most languages quickly with sustained effort.
What is a big deal is being smart and motivated and knowing a lot about at least something useful. Everything else is gravy.
The better question is, in your situation, why would you consider looking for a generic opening? If you can build that sort of business, then you probably don't need a "job".
I'd expect the boundary condition to be whether those web apps were all exactly the same technology, or if there's evidence you're quick to learn and pick up new stuff. If you're like "I did this first thing in PHP but for the second, bigger project I moved to Python/Django with some client-side JS", your odds should be great.
Hiring highly skilled programmers that know exactly the technologies they need is what many companies aim for when hiring, and never accomplish. They're wrong. Even Google has problems finding (and hiring) those. That's why I said it was a mistake.
So, I would expect that you can find these jobs. And the companies that are willing to hire you might also be the ones you want to work at. But some HR departments will turn you down, and some people (like the original poster) may turn you down because it's a risk. (I can't blame them - hiring the wrong person is a bad mistake, too - but they shouldn't complain it's hard to find good people.)
My suspicion is that the underlying motivation in both cases is a desire for "social proof". You might have evidence that the person you're interviewing is a good fit for the job, but why hasn't anyone else hired them to do it? As much as I dislike the whole idea, it seems to just be a fact of human psychology that you have to deal with.
I suppose at the end of the day, startup founders should at least have empathy for this situation. After all, starting a startup is an exercise in not having enough "social proof".
It's hard to comment accurately without knowing much more about both sides involved here, but generally speaking, rejecting a (skilled+proven) developer who's willing to learn a new technology because he doesn't have experience in it is just...a mistake.