Interviewfragen für App-Entwickler, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Sag jede kurze Antwort laut und verbinde sie dann mit einer App, an der du gearbeitet hast: der Screen, das Problem, die Zahl, die sich bewegt hat. Interviewer für App-Rollen öffnen gern deine eigene App auf einem Handy und fragen danach, also kenne ihre Schwachstellen, bevor sie sie finden.

Was ein App-Entwickler können muss

• Die Plattform: SwiftDie Sprache des modernen iOS: Werttypen, async und await und SwiftUI oder UIKit für die Screens. und SwiftUI auf iOS, KotlinDie Sprache des modernen Android: Coroutines für Arbeit im Hintergrund, Null-Sicherheit und Jetpack Compose für die Screens. und Jetpack Compose auf Android oder ein Cross-Platform-Werkzeug wie Flutter oder React NativeReact Native baut Apps für iOS und Android aus einer Codebasis in JavaScript oder TypeScript; wisse, wo es nativen Code braucht., mit Xcode und Android Studio als tägliche Werkzeuge.
• Das Leben der App: was das System tut, wenn der Nutzer die App verlässt, zurückkommt oder der Speicher knapp wird, und wie der State das übersteht.
• Daten und Netzwerk: REST-APIsDas Backend gut aufrufen: Timeouts, Wiederholungen, Paginierung, Caching und Fehlermeldungen, die ein Mensch versteht. oder GraphQLManche Backends bieten es an: Abfragen für genau die Felder, die ein Screen braucht, und ein Cache auf dem Gerät., Caching, Offline-Speicher und Synchronisation und Fehler, auf die ein Nutzer reagieren kann.
• Qualität: Unit-TestsTests für View Models, Parsing und Geschäftslogik, die bei jeder Änderung in Sekunden laufen., UI-Tests auf Geräten, Absturzberichte, Performance und Akkuverbrauch.
• Ausliefern: die Build-PipelineJede Änderung wird von der Pipeline gebaut, getestet und signiert; Store-Uploads und Testversionen ohne Handarbeit., Signieren, die Review-Regeln der beiden Stores, gestaffelte Releases und Feature Flags.

Plattformen und der Lebenszyklus der App

Nativ oder Cross-Platform: Wie würdest du zwischen Apps in Swift und Kotlin und einer gemeinsamen Codebasis in Flutter oder React Native wählen?

Worauf sie achten: dass du die Anforderungen des Produkts und das Team abwägst und nicht nach Geschmack argumentierst.

Kurze Antwort: „Nativ heißt eine App pro Plattform, in der eigenen Sprache und mit den eigenen Werkzeugen der Plattform; Cross-Platform heißt eine gemeinsame Codebasis, die auf beiden läuft. Ich frage, was die App mit dem Handy tun muss, etwa Kamera, Sensoren, Arbeit im Hintergrund oder Widgets, wie sehr sich die beiden Apps unterscheiden und wer im Team ist. Viele Gerätefunktionen und ein plattformtypischer Look sprechen für nativ; eine App, die vor allem aus Formularen und Listen besteht, mit einem kleinen Team, spricht für eine gemeinsame Codebasis.“

Die ausführliche Antwort: Beide Wege bringen gute Apps hervor. Nativ bringt die neuesten Funktionen der Plattform vom ersten Tag an und das direkteste Debugging, um den Preis, Features zweimal zu bauen. Flutter zeichnet seine eigenen Screens und verhält sich auf beiden Plattformen gleich; React Native nutzt die eigenen Bausteine der Plattform und passt zu Teams, die schon TypeScriptDie übliche Sprache von React-Native-Teams; typisierte Props, State und API-Aufrufe halten eine gemeinsame Codebasis sicher. schreiben. So oder so bleibt etwas nativer Code für Zahlungen, Benachrichtigungen oder Hardware, also braucht auch ein Cross-Platform-Team jemanden, der jede Plattform kennt. Viele Firmen teilen auch nur die Geschäftslogik, etwa mit Kotlin Multiplatform, und behalten native Screens.

Schwache Antwort: „Cross-Platform ist immer billiger.“ Nachfrage: „Unsere App nimmt Videos auf und lädt sie im Hintergrund hoch.“ Nenne die beteiligten Funktionen der Plattform und wo bei jedem Ansatz nativer Code nötig wäre.

Der Nutzer wechselt mitten in einem Formular in eine andere App. Was passiert mit deiner App, und wie gehst du auf iOS und Android mit dem Lebenszyklus um?

Worauf sie achten: dass du weißt, dass das System entscheidet, wann deine App läuft, nicht die App.

Kurze Antwort: „Die App geht in den Hintergrund und kann jederzeit ohne Vorwarnung beendet werden, um Speicher freizugeben. Also speichere ich, was der Nutzer eingetippt hat, während es sich ändert oder wenn die App den Vordergrund verlässt, stelle es wieder her, wenn der Screen zurückkommt, und verlasse mich nie darauf, dass eine Aufgabe im Hintergrund fertig wird, außer ich habe das System um diese Zeit gebeten.“

Die ausführliche Antwort: Beide Plattformen führen Apps durch Zustände wie aktiv, im Hintergrund und beendet, und beide schicken bei jedem Wechsel Ereignisse. Auf Android wird ein Screen außerdem neu aufgebaut, wenn das Handy gedreht wird oder die Sprache wechselt, also gehört der State in ein View Model oder einen gespeicherten Zustand, nicht in den Screen. Lange Arbeit geht an die eigenen Scheduler des Systems, die Akku- und Datenlimits beachten. Teste es gezielt: Schalte die Entwickleroption ein, die Hintergrund-Apps beendet, dreh das Handy, wechsle die Sprache und schau, was überlebt.

Schwache Antwort: „Die App läuft im Hintergrund weiter, also ist das Formular noch da.“ Nachfrage: „Ein Nutzer kommt nach einer Stunde zurück, und die App öffnet auf dem Startbildschirm.“ Erklär den beendeten Prozess und wie gespeicherter Zustand und Deep Links den Nutzer zurückbringen.

Architektur, State und Offline-Betrieb

Wie strukturierst du die Architektur und den State einer App, damit ein Team sie weiter ändern kann?

Worauf sie achten: klare Schichten, eine einzige Quelle der Wahrheit und Code, den andere testen können.

Kurze Antwort: „Ich halte drei Schichten: Screens, die nur State zeichnen, View Models, die den State des Screens halten und auf den Nutzer reagieren, und eine Datenschicht, die mit dem Netzwerk und der Datenbank spricht. Der State fließt in eine Richtung, von den Daten zum Screen, und jeder Screen hat eine einzige Quelle der Wahrheit. Features leben in eigenen Modulen, damit Teams sich nicht in die Quere kommen.“

Die ausführliche Antwort: Deklarative Screens, SwiftUI und Jetpack Compose, zeichnen sich aus dem State neu, also ist die Frage, wo der State liegt und wer ihn ändern darf. Muster wie MVVM oder ein unidirektionaler Datenfluss geben der Antwort einen Namen; der Name zählt weniger als Konsequenz. Dependency Injection macht die Datenschicht in Tests austauschbar. In einer großen App beschleunigen Module pro Feature die Builds und lassen Teams ihren Teil verantworten, mit einem kleinen gemeinsamen Kern für Design und Netzwerk.

Schwache Antwort: „Ich schreibe die Logik in den Screen, das geht schneller.“ Nachfrage: „Zwei Screens zeigen denselben Warenkorb und sind sich nicht einig.“ Verlege den Warenkorb in eine einzige gemeinsame Quelle und lass beide Screens sie beobachten.

Die App muss im Zug offline funktionieren und später aufholen. Wie entwirfst du Offline-Speicher und Synchronisation?

Worauf sie achten: dass du Konflikte und Fehler einplanst, nicht nur den Idealfall.

Kurze Antwort: „Die App liest zuerst aus einer lokalen Datenbank und zeigt diese Daten sofort. Änderungen des Nutzers werden lokal gespeichert und in eine Warteschlange gestellt; wenn das Netz zurück ist, wird die Warteschlange der Reihe nach geschickt, mit Wiederholungen. Mit dem Backend-Team lege ich fest, was bei einem Konflikt passiert, und ich zeige dem Nutzer, was auf die Synchronisation wartet.“

Die ausführliche Antwort: Offline First heißt, die lokale Datenbank ist die Wahrheit für den Screen, und das Netzwerk aktualisiert sie. Jede Änderung braucht eine ID, damit eine Wiederholung sie nicht doppelt anlegt. Konflikte brauchen eine Regel: Der letzte Schreibvorgang gewinnt, der Server gewinnt oder der Nutzer wählt; leg sie pro Art von Daten fest. Die Hintergrund-Scheduler der Plattformen können die Synchronisation starten, wenn das Handy Verbindung und genug Akku hat. Teste mit ausgeschaltetem, wackligem und langsamem Netz, nicht nur im WLAN des Büros.

Schwache Antwort: „Ohne Verbindung zeigen wir einen Fehler.“ Nachfrage: „Zwei Techniker bearbeiten offline denselben Auftrag.“ Erklär die Konfliktregel, die du vereinbaren würdest, und wie die App es ihnen mitteilt.

Performance, Abstürze und Tests

Nutzer sagen, die App ist langsam, wird heiß und leert den Akku. Wie findest und behebst du das Performance-Problem?

Worauf sie achten: dass du mit den Profilern der Plattform misst, bevor du Code änderst.

Kurze Antwort: „Ich stelle es auf einem Mittelklasse-Handy nach, nicht auf meinem eigenen, und profiliere es: Instruments in Xcode, die Profiler in Android Studio. Ich schaue auf den Main Thread für langsame Arbeit, auf den Speicher für Lecks und große Bilder, auf das Netzwerk für wiederholte Aufrufe und auf den Akku für Standortabfragen oder Hintergrundarbeit, die nie aufhört. Dann behebe ich die größte Ursache und messe noch einmal.“

Die ausführliche Antwort: Startzeit, flüssiges Scrollen und Akku sind das, was Nutzer spüren. Halte Festplatte, Netzwerk und das Dekodieren von Bildern vom Main Thread fern; lade Bilder in der Größe, in der sie angezeigt werden; verwende Listenzellen wieder; bündle Netzwerkaufrufe; und stoppe Standort-Updates und Timer, wenn der Screen verschwindet. Speicherlecks kommen oft von Screens, die nie freigegeben werden. Miss Startzeit und langsame Frames auch in der Produktion, denn Testhandys sind selten die Handys, die Nutzer haben.

Schwache Antwort: „Auf meinem Handy läuft sie gut.“ Nachfrage: „Die App braucht auf älteren Android-Handys vier Sekunden zum Start.“ Zeig, wie du den Start messen, Arbeit verschieben würdest, die für den ersten Screen nicht nötig ist, und das Ergebnis prüfst.

Wie verfolgst du Abstürze, und welche absturzfreie Rate strebst du an?

Worauf sie achten: dass du Stabilität als Zahl behandelst, für die das Team einsteht.

Kurze Antwort: „Ein Werkzeug für Absturzberichte sammelt jeden Absturz mit Stack Trace, Gerät und App-Version, gruppiert nach Ursache. Die absturzfreie Rate ist der Anteil der Sessions oder Nutzer ohne Absturz; die meisten Teams zielen auf fast alle, und ich beobachte sie bei jeder neuen Version. Ich behebe zuerst die Gruppen, die die meisten Nutzer treffen.“

Die ausführliche Antwort: Lade mit jedem Build die Symboldateien hoch, damit Abstürze als Funktionsnamen lesbar sind, nicht als Adressen. Beide Plattformen melden auch Fälle, in denen die App nicht reagiert, und Abbrüche wegen Speichermangels, die für den Nutzer auch ohne Absturz als Ausfall zählen. Eine steigende Absturzrate nach einem Release ist ein Grund, ein gestaffeltes Release anzuhalten. Schreib für jeden behobenen Absturz einen Test, damit er nicht unbemerkt zurückkommt.

Schwache Antwort: „Wir schauen uns die Bewertungen im Store an.“ Nachfrage: „Ein Absturz passiert nur auf einem Handymodell.“ Filtere nach Gerät und Systemversion, leih oder miete dieses Gerät und prüfe, was dieser Hersteller am System ändert.

Wie testest du eine App, von Unit-Tests bis zu echten Geräten?

Worauf sie achten: ein Gleichgewicht aus schnellen Prüfungen und Prüfungen auf echten Geräten, ausgeführt von der Pipeline.

Kurze Antwort: „Die meisten Tests sind Unit-TestsTests für View Models, Parsing und Geschäftslogik, die bei jeder Änderung in Sekunden laufen. für View Models und Geschäftslogik; sie laufen bei jeder Änderung in Sekunden. Eine kleinere Menge UI-Tests deckt die wichtigsten Abläufe auf Simulatoren und Emulatoren in der Pipeline ab. Vor einem Release laufen einige Abläufe auf echten Geräten, alten und neuen, über eine Device Farm oder von Hand.“

Die ausführliche Antwort: Die Architektur entscheidet über die Testbarkeit: Logik außerhalb der Screens lässt sich ohne Handy testen. UI-Tests sind langsamer und unzuverlässiger, also halte sie wenige und stabil, mit den Werkzeugen für TestautomatisierungUI-Tests auf Simulatoren, Emulatoren und echten Geräten für die Abläufe, die nie kaputtgehen dürfen. jeder Plattform. Snapshot-Tests fangen Änderungen am Layout ab. Echte Geräte finden, was Simulatoren verstecken: Speicherdruck, Kamera, Benachrichtigungen, die eigenen Systemänderungen des Herstellers. Teste Barrierefreiheit und große Schriftgrößen als Teil der Abläufe.

Schwache Antwort: „Die Tester testen sie vor dem Release.“ Nachfrage: „Die UI-Tests schlagen zufällig fehl.“ Finde die Ursache, etwa Wartezeiten auf Netzwerk oder Animationen, behebe oder entferne den Test und halte die Testsuite vertrauenswürdig.

Datenschutz, Berechtigungen und Sicherheit

Wie schützt du die Privatsphäre der Nutzer, und wie fragst du richtig nach Berechtigungen wie Standort oder Kamera?

Worauf sie achten: Respekt vor den Nutzern und das Wissen, was beide Plattformen und Stores verlangen.

Kurze Antwort: „Ich frage nach einer Berechtigung erst, wenn der Nutzer die Funktion startet, die sie braucht, mit einem Satz, der sagt, warum, und die App funktioniert auch, wenn er Nein sagt. Ich erhebe nur die Daten, die die Funktion braucht, und halte die Datenschutzangaben im Store und die Datenschutzerklärung im Einklang mit dem, was die App und ihre Bibliotheken von Drittanbietern wirklich tun.“

Die ausführliche Antwort: Beide Plattformen lassen Nutzer einen ungefähren statt eines genauen Standorts freigeben, eine Berechtigung nur einmal erlauben und ungenutzte Berechtigungen entfernen. Apples Store verlangt ein Privacy Label und für manche Datennutzungen ein Privacy Manifest; Google Play verlangt einen Abschnitt zur Datensicherheit. Bibliotheken für Analytics oder Werbung erheben ebenfalls Daten, also prüfe sie. In der EU ergänzt die DSGVO, das Datenschutzgesetz der EU, Regeln zu Einwilligung und Zweck für personenbezogene Daten; andere Länder haben eigene Gesetze.

Schwache Antwort: „Wir fragen beim ersten Start nach allen Berechtigungen, dann ist es erledigt.“ Nachfrage: „Ein Nutzer verweigert den Standort.“ Zeig die Alternative, etwa die Eingabe einer Postleitzahl, und wie du später im passenden Moment noch einmal fragst.

Was heißt Sicherheit für eine App, für die Daten auf dem Handy und die Verbindung zum Backend?

Worauf sie achten: dass du davon ausgehst, dass ein Angreifer das Handy und die App untersuchen kann.

Kurze Antwort: „Kein Geheimnis kommt in die App, denn eine App lässt sich zerlegen. Tokens liegen im Keychain auf iOS und im Keystore auf Android, Sessions laufen ab, und jeder Aufruf geht über verschlüsselte Verbindungen an ein Backend, das jede Anfrage selbst prüft. Sensible Screens verbergen ihren Inhalt im App-Umschalter.“

Die ausführliche Antwort: Das Backend ist das eigentliche Tor: Die App hält nur, was ein Nutzer sehen darf. Nutze den sicheren Speicher und die biometrischen Abfragen der Plattformen, halte Logs frei von personenbezogenen Daten und aktualisiere Bibliotheken mit bekannten Lücken. Für Banking- oder Gesundheits-Apps kommen Prüfungen gegen manipulierte Handys und Certificate Pinning dazu, wo das Risiko den zusätzlichen Pflegeaufwand rechtfertigt. Der OWASP Mobile Application Security Guide ist eine verbreitete Checkliste für App-SicherheitGeheimnisse aus der App heraushalten, Tokens im sicheren Speicher der Plattform ablegen und prüfen, was das Gerät verlässt..

Schwache Antwort: „Wir verstecken den API-Schlüssel im Code.“ Nachfrage: „Ein Sicherheitstest findet den Schlüssel.“ Verlege ihn ins Backend, tausche ihn aus und prüfe, worauf er Zugriff hatte.

Releases, Stores und Feature Flags

Führ uns durch ein Release, vom letzten Merge bis zur App in beiden Stores, samt Review.

Worauf sie achten: dass du sicher ausliefern und um beide Stores herum planen kannst.

Kurze Antwort: „Die Pipeline baut, testet, signiert und lädt den Release Candidate hoch. Tester und eine Gruppe von Beta-Nutzern probieren ihn über TestFlight und die Test-Tracks von Google Play aus. Wir reichen beide Versionen mit Release Notes und allen neuen Angaben zum Datenschutz zum Review ein und geben dann in Stufen frei: ein Phased Release im App Store und ein Staged Rollout bei Google Play, und wir beobachten Abstürze und Bewertungen, bevor alle es bekommen.“

Die ausführliche Antwort: Apple prüft jede Version gegen seine App Store Review Guidelines, Google Play gegen seine Developer Program Policies; beide decken Datenschutz, In-App-Zahlungen, Inhalte und Berechtigungen ab, und beide können Änderungen verlangen. Die Dauer des Reviews schwankt, also plane Puffer vor einem festen Starttermin ein. Ein Phased Release verteilt ein Update über mehrere Tage; ein Staged Rollout schickt es an einen Anteil der Nutzer, den du Schritt für Schritt erhöhst. Beide lassen sich anhalten, wenn die Absturzrate steigt. Ein Release Train, etwa alle zwei Wochen, hält beide Plattformen im Gleichschritt.

Schwache Antwort: „Wir laden es hoch und hoffen, dass das Review durchgeht.“ Nachfrage: „Das Review lehnt die iOS-Version am Tag vor dem Start ab.“ Lies die genannte Regel, behebe oder erkläre, antworte über den Review-Kanal und entscheide mit dem Produkt, ob Android wartet.

Alte App-Versionen bleiben monatelang auf den Handys. Wie nutzt du Feature Flags und erzwungene Updates?

Worauf sie achten: dass du dafür entwirfst, dass viele Versionen gleichzeitig im Einsatz sind.

Kurze Antwort: „Ein Feature Flag ist ein Schalter, den der Server steuert, sodass ein Feature versteckt ausgeliefert und ohne neues Release eingeschaltet wird, für einige Nutzer oder alle; geht es kaputt, lässt es sich ausschalten. Für alte Versionen hält das Backend seine APIs am Laufen, und eine Prüfung der Mindestversion bittet Nutzer nur dann um ein Update, wenn eine alte Version nicht mehr sicher funktionieren kann.“

Die ausführliche Antwort: Nutzer aktualisieren spät oder nie, also muss jede API-Änderung alte Versionen für eine vereinbarte Zeit funktionsfähig halten. Mit Flags kann ein Team ein Feature an einem Anteil der Nutzer testen und die Ergebnisse vergleichen; entferne jedes Flag nach der Entscheidung, sonst füllt sich der Code mit toten Zweigen. Ein erzwungenes Update ist das letzte Mittel, für Sicherheit oder eine kaputte API, denn es blockiert Nutzer in einem schlechten Moment.

Schwache Antwort: „Alle aktualisieren automatisch.“ Nachfrage: „Zehn Prozent der Nutzer sind auf einer Version vom letzten Jahr.“ Erklär, wie das Backend und die Prüfung der Mindestversion mit ihnen umgehen.

Barrierefreiheit, Benachrichtigungen und Deep Links

Wie machst du eine App barrierefrei, und wie testest du das?

Worauf sie achten: dass Barrierefreiheit Teil deiner Arbeitsweise ist, keine späte Korrektur.

Kurze Antwort: „Jedes Bedienelement hat eine Beschriftung, die der Screenreader vorlesen kann, Touch-Ziele sind groß genug, Text wächst mit den Einstellungen des Nutzers, Farben haben genug Kontrast, und nichts hängt allein an der Farbe. Ich teste mit VoiceOver auf iOS und TalkBack auf Android und mit der größten Schriftgröße.“

Die ausführliche Antwort: Die Komponenten der Plattform sind von Haus aus barrierefrei; eigene brauchen Beschriftungen, Rollen und eine sinnvolle Fokusreihenfolge. Die Web Content Accessibility Guidelines sind auch für Apps die gemeinsame internationale Referenz. In der EU macht der European Accessibility Act Barrierefreiheit seit Juni 2025 für viele Verbraucher-Apps, etwa für Banking und Shopping, zur gesetzlichen Pflicht; jedes Land benennt seine eigene Behörde, die sie durchsetzt. In Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) den European Accessibility Act um.

Schwache Antwort: „Unsere Nutzer brauchen das nicht.“ Nachfrage: „Ein Nutzer mit Screenreader kommt nicht durch den Checkout.“ Geh den Ablauf mit TalkBack oder VoiceOver durch, behebe Beschriftungen und Fokus und nimm den Ablauf in die Tests auf.

Wie funktionieren Push-Benachrichtigungen und Deep Links, und was geht dabei schief?

Worauf sie achten: dass du den Weg von einem Server bis zu einem Screen in der App kennst.

Kurze Antwort: „Das Backend schickt eine Push-Benachrichtigung über den Push-Dienst von Apple für iOS und über Firebase Cloud Messaging für Android, adressiert an ein Geräte-Token. Der Nutzer muss Benachrichtigungen erlauben. Ein Deep Link ist eine Adresse, die einen bestimmten Screen in der App öffnet, aus einer Benachrichtigung, einer E-Mail oder einer Webseite; Universal Links auf iOS und App Links auf Android binden ihn an die Website der Firma.“

Die ausführliche Antwort: Tokens ändern sich, also schickt die App jedes Mal das neue an das Backend. Benachrichtigungen, die ankommen, während die App offen, geschlossen oder beendet ist, werden an verschiedenen Stellen behandelt, und jeder Fall braucht einen Test. Deep Links brechen, wenn der Screen einen Login braucht, Daten, die noch nicht geladen sind, oder eine App-Version, die die Adresse nicht kennt; plane jeden Weg. Zu viele Benachrichtigungen bringen Nutzer dazu, sie abzuschalten, also stimm ihren Zweck mit dem Produkt ab.

Schwache Antwort: „Push funktioniert einfach, sobald es eingerichtet ist.“ Nachfrage: „Nutzer tippen auf eine Benachrichtigung und landen auf dem Startbildschirm.“ Verfolge die Behandlung des Links bei einem Kaltstart und bei einem abgemeldeten Nutzer.

Lead-App-Entwickler, Mobile-Architekt und Head of Mobile Engineering

Diese Fragen kommen in Rollen als Senior-App-Entwickler, Lead-App-Entwickler, Mobile-Architekt und Head of Mobile Engineering, in denen die Arbeit Teams, Plattformen und Jahre umspannt.

Wie würdest du als Lead-App-Entwickler oder Head of Mobile Engineering iOS und Android über mehrere Teams hinweg führen?

Worauf sie achten: dass du viele Teams schnell und beide Apps einheitlich halten kannst.

Kurze Antwort: „Ich lege eine gemeinsame Architektur und Regeln für Module fest, ein Designsystem, dem beide Apps folgen, einen Release Train mit automatischen Prüfungen und ein kleines Plattform-Team, das Build, Pipeline und gemeinsame Bibliotheken verantwortet. Feature-Teams verantworten ihre Screens auf beiden Plattformen, wo es geht. Ich beobachte Build-Zeiten, absturzfreie Raten und die Release-Häufigkeit und behebe zuerst den langsamsten Teil.“

Die ausführliche Antwort: Auf dieser Stufe geht es um Struktur und Abwägungen. Entscheide, was geteilt wird und was nativ bleibt; halte die Features dort gleich, wo Nutzer es merken; plane Migrationen, etwa den Umstieg auf SwiftUI und Compose, in Schritten, die Releases nie anhalten. Ein Mobile-Architekt schreibt die Entscheidungen auf und prüft sie; ein Head of Mobile Engineering stellt außerdem ein, entwickelt Leads weiter und verantwortet das Budget für Geräte, Werkzeuge und die Pipeline.

Schwache Antwort: „Jedes Team entscheidet selbst.“ Nachfrage: „Builds dauern vierzig Minuten.“ Zeig, wie du sie messen, Module aufteilen, Builds cachen und ein Ziel setzen würdest.

Dein Lebenslauf für diese Fragen

Jede Zeile deines Lebenslaufs ist eine Frage, die darauf wartet, gestellt zu werden: welche App, was du geändert hast, wie du es gemessen hast. Schreib Zeilen, über die du fünf Minuten reden kannst, unter den Job, in dem die Arbeit passiert ist:

Halte deinen Lebenslauf vor dem Vorstellungsgespräch an einen echten Job als App-Entwickler: Die Lücken, die er zeigt, sind die Zeilen, deren Vorbereitung sich am meisten lohnt.