Getting that senior iOS developer title

I’ve worked with many developers who would love to get that senior iOS title. Typically, the most motivation is to get better compensated, or to have a better looking resume. While the title of senior iOS developer or senior iOS engineer can be quite subjective across companies, I will try my best to describe what I think is a senior iOS developer, but more importantly how to get there.

The breakdown

So as a developer, you obviously need technical skills, but soft skills become increasingly important as you level up in your career. I’ve made pretty much every mistake in the book in both of these categories, so I’m talking from my experience. In this article, I’ll be focusing on the technical skills. Maybe I’ll write something about soft skills another time.

How to learn

There have been many different studies and personal anecdotes on the subject of studying, but I’ll try and describe what has worked for me. The most effective way to study something, is to be constantly studying it in smaller sessions. That’s about 10 to 60 minute sessions for me personally. Sitting there grinding for hours with no breaks isn’t particularly effective, as your mind’s ability to absorb new info decreases over time. Taking a break provides a mental reset. A rest between sets if you will. The other benefit of smaller sessions, is that it’s a lot less daunting to get started on something. It’s a lot more motivating to study, knowing that you’ll be dabbling for a bit, and then you’ll be done within the hour. Thinking about sitting in front of the computer for 3+ hours learning complicated technical topics can be demotivating, to the point where it will prevent me from even studying in the first place. But short spurts? Much easier, especially when we factor in that most developers are already busy with their careers as is.

The key takeaway is this: you want to build that habit of constantly studying in smaller sessions.

The actual study sessions

Each session you practice should hopefully be made of reading theory ( or watching videos ), and/or actual practice writing code. Both of these work together: theory & practice.

For example, let’s say we want to learn about generics in Swift. We might read about what kinds of problems generics solve – and how they’re implemented in Swift. From there, we can experiment in code with every permutation we can think of. We could start with a generic function, and then work with generic structs/classes, generic constructors. Then maybe start poking around with protocols with associated types, etc… While we’re experimenting in code with these things, we’ll run into all kinds of compiler problems, but as we solve these compiler issues one by one, we’re building up our repertoire of how to solve these problems. It might not seem glamorous, but knowing how to get the actual idea in our head to compile is equally important as the theory itself. When a developer understands theory, and can execute in code, this is what I think of as a senior iOS developer.

Playgrounds & Sample Apps

I always recommend people to have their own playground or sample app where they can experiment and test things out without the pressure of a full on production app. It compiles much faster, and allows quick experimentation.

Playgrounds

Pros of Playgrounds:

They’re super lightweight.
Easy to generate many different pages.
Can compile partially, even if other pages are broken.
Can include dependencies.

Cons of Playgrounds:

No breakpoints.
We need to learn about playground specific quirks, such as handling async code.
Harder to include third party dependencies.

Test App

The test app approach is best done by writing things in unit tests. It allows a sort of pseudo playground approach, because we can run specific unit tests.

Pros of Test App Approach:

Can use breakpoints.
Can include dependencies.

Cons of Test App Approach:

Generally not as performant as playgrounds.
All of our code needs to be in a compiling state.

Topics to study

There’s loads of things we can work on as iOS developer, but here’s a starter list I think would be a great place to start:

Things to study:

Concurrency.
Value vs reference types.
Closures.
Reference counting (the memory model ARC uses. Also understand how strong reference cycles are formed).
Protocols
Extensions.
Dependency Injection.
Unit testing.
UIKit / SwiftUI.
Architecture (MVVM, MVVMC, MVC, TCA are probably the ones you should be aware of).
Generics / protocols with associated types / generic type aliases / opaque types.
KeyPath (bonus points if you learn about CasePaths)
Mirror (reflection).
Build systems / CI / Dependency management.

Hacking with Swift questions

Paul from Hacking With Swift also has a great set of interview questions to look at. The way I used these, I tried to answer each question on my own, then looked at the answer. Then, I went on a wild reading spree to learn everything about the answer and the question. [HackingWithSwift interview questions[(https://www.hackingwithswift.com/interview-questions).

Coding challenges

Certain companies interview with coding challenges more than other companies. This is particularly true for big tech companies, bay area companies, and fintech companies. I like it when companies provide you with coding challenges that you can just “logic it out”, however, there are many situations where one needs to have a good amount of practice going into them.

The industry’s defacto coding challenge site at the moment seems to be Leetcode, as the site itself is free. However, if you’re looking to save some money by skimping on the their Leetcode premium (which is pretty great)!, then you can also use Neetcode, which has free video solutions. There’s also the forums on Leetcode itself which usually has some good solutions, but usually don’t explain to how what’s going on.

The term “Blind 75” has gained a lot buzz lately. What is this? It’s a set of 75 questions that cover a variety of topics, and covers a multitude of different problems that require different solutions. Neetcode has even expanded it to have their own 150 questions.

Coding Challenges in an interview

It’s very important to know that it’s fine to use use a solution that’s easy as possible to implement, even if it’s brute force. You can then state the time and space complexity, but then you should talk about other solutions, and why they are faster / more performant. You also need to keep talking out loud as much as you comfortably can, and ask for some time to think if you need a few minutes.

Usually, if the interviewer likes you, they are far more likely to provide you hints on your coding challenges – to the point where they can give you the answer. How do you get someone to like you? That’s a very complicated topic, but keeping the vibe light is probably a good place to start!

Additionally, there’s all kinds of content creators on Youtube etc, where you can see mock interviews, and what interviewers like to see. So I would probably check out at least some of those videos to be familiar with the interview process itself.

If you’re only going to do limited studying on coding challenges, typically you want to focus on Arrays, Strings, and Linked Lists. Often times, that’s enough to get you by.