It's a fine article, but the implied answer to the title is: you can't. Know the technology, then get the job. I was hoping it was about getting a job when you wouldn't know the technology until you started.
You can come pretty close. For example, I spend maybe 15-20 hours teaching myself AngularJS, and then the next AngularJS work I did was paid work.
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 got a job as a Rails developer without knowing Rails. Here's how I did it.
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.
This is good advice but it really depends on whether the client/company views software as a revenue driver in its own right, or a means to an end.
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.
That's one of my favorite books. You could also say that this is an application of Be Proactive (decide what technologies you want to learn rather than only using the technologies handed to you) and Begin With The End In Mind (I eventually want to be an expert AngularJS developer with plenty of production experience).
Still it's pretty hard to sell GitHub projects to HR drones who want "commercial experience" and might not even know about GitHub. No matter how good your code is, if it's not seen by someone who can judge it, you can't even get your foot in the door.
My solution to this is to write beautifully formatted README.md's with demo links and gifs.
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.
I don't expect them to clone my repo and see my work AND I don't expect them to see the readme. They won't understand (quite understandably) most of the work I do and it will not have any GUI candies to show either :)
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.
The code isn't necessarily the relevant thing. My early Rails code was terrible, but my manufactured experience WAS "commercial" experience, since I had real users (in some cases paying users).
Finding customers is more a function of skill + effort than luck. I visited over 100 hair salons, did a bunch of cold calls, and more. You can get customers if you try hard enough for long enough, and try enough different business ideas.
Yeah. Top comment is true, but not too relevant. If you're not dealing with someone who appreciates this stuff, then you're not dealing with the best person. If the company you're applying to doesn't have such a person, then it's not a good company to join.
Unless they're a start-up recruiting you as CTO/similar to be that person. But that's quite a different proposition.
Wow, gotta disagree there. I found that having projects on Github was impressive to potential employers 100% of the time I brought it up. Before I had them on there (in particular, two small personal side projects) it was much more difficult to prove that I know stuff because I commit to private repos.
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.
Of 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.
I 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.
I 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.
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.
Larger 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.
This 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.
You 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.
32 comments
[ 3.3 ms ] story [ 88.6 ms ] threadAlso, 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...
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.
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.
I went from first Rails side project -> Freelance consulting -> Early Stage startup -> Acquired startup at Fortune 100.