Android Interview Fragen mit Antworten: Kotlin und Jetpack Compose Vorbereitung für mobile Entwickler

Android Interview Fragen sind die Fragen, mit denen Unternehmen die Kotlin Kenntnisse eines mobilen Entwicklers prüfen, dazu seine Fähigkeit, Oberflächen mit Jetpack Compose zu bauen, und sein Verständnis der Lebenszyklen von Android Komponenten. Seit 2012 betreue ich digitale Projekte, und bei der Auswahl von Entwicklern für mobile Teams stelle ich genau diese Fragen. In diesem Leitfaden ordne ich sie nach Themen und teile Antworten mit kurzen Codebeispielen.

Mein Ziel ist keine Liste zum Auswendiglernen. Zu jeder Frage erkläre ich deshalb auch, was der Interviewer wirklich wissen will. Eine starke Antwort nennt den Grund, nicht nur die Definition. Weitere Beiträge finden Sie in der Kategorie Software.

Welche Android Interview Fragen kommen am häufigsten vor?

Android Interview Fragen decken vier Bereiche ab: Kotlin Grundlagen, Nebenläufigkeit mit Coroutines und Flow, Oberflächen mit Jetpack Compose sowie Android Komponenten und App Architektur. Zur Vorbereitung beantworten Sie aus jedem Bereich einige Fragen in eigenen Worten, schreiben kurzen Code und erklären laut, warum er funktioniert.

Offizielle Quellen zeigen, warum Kotlin diese Gespräche dominiert. Laut der Seite Kotlin first bei Android Developers kündigte Google auf der Google I/O 2019 an, dass die Android Entwicklung zunehmend auf Kotlin setzt. Dieselbe Seite nennt über 70 Google Apps, die Kotlin nutzen. Zudem stürzen Apps mit Kotlin Code laut Google mit 20 Prozent geringerer Wahrscheinlichkeit ab. Folglich prüfen fast alle aktuellen Stellenanzeigen Kotlin statt Java.

Ich empfehle eine klare Reihenfolge: zuerst Kotlin, dann Coroutines, danach Compose und zuletzt Architektur. Wer schwache Sprachgrundlagen hat, tut sich auch mit Compose schwer. Ohne Lambdas, Extension Functions und Unveränderlichkeit lässt sich Recomposition kaum erklären.

Aus welchen Phasen besteht ein technisches Android Interview?

Der Ablauf unterscheidet sich je nach Firma. Trotzdem sieht er in der Praxis meist ähnlich aus. Die Tabelle fasst deshalb zusammen, was jede Phase misst und wie Sie sich vorbereiten. Die Dauer ist ein Startbereich aus meiner Praxiserfahrung, keine Garantie.

Bei Senior Rollen kommt außerdem ein Verhaltensinterview dazu. Dort erzählen Sie konkret von einem Fehler in Produktion und wie Sie ihn behoben haben.

Was ist der Unterschied zwischen val und var in Kotlin?

val deklariert eine schreibgeschützte Referenz, die Sie einmal zuweisen. var deklariert eine Referenz, die Sie neu zuweisen können. Allerdings erwartet der Interviewer vor allem ein Detail: val fixiert die Referenz, nicht den Inhalt des Objekts. Zum Beispiel können Sie einer MutableList in einem val weiterhin Elemente hinzufügen.

val liste = mutableListOf(1, 2)
liste.add(3)      // funktioniert
// liste = mutableListOf() // Compilerfehler

Eine gute Antwort erwähnt zudem, dass Teams standardmäßig val nutzen. var bleibt dagegen für Werte, die sich wirklich ändern. Somit erkennen Leser sofort, welche Werte sich bewegen können.

Wie unterscheidet sich const val von val?

const val steht für einen primitiven Wert oder String, den der Compiler bereits kennt. Sie deklarieren ihn nur auf oberster Ebene oder in einem object beziehungsweise companion object. Ein normales val kann dagegen zur Laufzeit entstehen. Daher können Sie einem const val kein Funktionsergebnis zuweisen.

Wie funktioniert Null Safety in Kotlin?

Das Typsystem von Kotlin trennt Typen, die null annehmen können, von solchen, die es nicht können. Zum Beispiel kann String nicht null sein, String? schon. Der Compiler lässt Sie einen solchen Wert nicht ohne Prüfung verwenden. Somit landen die meisten NullPointerException Fehler bereits beim Kompilieren.

Die häufigsten Operatoren im Gespräch lassen sich so zusammenfassen:

• ?. sicherer Aufruf: liefert null, wenn das Objekt null ist.
• ?: Elvis Operator: nimmt den rechten Wert, wenn links null steht.
• !! behauptet, dass der Wert nicht null ist, und wirft sonst eine Ausnahme.
• ?.let führt einen Block nur aus, wenn ein Wert existiert.

Kurz gesagt: Wenn Sie erklären, warum Sie !! meiden, heben Sie sich ab. Außerdem zeigt der Hinweis auf Plattformtypen aus Java Code, dass Sie echte Erfahrung haben.

Wofür nutzt man data class, sealed class und object?

Eine data class erzeugt equals, hashCode, toString, copy und componentN automatisch für Klassen, die Daten tragen. Vor allem bei UI State ist copy nützlich, denn damit aktualisieren Sie den Zustand ohne Mutation.

Eine sealed class definiert dagegen eine geschlossene Hierarchie von Unterklassen. Modellieren Sie zum Beispiel die Zustände Laden, Erfolg und Fehler eines Screens als sealed interface, dann prüft der Compiler, ob Ihr when Ausdruck jeden Fall abdeckt.

sealed interface UiState {
    data object Loading : UiState
    data class Success(val items: List<String>) : UiState
    data class Error(val message: String) : UiState
}

Zudem erzeugt das Schlüsselwort object ein Singleton. Ein companion object liefert statikähnliche Mitglieder einer Klasse. Andererseits fragen Interviewer oft nach dem Unterschied zwischen enum und sealed: Enum Konstanten haben je genau eine Instanz, sealed Unterklassen können dagegen verschiedene Daten tragen.

Wie setzen Sie Extension Functions und Scope Functions ein?

Mit einer Extension Function ergänzen Sie eine Klasse um eine Funktion, ohne die Klasse zu ändern. Intern entsteht daraus eine statische Funktion. Deshalb erreicht sie keine privaten Mitglieder und verhält sich nicht polymorph. Genau dieses Detail fragen Interviewer gern ab.

Scope Functions unterscheiden sich auf zwei Achsen: Zugriff über it oder this und der Rückgabewert. Diese Übersicht hilft:

• let: Zugriff über it, liefert das Ergebnis des Lambdas; häufig bei Nullprüfungen.
• run: Zugriff über this, liefert das Ergebnis des Lambdas.
• apply: Zugriff über this, liefert das Objekt selbst; gut für Konfiguration.
• also: Zugriff über it, liefert das Objekt selbst; gut für Nebeneffekte wie Logging.
• with: keine Extension, sondern nimmt das Objekt als Parameter.

Trotzdem ist die beste Antwort die, die zugibt: Verschachtelte Scope Functions schaden der Lesbarkeit.

Was ist eine Coroutine und worin unterscheidet sie sich von einem Thread?

Eine Coroutine ist eine leichte Arbeitseinheit, die pausieren kann. Blockiert ein Thread, wartet dieser Betriebssystem Thread untätig. Eine Coroutine pausiert dagegen an einem Suspend Punkt und gibt den Thread für andere Arbeit frei. Deshalb laufen Tausende Coroutines auf wenigen Threads.

Danach folgt fast immer die Frage nach Dispatchern. Dispatchers.Main steht für UI Arbeit. Für wartelastige Arbeit wie Netzwerk und Datenträger nutzen Sie Dispatchers.IO. Rechenintensive Aufgaben laufen auf Dispatchers.Default. Konkret gehört das Sortieren einer großen Liste auf Default, das Lesen aus der Datenbank auf IO.

viewModelScope.launch {
    val nutzer = withContext(Dispatchers.IO) {
        repository.ladeNutzer()
    }
    _state.value = UiState.Success(nutzer)
}

Zudem sollten Sie launch und async unterscheiden. launch startet einen Job ohne Ergebnis. async liefert ein Deferred, dessen Ergebnis Sie mit await lesen. Die offiziellen Details stehen in der Kotlin Dokumentation zu Coroutines.

Warum sind Structured Concurrency und Scopes wichtig?

Structured Concurrency bedeutet, dass jede Coroutine zu einem Scope gehört. Brechen Sie den Scope ab, enden auch alle untergeordneten Coroutines. Somit überleben vergessene Netzwerkaufrufe und Speicherlecks den Screen nicht.

Unter Android übernehmen fertige Scopes diese Arbeit. viewModelScope endet, sobald das ViewModel aufgeräumt wird. lifecycleScope endet mit dem Lebenszyklus seines Besitzers. Daher kostet es meist Punkte, GlobalScope zu verteidigen.

Fehlerbehandlung setzt dieses Thema fort. In einem normalen Job bricht ein fehlerhaftes Kind auch seine Geschwister ab. Ein SupervisorJob hält den Fehler dagegen beim betroffenen Kind. Erwähnen Sie außerdem, dass ein CoroutineExceptionHandler nur bei Root Coroutines greift, dann zeigen Sie echte Praxis.

Worin unterscheiden sich Flow, StateFlow und SharedFlow?

Flow ist ein kalter Datenstrom: Er startet erst, wenn jemand ihn sammelt, und beginnt für jeden Sammler neu. StateFlow und SharedFlow sind dagegen heiße Ströme, die unabhängig von Sammlern Werte senden. Die Tabelle fasst die Unterschiede zusammen.

StateFlow sendet denselben Wert nicht zweimal hintereinander, verhält sich also wie distinctUntilChanged. Folglich passt StateFlow schlecht zu einem Snackbar Ereignis, das Sie eventuell zweimal zeigen wollen. In Compose stoppt collectAsStateWithLifecycle das Sammeln, solange die App im Hintergrund liegt.

Was ist Jetpack Compose und wie unterscheidet es sich von Views?

Jetpack Compose ist das deklarative UI Toolkit für Android. Statt einen View Baum in XML zu bauen und ihn von Hand zu aktualisieren, schreiben Sie die Oberfläche als Funktion des Zustands. Ändert sich der Zustand, zeichnet Compose den betroffenen Teil neu. Google nennt diesen Vorgang Recomposition.

Ein konkreter Vergleich wirkt im Gespräch gut, denn er zeigt Praxis. Mit Views suchen Sie ein TextView per findViewById und rufen setText auf. Mit Compose ändern Sie nur den Zustand, den Rest erledigt das Framework. Die Seite Thinking in Compose erklärt dieses Modell ausführlich.

@Composable
fun Begruessung(name: String) {
    Text(text = "Hallo, $name")
}

Außerdem funktionieren Compose und Views zusammen. ComposeView bettet Compose in einen XML Screen ein, AndroidView bettet eine klassische View in Compose ein. Deshalb überzeugt die Antwort "Ich migriere Screen für Screen, nicht alles auf einmal" die meisten Interviewer.

Wie funktionieren remember, rememberSaveable und State Hoisting?

remember hält einen Wert über Recompositions hinweg. Allerdings verliert es den Wert bei Konfigurationsänderungen wie einer Drehung. rememberSaveable speichert den Wert stattdessen in einem Bundle. Also überlebt der Wert Konfigurationsänderungen und sogar das Beenden des Prozesses.

@Composable
fun Zaehler() {
    var zahl by rememberSaveable { mutableStateOf(0) }
    Button(onClick = { zahl++ }) { Text("Klicks: $zahl") }
}

State Hoisting verlagert den Zustand aus einem Composable nach oben zum Aufrufer. Konkret erhält das Composable einen Wert und ein onChange Lambda als Parameter. Dadurch bleibt die Komponente zustandslos, wiederverwendbar und testbar. Anders gesagt: Sie wenden das Prinzip der einzigen Wahrheitsquelle an.

Ein starker Kandidat ergänzt einen Punkt. Vor allem gehört Geschäftslogik ins ViewModel. Nur flüchtiger UI Zustand, etwa ob ein Menü offen ist, bleibt im Composable.

Warum spielen Recomposition und Performance bei Android Interview Fragen eine Rolle?

Recomposition startet, sobald sich ein State Objekt ändert, das ein Composable liest. Compose führt dann möglichst nur die betroffenen Composables erneut aus. Aufrufe mit stabilen, unveränderten Parametern kann es überspringen.

Diese Performance Tipps fragen Interviewer am häufigsten ab:

1. Legen Sie teure Berechnungen in remember, damit sie nicht in jedem Frame neu laufen.
2. Nutzen Sie derivedStateOf für Werte, die aus sich schnell änderndem Zustand entstehen.
3. Vergeben Sie für LazyColumn Elemente einen key, damit Einträge bei Änderungen richtig zugeordnet bleiben.
4. Lesen Sie Werte wie die Scrollposition möglichst spät, zum Beispiel über Modifier mit Lambda.
5. Verwenden Sie unveränderliche Datenklassen und stabile Typen statt veränderlicher Listen.

Außerdem bringt es Punkte, wenn Sie nie ohne Messung optimieren. Die Recomposition Zähler im Layout Inspector zeigen, welches Composable unnötig läuft. Dieselbe Disziplin nutze ich im Web beim Lighthouse Test der Website Performance.

Wann setzen Sie Side Effect APIs ein?

Composables sollten frei von Nebeneffekten bleiben, denn Sie bestimmen nicht, wann und wie oft sie laufen. Trotzdem müssen Sie manchmal ein Analytics Ereignis senden oder einen Listener registrieren. Dafür bietet Compose kontrollierte APIs:

• LaunchedEffect: startet eine Coroutine, die bei geändertem Schlüssel neu beginnt, etwa für eine Snackbar.
• rememberCoroutineScope: startet eine Coroutine in einem Ereignis wie einem Klick.
• DisposableEffect: für Arbeit mit Einrichtung und Aufräumen; onDispose ist Pflicht.
• SideEffect: aktualisiert nach jeder erfolgreichen Recomposition ein Objekt außerhalb von Compose.
• produceState: wandelt eine externe Quelle in State um.

Oft fragen Interviewer, was LaunchedEffect(Unit) bedeutet. Der Schlüssel ändert sich nie, daher läuft der Effekt nur beim ersten Eintritt des Composables in die Komposition.

Wie funktionieren die Lebenszyklen von Activity und Fragment?

Der Lebenszyklus einer Activity besteht aus onCreate, onStart, onResume, onPause, onStop und onDestroy. Nach onStart ist der Screen sichtbar, nach onResume kann der Nutzer mit ihm interagieren. Den offiziellen Ablauf finden Sie im Leitfaden zum Activity Lebenszyklus.

Das eigentliche Unterscheidungsmerkmal ist die Konfigurationsänderung. Dreht sich der Bildschirm, zerstört das System die Activity standardmäßig und erstellt sie neu. Deshalb halten Sie den Screen Zustand im ViewModel und kleinen, kritischen Zustand in SavedStateHandle oder rememberSaveable.

Fragments haben zwei Lebenszyklen: den des Fragments und den seiner View. Sammeln Sie beispielsweise einen Flow mit lifecycleScope statt mit viewLifecycleOwner.lifecycleScope, aktualisieren Sie womöglich eine View, die nicht mehr existiert. Verknüpfen Sie zudem das Beenden des Prozesses mit diesem Thema: Das System kann eine App im Hintergrund beenden, und nur gespeicherter Zustand kommt zurück.

Welche vier Grundkomponenten hat Android?

Die vier Grundkomponenten einer Android App sind Activity, Service, BroadcastReceiver und ContentProvider. Jede deklarieren Sie im Manifest, und das System kann jede einzeln starten. Im Gespräch erwartet man einen Satz dazu, wann Sie welche nutzen.

• Activity: der Screen, mit dem der Nutzer interagiert; moderne Apps nutzen oft eine einzige Activity mit Compose Screens.
• Service: Arbeit ohne Oberfläche; lange, sichtbare Arbeit braucht einen Foreground Service mit Benachrichtigung.
• BroadcastReceiver: hört auf System oder App Broadcasts, etwa den Gerätestart.
• ContentProvider: teilt Daten sicher mit anderen Apps.

Danach folgen Intents. Zunächst zielt ein expliziter Intent auf eine bestimmte Komponente. Ein impliziter Intent beschreibt dagegen eine Aktion, und das System sucht eine passende App. Ab Android 12 müssen Komponenten mit Intent Filter android:exported ausdrücklich angeben.

Wann wählen Sie WorkManager für Hintergrundarbeit?

WorkManager dient für aufschiebbare Arbeit, die auch nach dem Schließen der App oder einem Neustart des Geräts laufen muss. Foto Uploads, tägliche Synchronisation und das Senden von Logs gehören dazu. Als Bedingung können Sie etwa Netzverbindung oder Ladezustand festlegen.

Die Interviewfrage verlangt meist eine Entscheidung: Coroutine, WorkManager oder Foreground Service? Eine kurze Regel hilft:

1. Zählt die Arbeit nur bei offenem Screen, nutzen Sie eine Coroutine in viewModelScope.
2. Muss die Arbeit bestehen bleiben und darf warten, nutzen Sie WorkManager.
3. Muss sie sofort starten und der Nutzer bemerkt sie, etwa bei Musik oder Navigation, nutzen Sie einen Foreground Service.

Folglich zeigt die Antwort "Ich mache alles in einem Service", dass Sie aktuelle Android Grenzen nicht kennen. Akkuoptimierung und Doze Modus begrenzen Hintergrundarbeit streng.

Wie bauen Sie ein ViewModel und eine MVVM Architektur auf?

Das ViewModel ist eine Jetpack Komponente, die UI Zustand über Konfigurationsänderungen hinweg hält und Logik vom Screen trennt. In MVVM zeigt der Screen nur Zustand und leitet Nutzerereignisse weiter. Das ViewModel holt Daten über ein Repository und sendet neuen Zustand.

Googles Leitfaden zur App Architektur empfiehlt heute Schichten: eine UI Schicht, eine optionale Domain Schicht und eine Datenschicht. Daten fließen in eine Richtung: Zustand nach unten, Ereignisse nach oben. Das nennt man unidirektionalen Datenfluss (UDF).

class ProfilViewModel(
    private val repo: ProfilRepository
) : ViewModel() {
    private val _state = MutableStateFlow<UiState>(UiState.Loading)
    val state: StateFlow<UiState> = _state.asStateFlow()
}

Häufig fragen Interviewer, warum der MutableStateFlow privat bleibt. Sie geben nur einen lesbaren Strom nach außen, also ändert allein das ViewModel den Zustand. Kommt MVI zur Sprache, erklären Sie: MVI bündelt alle Ereignisse in einem Intent Strom und hält den Zustand in einem Objekt.

Wie nutzen Sie Hilt für Dependency Injection?

Hilt ist die empfohlene Bibliothek für Dependency Injection unter Android und basiert auf Dagger. Statt Objekte selbst zu erzeugen, beschreiben Sie, wie sie entstehen. Hilt liefert sie dann im passenden Scope. Dadurch übergeben Sie in Tests leicht ein Fake Repository.

Einige Annotationen reichen für den Start: @HiltAndroidApp an der Application Klasse, @AndroidEntryPoint an Activities, @HiltViewModel an ViewModels sowie @Module mit @InstallIn für Module. Zudem binden Sie Interfaces mit @Binds und Objekte von Drittanbietern mit @Provides.

Auch Fragen zu Scopes tauchen oft auf. @Singleton erzeugt eine Instanz für die ganze App, @ViewModelScoped lebt so lange wie das ViewModel. Anders gesagt: Wer alles zum Singleton macht, bekommt Probleme bei Speicher und Tests. Sie können Alternativen wie Koin für kleine Projekte nennen und dann erklären, warum Sie Hilt wegen der Prüfung beim Kompilieren bevorzugen.

Wie speichern Sie lokale Daten mit Room?

Room ist eine Persistenzbibliothek auf Basis von SQLite, die Abfragen beim Kompilieren prüft. Zudem besteht sie aus drei Teilen: @Entity für Tabellen, @Dao für Abfragen und einer @Database Klasse. DAO Funktionen können suspend sein oder einen Flow liefern.

Eine Abfrage mit Flow sendet bei jeder Tabellenänderung ein neues Ergebnis. Deshalb wird die Datenbank in einer Offline First Architektur zur einzigen Wahrheitsquelle. Netzwerkdaten gehen zuerst in Room, und die Oberfläche hört nur auf Room.

Auch Migrationen kommen zur Sprache. Ändert sich das Schema, erhöhen Sie die Versionsnummer und ergänzen eine Migration oder eine automatische Migration. fallbackToDestructiveMigration löscht Nutzerdaten, daher verlangt der Einsatz in Produktion Vorsicht. Ehrlich gesagt überzeugt eine echte Geschichte wie "Ich habe einmal Daten verloren und danach Migrationstests geschrieben" am meisten.

Wie schreiben Sie Tests für eine Android App?

Android Tests teilen sich in drei Ebenen: Unit Tests, Integrationstests und UI Tests. Unit Tests laufen schnell auf der JVM und prüfen die Logik von ViewModel und Repository. UI Tests laufen dagegen auf einem Gerät oder Emulator.

Für Code mit Coroutines nutzen Sie runTest und einen Test Dispatcher, somit vergehen Verzögerungen sofort in virtueller Zeit. Für Compose Screens finden Sie mit createComposeRule Knoten, klicken sie an und prüfen Texte. Bei Flow Tests erleichtern Bibliotheken wie Turbine die Prüfung der gesendeten Werte in Reihenfolge.

Interviewer verknüpfen Testbarkeit meist mit Architektur. Erzeugt ein ViewModel zum Beispiel selbst eine Retrofit Instanz, wird Testen schwer. Übergeben Sie die Abhängigkeit dagegen im Konstruktor, reichen Sie ein Fake Repository hinein. Dieselbe Denkweise zeigt sich im Web beim Test der Mobilfreundlichkeit.

Wie finden Sie Speicherlecks und Performance Probleme?

Das häufigste Speicherleck unter Android entsteht, wenn ein langlebiges Objekt eine Referenz auf eine kurzlebige Activity oder einen Context hält. Ein Beispiel ist eine Activity in einem statischen Feld, ein anderes ein registrierter Listener, den niemand entfernt.

Diese Diagnosewerkzeuge nutze ich in der Praxis:

• LeakCanary: findet Lecks in Debug Builds und zeigt die Referenzkette.
• Android Studio Profiler: zeigt Speicher, CPU und Netzwerk live.
• Baseline Profiles: verbessern Start und Scrollen durch Vorabkompilierung.
• StrictMode: meldet Datenträger oder Netzwerkzugriffe auf dem Main Thread während der Entwicklung.

Auch ANR Fragen (Application Not Responding) gehören hierher. Blockieren Sie den Main Thread zu lange, meldet das System dem Nutzer, dass die App nicht reagiert. Daher verlagern Sie schwere Arbeit weg vom Main Thread. Wie Tempo das Ranking beeinflusst, beschreibe ich im Beitrag wie die Ladezeit SEO beeinflusst; in einer App zeigt sich Tempo direkt in den Bewertungen.

Welche Live Coding Aufgaben gehören zu Android Interview Fragen?

Beim Live Coding verlangen Interviewer selten Algorithmusrätsel, sondern meist einen kleinen, realistischen Screen. Diese Aufgaben sehe ich am häufigsten:

1. Ein Screen, der eine Liste aus einer API lädt, sie in einer LazyColumn zeigt und Lade sowie Fehlerzustände behandelt.
2. Ein ViewModel, das Ergebnisse beim Tippen filtert, mit debounce.
3. Ein Compose Formular, das Felder prüft und den Senden Button nur bei gültigen Eingaben aktiviert.
4. Eine einfache Favoritenliste in Room, die auch offline funktioniert.

Dabei erwartet niemand perfekten Code; der Interviewer beobachtet Ihr Denken. Wiederholen Sie zunächst die Anforderung. Schreiben Sie dann das Zustandsmodell als sealed interface und bauen Sie danach den Screen. Erklären Sie dabei laut, was Sie tun. Wenn Sie festhängen, ist eine ausgesprochene Annahme immer besser als stilles Warten.

Zum Beispiel zeigt bei der debounce Aufgabe eine Kette aus debounce, distinctUntilChanged und flatMapLatest Ihr Coroutine Wissen in einer Zeile.

Welche Fehler sollten Sie bei der Vorbereitung vermeiden?

Über die Jahre ähneln sich die Fehler der Kandidaten stark. Planen Sie Ihre Vorbereitung danach, hinterlässt dasselbe Fachwissen einen deutlich besseren Eindruck.

• Definitionen auswendig lernen und bei der Frage nach dem Warum verstummen.
• Veraltete Ansätze wie AsyncTask oder GlobalScope verteidigen.
• Architekturentscheidungen im eigenen Projekt nicht erklären können.
• Beim Live Coding schweigen und keine Rückfragen stellen.
• Nie überlegt haben, was man wie testen würde.

Unterschätzen Sie außerdem Ihr Portfolio nicht. Denn eine kleine App im Play Store ist ein stärkerer Beleg als eine lange Liste von Zertifikaten. Hat Ihre App eine Landingpage, stärken Prinzipien des Mobile First Designs zudem Ihren professionellen Auftritt.

Wie verändern sich Android Interview Fragen auf Senior Niveau?

Auf Senior Niveau verschiebt sich der Fokus von Syntax zu Entscheidungen. Der Interviewer fragt also nicht mehr, was StateFlow ist. Stattdessen will er wissen, wie Sie die Zustandsverwaltung in einem Team mit zehn Personen vereinheitlichen. Er erwartet begründete Entscheidungen und klare Abwägungen.

Typische Themen sind dann Projekte mit vielen Modulen und die Build Zeit, die Grenzen geteilten Codes mit Kotlin Multiplatform, Konfliktlösung bei der Offline Synchronisation, App Größe und Startzeit sowie CI Automatisierung für Tests und Releases. Konkret können Sie bei der Modularisierung erklären, wie die Trennung von Feature und Core Modulen den Build Cache beeinflusst.

Zudem zählt Kommunikation in einer Senior Rolle ebenso viel wie Technik. Technische Schulden einem Produktteam zu erklären, ähnelt der Verteidigung einer Entscheidung für Micro Frontends in einer großen Webarchitektur. In beiden Fällen zeigen Sie die geschäftliche Wirkung klar.

Wie erstellen Sie einen Lernplan für Android Interview Fragen?

Android Interview Fragen umfassen ein weites Feld, daher kostet Lernen ohne Plan Zeit. Der folgende Vierwochenplan ist ein Startvorschlag aus meiner Praxiserfahrung, keine Garantie. Passen Sie ihn also an Ihr Niveau an.

1. Woche 1: Kotlin Grundlagen, Null Safety, Collections und Scope Functions. Probieren Sie täglich ein Konzept mit kurzem Code aus.
2. Woche 2: Coroutines, Flow und Test Dispatcher. Schreiben Sie ein kleines Beispiel mit Netzwerkabfrage von Anfang bis Ende.
3. Woche 3: Jetpack Compose, State Hoisting und Side Effect APIs. Bauen Sie eine App mit zwei Screens.
4. Woche 4: Architektur, Hilt, Room und Tests. Räumen Sie das Projekt auf, stellen Sie es auf GitHub und üben Sie, die Architektur laut zu erklären.

Zusammengefasst empfehle ich am Ende jeder Woche ein Probeinterview mit einem Bekannten. Die eigenen Antworten laut zu hören, zeigt Lücken viel schneller als Lernen auf Papier.

Planen Sie für eine App oder ein Produkt eine Landingpage, Sichtbarkeit im Store oder eine Suchstrategie, dann werfen Sie einen Blick auf mein Webdesign Angebot und meine SEO Beratung. Direkt erreichen Sie mich über die Kontaktseite.