iosNudge

Introduction

Chapter 1 of 10 6 min read

This playbook is a map of the iOS interview. It tells you what each round checks, how to prepare, and what a good answer looks like.

Read it from start to end once. Then come back to the chapter you need before each round.

What iOS interviews test today

An iOS interview is not only "Do you know Swift?". Most companies check six things.

SkillWhat they want to seeTypical round
Problem solvingYou can solve a small algorithm problem in Swift and explain it.Coding (DSA)
Swift and iOS knowledgeYou understand memory, concurrency, UIKit, SwiftUI and the app lifecycle.iOS knowledge
Building UIYou can build a real screen with clean code, states and tests.UI coding or take-home
Design thinkingYou can plan a whole app: layers, data, caching, offline.Mobile system design
CommunicationYou think out loud, ask good questions and accept hints.Every round
TeamworkYou work well with designers, product managers and other engineers.Behavioral

Notice the last two rows. Communication is checked in every round. A correct answer in silence often scores lower than a good answer explained clearly.

How the bar changed

A few years ago, many iOS interviews were mostly trivia: "What is a delegate?" Today the questions go deeper.

  • Swift concurrency is expected. You should know async/await, Task, actors, @MainActor and Sendable. Interviewers still ask about GCD, so know both.
  • SwiftUI is normal. Many teams use SwiftUI for new screens and UIKit for older ones. Expect questions on both.
  • Architecture matters. "Where does this code live, and how do you test it?" is a common follow-up.
  • Quality matters. Tests, accessibility and error states are part of a good answer, not extras.

Here is the kind of code a modern interviewer likes to see. It is small, but it shows concurrency, error handling and testable design.

protocol ProfileService: Sendable {
    func fetchProfile(id: String) async throws -> Profile
}

@MainActor
@Observable
final class ProfileViewModel {
    private(set) var profile: Profile?
    private(set) var errorMessage: String?
    private let service: ProfileService

    init(service: ProfileService) {
        self.service = service
    }

    func load(id: String) async {
        do {
            profile = try await service.fetchProfile(id: id)
        } catch {
            errorMessage = "Could not load the profile."
        }
    }
}

The service is a protocol, so a test can pass a fake one. The view model runs on the main actor, so UI updates are safe. You will see this pattern again in later chapters.

Who this playbook is for

  • Junior developers looking for a first or second iOS job.
  • Mid-level developers moving to a bigger company or a senior role.
  • Senior developers who have not interviewed for a few years.
  • Developers from other platforms (Android, web) moving to iOS.

If you are a beginner, read every chapter. If you are senior, focus on the chapters about system design, behavioral rounds and negotiation.

How to use this playbook

The chapters follow the order of a real job search.

  1. Interview process — the rounds and what each one checks.
  2. Preparation plan — a plan for 1 week, 1 month or 3 months.
  3. Resume — how to get the interview in the first place.
  4. Coding interviews — solving algorithm problems in Swift, live.
  5. iOS knowledge interviews — how to answer trivia questions well.
  6. UI coding and take-homes — building a screen live or at home.
  7. System design interviews — a short framework for mobile design rounds.
  8. Behavioral interviews — the STAR method and sample answers.
  9. Offers and negotiation — comparing offers and asking for more, politely.

Each chapter is short. Each idea has an example: Swift code, a sample answer, a resume bullet or a checklist.

A simple way to use it:

  • Read the Interview process and Preparation plan chapters today.
  • Pick a plan length (1 week, 1 month, 3 months).
  • Fix your resume before you apply.
  • Before each round, read the matching chapter again.
  • After each real interview, write down the questions you got.

How to use the rest of the site

The playbook tells you how to prepare. The rest of the site gives you the practice.

Questions

There are four kinds of questions.

TypeWhat you doGood for
CodingWrite Swift in the browser. Press "Run" for some tests and "Submit" for all tests.The DSA round
UI buildRead the requirements and build the screen in Xcode. Then compare with the solution.The UI coding round and take-homes
QuizRead a question, answer it out loud, then read the model answer.The iOS knowledge round
System designDesign an app on paper, then read a full design.The system design round

Coding questions run on a Linux Swift compiler. So you can use Foundation, but not UIKit or SwiftUI there. This is close to many real coding rounds, where you write plain Swift in a shared editor.

A tip for quiz questions: do not just read them. Say your answer out loud first, like in a real interview. Then read the model answer and see what you missed.

Roadmap

The roadmap shows the topics in a good order: Swift basics first, then memory, concurrency, UI frameworks, architecture and so on. Each topic links to questions. Use it when you do not know what to study next.

Study plans

Study plans are fixed lists of questions for a fixed time, for example one week or one month. They match the plans in the Preparation plan chapter. Pick one and follow it day by day.

What a good candidate does differently

From many interviews, the same habits show up again and again in strong candidates.

  • They ask questions first. "Should this work offline?" before writing any code.
  • They say the trade-off. "I use weak here. The cost is that I must handle nil."
  • They test their own code. They walk through an example before saying "Done".
  • They stay calm when stuck. "I am not sure. Let me think about it this way…"
  • They are honest. "I have not used Core Data in production, but I have used SwiftData."

Here is a short example of the difference.

Weak answer: "A retain cycle is when objects retain each other."

Strong answer: "A retain cycle is when two objects hold strong references to each other, so ARC never frees them. A common case is a closure that captures self while self stores the closure. I fix it with [weak self]. The trade-off is that self can be nil inside the closure, so I unwrap it."

final class SearchViewModel {
    var onResults: (([String]) -> Void)?

    func bind(to service: SearchService) {
        service.onUpdate = { [weak self] results in
            self?.onResults?(results)
        }
    }
}

The strong answer has a definition, an example and a trade-off. The iOS knowledge chapter teaches this pattern in detail.

A note on honesty

Never fake experience. Interviewers ask follow-up questions, and fake answers fall apart fast. It is fine to say "I don't know". Then say how you would find out, or reason about it out loud.

"I have not used NSCache directly. I think it is like a dictionary that frees memory when the system is low on memory. I would check the docs for the eviction rules."

This answer is honest and still shows good thinking.

Next step

Go to the next chapter, Interview process. It explains each round, so you know exactly what you are preparing for.