How to get a job as an iOS developer

What to apply for, interview tips, and recommended reading to help you land that job you want.

Paul Hudson    September 8th 2017    @twostraws

Applying for app development jobs can seem a lot like roulette because each company applies different interviewing techniques, some add coding tests to the mix, and most have particular things they look for on your résumé.

To help make the process easier, I’ve put together some tips to help you prepare yourself for any eventuality, based entirely on how I interviewed people previously, what other interviewers have told me, and feedback from readers.

So, in this article you’ll find advice for various levels of developers, a discussion of what might happen in interviews, plus some recommended reading to help prepare yourself fully.

You will never need all of the information below for any single interview, but if you’re interviewing at three or four different places this list should serve you well!

Sponsor Hacking with Swift and reach the world's largest Swift community!

Decide what level you are

This isn’t easy, because it involves a genuine ability to evaluate your skills and experience then decide where you fit in among your peers.

Our industry sometimes has a tendency to say that someone with more than three years of experience is “senior”, but I try to break it down to a more fine-grained level than that. As much as I hate using “years of experience” as a prediction of success, here’s a rough guide just to get us started:

• If you have under one year of experience, you’re looking for an entry-level role.
• If you have fewer than three years of experience, most people would classify you as a junior developer.
• If you have between three and five years of experience, most people would classify you as a mid-range developer.
• If you have over five years of experience, you might be called a senior developer, but at the same time you might just be called an experienced mid-range developer.

Applying for entry-level roles

Make no mistake: applying for an entry-level role can be one of the hardest things you’ll ever do. Not only do most entry-level developers lack confidence in whatever skills they have, but they also don’t have much idea where their abilities fit in compared to others.

So, first I want to re-assure you that if you’re really stressed out about finding your first app development job, or if you’ve been applying to places for months and have yet to make any progress: you’re not alone! It is hard to get your foot on the ladder, and as long as you’re still busy learning, coding, and applying for jobs, then you’re doing the right thing.

Some tips to get you started:

1. Having a portfolio of work is important. This can feel like a chicken and egg problem because it’s not possible to have a commercial portfolio without work, and you can’t get work without a portfolio, but try to break that cycle: put projects on GitHub that you made following Hacking with Swift, put projects on GitHub that you made in your spare time, put projects on GitHub that you forked from someone else and tweaked in interesting ways.
2. Learn to interview well. Find a more senior developer than you, and ask if they could give you a mock interview. Your skills might be limited, but you need to learn to use them confidently!
3. Try to attend some conferences. This helps you get a feel for what other developers are talking about, but is also a great way to build some contacts. Having friends in the right place is the easiest way to get your first experience – even if it’s just a six-week placement, that can be enough to help point you towards your job.
4. Always be coding something. If you’ve been looking for a job for a few months it’s easy to get discouraged, but don’t let that stop you writing code. I can’t overstate how important it is to be able to point at GitHub and say, “this is how I spent the last few months.”
5. Be flexible in what you apply for. If development jobs aren’t in plentiful supply near you, would you be happy applying for QA jobs? Keep in mind that’s it’s easier to switch jobs internally to a company than apply for them from the outside.

Applying for junior roles

Once you’re past the initial immersion into a commercial environment, you qualify as a junior developer and can start to think about the path upwards.

By this point you should be familiar with all the non-coding aspects of being a developer: you’re happy using Git with a team, you’re happy filing and responding to issues in a system like Jira, you’re familiar with Scrum or some other agile process, you’re able to take part in code review in a meaningful way, and so on.

When applying for junior jobs, I believe the issue of “experience” becomes more than a little fuzzy. Thinking purely in terms of Swift, no one has much experience. A lot of people – myself included – started learning Swift the very day it was announced, but even we can't lay claim to having more than a few years of experience.

Mobile is of course different, because iOS has been around much longer than Swift. But you have to ask yourself: if you can demonstrate you're capable of independently making great apps, if you are indeed strong at solving general computing problems, and you have a genuine drive to succeed, would you really want to work for a company that says, "sure, you have all those things, but we need someone with more years on their résumé"?

So, when you’re applying for junior roles there are a few things to take into account:

1. Does this company take you where you want to be? The goal of every junior developer is ultimately to break out of the role and get a great mid-level job where they can shine. Does this company look like a place where you can spend three or more years? Do they care about mentoring junior developers? Do they give you meaningful, interesting problems to solve?
2. Does this company care about the technical things that matter? Although being a junior developer is sometimes known as being a “code monkey”, there are some other important skills you’ll need to pick up if you want to progress. Does this company encourage (or enforce!) good tests being written? Do they take QA seriously, to the point where the QA team is able to halt a release if they aren’t happy? Do they have a structured and sensible approach to UX?
3. Does this company care about the non-technical things that matter? Even if a company helps you write better code, enforces tests, has great QA, and a dedicated UX team, it can still fall down for cultural reasons. Uber, for example, is now positively a poisonous thing to have on your résumé – it’s probably better to say you spent two years in prison than two years at Uber. So, be specific when you interview: do they have a policy to ensure employees are treated equally? What steps do they take to try to get a diverse team? How long do people stay at the company on average? How do they handle failure?
4. Will they pay for you to be trained? That might be attending conferences or workshops, it might be internal “lunch and learn”-style sessions, it might be specific classroom training for your role, or it might just be having a book budget so you have something new to read regularly. The point is that training is essential to driving your skills forward, and if they won’t help fund that even a little then it doesn’t say much for their long-term interest in your career development.
5. Will they let you continue your side projects? Although the work you do from 9-5 is important, I hope you still have your own interests that you want to work on. That might be personal projects on GitHub, it might be speaking at conferences, or it might even be some freelance work. Regardless of what it is, make sure the company lets you continue what matters to you most, without any sort of bizarre copyright assignment clauses in your contract.
6. Are you going to be able to mistakes at this company? Being able to make (and learn from!) mistakes is important to being a junior developer, and you need to find a place that lets you fail, try again, and learn freely. So, look for places that have good code review systems in place to help identify and correct your mistakes, and don’t be afraid to ask about pair programming opportunities with senior developers.

Applying for mid-level roles

If you’re on the cusp of moving from junior to intermediate roles, then my advice is this: fake it until you make it. That is, if you think you’re an intermediate developer and you have several years of experience backing you up, chances are you’re right – or at least close enough that folks can't tell the difference.

So, imagine me tapping a sword lightly on your shoulders: “Arise, Intermediate Developer, here’s your key to the gold-plated bathroom, and here’s the secret button you press to make Stack Overflow users seem less like complete nonces.”

Of course, I’m being more than a bit facetious. Making the move from a junior role to a mid-level role is often a strange experience, and in some ways it’s like becoming an adult – you don’t just turn 18/25/40 and suddenly feel all grown up, but instead it’s a slow, almost ethereal process.

There is no magic point where you get handed a certificate and told you’ve graduated from being a junior developer. Instead, honestly, you stop being a junior developer when you’ve had enough development experience that you are confident enough to take on important tasks without supervision.

That last part can be a sticking point for some people. I expect junior developers to work on important tasks, but at the same time I would always spend some time with them talking through possible solutions, explaining likely problems, and so on. As an intermediate developer you need to be much more independent – you still might get guidance from the lead engineer, but at the same time they should be able to trust you enough to know that if you’re working away quietly then things are going well.

In any sensible company at least, ultimately the only thing that matters for mid-range developers is experience: do you have some proof that you can write iOS/macOS/whatever apps at a certain level? Do you have a portfolio you can demonstrate, and discuss in technical detail? Can you walk an interviewer through what problems you faced and how they were solved? If so, then you’re a great mid-level developer, and should be interviewing for those jobs.

Applying for senior roles

Some people find it hard to differentiate mid-level developers from senior developers, but for me the distinction is pretty clear.

I would expect an intermediate developer to be able to take on tasks independently and solve them with no direct oversight from elsewhere. They might need some guidance how to solve things, but once you've had an initial discussion they should be in a position to design, implement, test, and profile a particular piece of work.

In comparison, I would expect a senior developer to have skills that extend beyond themselves. This would include mentoring junior developers, organizing code reviews for junior and intermediate developers, and providing input into or leading architecture discussions.

In practice, I would also expect senior developers to be able to communicate comfortably outside the development team, perhaps with senior management and certainly with other teams. Ideally, I would also like them to have commercial awareness, so they are able to consider technical decisions alongside the company's revenue needs.

Being a great senior developer isn't just about writing good Swift code: you need to plan, test, debug, document, communicate, and more, and also have a structured, sensible work ethic.

To give you an example, I’m a chartered engineer, which is a UK accreditation for senior developers. Literally not a single part of the application process for chartership focuses on how much code you write – instead they are more interested in how you develop people, how you behave professionally, how you show a commitment to sustainability, and more.

Please don’t imagine that senior developers have some sort of encyclopedic knowledge of coding. In fact, it's important that you understand experts use Stack Overflow, Google, and autocomplete as much as novices.

I've been coding for 25 years now, and it's impossible to keep even a quarter of all that information in my head at the same time. My introductory iOS book, Hacking with Swift is there to give people the foundations for future learning – it will help you try out things like particle effects, WatchKit, iBeacons, MapKit, Core Image, XCTest, and so on, but the goal isn’t to make you memorize these things so you magically become a senior developer

Instead, all I hope for is that at some point in the future when you hit a problem, you think "I solved something like this in project 33 of Hacking with Swift…" and you can then look it up, revise that material, and apply it to your new problem. Unless you're extremely lucky, you're never going to be asked to create an app that is the same as one of the Hacking with Swift projects. Instead, you'll find it's a bit of project 5, mixed with a bit of project 31, and a bit of project 13, plus a new twist.

Developer vs programmer vs engineer vs architect vs ninja rockstar

Job titles are strange things, and job title inflation has meant that just being a developer isn’t enough for some people.

Broadly speaking, there is no difference between being a developer, a programmer, and an engineer. Literally none. They are just different terms for the same thing: someone who creates computer software.

The only exception to that is if you live in a country where some professional titles are legally restricted. In the words of the comedian Dara Ó Briain you should never trust a nutritionist because “nutritionist” isn’t a legally protected job title, so anyone can call themselves a nutritionist. “Dietician” is legally protected, though: “dietician” is like “dentist”, whereas “nutritionist” is like “tootheologist”.

If you’re in one of those countries, then you may need to think carefully about calling yourself an engineer or an architect.

What might happen in interviews?

I can tell you precisely what my own interview process involved. I interviewed a lot of people over the years, and my interview process evolved slowly and steadily as I learned and improved things.

My interviews had five components:

A five-minute introduction from myself. This was always identical: I introduced myself, I introduced the person who accompanied me (it was never one-on-one), I introduced the company and our products and made it clear exactly what we do and what we want to do, and I also outlined how the rest of the interview will unfold. (Pro tip: when your interview offers you a drink, take it. Sipping a cup of coffee gives you an extra moment or two to frame your answers.)

We talked through the candidate's résumé. They said they used X technology for Y company to build Z product – great. Why did they choose X rather than Q? What problems did X bring and how were they solved?

My goal here was to try to get some informal detail about their previous work experience, because when everyone's résumé is glowing you need to find a way to dig a little deeper.

I asked general technical questions about iOS, and Swift/Objective-C. Have they used much Core Graphics? How do you think iOS 7 impacted developers? What excites you most about [whatever the latest iOS version is]? What do you think are the advantages and disadvantages of using Core Data?

The goal here is to try to understand what they know, what they don't know, what they don't know they don't know, and what they want to know.

I'm generally looking to get a sense of excitement from the candidate: I'd much rather hire an average coder who is excited about learning more than an experienced coder who is a bit tired of it all.

Pro tip: with these questions, saying "I don't know anything about Core Graphics," isn't a great answer. Saying, "I don't know anything about Core Graphics, but I'm keen to learn" is immeasurably superior.

I give a short reading test: here is some code, talk to me about what's wrong with it. This was a quick and dirty test; I think there were maybe 12 errors in the code, of which 3 were obvious, 3 took some experience to spot, 3 took a lot of experience to spot, and the rest were just sneaky.

The goal of this was two-fold: if someone failed to spot at least 4 errors and were applying to an intermediate or senior role, we'd usually end the interview shortly afterwards, so this test was helpful to weed out people who had learned all the right buzzwords to use but hadn't spent much time in front of actual code.

However, that was fairly rare, so the real goal of this test was to relax people: reading someone else's code and saying "oh, this line of code isn't ideal because…" is significantly easier to do than writing your own code, so I found this test worked really well to help people loosen up in preparation for…

I give a coding test. "Here is a video of a basic iOS project: please recreate as much as you can in 30 minutes." This was done using Xcode on a MacBook Pro rather than a whiteboard, but – crucially – without internet access.

The app was of course utterly trivial, but I don't think anyone ever finished all of it inside the time. Fortunately, this wasn't a "pass or fail" test: it was a simple and effective way to generate a massive amount of discussion.

When the time was up, we'd ask each candidate to walk us through what they did: how did they approach the problem? Which bits did they solve, and why? How did they prioritize their time? Why did they choose A rather than B?

One candidate wrote no UI code, but instead wrote a fairly extensive class hierarchy for how he thought the code could work. (They got the job.) Another candidate got about a third of the way through, but emailed me later that evening saying "I was disappointed with my performance, so I tried again – here's my finished project." (They got the job too.)

Now, that's just the way I did things, and there are people who will say coding tests are bad, or whiteboard tests are required, or whatever, and that's OK – we all do what works for each of us. However, I think you should at least watch for some basic things: does the interviewer ensure you're feeling comfortable? Are they asking pointless "aha!" questions that don't have practical application? Are they interested in what you're saying, perhaps taking notes or asking follow-up questions?

Recommended reading

I’ve published a few resources that will help you prepare for job interviews, regardless of what level you’re applying for.

• Interview questions for iOS developers contains over 100 questions designed to generate discussion during interviews. They aren’t designed to be hard to answer – the goal is to give you the chance to demonstrate what you know.
• Test your Swift skills using my “be the compiler” tests. This will present you with 20 questions graded at three difficulty levels, and ask you to choose a correct answer. This is a highly technical test designed to hone your Swift knowledge.
• Swift Coding Challenges is a book that presents 64 graded coding challenges for you to solve. Each problem comes with hints, plus solutions and explanations from me, so you learn while you solve.

To finish up, here’s a snippet from the email that gets sent to purchasers of my Swift Power Pack. This is made up of the first six books here, and the email tries to provide some guidance where to start. This is (again) broad brush strokes, but you might find it useful:

Thank you for purchasing the Swift Power Pack!

You've just acquired a massive amount of training material all in one, but just buying stuff isn't enough: it's time for you to read and watch it all, because I hope it's your ticket to a fantastic career in app development.

With so much material, you might wonder where to start, so I want to give you some suggested reading orders.

No matter what your goal, you should absolutely start with the Hacking with Swift guidebook. This sits alongside the main Hacking with Swift book, and gives you revision notes and exercises to help you learn more thoroughly. Open that now, then follow its reading instructions until you complete Hacking with Swift.

Once you finish Hacking with Swift, where you go is down to you…

If your goal is to get into a development career as fast as possible:

Start with Pro Swift: this will teach you advanced Swift techniques that help you code faster and more efficiently.

Continue with Swift Coding Challenges: this will help you work through common interview problems and solutions in Swift.

Finish with Beyond Code: this gives you core engineering skills such as source control, Unix commands, and regular expressions.

If you want to move to a more senior development position:

Start with Pro Swift: techniques like functional programming. protocol-oriented programming, operator overloading and more will help you tackle advanced problems.

Continue with Objective-C for Swift Developers: this will help you understand how the underlying APIs work, and also tackle the kind of legacy codebases you're likely to find in big business.

Finish with Beyond Code: the regular expressions part is particularly useful, but you should particularly focus your attention on the chapters that teach agile planning, team development, and presentation.

If you just want to make the best apps you can:

Start with Practical iOS 10: this walks you through seven advanced projects using new APIs introduced in iOS 10.

Continue with Pro Swift: you'll learn a lot about how to write simpler, smarter code.

Finish with Swift Coding Challenges: this will help keep your brain challenged while you tackle your apps. Try doing one challenge a day to keep you on your toes!

Sponsor Hacking with Swift and reach the world's largest Swift community!