14 March 2016
You’re always asking:
And it’s hard! What you end up doing is persevering anyway, hoping you’re on track.
I reached out to some of the best dev shops in the world in order to see what they want from self-taught developers looking for work. In this small series, we’re going to hear from people just like you, who now either run or are involved in some great development companies.
Today, I briefly chat to Mikel Lindsaar from reinteractive in Sydney, Australia.
Mikel is the author of the incredibly popular Ruby library mail which has had millions of downloads from all around the world and is the CEO and founder of reinteractive. Check out the 5m interview below.
Mikel: The best way to learn something as complex as Ruby on Rails is to have a clear Goal and a Purpose. That is, what are you trying to achieve and why are you trying to achieve it. In my case, when I started learning (after having minimal knowledge of HTML) was to build an entire contact management system for a non profit I was working for. During this time I also learned enough Ruby that I wrote the mail gem.
To do that, I bought the Pick Axe Ruby book and read it from cover to cover doing all the examples, then (as there were no online courses at the time) read every blog and screen cast I could find trying out different things and then started blogging about my own experience.
So have something you want to build, and go and build it. If you don’t have an idea of something you want to build, then learning Ruby on Rails from scratch will be a hard slog, you can do it, but you’ll have to artificially generate your drive and passion through discipline, which is hard.
Having a project you are building has the added benefit of forcing you to learn all the things™ and has the extra awesome benefit of being able to show a potential employer “hey, I built this cool thing myself, check it out and here’s the source code showing specs, mistakes and learnings”.
Mikel: It’s not a deal breaker, but you will come in at the lower price bracket, at least initially, unless you have something else to offer in addition to your Rails skills.
You can demonstrate competence in being able to work with a team in many ways, previous jobs will show this.
But in programming, really, “team work” means writing specs, keeping the build clean, doing pull requests and incremental development, not making life hard for other developers due to poorly thought out code and so forth. There is another aspect of team work which is “getting along well with others” which is very important, sometimes your preferred way of doing something will be out voted, you can’t throw a tantrum due to this, or tell everyone they are misguided, sometimes you need to roll with it and help improve the scene and educate.
Actually, if I was that developer, the way I would get work is go to the freelance sites and get as many small Rails jobs as you can, even if they pay little, just get the experience of working with clients. Saying to your prospective employer that “I had no commercial experience, so I went and got some, it didn’t pay great but I learnt a LOT on how to deal with clients and their other developers” would be serious points in my book.
Mikel: We don’t hire people who can’t write specs or tests.
Having said that, TDD and BDD in the purest sense can be overrated. We always have covering specs at reinteractive, but these are not necessarily written BEFORE the code is, sometimes you just have to hack something out to get your head around it, and then back fill with specs.
I would say though that a developer should at least do a whole hobby project totally BDD or TDD to understand the process and power it can deliver.
Mikel: THE MOST IMPORTANT THING to demonstrate is a willingness to get a job done and delivered with high communication with those involved. I value most the people that can produce in reinteractive. Those people that I can go “Hey, client XYZ wants to get this done, please go ahead and handle it”. The developers that can take that instruction and run with it, clarifying requirements as needed, working with the clients and learning what is needed and implementing it in a timely manner are pure gold.
Note, this does not mean, “Produce at the expense of someone else or something else”. Communication and Affinity play a big part in getting something done.
Mikel: If they are self taught then I want to see the self taught stuff they self taught with! When we hire, we do a thorough production check, we want to make sure the person can produce what they say they can produce, so if they have no commercial experience, the only solution is being able to see their commits on a github project or a portfolio. Just saying “Honest, I know how to code” is not good enough if there is no proof.
Thank you Mikel!