Interviewing and an Open Source Portfolio
The conversation of working on Open Source as a way of improving the chances of getting hired has been coming up a lot this past year. The argument against using Open Source work to evaluate a candidate’s ability is that many people have families and other responsibilities which makes it nearly impossible to dedicate hours each week to an Open Source project. That is a valid argument, though I think everyone should still consider doing some Open Source work.
When it comes to software development, it is now often Open Source work which is pushing forward this industry. There are so many examples. A big one is how Apple picked up KHMTL and made it into WebKit. When this project was made public the main Open Source layout engine was Gecko which is used by Mozilla Firefox. At the time the Mozilla code base was quite large and complicated with years of development put into adapting to a rapidly changing set of web standards. It was hard to maintain and slow to add support for stabilizing web standards. In contrast, KHTML and WebKit were a much smaller code base without a long legacy or a lot the same level of complexity. Since that time WebKit has added support for a wide range of web standards and was forked off for use in the Google Chrome browser. Blink is the result of that work. It has clearly benefitted all of us.
Now this has been a massive effort. Hundreds of thousands of hours have gone into WebKit and Blink to make it what they are today. And perhaps this is the kind of project people think about when they decide that they cannot possibly do any work which is Open Source. Clearly making a significant contribution would be serious commitment. I’d like to suggest smaller projects, either started from scratch or joining an effort which has already been underway for a while.
One easy path into Open Source is to look at the code which is used at work. Most work projects use some kind of Open Source. Let’s say one work project is built with React Native. It is an Open Source project which has become very popular in the past couple of years. It is a very modular system which represents many opportunities to contribute to an existing module or even create a new module. A good place to start would be to create a UI component which may be used at work but would be useful to many others. From start to finish it may just be a few hours of work, which could be done on the job. (Be sure to discuss making some of your work Open Source with your team along with selecting a license. Also consider how publishing Open Source work can attract new hires to your company.)
In this way it is possible to use work time to contribute to Open Source and get the professional benefits of “being published” which is the goal with other professions. Just a couple of small contributions each year could be enough to give a company a reasonable sample of how you work and what you can produce. It also demonstrates your interests which is a key indicator when evaluating a candidate.
I have used my day job as a way to consume and produce Open Source. Back in 2014 I needed a way to shorten URLs so I used Bitly. Since I wanted a very simple client and did not find one I created one. I also decided to make it available for others via CocoaPods. I called it BitlyForiOS. In 2014 iOS projects were still all Objective-C so naturally that is the language I used to create it. This past year I wanted to practice working with Swift to I upgraded that code base to include nullability annotations and released a new version to make that existing code work better with Swift. I learned a lot about Objective-C and nullability while making that update. I then created BitlyKit in Swift because I wanted to see how that client could be implemented in the new language. Putting that project together taught me a lot. The additional benefit is that others can see the result of my work which may assist with evaluating my ability when a company is considering candidates.
Altogether the work I did on BitlyKit was completed in under 5 hours which I did over the course of my daily commute on a train. It was my way of making good use of that time. I could be watching Netflix, playing a video game, reading a book or anything else but I have been choosing to use that time to get up to speed with Swift little by little every day. When Swift 4 is out I will be able to return to that project to get it up to date and continue my learning.
You Can Do Open Source
Open Source work does not have to be a huge time commitment, so perhaps that fact is enough to encourage more people to get started with Open Source. Does this mean everyone should be expected to publish code? That depends on what you want to do with your career. You may want to upgrade your skills and experience and working on Open Source may allow you to do that if your daily work does not expose you to the new technologies and languages as rate which would make your skill set more marketable. I found much of my daytime work was still focused on Objective-C so I chose to work with Swift on my own time.
It is also important not to compare yourself to every developer out there. Back in 2015 Ray Wenderlich gave a great presentation called Overloading Comparison on this topic. There’s nothing wrong with choosing a path and speed which is right for you. Not all of us will be Chris Lattner or Mattt Thompson. That is perfectly alright. I decided my pace over the last few years and know that I am naturally curious. I define what I want to learn and set a balance for work, Open Source and my personal life. I know that slows down the rate that I can learn, but that is the compromise I have chosen. It is up to each of us to make that choice for ourselves.
