Ask HN: How important is having experience in specific technologies?

4 points by Floog ↗ HN
During my job search I'm finding plenty of companies that I'd love to work for, but the skills they are looking for specifically are not ones I have.

For example, I have personal project experience in PHP with the Laravel framework and AngularJS on the front-end. But a job I'm looking at is asking for EmberJS front-end with Ruby on Rails back-end experience.

Is it worth my time to apply for this position? Or should I acquire experience in new technologies?

7 comments

[ 2.7 ms ] story [ 28.3 ms ] thread
A lot of companies are starting to hire for capability instead of experience in just the specific tech. But I can't imagine if you have no experience in their stack that there would be much interest from a company. Unless you have significant domain experience or the stack is very similar to what you have been working in.

So to answer your question, I don't think going after a RoR position would be worth your while given what you have said. But Angular vs Ember seems reasonable. e.g. framework switches aren't as critical to me as would be you having no experience in the core development language, depending on the situation of course.

I'm curious what about RoR vs Laravel makes it not worthwhile, while Angular vs Ember is?
Actually fair point. In my mind I was thinking Ruby vs PHP more than RoR vs Laravel, as really those are just frameworks. I am glad you said something.

I saw a couple of other comments point out that the more experience you have the less this is an issue and I think that is also valid. I would just think if all your time has been in PHP, making the jump to Ruby might be tough, but making the jump to PHP with different frameworks is not nearly as hard. But again, it depends on the other skills and experience you bring to the table as to whether an employer would bet on you to make the leap from one core language to another.

* EDIT: Fixed spelling

You generally need to bring an applicable skill to the table immediately on hire. With the exception of a few stable mid-sized companies that really love generalists and cultivating long-term employees, and fresh-grad hiring, most places can't take the time to ramp you up on a new skill AND their codebase before getting value back out of you.

But it also depends on the distance between skills (frameworks < platforms < languages), whether you know the industry or applicable business logic already, the breadth of your resume as a whole (a proven generalist vs a transitioning specialist).

But most importantly -- you can't really know from the outside -- don't be afraid to burden them with your resume. Worst case, they'll throw it out immediately and forget they ever saw it. Best case, they'll be in a pinch or spot a detail in your resume that you didn't even know they were looking for.

>You generally need to bring an applicable skill to the table immediately on hire.

I don't really understand this mentality unless you're talking about the first 5 employees or so.

If I find someone who is otherwise great, but has experience in PHP, and my team uses Ruby, I'd rather hire that person now and spend a few weeks getting them up to speed. The alternative is to spend even more time waiting for the perfect candidate to come along who can hit the ground running.

You touched on my next point a bit when you said a proven generalist. I think that if you have a strong grasp of CS fundamentals, and 5 or 10 years of experience, you should be able to pick up enough of almost any imperative language to be productive within a few weeks.

I don't often use Python, but I do have years of experience with C, Ruby, Java, C# and others. The first time I needed to use Python I was able to pick up enough to get by in a weekend. The first time I used haskell, now that was a bit different.

I'll leave this here. http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...

I personally agree with you, I just find that you/we are in the minority as hiring managers.

When you hire a PHP person to join your Ruby team, you're making a bet that they're able to ramp up on the new environment as readily as you and I might. I've seen great engineers fail to make leaps exactly like that one. The weirdest things can hang some up, and it can take quite a while to recognize and address the issue. It can cost quite a lot more than holding out for the right candidate. Sensibly or not, that's a risk that a lot of employers aren't willing to accept (or maybe aren't able to).

What mitigates the risk for these employers is if the candidate has other ready skills or has a track record of picking up plethora of skills like "C, Ruby, Java, C# and others" as you describe. I tried to express that in my original comment, but maybe didn't do so as clearly as I'd hoped.

The more senior you go the less it matters. At senior positions your architectural understanding matters more. If it's a junior position then all depends on their willingness to train you. Basically if they want someone to crank out code tomorrow, they probably won't hire you. If they just happen to use ROR and want you to architect the cloud backend of their technology then they shouldn't care so much.

But all in all it never hurts to try! :-)