When I was at the beginning of my career, my first developer job application was to a design agency who were doing Mac development too. It was pretty nerve-wracking to apply for my first programming job, and I came into the interview with no idea what to expect. I had just graduated from university and was at the first few steps of my career, I'd call this being a junior. It was a time period where I would need mentoring, and supervision in order to grow. A good explanation is in this StackOverflow.
Now that I'm both further on in my career, and involved with so many juniors in NYC, I'm meeting with a lot of people who are in the same position I was then and I get a lot of questions asking what they can do to prepare. This post attempts at being a comprehensive collection of recommendations. It is subjective, of course, and strongly biased towards my experiences.
Before I jump through to the article, there's one thing that should be above the fold. Chill out. You might not get it right on the first try, I've applied for jobs and received a "no thanks." Yet eventually I became the head of mobile at Artsy. Everyone finds their place in time.
On Your Readiness
I had a long list of specific things relating to Xcode and iOS. They were very tedious things like, “you should know how to add a new file to an Xcode project.” I’ve shortened that list to a general description here.
I expect you to be able to start a new project, write some code to download a bit of JSON via HTTP, and use the parsed JSON to present some data in a UITableView.
If you can do that, in a well organised manner, and can discuss the choices you made to get your app built you’ll have been able to do almost everything that was on that long and tedious list.
This is a great starting point. In an ideal world, an interviewer isn't going to judge you on not knowing every detail about the whole system. They will have expectations that you're going to have to learn on the job for a lot of things, and that's ok.
On the lookout
There are a bunch of websites for putting up job adverts.
- StackOverflow jobs
- Natasha The Robot's Swift Jobs
- Core Intuition's Jobs Board
- Apple's Jobs Site
These kind of things work, I got my first programming job through CocoaDev Jobs.
These are great, but in my opinion the best way to find out what companies are hiring is to attend meet-ups in the city. In NYC we have 3-4 big iOS meet-ups a month, and all of them give a chance for people looking for others to work to speak up. You might not live in as big of a city, but I used to travel an hour to Manchester to attend a meet-up, they would have the same thing, I almost became a full-time rubyist because of it. I have quite a few friends in NYC who started their careers by talking to someone at a meet-up.
Generic job websites can be good, for example Artsy's job postings are on AngelList and Glassdoor but the vast majority of applications feel like they were sent to a lot of companies. They are given a low priority when compared to direct inquiries because of this. I can't speak from experience but Ladders, LinkedIn, Hired and weworkremotely are probably worth a look too.
Finally, search the websites of companies you like for careers or jobs pages.
If you see an advert for a mobile developer, but they don't mention juniors, you should apply anyway. We've never had junior positions on our jobs pages, but have hired some who inquired anyway. Don't pretend to be more senior than you are though, set the right expectations.
Finally, consult your network, talk to people at meet ups, sneakily contribute to open source projects with people you want to talk to and then email the project owner after they've got to know your name.
On a Coffee
Know what goes a long way? Talking with someone before applying. I regularly get coffee with applicants or potential applicants when I'm in NYC. Coffee can be hard when applying for junior roles when remote, but so far, to my knowledge I've not talked to anyone who hires a junior as a remote developer. I'm not sure it could work unless the entire team was remote, or the junior developer had a lot of experience and was only a junior in the sense that they were just hitting the work-force.
These are 15-30 minute informal chats, but from an employers perspective they are definitely a good way to filter candidates. A coffee is time-cheap, interviews are time-expensive. So ask someone on the dev team to do them, you'll usually get a yes. Tamar Nachmany has some great, salient points on the right way to pitch these emails.
It's definitely worth doing your homework on both the person doing coffee, and the company they work for. A coffee could turn into an interview.
But I don't live in a major metropolis
So meet-ups aren't going to work for you. I lived for most of my life (\~25 years) about 2 hours train ride from Manchester. I love the little town, but there's very little meet-up scene or tech scene at all. Our meet-ups were people all starting together, and without a general core set of experienced people providing some consistency.
Personally, I wouldn't hire a junior who was remote. I don't think that relationship would work out well for mentor/mentoree. You'd need the entire company to be remote for that to work, and it's too much to ask for someone to be both learning everything on the job and to also have to play catch-up with company culture.
So then what are the options? When I was looking I took a local white-pages/local ads and applied to all of the companies in my local area who were doing what I was interested in. I ended up working somewhere close enough to walk to work.
The other option is to move to a big city with existing infrastructure. This can obviously be hard, but being surrounded with people doing similar things is difficult to put a price on. I never wanted to move to a big city, but once I did, it boosted my abilities to get things done considerably. Constant access to people and ideas change you. Most people now live in cities.
Finally, one of the best ways to distinguish yourself if you're going to aim for remote is in Open Source contributions. The process of contributing to Open Source is very similar to working as a remote developer. They both require self-motivation, clearness in your messaging and dealing with asynchronicity well.
On an Intro Email
Look at the language in the jobs page, and have your email / intro letter reflect that. When I receive very formal "dear hiring manager" emails it reflects badly on the applicant, our jobs page states to not worry about that, as we're not that kind of culture.
An intro email is your chance to show that you understand the core value of a company. For example when I receive applications that only talk about our contributions to OSS then I wonder if they've even studied what Artsy is, and how OSS by Default is derived from deeper values as opposed to being an end-goal in itself. If you apply to Facebook and the only thing you mention is React-Native I think you'd also be missing the point of Facebook. A great opener to Facebook might talk about how amazing it is that they can work on a product that pretty much everyone they meet uses, and you think it's amazing that there is now 1 billion active users a day. It shows you understand the scope of their problems, and have done your homework.
Let's look at Ash's intro email:
My name is Ash Furrow and I’m writing in regards to your mobile engineering position. I heard about the position first through Orta Therox, who spoke highly of Artsy.
Upon further reading, Artsy sounded exactly like the kind of place I want to work. An ambitious goal, to change the world, with a thorough mix of math, software engineering, and art. I consider myself to be an artist, both when I code and when I am behind the lens of a camera (I like to develop my own film). I love working with companies who understand the important role of art in our society, as I did with 500px.
10/10. Extremely on topic.
Next, you're going to want to now talk about great of a fit you would be, how well you understand the domain and how you've been doing similar work already.
I love how you’ve contributed back to the open source community. I am a strong believer in the power of open source, especially in the iOS community, where there has historically been a resistance to opening software. Sponsoring CocoaPods is a fantastic contribution toward the iOS community and I thank you for it. I’ve contributed back to several projects on GitHub, have written for the Teehan+Lax blog professionally, and have a selection of the apps I’ve written on my portfolio.
I know what you're thinking: "Ash wasn't a junior when he applied", well, chances are you've still got a history of things that can be applied towards an email like this. Also, flattery can get you everywhere. "I've been using your app for years, I love how it does 'x' - have you thought of doing 'y'?"
Sarah's was similar:
First, I'd just like to say I love Artsy and have been following your company since I learned of its existence two years ago. Making art accessible to the world is a problem the architects of the Internet should undoubtedly be solving and Artsy is doing so with elegance.
I'm currently transitioning from embedded systems to iOS development and looking for a place where I can learn a lot while making significant contributions to a product. As for my background, I just graduated from NYU with a B.S. in Electrical Engineering and completed a seven-month-long research and development internship at Canary (a home security hardware startup). While I do enjoy building hardware, I find software engineering generally more fun and in tune with my intellectual and creative preferences.
On a Portfolio
on wording: I use the word portfolio, to encapsulate a CV/Resume/Design Portfolio. They all have specific meanings, but in this case, I mean something you attach to the email to provide the full context of your history/experiences.
There are a lot of places for good, solid advice on the document you are using to persuade someone to interview you. So I'll tell you what has worked for me. I think it should be a one page document, that captures a snapshot of you. Things they must have: your name, a way to contact you and a list of things you think is relevant.
You should consider what you think are qualities that you bring to the table, for some job applications I have submitted both a resume and a design portfolio. If you are particularly proud of your design work, perhaps find a way to include your app store screenshots and branding, or make your portfolio distinctive via design.
Finally, consider that this is a document someone else will have to read. A dense document full of long descriptions and wordy titles is tough to read. Spend some time on making it as readable and easily digestible as possible.
On Representing Myself
I dug through my archives and found every resume I have ever created; ranging from my first as a student, through to last year.
- 2007 as a part of the WWDC Student Scholarship. It was significantly less competitive then.
- 2008 as a graduate applying for jobs that were not programming focused.
- 2008 as a graduate applying for programming jobs.
- 2010 when applying for jobs once I had stopped being a junior.
- 2015 my CV as a part of my U.S. VISA process.
You can definitely get a sense of my skill specialisations happening over the last 8 years, but the tone of how I present myself hasn't really changed.
On the team
Want to know what the resumes looked like for people applying to Artsy? I asked some of our team to send me their last resumes
|Ash Furrow (2013)||
Sarah Scott (2014)
|Maxim Cramer (2015)|
A portfolio can be whatever you want it to be. You could spend forever on a portfolio, but it's really just an exercise in restraint and prioritisation. Eventually it's been shaved to a point where you can remove nothing more.
More infö that I've reviewed and given a 👍:
- iOS Developer Resume Examples - Somehow I ended up sneaking on this article too.
- 8 Minute Guide to Writing a Resume - Marc has a lot of experience in this space, plus his advice is definitely better if you're focusing on larger companies.
On The One
So you know exactly who you are interested in applying to. One of your passions in life is to make music, and you think being a engineer at Spotify would be a dream job. How do you increase your chances?
First up, you should have some experience before you apply. Apply at one or two other companies that you'd also really like to work for first, test out the water. Then for Spotify, you should make sure everything is perfect for them. Write a new CV and mention your band on it, include links to your music in the bottom. Consider Maxim's portfolio above, this was obviously made specifically for an audience of Arts/Tech people, Sarah's also talks about activism and art projects. These are well-tuned portfolios for an audience of Artsy.
A lot of companies have public employee get-togethers, for example at Artsy we have weekly Happy Hour in the office, or Peer Labs where you can meet a lot of the people working at a company. This is a great way to mine the employees for information about the culture and to try and peek behind the curtain. In the case of Spotify, they host a lot of meet-ups, try attending some at their offices.
On Interview Preparation
So you've got an interview, be gracious in setting up a time, it's normal for a bit of back and forth, the company probably has to find a time for a lot of people.
There's a lot of value in a collection of interview questions though, one that IMO is a solid resource is CameronBanga/iOS-Developer-and-Designer-Interview-Questions on GitHub. You could get asked a few of these.
Be cautious with links on the internet here, some of the top links to search here are probably not great for people starting. They aim at a different audience, or focus on minutiae that juniors probably don't know. If you want to help out there, and you're linking to this blog post on a website link it with the name include "iOS interview" in the text of the link.
One book that is considered the go-to for interview preparation is Cracking the Coding Interview, it's considered a great guide to some of the computer-science-y questions you could get asked.
I didn't study Computer Science
Then I'd definitely recommend Cracking the Coding Interview. I don't think this is a blocker at all - we have a lot of engineers on staff who do not have a computer science degree. In our line of work, having experience of the art world can be more useful in a lot of cases. It's very likely that you'll feel a hint of impostor syndrome - you shouldn't - the tech industry should be (and is) begging for people who can bring interesting new contexts.
During the process of setting up your interviews, you should ask what to expect from the interviews. If they are going to be whiteboards + algorithms like they do at Google/Facebook, then I think you're gonna have to hit the books.
If you can do Mock Interviews you should. You need an existing network in order to pull that off, but you can get real feedback that can be extremely helpful. As an employer you have to be very cautious in the way you word a rejection, in a mock interview you don't. This isn't a one-sided process, the interviewer can use the chance to try out a different technique or to improve their interviewing skills.
If you don't know anyone who can do this for you, I'd feel like there are two options: buy a mock interview and befriend someone who says they're looking for someone at a meet-up - they must be interviewing so they might want a practice run too. I've given about as many mock interviews as I have done real interviews in the last 2 years.
More info that I've reviewed and given a 👍:
- So You Have a Technical Interview at Macoscope - Again, probably a bit more than expected of a junior, but a great summary of how they do it
- How we hire - How Google's hiring process works.
On iOS Interviews
To be at this point, a employer has already decided to invest probably something like 10 hours into you. This is spread across a few people but the point is important. To have got here, someone has to be on your side. They will have had to put in work to even get people to agree to schedule you into their day. Your mindset should reflect this, it's not you vs them. It's you and someone. Your job from here is persuading everyone else that gut feeling from that person is correct.
There is no catch-all solid advice for interviews, but I can give you some of the things we talk about in Artsy.
We look for T shaped engineers, even in juniors. This means someone who has experience in a pretty wide net of things, but that they have a solid focus. This could be building their APIs for apps, writing their own blog, designing their website, automating some regular tasks or using technology for art.
As a junior, the employer is looking for growth potential. Looking for people who, in the right environment could really thrive. However it's important to note, an interview only lets you know how well someone interviews. The greatest programmers can choke on interviews.
You should come in with a few ideas about questions you'd like to ask of the company, as interviews work both ways. Think of some specific to the space the company works, and this is a great list of general questions to work from. You could consider them icebreakers, or they can be used to finish up an interview. The most memorable question asked to me was "Where would I work if I wasn't at Artsy?" which threw me off completely, but probably told the interviewer a lot about the culture at Artsy.
How I interview Juniors
One thing I can tell you concretely though, is what I do. My interviews with juniors come in three parts:
I want to get someone comfortable with the interview, I'll have taken points from looking over the portfolio to explore. It will be a pretty one-sided conversation with me only trying to provide points to spring off. "So tell me about when you did x".
I want to get a sense of how you use a computer and act under mentorship. So I do one of two things, depending on how work has been the last week. If there's been a pull request which seem small and contained enough from our team on one of our apps, I will pair on re-creating the pull request from scratch, without letting it be known that the PR had already been built and accepted. If there isn't, we'll take a pre-built broken app and fix it.
I want to see things like; do you use Xcode shortcuts? Can you explain the code you're looking at? If I offer some advice, do you use it? Can you present ideas when we're figuring out an abstraction? Can you identify where problematic behaviour lies?
Learn you a thing
Alright, so I've been building up the applicant's confidence and now it's time to bring that all down. Sorry. I have been paying attention to finding out what the applicant doesn't know. Then I start asking questions about this. It doesn't really matter what the topic is, it could be threading, view controller lifecycle, code coupling, dynamic vs static dispatch, whatever. The point is that I want to understand how someone learns during a discussion. So the conversation tends to switch around, where-in I lead a conversation on the topic - try to lay foundations then experiment with questions that should require an understanding of the topic.
Here's a long writeup, with a lot of depth (and places to jump off from) from someone who has just come out of a mock interview with me. Thanks Jon.
None of this process aims to be adversarial, if someone has got this far, I really want to have a sense of how much time and attention will be required to give them some independence. I think a lot of interviewing techniques are created organically, so it's hard to provide a lot of context.
References are important to everyone. When you're trying to get a sense of what someone's like on the long-term, asking their friends is a great idea. Colleagues tend to be the next best thing. We tend to ask for someone you reported to, someone who was a colleague and if you had reports one of them.
Artsy puts a lot of priority on references, Check out Brennan Moore's article on this, a lot of the behind the scenes emails afterwards uses quotes taken from references as examples of why someone should be hired. I don't think this will be unique to Artsy. References should be your cheerleaders. In an ideal world you should be looking for references like the ones we got for Maxim:
However, if I had to fire people gradually, I'd fire her last. her skill-set is so valuable, and so scarce that it's super valuable. I'd fire me before her.
She was the glue that held the team together - could talk at a different level to each contributor. Great intuition, could put in a room with anyone and they could understand how to get their bits done.
I respect that no-one is in control of other people, so yes, references are a bit of a wild card from a junior's perspective. However, hopefully you've had a collection of positive interactions with people who can talk about that. It's not about your programming prowess at this point, it's about how you work with others and character reference. Consider listing professors, advisers or supervisors from other jobs.
About that thanks
Sending an email to say thanks for your interview seems to be the ettiquette in the US. I don't recall doing it for my interviews, and not every person I've interviewed at Artsy has done it. When I brought up the concept recently, people mostly felt like another chore in the process. So, I'd recommend doing it - but do it with a purpose. Provide a link to something you talked about during the interview and make it feel like an email with a reason to exist.
On the Aftermath
So, interviews are over. What is happening behind the scenes? After your interviews are done, there will be a flurry of behind the scenes emails. From my experience at Artsy, it probably takes a few days to get enough of a consensus around a yay/nay. Someone should be keeping the applicant up to date, even if it's a matter of "not yet, but we're talking."
This bit is hard, because you're in limbo, and it can take a while. I think with Sarah this took about a week and a half, from her final interviews to being able to send her an offer. Which I'm sure for her weren't great, she could be so close to an offer - or weeks wasted on moving towards another. Sending "How's it going?" emails is totally fine if you've not heard back in a week. It's not cool for a company to not get back to you if you have interviewed.
On the Launch Pad
OK, so you've been given an offer. If it's a startup, you might be offered equity. If you don't know this world, that's OK, it's hard to give advice here - but this seems to be the most comprehensive resource, and this seems to be the best starter. I started with no knowledge, and eventually got a reasonable understanding. If you want one sentence from me, "equity is a risk, be damn sure you think the company is going to go somewhere." I opted for a chunk of equity in Artsy, but I've worked at places where I've taken the minimum option.
Ideally you are presented with a great offer, I've never negotiated salary and we don't do it at Artsy as it introduces bias, so I can't offer much there. But I have recieved some good advice I'll paraphrase.
It's up to you whether to negotiate. In order to negotiate, you need to have an understanding of what people in similar companies/positions are. Ask people in the industry, friends and mentors. Talk in pay-ranges if that's easier. Note: The type of company, its/your location, benefits, equity and the economy are all things that will move those ranges.
OK, so, while I have your attention, what else can I recommend?
The way in which you present yourself online will attract similar people. If you are always being negative, and it sure is easy, expect to end up surrounded with people who are similar. Being nice is nice.
If you have a blog, and it's on medium, look into making/editing your own blog. Jekyll is the defacto go-to in that space, but I know people have enjoyed using middleman and hugo. Do not use Octopress, vanilla Jekyll will do you just fine.
If you're not active on Twitter, you should start trying. Every time you think of something worth saying to someone next to you, say it to them, then say it to twitter. Show off pictures of what you're working on, reply to people with more followers than you when they ask questions, talk about code. It took me 4 years to hit my first thousand followers, hopefully you can be more interesting than I was for a while.
This article covers how developers in general use twitter it's an interesting read. You can get a lot of value by following developers whose work you rely on, or whose blog posts you think are awesome.
When people say GitHub is your resume, they are right and they are wrong. GitHub can help get you through the door, but you can't rely on that in your interviews. Check out the advice at the end of this post on how to make your GitHub look good for people looking at whether to interview you.
However you can distinguish yourself by contributing to Open Source: Fix READMEs, improve documentation or the Pods you use. These slides go into other ways to contribute.
The other side of community work is to devote time to helping out on Stack Overflow, follow tags that you know something about, or want to - and try respond to a few.
Some links for further reading
- Male Programmers Privilege - The geek feminism wiki is a great resource for understand some of the less positive aspects of a male-dominated culture.
- The Social Coding Contract - I'd recommend this to anyone on any topic, regardless of what they were really asking.
- Git Conflicts and Empathy - Understanding that a git conflict is that two people really want to do something positive.
- Finding Joy at Work - On the risks of being in a small company.
This blog's best-of for Juniors:
- OSS Expectations - On how to talk the talk when thinking about Open Source.
- Being a good OSS citizen - On how to walk the walk when contributing back.
- Video code-reviews: Eidolon / Emergence - On the gestalt of an app.
- Dropped Design Patterns - On understanding that technical decisions aren't permanent.
- How To Write Unit Tests Like a Brood Parasite - On using metaphors to understand complex ideas.
- Artsy's Engineering Compensation Framework - On ways in which you can rank yourself.
- The Culture of Openness in the Artsy Mobile Team - On how a team talks about it's culture.
- Building the Xcode Plugin Snapshots - On how your tools can be improved, and how easy it is to get started.
- MVVM in Swift - On understanding that there is more than one way to skin a cat.