This anecdote well encapsulates the impression I had of a lot of them.
I'd really like to meet the better of the crop, because I can't imagine PG and Jessica (she's usually the expert on character and personality in YC interviews) are intentionally picking petty people.
I'm not the only person in the startup industry who's had this impression either. They remind me a lot of underqualified legacy Harvard kids who think they're god's gift because they snagged a status symbol.
Maybe the better founders are too busy shipping product to run into me :)
That aside, both of my interviews at YC companies (two, although I've talked to a lot of YC'ers besides), had profitability so the typical runway concerns weren't predominating their conccerns I would think.
When I was at my startup, I hired a guy with no Django experience and minimal python. He made his first bug fix within 24 hours of showing up and was productive within a week.
Maybe RoR has a much steeper learning curve, or maybe the people doing the hiring just don't get it.
I had the same experience with Django walking in with the same repertoire (minimal Python, no Django) back when I lived in NYC.
I don't do Django anymore, but it taught me a lot about trusting people to pick things up on the fly. Especially with the right person and environment.
Seems like it would be so drastically high that hiring a MVC (Minimal Viable Candidate) might be the right choice.
Using management skills as a primary selection criterion would be premature optimization in YC's process. At some point, hopefully HR is screening rather than the founders, but early on putting up with the founders' bullshit is part of a necessary skill set.
Familiarity with Active Record, and making it reasonably performant, handling rails security issues, experience with the gem ecosystem, understanding the intricacies of the routing DSL, getting a handle on reasonable rspec/capybara or cucumber practices, ruby metaprogramming, knowing the Rails conventions and what it looks for automatically in controllers, views, and partials, and which methods are available where, knowing all the various helper methods rails provides for text processing, working with dates, and html tags, best practices integrating with AJAX, migrations, rack middleware, the asset pipeline, etc, etc. I've been working on our Rails app non-stop for 9 months now and every day I learn new stuff.
Long story short, for a start up which needs to iterate fast before it dies, acclimating a competent programmer to the "Rails Way of Life" just might not be worth it. Now, it's a completely different story if you have important domain specific knowledge, and the company is working on something especially innovative, but it seems like a lot of start-ups are scrambling for a pretty low-tech piece of the pie where "execution wins". My point is, Rails is surprisingly big, and while you can become useful in a matter of weeks, you can't become extremely productive with it for awhile longer.
Particularly with Rails where it's convention over configuration, knowing the conventions is a great headstart.
Unless you need language guru, the languages known don't matter much. If someone can write a LISP interpreter in Haskell for 2 days I would hire her for a Java position even if she doesn't know what a loop is.
Either you have another skill that they need, or they just want a "generic (good) rails programmer"
Of course skills are transferrable, within a timeframe. So if you're trying to ship something in 6 months this may not be acceptable
- Knowing and using the basic underlying technologies (languages, but also concepts, like machine learning, databases, UI skills or so on)
- Knowing the specific codebase and process for those projects (how the build works, what are the components, what they do, etc).
True, someone knowing the first skillset has an advantage, but a talented person will have no problem doing the second one much faster. For an hire, I would rather factor in the long term. It's about sane finance management and ROI, actually. For any given pool of candidates, you are considerably reducing the chance you hit a talented people, if you interview only 10% of all candidates just based on their previous base skills.
EDIT: Actually, I want to tell more of this story to emphasize what you can do with a reasonably competent employee willing to learn.
At the time, I was hired as a temporary contractor for 3-4 months. I had basically most of 1 month to get to basic competence with Rails, and it was supposed to be less. Then I started getting real work thrown at me. By the end of 3 months, I had justified my pay and my employers had no more temporary work to throw at me. They offered to hire as a full-time salaried employee, but by then I had a plan for grad-school and research.
That was at the end of June. Midway through November, my friend who originally recommended me to that employer messages me on Facebook. He tells a bit of an ironic story, one point of which is that he himself is now using and expanding-on the code I wrote in those two-point-something months. Apparently it's holding up pretty decently, and the team is able to ship product.
All this because the proprietor of the firm figured he could hire someone smart with a good work-ethic for a while and give him time to get competent with Rails rather than go unicorn hunting.