It's not just HR. I did an interview with a YC startup that obsessed over my lack of Rails experience. I have several years of industry relevant professional experience in Java, Python and PHP, but only ever dabbled in Ruby and Rails. Their offer (which did come through, grudgingly, through many repetitions of "so will you commit to teaching yourself rails before starting?" (No, I won't.) was quite a bit on the low end, but I'd probably have turned it down anyway for that strange lack of comprehension of programming skills.
I've had a lot of encounters with YC founders, most of them negative.
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 :)
Leaders may be born, but management skills are learned from experience. Those skills require conscious thought to implement because they are antithetical to the natural inclination to abuse power disparities within a relationship.
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.
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.
>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.
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.
Specific skills weren't the issue in my interviews. I was remarking more on the pettiness of the founders I talked to.
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.
This was my first thought, although it comes from my POV where I think I am a slow learner because I can't pickup a new programming language over a weekend. I'm still exploring the dark corners of C++ after a year or two, but mostly that's due to the demands of the current and previous project. I went through the whole Python tutorial once, to never use it much again, then flubbed a Google on-site because of it. On the flipside, when given a week to work up some post-proc analysis code and the opportunity to do it Python, I was up and running in a little less than a day. It's amazing what you can do when you have access to reference materials and more than 60 minutes.
But how were they supposed to know you were the kind of programmer that picks up a new language in a matter of days or weeks? Most programmers take years to become competent in a language. I think this hiring practice, although unfortunate, is just the employer securing themselves in case the programmer is only at medium competency. Then at least he or she can use that one language where they have shown at least some competency.
You're deluding yourself if you think you'd be as valuable to an early RoR-based company as a good dev with a year of Rails experience. I used RoR for my start-up because I was sick of PHP and wanted to learn Rails, and I feel immensely more productive now than I did when I began. And I'm a "quick learner", too.
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.
I don't see a problem with requiring Rails experience. It depends on the job of course. If I don't mind a slow ramp up and want someone right for the job that might last a few years then I don't care. If I have some complicated technical issues I need fixed quickly, I want someone that can jump in and go right away.
Particularly with Rails where it's convention over configuration, knowing the conventions is a great headstart.
Then you probably need consultant if it is only for a specific issue. Otherwise once this is solved you got bored to death employee, with skill set for which you are overpaying and under-utilizing.
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.
I got competent with Rails in 1 month. It would have taken less time if my boss hadn't had to run away for a week and a half and leave me with tutorial/study work rather than real meat I could cut my teeth on.
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.
Usually there are two skills to have to ship a software project:
- 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.
