After spending the summer working at Shopify as an intern on the iOS team, I thought I’d share the hiring process, technical challenges, as well as what I learned during my time there. Overall, this summer has been an incredible experience where I got to meet amazing people, work on really cool projects and grow tremendously as an individual.
The hiring process
Background and disclaimer; I had roughly a year of professional iOS experience before applying for the internship. The current process will likely have changed from the one I describe. All in all, it took roughly 3 months between applying and getting my offer.
As many already know, the hiring process at Shopify is fairly unique. This begins with the application, which took me nearly 5 hours to complete. It involves answering some short form questions, building my own Shopify store, and building a small iOS app following the provided criteria. The app was a simple product list view with data and images pulled from a REST API endpoint, and for bonus points, add product pages and search functionality. I enjoy doing these types of challenges because I can do them on my own time and in my own environment.
The next step was the infamous Life Story interview, which is essentially an hour long video chat with a recruiter to talk about your background and how you got into the field you’re applying for. This isn’t a technical interview, although, during mine, we discussed my past projects and the tools I used to build them. I believe anyone can pass this interview as long as they show enough authenticity and passion for what they do.
The final step for my internship hiring process was a 2-part technical interview. I’m fortunate enough to be living in Ottawa (where Shopify’s headquarters is located) which gave me the opportunity to go on-site for this portion, but typically this step is also done over a video chat. The first part was a project demo where I showed off an app I built on my own time to two senior engineers and went through the code and architecture choices I made. The second part was a technical question along the realm of system design and scaling.
A very long couple of weeks later I got the call with my offer 🚀
For a more in depth description of the intern hiring process, I strongly recommend having a look at one of my fellow interns article on the subject.
How I got an internship at Shopify
The interview season for the 2018 summer internships is finally over. After over a month of interviews and tests at…
There’s a lot to be learned when starting on a new team — especially on one of such large scale. Fortunately, each individual contributor at Shopify is given a mentor — they are an incredible resources when joining a team as they will likely have a lot of context on the work you do and will be able to answer your questions. For me, one the biggest technical challenges I had when starting was adapting to building views fully programmatically. Previously, most of the views I’d built were done in Interface Builder (i.e. Storyboards & XIBs), which, in hindsight, is only sustainable for small-scale apps (merge conflicts suck 🙅️).
Having said that, another big change in coding styles for me was no longer using traditional UITableView / UICollectionView for building views. Since almost the entire app is some sort of table view, it wouldn’t make sense to not use a more functional approach. That said, Shopify uses their open source FunctionalTableData (FTD) framework for constructing views. FTD facilitates building views by allowing state-based view rendering (this brings react-like thinking to mobile!). This framework heavily revolves around the Builder design pattern which, in this case, segregates each view into 3 components;
- the state: responsible for maintaining the current source of truth of the view’s data.
- the builder: responsible for deciding what data from the state to display, in what style, and how to handle action events.
- the view controller: responsible for performing or delegating actions passed from the builder, then updating the state accordingly.
That likely doesn’t make a whole lot of sense right now, and trust me, it took me awhile to understand what was going on — but it works so well when properly executed. For example, let’s say you want a cell that has a label on the left, and a checkmark on the right which is displayed conditionally, all you would need to do is tell your builder to create an instance of your checkmark cell template and pass data from the state it needs — such as the label’s text, a boolean whether or not the checkmark should be displayed, and an action block to be execute when the cell is selected. You can also optionally provide a ton of customizations for the cell’s style to perfectly match the design requirements. This approach has completely changed the way I think about building views and was incredibly eye-opening to me when I finally understood how all these working components were pieced together.
In addition, all of my past experience when building an iOS clients with a network layer was either through REST API, or some sort of database integration like Firebase. However, Shopify changed that by introducing me to GraphQL (GQL). GraphQL is a query language that allows clients (i.e. iOS, Android, Web) to request and mutate exactly the data it needs for a given component. This allows for extreme flexibility when building views across multiple clients, and is especially beneficial on mobile clients in terms of saving network bandwidth for the user. I won’t go into many details here, but there are many great resources available to teach beginners about the gist of GQL. I spent a decent majority of my time this summer working on building GraphQL queries and mutations which was a new and challenging experience for me. In order to work with GQL, it requires knowledge of this new query language, such as understanding the syntax and its components — like fragments. Of course, with everything new, it takes time to learn, but really pays of to understand.
Another thing to expect when working as a developer is doing code reviews. Shopify has a really good culture for their CR process where their developers typically dedicate up to a quarter of their day for doing reviews. This was a fairly new process for me as reviewing code was never a top priority during my previous day-to-day schedule. In order for me to properly set aside this time, and get in the habit of reviewing pull requests (PRs), I started scheduling 30 to 60 minute blocks in my calendar purely dedicated to doing code reviews. This dedicated time spent reading and reviewing my teammates code helped me understand how they approach problems, and, in turn, helped me improve my own coding practises. At times, it felt like my PRs were never going to get merged because of seemingly never-ending nit-picky requests, but, in hindsight, all of those little details go a long way when maintaining such a large codebase. Fortunately, with this strong culture of code reviews comes high standards of code.
On a less technical side, since Shopify is such a large organization, a lot of soft skills are needed to work efficiently — such as communication. There were times where I would be working on a feature that would require certain fields to be available for me from the server that weren’t already available. This would normally be fine — just ping the team which “owns” the relevant fields and try and borrow one of their backend dev’s time to get those exposed on GraphQL. However, when working on new features, it wasn’t always obvious if there was a team that owned the data you were looking for. This caused what seemed like a never ending pursuit to find someone with the necessary context to get what you needed. Dealing with this can be frustrating, but definitely taught me a lot about working on projects which spanned multiple teams.
TL;DR — Takeaways
Often the biggest takeaways from a work term are concepts not taught in school — such as being an effective team member. What stuck with me the most was the idea of writing code for others, not yourself. A common misconception for programers (especially found in Junior developers) is that the code they write should be as dense as possible, and use all the new and fancy APIs to impress their coworkers. In fact, this coding practise has a negative impact on your team, and is not specific to iOS developers either. After all, the ultimate goal when on a team is to write code which will be easy for others to read (and maintain).
Thankfully, Shopify provides an amazing environment for growth and supporting employees throughout the learning curve. They host weekly developer talks, team show and tells, community developer events, company-wide summits with workshops and so much more.
If you’re up for the challenge, consider interning at Shopify!