What to apply for, interview tips, and recommended reading to help you land that job you want.
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!
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:
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:
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:
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.
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.
Uh, thanks? I’d prefer not to be considered a beast…or ninja or rockstar or whatever stupid terminology is used now ???? pic.twitter.com/FucztdulKu— Kristina Thai ⌚️ (@kristinathai) February 22, 2017
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.
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?
I’ve published a few resources that will help you prepare for job interviews, regardless of what level you’re applying for.
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!
SAVE 20% ON iOS CONF SG The largest iOS conference in Southeast Asia is back in Singapore for the 5th time in January 2020, now with two days of workshops plus two days of talks on SwiftUI, Combine, GraphQL, and more! Save a massive 20% on your tickets by clicking on this link.
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and a speaker at Swift events around the world. If you're curious you can learn more here.