Pick a technology stack that you want to get a job in and build a side project in your spare time. Attend meetups with experts in your local community and learn how to make it awesome. Build relationships with them along the way.
Use those relationships to get some part-time contract work in said technology stack with someone local. Document this experience and build up a portfolio.
Eventually, use the knowledge you've obtained from your side project and part time contract work to apply for full time jobs. You'll then be very marketable, and you will have enough knowledge to do well in interviews.
I do recruiting and I have an awesome story like this. Back in 2010 I worked at a mobile reading company. I was trying to hire iOS developers. I found an awesome github from a dude who was doing backend C# stuff at MSFT, but was building AWESOME iOS apps at night.
I emailed him and asked if he wanted to do the thing he was clearly passionate about full time.
He aced the interviews, came out and built our app. About a year later one of our founders left to start a new company. The founder recruited this guy. Within 18 months, their company sold for a few hundred million and now instead of writing the C# code he hated, he has now helped build an awesome company, build a whole new skillset and built his leadership skills. Not to mention the fact that his wife and child are basically taken care of for life because of this decision.
I did this in 2013. This advice is spot on. Learn the hell out of the new technology stack, and then build up a portfolio (for example, you can contribute to open source projects, or start your own).
If the antiquated tech you have experience in is more complex than the new stack (antiquated tech usually is), it sometimes works as a positive: you have a perspective 'native' users of the stack don't.
Former .NET enterprise dev, current Rails consultant here.
I did this with a twist, if you can swing it.
1) Find a local client that is looking to do a project on the cheap - someone who has an Elance budget but is uncomfortable dealing with someone remotely.
2) Propose to do this project pro-bono if they budget the availability of a sr. resource for mentorship - say 5 hrs a week.
3) Put in reasonable constraints AFA availability, estimates, testing, etc., that befits your jr. status. Ultimately you want your mentor to guide you as much as possible and the client to understand this relationship. It shields you from unreasonable expectations.
Doing this, a) you get to work on a real-world project (it pushes you forward faster with issues that a side project usually doesn't... if for nothing else you're interacting with others on their schedule, their whims), b) you get on-hands training, and c) you get access to the networks of your mentor/client if the relationship is fruitful.
I did this back in 2012 - the only work I had done prior to this was going through the Hartl Rails Tutorial. The initial project lasted for 4 months @ ~20hrs/week and I was paired with someone who was an early engineer from Gilt Groupe. During this time I continued to work my day job.
Toward the end of that project my mentor brought me the opportunity to bid a long-term gig. I quit my job the day the that contract was signed w/ about 3 months of financial runway. A few months later he brought me another, and that work kept me going for over a year at an overall cashflow greater than I had made at my enterprise job. Toward the end of these engagements I started consulting for a local startup which converted into a FTE situation for a year and a half. Now I'm back consulting on another long-term project by way of a recommendation from the design team on one of those earlier projects.
The one thing I will say about consulting is when you're starting out communication is more key than technical skill. Just be open w/ the client, you're both making concessions in such a situation.
This! I've had the opportunity to hire for our company for the past year or so. We use a somewhat uncommon paradigm in our tech stack that is very attractive to a lot of developers. Many of our applicants have exactly what you said: plenty of side projects in that paradigm / stack and participation to meetups / communities etc.
Occasionally however I run into people who have absolutely no side projects and have been doing the same stuff for 10+ years. I'm a Java expert (or .NET or C etc.), they claim. When I ask them if they've tried anything else besides that one thing they've been doing over and over for a decade, perhaps a side project, a toy product, some contribution to OSS in the new paradigm they apparently really want to work in, I get responses along the lines of "I'd never work on something I'm not being paid for, I'm a serious professional that's irresponsible".
Er.. ok. So I'm supposed to hire you, take a huge risk not knowing if you can pull this off or not, train you for a year to do something you have 0 familiarity with, and then you might peace out right about the time when I'm starting to recoup the onboarding costs? I'll pass. Candidates who already demonstrate a lot of interest, side projects, and desire to learn outside of their 9-5 will win any day of the week with me.
I agree that someone who doesn't have side projects isn't as attractive as someone who does, in general. But there are lots of people who don't do any programming once they leave the office (8-9 hours of computer time is more than enough for them). That doesn't mean that they aren't dedicated or that they are a risk.
As someone who struggles to find enough time for side projects, I agree that it isn't necessarily a sign that someone isn't passionate about the job. However, if someone says stuff like "I'd never work on something I'm not being paid for, I'm a serious professional that's irresponsible", its pretty obvious that they don't actually like what they are doing.
its pretty obvious that they don't actually like what they are doing.
My dad has been a mechanical engineer for almost 40 years and I struggle to think of anyone who enjoys their job as much as he does. Yet I have never once seen him do any personal "side projects" that are in any way related to his day job.
Many people truly believe in not doing anything related to their career/job outside of their workplace. They do something totally different instead. One might train for a marathon in her spare time, instead of learning the newest JS framework for example.
The side project concept is fairly unique to digital workers, especially software engineers simple because we can. Noone asks an accountant or a secretary for side projects.
pretty obvious that they don't actually like what they are doing
Not to get into a debate, but there are tons of people who don't like what they are doing. But they are still good at it. Sure they may not be truly happy, but they are good at what they do even if they don't like it.
Fundamentally, risk isn't binary. There's more risk and there's less risk. For my kind of team, the absence of side projects, demonstrated lack of interest in furthering one's craft outside of paid hours increases the risk of this person not being able to pull his weight, if somehow he slips through the regular filtering mechanisms. As you pointed out, every candidate presents a unique risk profile, and every company weighs different factors differently.
I work for myself specifically to be able to isolate the kind of developers that will make my organization successful. It's wonderful that we all have the opportunity to choose what kind of environment we want to work in.
> "I'd never work on something I'm not being paid for, I'm a serious professional that's irresponsible".
I can understand a false "expert" delusion, but have you literally heard someone say they'd never work on something unpaid because it's unprofessional?
I can attest to this method being completely effective, but I think you can skip the contract work, and it might get in the way.
At least in my experience as a contractor, people are looking for contractors because they have lots of experience in this technology but don't have the resources or time to devote to their project full-time. So if you have little experience in a tech stack, you may have a hard time finding this kind of work.
I simply built a side project (I did this with Rails) and then got hired full-time at a startup to do Rails work. As with everything, YMMV.
hm. My experience is that contract work (I mean, real contract work, not working as a temporary employee through an agency, like I'm doing now) has higher standards and pays less per unit work, for the 90% of us who aren't super effective all the time.
Taking a less-senior position for less-senior pay in the new tech stack is probably going to be more money per unit work, and my experience has been that you can get people to work with you on titles and that nobody actually knows what you got paid at your old jobs.
I mean, sure, if you really are that good and actually get things done regardless, your way might be better. My experience has been that good contractors going direct get a little more money than you can get through a body shop or as an employee. But... I'm talking like top 5%. Most of us aren't there. If you are mediocre... if you are merely 'good enough' - being a "real" contractor is difficult and under-remunerated. (to be clear, it's under-remunerated for the top 5%, too... but those people work like crazy all the time, so it's not like the customer is expecting more out of them.)
I can't upvote this post enough! I would also like to add a point to pick a new tech stack and stick to it. Don't fall into the trap like I did some years ago where I kept jumping ship every few months which was causing me to not get anywhere. You'll see people posting to do this and that, all it did for me was just create noise and prevented me from learning new things.
One of the developers I previously worked with had gotten his job in a similar fashion. He went and made friends in the community and ended up getting a good job because they saw he had learned enough and was an experienced programmer that the growth from that point would be pretty quick.
And (this might be obvious), but read, read, read! That's what works for me at least. Articles, books, blogs, IRC, IRC chat logs, Github issues, etc. When I am learning something new I might spend a few days (or even weeks depending on the subject) reading around about it before I take that first step to build my side project.
Reading to learn is not borne out by research as a good way to build and retain skills, and can just as likely create illusions of competence http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect. Research shows it's far better to just start doing the activity. The reading should just be used to get you just to the point where you can start doing.
Understanding fundamentals before doing some activity is empirically more efficient though. Both thinking and doing are necessary for understanding the fundamentals of a given skill. Reading or communicating about things is a subset of thinking about them. It's all necessary at some point, whether you do it before, during or after your activity.
I read to understand fundamentals and to get useful information such as which libraries, techniques, etc are popular in the arena that I'm entering or things to avoid. Many, many times reading has saved me from entering a given arena because I was able to conclude that whatever new technology I was looking into wasn't really going to work the way that I wanted.
Pick a technology stack that you want to get a job in and build a side project in your spare time. Attend meetups with experts in your local community and learn how to make it awesome. Build relationships with them along the way.
Use those relationships to get some part-time contract work in said technology stack with someone local. Document this experience and build up a portfolio.
Eventually, use the knowledge you've obtained from your side project and part time contract work to apply for full time jobs. You'll then be very marketable, and you will have enough knowledge to do well in interviews.
Good luck!