iOS (Swift) Entwickler Interviewfragen: Die Themen, die am häufigsten vorkommen

iOS Interviewfragen sind technische Fragen, mit denen Unternehmen Ihr Wissen über Swift, SwiftUI, UIKit, Speicherverwaltung und Nebenläufigkeit prüfen. Ich leite seit 2012 Web und Mobile Projekte. Wenn ich Entwickler für die App Seite einstelle, sitze ich auf der anderen Seite des Tisches und stelle genau diese Fragen.

In diesem Beitrag ordne ich die Fragen nach Themen und ergänze kurze Antworten sowie Codebeispiele. Eine Liste zum Auswendiglernen ist allerdings nicht mein Ziel. Zu jedem Thema erkläre ich deshalb auch, was der Interviewer eigentlich misst. Denn eine gute Antwort nennt den Grund, nicht nur die Definition. Weitere Beiträge finden Sie in der Kategorie Software.

Welche Themen decken iOS Interviewfragen ab?

iOS Interviewfragen decken fünf Kernbereiche ab: Grundlagen der Sprache Swift, Speicherverwaltung mit ARC, Zustandsverwaltung in SwiftUI, den Lebenszyklus in UIKit und Nebenläufigkeit. Mit steigender Erfahrung kommen Architektur, Tests und Performance hinzu. Bauen Sie Ihre Vorbereitung daher Schicht für Schicht auf.

In der Praxis sehe ich folgendes Muster. Junior Kandidaten bekommen meist Fragen zu Optionals sowie zum Unterschied zwischen Struct und Class. Auf mittlerem Niveau stehen dann ARC, Capture Lists bei Closures und die Property Wrapper von SwiftUI im Vordergrund. Senior Kandidaten diskutieren zudem Swift Concurrency, Actor Isolation, modulare Architektur und Teststrategie.

Ihre erste Quelle sollte die offizielle Dokumentation sein. Das Buch The Swift Programming Language erklärt alle Kernkonzepte kostenlos. Außerdem beobachte ich, dass viele Interviewer ihre Fragen direkt aus den Kapitelüberschriften ableiten.

Wie läuft ein typisches iOS Bewerbungsverfahren ab?

Der Ablauf unterscheidet sich je nach Unternehmen, ähnelt sich aber meist. Die Tabelle fasst zusammen, was jede Stufe misst. Die Zeitangaben sind eine Startspanne aus meiner Praxiserfahrung, also keine Garantie.

Für das Live Coding brauchen Sie zudem etwas Algorithmentraining. Halten Sie es allerdings im Rahmen. Mobile Runden verlangen selten schwere dynamische Programmierung.

Was ist ein Optional in Swift und wie entpacken Sie es sicher?

Ein Optional drückt im Typsystem aus, dass ein Wert vorhanden oder nil sein kann. Der Interviewer prüft hier, wie Sie mit Absturzrisiken umgehen. Wer reflexartig zum erzwungenen Entpacken (!) greift, verliert meist Punkte.

Vier sichere Techniken reichen aus:

• if let: Sie nutzen den Wert in einem kurzen Block, falls er existiert.
• guard let: Sie steigen früh aus und behalten den entpackten Wert für den Rest der Funktion.
• Nil Coalescing (??): Sie setzen einen Standardwert, falls der Wert fehlt.
• Optional Chaining (?.): Ist ein Glied der Kette nil, ist auch das Ergebnis nil.

func anzeigeName(_ user: User?) -> String {
    guard let user, !user.name.isEmpty else { return "Gast" }
    return user.name
}

Wenn Sie ein guard let erklären, erwähnen Sie zum Beispiel, dass der Hauptpfad links ausgerichtet bleibt. Diese kleine Bemerkung zeigt, dass Ihnen Lesbarkeit wichtig ist. Zudem kann eine Frage zu implizit entpackten Optionals (String!) kommen. Nennen Sie dann Stellen wie IBOutlets, an denen der Lebenszyklus einen Wert garantiert.

Worin unterscheiden sich Struct und Class?

Diese Frage gehört zu den iOS Interviewfragen, die fast immer kommen, weil sie viele Designentscheidungen prägt. Ein Struct ist ein Werttyp, also ist jede Kopie unabhängig. Eine Class ist dagegen ein Referenztyp. Zwei Variablen zeigen auf dasselbe Objekt, und eine Änderung über die eine erscheint auch über die andere.

Eine gute Antwort geht allerdings einen Schritt weiter. Apples Leitfaden zur Wahl zwischen Structures und Classes empfiehlt standardmäßig Structs und Classes erst dann, wenn Sie Identität oder Kompatibilität mit Objective C brauchen. Erwähnen Sie außerdem, dass Array und Dictionary nach dem Prinzip Copy on Write arbeiten. Damit zeigen Sie, dass Sie auch an Performance denken.

Wie funktioniert ARC und wie entsteht ein Retain Cycle?

ARC (Automatic Reference Counting) zählt die starken Referenzen auf eine Instanz einer Class. Fällt die Zahl auf null, gibt ARC den Speicher frei. Anders als ein Garbage Collector arbeitet ARC mit retain und release Aufrufen, die der Compiler beim Build einfügt.

Ein Retain Cycle entsteht, wenn zwei Objekte sich gegenseitig stark halten. Die Zahl erreicht nie null, deshalb entsteht ein Speicherleck. Der klassische Fall: Ein View Controller speichert eine Closure, und diese Closure hält self fest.

viewModel.onUpdate = { [weak self] data in
    guard let self else { return }
    self.render(data)
}

Danach folgt unter den iOS Interviewfragen oft der Unterschied zwischen weak und unowned. Kurz gesagt ist weak immer optional und springt auf nil, sobald das Objekt verschwindet. Unowned setzt dagegen voraus, dass das Objekt mindestens so lange lebt wie die Referenz. Stimmt die Annahme nicht, stürzt die App ab. In der Praxis erwarte ich, dass Kandidaten im Zweifel weak wählen und den Grund nennen.

Wozu dienen Escaping Closures und Capture Lists?

Läuft eine Closure erst nach dem Ende der Funktion, markieren Sie sie mit @escaping. Completion Handler bei Netzwerkaufrufen sind das typische Beispiel. Eine nicht escaping Closure endet dagegen vor der Funktion. Deshalb müssen Sie self nicht explizit schreiben, und der Compiler kann stärker optimieren.

Eine Capture List wie [weak self] oder [count] legt fest, wie die Closure äußere Werte hält. Steht ein Werttyp in der Liste, hält die Closure eine Kopie vom Zeitpunkt ihrer Entstehung. Dieses Detail ist eine beliebte Fangfrage:

var zaehler = 0
let a = { print(zaehler) }
let b = { [zaehler] in print(zaehler) }
zaehler = 5
a() // 5
b() // 0

Erklären Sie, warum die Ausgaben unterschiedlich sind. Damit beweisen Sie, dass Sie das Modell verstehen und keine Regel auswendig aufsagen. Andererseits sollten Sie betonen, dass [weak self] überall nur Rauschen erzeugt. Denn nicht escaping Closures bergen kein Zyklusrisiko.

Warum ist protokollorientierte Programmierung in Swift wichtig?

Swift fördert das Teilen von Verhalten über Protokolle und Protocol Extensions statt über Vererbung. Eine Protocol Extension liefert eine Standardimplementierung. Somit teilen auch Structs und Enums gemeinsames Verhalten, obwohl sie keine Vererbung kennen.

Häufige Fragen in diesem Bereich:

1. Worin unterscheidet sich ein Protokoll von einer abstrakten Klasse?
2. Was macht associatedtype, und warum können Sie ein solches Protokoll nicht direkt als Typ nutzen?
3. Worin unterscheiden sich some und any?
4. Warum nutzt eine Methode in einer Protocol Extension manchmal statischen Dispatch?

Die letzte Frage ist anspruchsvoll. Anders gesagt: Eine Methode, die nur in der Extension steht und nicht in den Anforderungen des Protokolls, läuft über statischen Dispatch. Also kommt die eigene Version des Subtyps womöglich nie zum Zug. Zeigen Sie das mit einem kurzen Codebeispiel, heben Sie sich auf Senior Niveau deutlich ab.

Worin unterscheiden sich Generics, some und any?

Generics erlauben Ihnen, Code für viele Typen zu nutzen, ohne Typsicherheit zu verlieren. Das Schlüsselwort some deklariert einen opaken Typ. Der konkrete Rückgabetyp steht fest, bleibt für den Aufrufer aber verborgen. Das bekannteste Beispiel ist some View in SwiftUI.

Mit any entsteht dagegen ein existenzieller Typ. Er kann zur Laufzeit verschiedene konkrete Typen in derselben Box tragen. Allerdings kostet diese Box Leistung und verlangt dynamischen Dispatch. Daher ist es eine solide Antwort, in performancekritischem Code Generics oder some zu bevorzugen.

func erstesElement<T: Collection>(_ c: T) -> T.Element? { c.first }
let formen: [any Shape] = [Circle(), Rectangle()]

Der Interviewer achtet stärker auf Ihre Entscheidungslogik als auf Theorie. Eine klare Regel wie „Für eine gemischte Liste nehme ich any, für einen einzelnen verborgenen Rückgabetyp some“ bringt zum Beispiel mehr als eine lange Definition.

Wie beantworten Sie Fragen zu Enums und Pattern Matching?

Enums in Swift können assoziierte Werte tragen und Methoden sowie Computed Properties enthalten. Deshalb eignen sie sich hervorragend zur Modellierung von Zuständen. Im Interview sollen Sie häufig die Zustände Laden, Erfolg und Fehler eines Bildschirms mit einem Enum abbilden.

enum BildschirmZustand {
    case laden
    case geladen([Produkt])
    case fehler(String)
}

Danach erwarten Interviewer, dass Sie jeden Fall mit switch behandeln. Erklären Sie, warum die Warnung des Compilers bei einem fehlenden Fall wertvoll ist. Zudem tauchen indirect Enums, der Typ Result und die Syntax if case let auf. Zusammengefasst: Präsentieren Sie Enums als Designwerkzeug, das ungültige Zustände unmöglich macht, nicht bloß als Liste von Konstanten.

Wann nutzen Sie @State, @Binding und @Observable in SwiftUI?

SwiftUI steht heute im Zentrum vieler iOS Interviewfragen. Der Interviewer prüft, ob Sie sagen können, wem die Daten gehören. Eine kurze Regel hilft dabei:

• @State: kleine, lokale Daten, die der View selbst besitzt.
• @Binding: Lese und Schreibzugriff auf einen Wert, der einem übergeordneten View gehört.
• @Observable: das Makro aus dem Observation Framework, eingeführt mit iOS 17, für Modellklassen.
• @Environment: gemeinsame Werte, die Sie in den View Baum geben.
• @StateObject und @ObservedObject: die Trennung von Besitz und Beobachtung im älteren ObservableObject Modell.

Apples Leitfaden zur Migration auf das Observable Makro erklärt, dass ein View nun nur dann neu zeichnet, wenn sich die gelesenen Eigenschaften ändern. Dieser Unterschied ergibt also eine starke Antwort zur Performance. Nennen Sie außerdem einen Klassiker: Wer @ObservedObject statt @StateObject nutzt, riskiert, dass das Objekt bei jedem Neuaufbau zurückspringt.

Wie funktionieren View Identität und Lebenszyklus in SwiftUI?

Views in SwiftUI sind leichte Werttypen, und SwiftUI baut sie häufig neu auf. Entscheidend ist allerdings die Identität. Die strukturelle Identität ergibt sich aus der Position im Baum. Die explizite Identität stammt dagegen aus id() oder aus den Identifiable Werten in einem ForEach.

Ändert sich die Identität, behandelt SwiftUI den View als neu und setzt seinen @State zurück. Deshalb fragen Interviewer gern, warum ein Array Index als Identität in einem ForEach zu kaputten Animationen und verlorenem Zustand führt.

Beim Lebenszyklus sollten Sie onAppear, onDisappear und den Modifier task kennen. Vor allem bricht task seine Arbeit automatisch ab, sobald der View verschwindet. Diese Erklärung zeigt zugleich Ihr Wissen über Nebenläufigkeit. Ergänzen Sie schließlich, warum schwere Berechnungen im body ein Fehler sind.

In welcher Reihenfolge läuft der View Controller Lebenszyklus in UIKit?

SwiftUI wächst, trotzdem laufen viele Unternehmensapps weiterhin auf UIKit. Daher gehören UIKit Themen nach wie vor zu den iOS Interviewfragen. Die Grundreihenfolge:

1. loadView: erstellt die View Hierarchie.
2. viewDidLoad: läuft einmal, hier erledigen Sie die Ersteinrichtung.
3. viewWillAppear: läuft vor jedem Erscheinen.
4. viewDidLayoutSubviews: läuft nach der Layoutberechnung.
5. viewDidAppear: der View ist sichtbar, ein guter Moment für Animationen.
6. viewWillDisappear und viewDidDisappear: laufen beim Verlassen des Bildschirms.

Eine typische Anschlussfrage lautet: Können Sie Framegrößen in viewDidLoad vertrauen? Nein, denn Auto Layout hat das Layout noch nicht berechnet. Die Dokumentation zu UIViewController beschreibt zudem jede Methode und die Regeln für den Aufruf von super.

Worauf achten Sie bei Fragen zu Auto Layout und Table Views?

Fragen zu Auto Layout drehen sich oft um Compression Resistance und Content Hugging Priority. Diese Prioritäten entscheiden zum Beispiel, welches von zwei nebeneinander liegenden Labels zuerst gekürzt erscheint. Können Sie das skizzieren, hinterlassen Sie einen starken Eindruck.

Bei UITableView und UICollectionView ist die Wiederverwendung von Zellen das Kernthema. Eine Zelle aus dequeueReusableCell kann noch alten Inhalt tragen. Deshalb setzen Sie Bilder und Zustand in prepareForReuse zurück. Sonst sehen Nutzer beim schnellen Scrollen falsche Bilder.

Eine moderne Antwort erwähnt zudem Diffable Data Sources und Compositional Layouts. Sie übergeben einen Snapshot und überlassen dem System die animierte Aktualisierung. Wer beide Frameworks kennt, sollte außerdem erklären, wie UIHostingController und UIViewRepresentable die zwei Welten verbinden.

Wie beantworten Sie Fragen zur Fehlerbehandlung in Swift?

iOS Interviewfragen zur Fehlerbehandlung wirken einfach, trennen Kandidaten aber schnell. Eine werfende Funktion kennzeichnen Sie mit throws, rufen sie mit try auf und fangen Fehler in einem do catch Block. try? verschluckt den Fehler und liefert nil. try! lässt die App dagegen abstürzen, sobald ein Fehler auftritt.

Interviewer achten meist auf diese Unterscheidungen:

• throws oder Result: throws liest sich im synchronen Ablauf besser, Result passt zu Werten, die Sie speichern oder später auswerten.
• Eigene Fehlertypen: Ein Enum, das Error erfüllt, macht klar, welche Meldung ein Bildschirm zeigt.
• Typed throws: Seit Swift 6 können Sie genau angeben, welchen Fehlertyp eine Funktion wirft.
• rethrows: Die Funktion wirft nur, wenn die übergebene Closure wirft.

Eine starke Antwort beschreibt außerdem, wie Fehler beim Nutzer ankommen. Ein Button zum erneuten Versuch bei Netzwerkfehlern, eine Weiterleitung zur Anmeldung bei Berechtigungsfehlern und Logging für Unerwartetes zeigen Produktdenken. Kurz gesagt wirkt try? an jeder Stelle wie ein Warnsignal, denn es deutet auf still verlorene Fehler hin.

Worin unterscheiden sich Property Wrapper, lazy und Computed Properties?

Dieses Thema kommt vor allem auf mittlerem Niveau. Eine Computed Property speichert nichts und berechnet ihren Wert bei jedem Zugriff. Eine lazy Property rechnet dagegen einmal beim ersten Zugriff und behält den Wert. Sie deklarieren sie mit var, und sie ist nicht threadsicher. Dieser letzte Punkt zeigt Sorgfalt.

Ein Property Wrapper verlagert das Lese und Schreibverhalten in einen wiederverwendbaren Typ. @State und @AppStorage in SwiftUI sind ebenso Property Wrapper. Möglicherweise sollen Sie einen kleinen selbst schreiben:

@propertyWrapper
struct Getrimmt {
    private var wert = ""
    var wrappedValue: String {
        get { wert }
        set { wert = newValue.trimmingCharacters(in: .whitespaces) }
    }
}

Erklären Sie dann über projectedValue, woher das Präfix $ stammt. So verbinden Sie die Syntax $name in SwiftUI mit echter Logik. Kennen Sie zudem den Zeitpunkt, an dem die Beobachter didSet und willSet feuern.

Wie funktionieren async/await und Actors in Swift Concurrency?

Mit Swift 5.5 kam async/await. Damit schreiben Sie asynchronen Code als geraden Ablauf statt verschachtelter Completion Handler. Ein Actor ist ein Referenztyp, der seinen Zustand vor gleichzeitigem Zugriff schützt. Zugriffe von außen verlangen await, und der Compiler verhindert Data Races.

actor Warenkorb {
    private var artikel: [Produkt] = []
    func hinzufuegen(_ p: Produkt) { artikel.append(p) }
}

@MainActor
func aktualisieren() async {
    let liste = try? await api.produkteLaden()
    ansicht.anzeigen(liste ?? [])
}

Häufige Themen sind @MainActor für UI Updates, unstrukturierte Aufgaben mit Task, parallele Arbeit mit async let und TaskGroup, Abbruch von Aufgaben und das Protokoll Sendable. Wissen Sie zudem, dass der Sprachmodus von Swift 6 Data Races als Compilerfehler meldet. Der offizielle Migrationsleitfaden für Swift 6 ist hier die verlässlichste Quelle.

Kommen Fragen zu GCD und OperationQueue noch vor?

Ja, vor allem bei Unternehmen mit älterer Codebasis. Fragen zu GCD behandeln serielle und nebenläufige Queues, den Deadlock bei sync auf der Main Queue und das Warten auf mehrere Anfragen mit DispatchGroup.

Bei OperationQueue geht es um Abhängigkeiten, Abbruch und die maximale Zahl gleichzeitiger Operationen. Eine gute Antwort vergleicht beide Werkzeuge mit Swift Concurrency. Sagen Sie zum Beispiel, dass neuer Code async/await und Actors nutzt, während Sie alte Module schrittweise migrieren und mit withCheckedContinuation überbrücken.

Der Interviewer achtet hier stärker auf Ihre Migrationsstrategie als auf Treue zu einem Werkzeug. Versprechen Sie also keinen kompletten Neubau in einer Woche. Beschreiben Sie stattdessen einen schrittweisen Plan, der mit einem risikoarmen Modul beginnt und durch Tests abgesichert ist.

Wie bereiten Sie sich auf Architekturfragen zu MVVM, Coordinator und TCA vor?

Kein einzelnes Muster ist die richtige Antwort, denn der Interviewer hört auf Abwägungen. MVC ist der Standardansatz von UIKit, führt aber leicht zu überladenen View Controllern. MVVM verlagert die Präsentationslogik in ein testbares Modell und passt natürlich zu SwiftUI.

• MVVM: gut testbar und passend zu SwiftUI, allerdings kann das View Model anschwellen.
• Coordinator: trennt Navigation von Bildschirmen, verbreitet in UIKit Projekten.
• VIPER und Clean Architecture: klare Verantwortungen in großen Teams, für kleine Apps zu schwer.
• TCA (The Composable Architecture): gerichteter Datenfluss und starke Testbarkeit, mit steiler Lernkurve.

Die Antwort, die ich hören möchte, lautet etwa so: „Ich wähle nach Teamgröße und Lebensdauer des Produkts; ein kleines Team kommt mit MVVM und einer einfachen Navigationsschicht gut aus.“ Damit zeigen Sie, dass Sie nach Kontext entscheiden und nicht nach Ideologie.

Welche iOS Interviewfragen zu Tests und Debugging sollten Sie erwarten?

Fragen zu Tests kommen auf Senior Niveau fast sicher. Sie sollten die Netzwerkschicht per Dependency Injection hinter ein Protokoll legen und im Test ein Mock liefern. Erwähnen Sie zudem neben XCTest das neuere Framework Swift Testing mit den Makros @Test und #expect, dann wirken Sie aktuell.

Häufige Fragen zum Debugging:

• Wie finden Sie ein Speicherleck mit den Instruments Leaks und Allocations?
• Wie erkennen Sie einen Retain Cycle im Memory Graph Debugger?
• Wie finden Sie mit dem Time Profiler Code, der den Main Thread blockiert?
• Welche Fehler findet der Thread Sanitizer?

Beschreiben Sie dann Schritt für Schritt einen echten Fehler, den Sie gefunden haben. Nennen Sie zudem den Test, den Sie danach geschrieben haben, damit der Fehler nicht zurückkehrt. So zeigen Sie Prozessdisziplin.

Wie gehen Sie iOS Interviewfragen im Live Coding an?

Aufgaben im Live Coding sind meist praktisch. Sie laden etwa eine Liste von einer API, bauen ein Suchfeld mit Debounce oder schreiben einen Bildcache. Wiederholen Sie zunächst die Anforderungen und fragen Sie nach Lücken. Klären Sie konkret, wie der Fehlerzustand und die leere Liste aussehen sollen.

Schreiben Sie danach die einfachste funktionierende Version und verbessern Sie sie anschließend. Lautes Denken lässt den Interviewer Ihrem Gedankengang folgen. Bleiben Sie hängen, dann nennen Sie die Optionen, die Sie gerade abwägen, statt zu schweigen.

Kennen Sie außerdem die üblichen Fehler: UI Updates außerhalb des Main Thread, vergessene Zellwiederverwendung beim Bildladen und fehlende Fehlerbehandlung. Sagen Sie schließlich, welche Tests Sie ergänzen würden. So zeigen Sie, dass Sie Aufgaben zu Ende bringen.

Worauf kommt es bei einer Probeaufgabe für zu Hause an?

Eine Probeaufgabe zeigt am realistischsten, wie Sie im Alltag arbeiten. Achten Sie vor allem auf eine saubere Ordnerstruktur, eine Netzwerkschicht hinter einem Protokoll, verständliche Fehlermeldungen und einige sinnvolle Unit Tests. Ohne diese Punkte bringen auffällige Animationen nichts.

Auch die README zählt. Erklären Sie, welche Architektur Sie warum gewählt haben, was Sie bewusst weggelassen haben und was Sie mit mehr Zeit ergänzen würden. Dann liest der Prüfer die Lücken als bewusste Entscheidung über den Umfang.

Denken Sie zudem an Bedienbarkeit: Dynamic Type, Dark Mode und VoiceOver Beschriftungen sind kleine Details mit großer Wirkung. Wenn Sie Ihr Gespür für mobile Oberflächen schärfen möchten, lesen Sie den Beitrag zu Mobile First Design und den Artikel über UX Fehler, die Umsatz kosten.

Was erwarten Interviewer bei Fragen zum iOS Systemdesign?

Senior Kandidaten hören Aufgaben wie „Entwerfen Sie die Clientseite einer Messaging App“ oder „Bauen Sie einen Newsfeed, der offline funktioniert“. Im Gespräch geht es um die Architektur des Clients, nicht um den Server: Datenschicht, Caching, Synchronisierung und Fehlerzustände.

Eine starke Antwort geht die Schichten der Reihe nach durch. Dazu gehören Netzwerk und Wiederholungsstrategie, lokale Speicherung mit SwiftData oder Core Data, Konfliktlösung, Paginierung und Bildcache. Zudem erwarten Interviewer Plattformgrenzen wie Hintergrundaktualisierung, Benachrichtigungen und Akkuverbrauch.

Auch Messbarkeit kommt zur Sprache. Können Sie erklären, wie Sie Analytics Events in der App benennen und die Kampagnenmessung für das Marketingteam versorgen, zeigen Sie Produktdenken. Der Beitrag zu Online Marketing KPIs liefert dazu nützlichen Hintergrund.

Was sollten Sie in Verhaltensfragen und im Portfolio hervorheben?

Interviewer fragen ebenso, wie Sie einen Konflikt gelöst oder einen Fehler übernommen haben. Bauen Sie jede Antwort nach Situation, Aufgabe, Handlung und Ergebnis auf, dann bleiben Sie auf Kurs. Zahlen müssen Sie nicht nennen. Trotzdem sollten Sie die Quelle jeder genannten Zahl kennen.

Eine veröffentlichte App im App Store ist ein großer Vorteil. Fehlt sie, hilft auch ein sauberes Beispielprojekt auf GitHub. Eine persönliche Website bündelt zudem alle Projekte an einem Ort. Wie sie in der Suche erscheint, prüfen Sie mit der Google SERP Vorschau, und den Titel verbessern Sie mit dem Leitfaden zu Meta Title und Meta Description.

Wollen Sie aus Ihrer eigenen App ein Geschäft machen, dann sehen Sie auf den Seiten zu Webdesign und SEO Beratung, wie ich Landingpages und Sichtbarkeit angehe.

Welcher Lernplan hilft bei iOS Interviewfragen?

Folgen Sie einem Wochenplan, statt planlos zu lernen. Die Reihenfolge unten ist ein Startvorschlag aus meiner Praxiserfahrung, also keine Garantie. Verlängern oder kürzen Sie jede Woche nach Ihrem Niveau.

1. Erste Woche: Optionals, Wert und Referenztypen, Enums, Protokolle und Generics.
2. Zweite Woche: ARC, Capture Lists und Lecksuche mit Instruments.
3. Dritte Woche: Zustand in SwiftUI, View Identität und der Lebenszyklus in UIKit.
4. Vierte Woche: Swift Concurrency, Actors, Sendable und der Sprachmodus von Swift 6.
5. Fünfte Woche: ein kleines Beispielprojekt, Tests und lautes Erklären.

Führen Sie am Ende jeder Woche ein Probeinterview mit einer vertrauten Person. Etwas zu wissen und es unter Druck zu erklären, sind nämlich zwei verschiedene Fähigkeiten, und die zweite wächst nur durch Übung.

Ich empfehle außerdem, Ihre Probeinterviews aufzuzeichnen. Beim Nachhören bemerken Sie Füllwörter, Wiederholungen und fehlende Begründungen viel deutlicher. Schreiben Sie dann pro Thema eine Notiz auf einer Seite: Definition, Codebeispiel, ein Risiko und eine Entscheidungsregel. Diese Notizen am Vortag durchzugehen, bringt mehr als eine lange Liste erneut zu lesen.

Notieren Sie schließlich nach jedem echten Interview alle Fragen, die Sie gehört haben. Nach einigen Runden besitzen Sie somit Ihre eigene Fragensammlung, die aus dem Markt stammt statt aus allgemeinen Listen. Viel Erfolg.