How to Get a Job Using a Technology You Don't Know
jasonswett.net
jasonswett.net
Also, if you get a job where you have at least partial control over the technologies you use, you can of course get paid to use a technology with which you have no experience.
I would actually prefer to get a little non-paid experience first, though, in fairness to the person paying me. (Unless the boss/client is cool with paying me to learn.)
I went out to local community events with a focus on software and networked with other developers. Word got out that I (a student at the time) was a competent developer with open source experience. When I graduated, a few of my new developer friends tried to recruit me.
I took a job at a local startup as a software developer. I was going to build a new product, though the tech stack wasn't decided yet. Soon it was decided to be Ruby on Rails. I worked through the Rails guide on building your own blog, then continued to learn it on the job by doing a small project that shipped. At that point I had enough experience to design the important project and start building it.
It's worth noting that while learning Ruby/Rails, I completely surrounded myself with resources. I would answer questions on StackOverflow, follow Rails blogs, watch screencasts, hang out in the IRC channels, read and review Ruby books, watch and learn from public projects on GitHub, etc.
For places that use (not make) software, the best bet is always to focus on solving the client's problem in as economical a way as possible, irrespective of the technology used.
I'm surprised at how often I go back to the book and see it applicable to my life.
http://webcache.googleusercontent.com/search?q=cache:iG01hdg...
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.
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.
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.
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.
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.
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.
[1] Incidentally, a non-enterprise Java shop, where I was hired despite not having written much code in Java.
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.
Since most HR (and most engineering managers) aren't going to clone your repo and install your code to test it, this is the most efficient way to illustrate your awesomeness.
I just record the desktop with QuickTime screen record then edit in something like GifBrewery to get brief gif loops.
You'll want to make sure the demos are short and to the point... maybe 15 seconds per gif.
What you suggest is useful in many scenarios given that they are willing to go thorough the trouble of following the links and checking up the work. All they want to hear is "x years on y tech a z company". Not all of them are like this but so many are.
I have faced problems with HR people demanding "commercial" experience in some technology and not caring at all about your open source work.
Unless they're a start-up recruiting you as CTO/similar to be that person. But that's quite a different proposition.
I went from first Rails side project -> Freelance consulting -> Early Stage startup -> Acquired startup at Fortune 100.