6 ms·
If we're talking about full-time salaried jobs (and not just consulting gigs), the easiest way of getting a job using a technology you don't know is to find one
by fecak 12y ago
If we're talking about full-time salaried jobs (and not just consulting gigs), the easiest way of getting a job using a technology you don't know is to find one of the many companies that value the overall engineering background over things like syntax.
For many years I recruited for companies (mostly mid/large) that would only hire engineers with a highly specific technical background - X years of this language, Y years of this framework. Then I started working with smaller shops that weren't nearly as concerned about the specific tools, but were more focused on overall software development knowledge. I've placed Ruby devs into Python shops and vice versa, Java devs into Scala and Clojure shops, etc.
This is not as easily done if you're looking for someone to hire you as an independent consultant, but for perm hire it's now common.
- jghn 12y agoOf course now that many people have agreed that syntax is a silly thing to worry about, they've moved on to claiming that the impossibility is quickly picking up frameworks and libraries. In my career I've made drastic shifts in tech stacks, including some moves to some pretty esoteric/uncommon things. In every case I've been up to speed in a reasonable time - sure I might not be the world's expert but Good Enough. And honestly, because of that experience it's only made it easier to do so over time. I wish more people not only accepted such shifts but encouraged them as having a larger breadth of experience gives you a better vantage point in terms of design decisions and such.
- fecak 12y agoI feel that this method of hiring (not based on specific languages/tools) is increasing, but I imagine the biggest beneficiaries are going to primarily be younger engineers who haven't been involved with one technology for many years. Someone writing Java for 15 years may be less likely to get interest from a small Python shop than a much less experienced Ruby dev. Ageism could potentially be a contributing factor, but I think some of it also has to do with the popularity of the languages within other language communities. If the language you know isn't generally appreciated by the hiring team, your experience may not be as highly valued.
- jghn 12y agoI agree that there's a hint of ageism there in the standard case (i.e. the one you describe), and that's likely due to seeing someone w/ 15 years of experience in Java registers (perhaps subconsciously) as "old guy". And indeed, being young was how I fell into my first radical shift around 2000, from C based systems level stuff to R based bioinformatics tools. And admittedly, despite what I said previously I also hold it against people at times if all they've worked with is a single technology and they've done it for a very long time. To me that shows a potential lack of flexibility and perhaps they might not be able to transition to new technology all that easily. Even if a company thinks their stack is stable, it might change at any point and IMO it's good to have someone who can pivot easily. Also, as I mentioned previously having that broader range of experience is useful in terms of spotting pitfalls or good approaches.
- eldavido 12y agoThis has actually been opposite of my experience. I've seen that bigger cos, owing to being better resourced, can be more patient about the payoffs of long-term bets (including training young/inexperienced employees). Microsoft can afford to fight 10-year wars of attrition; small startups with 3 months of runway can't. Overall I've found that consulting gigs turn on value delivered immediately, whereas the stronger of a "software" culture that a company has, the more willing they've been to invest in training and letting people get up to speed with newer tech.
- fecak 12y agoLarger companies can be more patient about long-term bets, but in my experience I've found that they aren't regarding experienced hires. Of course they'll train the young and inexperienced, but I don't see as many large firms hiring experienced developers with a different skill set than they are ideally seeking. Part of this can probably be explained by the traditional big firm HR departments. Tech culture is probably the key ingredient regardless of company size, though I'd theorize that the type of culture open to diverse tech backgrounds is generally found in smaller shops.
- vonmoltke 12y agoThis has been my experience as well. With large companies, once you have "Senior" in your title, you are officially pigeon-holed. I broke out of that by going to a small company[1], but I think my varied background and career path is now blocks me from ever going back to a large one. [1] Incidentally, a non-enterprise Java shop, where I was hired despite not having written much code in Java.
- curun1r 12y agoYou nailed it with the HR departments. I'm a manager at a large company and I've done a lot of hiring. Whenever I open a rec, it's always a fight with HR to limit the scope of the filter they use to screen out candidates. They always want a list of 4+ skills with number of years experience to include in any job ad that they can confirm an applicant has before forwarding me the resume. I mostly want to see code that a candidate has written, regardless of language. It took me a lot of arguing/debating, but I figured out that they can (be forced to) handle ORs in the requirement, so my ads now ask for 2-4 (depending on whether it's a senior position) years of cumulative experience in any of C, C++, C#, Java, JavaScript, Python, Go, Haskell, Rust, ML, D or OCaml. But there are a lot of managers that won't bother to fight with HR for a month to avoid giving HR the simple filters that they seem to crave, so they end up with only candidates that have experience using the languages to be used in the position.
- jasonswett 12y agoGood point. I haven't personally gone that route but I could imagine it being an effective way to do it.