Android teknik mülakatları yalnızca Kotlin sözdizimini hatırlayıp ViewModel açıklamakla ilgili değildir. İyi bir mülakat; gerçek bir Android uygulamasını tasarlayıp geliştirebildiğinizi, hata ayıklayabildiğinizi, test edebildiğinizi, yayınlayabildiğinizi ve uzun vadede sürdürebildiğinizi anlamaya çalışır.

Mülakat yapan kişi production ortamında bir şey bozulduğunda nasıl düşündüğünüzü, mimari kararları nasıl verdiğinizi, Android temellerini ne kadar iyi anladığınızı ve teknik ödünleşimleri açıkça anlatıp anlatamadığınızı görmek ister.

Birçok Android mülakatı üzerinde çalışınca şu sonuç netleşir: Teknolojiyi bilmek mücadelenin yalnızca yarısıdır. Bildiklerinizi yapılandırılmış, ikna edici ve gerçek deneyimlerle desteklenen bir şekilde anlatmanız da gerekir.

Bu rehber; Android mühendisliği teknik mülakatına nasıl hazırlanabileceğinizi, hangi sorularla karşılaşabileceğinizi ve cevaplarınızı nasıl daha güçlü hâle getirebileceğinizi anlatır.

Android Mülakatları Gerçekte Neyi Ölçer?

Teknik mülakat basit bir bilgi sınavı değildir.

Mülakat yapan kişi genellikle aynı anda birkaç sorunun cevabını arar: Sürdürülebilir Android kodu yazabilir misiniz? Production problemini sistematik biçimde araştırabilir misiniz? Ezberlenmiş tanımların ötesinde mimariyi anlayabiliyor musunuz? Performans ve eşzamanlılık hakkında akıl yürütebiliyor musunuz? Değişikliklerinizi nasıl test edeceğinizi biliyor musunuz? Her zaman tek bir mükemmel çözüm varmış gibi davranmadan ödünleşimleri açıklayabiliyor musunuz? Bir feature production ortamına çıktıktan sonra sorumluluk almaya devam eder misiniz?

Bu yüzden şu cevaplar genellikle yeterli değildir:

“MVVM kullandım çünkü temiz.”

“Jetpack Compose daha iyi çünkü daha az kod yazılıyor.”

Mülakat yapan kişi hangi problemin bulunduğunu, neden belirli bir yaklaşımı seçtiğinizi, hangi alternatifleri değerlendirdiğinizi ve çözümün gerçekten çalıştığını nasıl doğruladığınızı duymak ister.

Teknik Cevaplar İçin Daha İyi Bir Yapı

Davranışsal sorularda STAR — Situation, Task, Action, Result — modeli oldukça kullanışlıdır. Android teknik soruları için ise şu yapı daha açıklayıcıdır:

Problem → Araç veya Teknik → Teknik Karar → Ödünleşim → Doğrulama → Sonuç

Bu sıra, yalnızca teknoloji isimlerini sıralamak yerine mühendislik kararlarını açıklamanızı sağlar.

Örneğin “Firebase kullanarak crash’leri düzelttim” demek yerine şöyle cevap verebilirsiniz:

“Production’daki Android uygulamalarımızdan birinde crash oranı yaklaşık yüzde 4’tü. En sık görülen crash gruplarını bulmak için Firebase Crashlytics kullandım; stack trace’leri, etkilenen Android sürümlerini, cihazları ve kullanıcı akışlarını inceledim. En yüksek etkili problemi lokal ortamda yeniden ürettikten sonra lifecycle ve state yönetimiyle ilgili bir sorun buldum. Sadece savunmacı bir kontrol eklemek alttaki problemi bırakacağı için kısa vadeli düzeltmeyi yaptım ve state yönetimini ayrı bir değişiklikte refactor ettim. Regression testleri ekledik ve deploy sonrasında Crashlytics’i izledik. Crash oranı yaklaşık yüzde 4’ten yüzde 1’e düştü.”

Bu cevap; hata ayıklama, önceliklendirme, mimari, risk yönetimi, test ve production sorumluluğu hakkında kanıt sunar.

1. Kotlin Temelleri

Rol Android odaklı olsa bile Kotlin soruları bekleyin. Null safety, data class, sealed class, extension function, higher-order function, collection, generic, immutability, scope function, delegation ve hata yönetimi konularında rahat olmalısınız.

Sözdizimini bilmek kadar kavramların arasındaki farkı anlamak da önemlidir. val ve var sorusuna “val değişmez, var değişir” cevabı eksiktir. Daha iyi cevap şudur:

“val referansın yeniden atanmasını engeller ve immutable tasarımı teşvik eder; ancak referans verilen nesneyi otomatik olarak immutable yapmaz. Örneğin val bir mutable listeyi gösterebilir ve listenin içeriği değişebilir. Özellikle Compose ve StateFlow ile çalışırken state geçişlerini daha kolay takip edebilmek için mümkün olduğunca immutable state kullanmayı tercih ederim.”

2. Coroutines ve Eşzamanlılık

Modern Android pozisyonlarında Kotlin Coroutines çok önemlidir. suspend, coroutine scope’ları, dispatcher’lar, structured concurrency, cancellation, exception handling, async, launch, withContext ve lifecycle-aware coroutine çalıştırmayı anlamalısınız.

launch doğrudan değer döndürmeden iş başlatır ve Job verir. async eşzamanlı işten sonuç beklediğinizde kullanılır; Deferred döndürür ve sonuç await() ile alınır. Her ikisini de cancellation ve hataların öngörülebilir ilerlemesi için structured scope içinde tutmaya çalışın.

İki coroutine aynı state’i aynı anda güncelliyorsa race condition oluşabilir. Çözüme göre immutable state, tek sahiplik, Mutex, atomic operation, database transaction veya mutation’ları tek bir akışta toplama yaklaşımlarından yararlanabilirsiniz.

3. Flow, StateFlow ve SharedFlow

Reactive state yönetimi modern Android’in temel parçalarındandır. Cold ve hot stream’leri, Flow, StateFlow, SharedFlow, lifecycle-aware collection, map, filter, combine, debounce ve hata yönetimini bilmelisiniz.

StateFlow mevcut durumu temsil eder ve her zaman bir değere sahiptir. SharedFlow ise güncel state semantiğinin gerekli olmadığı durumlarda birden fazla aboneye değer yayınlamak için kullanışlıdır.

“Loading, content veya error gibi bir ekran state’i için ViewModel’dan StateFlow expose ederim; çünkü UI en güncel durumu hemen görmelidir. Event benzeri bir davranış için SharedFlow kullanabilirim. Ancak event’in kaybolması UI’ı tutarsız bırakacaksa event’i kalıcı state’in parçası olarak modellemeyi de değerlendiririm.”

4. Jetpack Compose

Compose mülakatlarında recomposition, state, state hoisting, remember, rememberSaveable, LaunchedEffect, DisposableEffect, derivedStateOf, navigation, listeler, theming, preview ve geleneksel View’larla birlikte çalışma konuları sorulabilir.

Compose’un XML View’lara göre en önemli avantajı declarative ve state-driven modelidir. UI’ı elle bulup değişen state ile senkronize etmek yerine, belirli bir state için nasıl görünmesi gerektiğini tanımlar ve güncellemeleri Compose’a bırakırsınız. Bu yaklaşım boilerplate’i azaltır, ViewModel ve StateFlow ile doğal biçimde çalışır ve tekrar kullanılabilir bileşenlerle tutarlı bir design system kurmayı kolaylaştırır.

Ancak Compose otomatik olarak her uygulamayı daha hızlı yapmaz. Örneğin LazyColumn’ın her durumda RecyclerView’dan hızlı olduğunu söylemek doğru değildir. Compose’un avantajı çoğu zaman list state’ini ve güncellemeleri daha anlaşılır hâle getirmesidir. Stable key’ler, immutable UI state, gereksiz recomposition’lardan kaçınma ve pahalı işleri composable dışına çıkarma yine sizin sorumluluğunuzdadır.

5. Compose Performansını Ölçmek

Performansın iyileştiğini söylerseniz hemen şu soruyla karşılaşabilirsiniz: “Bunu nasıl ölçtünüz?” “Daha hızlı hissettirdi” bir mühendislik kanıtı değildir.

Duruma göre Android Studio Profiler, Compose Layout Inspector, recomposition incelemesi, frame rendering davranışı, memory kullanımı, startup ölçümleri, CPU profiling, Macrobenchmark, Baseline Profile ve gerçekçi büyüklükte dataset testlerinden bahsedebilirsiniz.

“Değişiklikten önce ve sonra scrolling davranışını Android Studio profiling araçlarıyla karşılaştırdım. Büyük dataset ile test yaptım, gereksiz recomposition’ları kontrol ettim ve pahalı işlemlerin composable içinde çalışmadığını doğruladım. ViewModel ve business logic’i koruyup presentation katmanını değiştirdim; liste yükleme, scrolling, seçim ve state değişiklikleri için UI testleri ekledim.”

6. Android Mimarisi

MVVM ve Clean Architecture’ı ders kitabı tanımı gibi değil, sorumluluklar üzerinden açıklayabilmelisiniz. ViewModel ekran state’ini sahiplenip dönüştürür; UI bu state’i gözlemler ve render etmeye odaklanır. Repository ve domain katmanları gerçekten değer kattığında kullanılır; UI bileşenleri networking, persistence ve business logic ile dolmaz.

“MVVM kullanıyorum çünkü UI state ile business logic arasında yararlı bir ayrım oluşturuyor. ViewModel ekran state’ini yönetiyor, UI ise bu state’i çiziyor. Bu ayrım test edilebilirliği artırıyor. Bununla birlikte küçük bir feature için yalnızca mimari saflık uğruna çok sayıda interface ve use case eklemem; gereksiz abstraction karmaşıklık yaratabilir.”

7. Lifecycle

Activity, Fragment, configuration change, process death, lifecycle-aware collection, ViewModel, saved state ve background davranışlarını anlamalısınız. Ezberlenmiş callback listeleri yerine sahipliği düşünün:

  • State’in sahibi kim?
  • State ne kadar süre yaşamalı?
  • Ekran kaybolduğunda bu iş durmalı mı?
  • Process yeniden oluşturulduğunda state korunmalı mı?

Bu sorular doğru lifecycle kararlarına doğal biçimde götürür. ViewModel ekranın yeniden oluşturulmasında state’i koruyabilir; lifecycle-aware collection ise artık görünür olmayan UI için gereksiz iş yapılmasını önleyebilir.

8. Background Work

Coroutine, Android Service, foreground service ve WorkManager arasındaki farkları bilin. WorkManager; uygulama process’i kaybolsa bile zaman içinde tamamlanması gereken, ertelenebilir synchronization, upload veya bakım işleri için uygundur. Sadece görünür bir ekrana bağlı işler için lifecycle-aware coroutine daha basit olabilir. Kullanıcının görünür biçimde devam eden uzun süreli bir iş beklediği durumda foreground service gerekebilir.

Seçimi teknoloji alışkanlığına göre değil; işin hemen mi başlaması gerektiğine, ne kadar süreceğine, kullanıcıya görünür olup olmadığına ve process termination sonrasında tamamlanıp tamamlanmaması gerektiğine göre yapın.

9. Networking

Retrofit, REST API, serialization, authentication, retry, cache, timeout, hata yönetimi ve connectivity failure başlıklarına hazırlanın. API bazen 500 dönüyor veya timeout oluyorsa client ve server hatalarını ayırın, güvenli request context log’layın, yalnızca tekrar edilmesi güvenli işlemlerde retry uygulayın ve exponential backoff kullanın.

“Üç kez retry ederim” demek yeterli değildir. Idempotency desteği yoksa POST işlemini körlemesine tekrar etmek duplicate kayıt oluşturabilir. UI’a da loading, offline, authentication failure ve server error gibi anlamlı durumlar aktarılmalıdır.

10. Room ve Yerel Persistence

Entity, DAO, migration, transaction, index, ilişki ve Room ile Flow kullanımını bilmelisiniz. Offline-capable bir uygulamada hangi kaynağın authoritative olduğunu açıklayın.

Yaygın bir akış Network → Repository → Room → Flow → ViewModel → UI şeklindedir; fakat bu tek doğru değildir. Önemli olan seçimin ürün gereksinimleriyle gerekçelendirilmesidir. Migration planı, iki işlemin aynı kayıtları değiştirmesi ve cache invalidation davranışı özellikle konuşulabilecek konulardır.

11. Dependency Injection

Dependency injection’ın amacı framework ezberinden önce anlaşılmalıdır. Nesne oluşturma sorumluluğunu nesneyi kullanma sorumluluğundan ayırır, bağımlılıkları görünür kılar, coupling’i azaltır ve test double kullanmayı kolaylaştırır.

“Bir ViewModel’ın repository’sini kendi içinde DeviceRepositoryImpl() ile oluşturması testleri zorlaştırır. Repository’yi constructor üzerinden almak, gerçek veya fake implementasyonu dışarıdan vermeyi sağlar. Hilt ve Dagger gibi araçlar büyük projelerde dependency graph’ını yönetebilir; ancak araç kullanmak dependency tasarımının kendisi değildir.”

12. Testler

Unit, integration ve UI testlerinin görevlerini ayırın. Deterministic business logic ve ViewModel state geçişleri için hızlı unit testler; repository, database veya API sınırlarının birlikte çalışması için integration testler; önemli kullanıcı yolculukları için UI testleri kullanın.

“Her implementation detail’i UI automation ile test etmeye çalışmam; bu testler yavaş ve kırılgan olur. Production bug’ı için önce problemi yeniden üretir, hatanın hangi katmanda oluştuğunu bulur, düzeltir ve aynı problemi yakalayacak en dar güvenilir regression testini eklerim. Sonra etkilenen akışın tamamını doğrularım.”

13. Production Problemlerini Araştırmak

Son release’ten sonra crash oranı artarsa Crashlytics veya başka bir monitoring sistemiyle başlayın. Crash’leri sıklık ve etki bakımından gruplayın; stack trace, app version, OS version, cihaz modeli ve etkilenen feature’ı kontrol edin. Artışın deployment ile zaman ilişkisini inceleyin, mümkünse yeniden üretin ve kök nedeni belirleyin.

Seviyeye göre hotfix, rollback, feature flag veya daha geniş bir refactor arasında karar verin. Regression koruması ekleyin, mümkünse kademeli yayın yapın ve sonucu izleyin. Bu sıralama production olgunluğunu gösterir.

14. Performance ve Memory Leak

Startup time, memory, rendering, ANR, network, pil tüketimi, database query ve excessive recomposition başlıklarını kanıtla tartışın. İlke basittir: Önce ölçün, sonra optimize edin.

Memory leak örnekleri arasında uzun ömürlü nesnelerin Activity tutması, kaldırılmayan callback ve listener’lar, yanlış scope’a sahip dependency’ler, static reference’lar, sahibinden uzun yaşayan coroutine’ler ve lifecycle’dan habersiz observer’lar bulunur. Memory Profiler veya LeakCanary ile retained object chain’i izleyerek araştırma sürecini anlatın; yalnızca araç adını söylemeyin.

15. Media Playback

Media ağırlıklı pozisyonlar için Media3 ve ExoPlayer’a hazırlanın. Player lifecycle’ı, MediaSession, audio focus, notification, foreground service, buffering, playback state, configuration change ve kullanıcı oturumunu geri yükleme konuları sorulabilir.

“Playback motorunu Activity veya composable’a bağlamam; çünkü playback tek bir ekranın yaşamına bağlı olmamalı. Media3 ve uygun bir MediaSession kullanır, kalıcı playback için foreground-service mimarisini değerlendiririm. Playback state’in net bir sahibi olur ve farklı ekranların gözlemleyebilmesi için UI’a Flow ile açılır. Audio focus, interruption, notification, lifecycle ve state restoration senaryolarını ayrıca test ederim.”

16. Android İçin Sistem Tasarımı

Sistem tasarımı sorusunda hemen kütüphane isimleri sıralamayın. Önce gereksinimleri netleştirin: Kullanıcılar kim, ana akış nedir, offline davranış gerekli mi, veri ne kadar büyüyecek, latency ve consistency beklentisi nedir, güvenlik ve gözlemlenebilirlik gereksinimleri nelerdir?

Bir müzik uygulamasını tasarlarken UI, ViewModel, repository, local database, remote API, playback service, cache, authentication ve analytics sınırlarını açıklayın. Sonra process death, ağ kesintisi, duplicate event, token expiration ve büyük katalog gibi failure mode’ları ele alın.

İyi sistem tasarımı diyagramdan çok, kısıtlar ile kararlar arasındaki ilişkiyi gösterir.

17. Clean Architecture — Overengineering Yapmadan

Clean Architecture presentation, domain ve data sorumluluklarını ayırabilir. Değeri test edilebilirlik, değiştirilebilirlik ve sınırların netleşmesidir. Riski ise gereksiz katmanlarla küçük bir feature’ı ağırlaştırmaktır.

Bir feature için Screen, ViewModel, UseCase, Interactor, Repository, DataSource ve başka abstraction’lar eklemeden önce gerçek bir karmaşıklık problemi olduğundan emin olun. Mimari karmaşıklığı yönetmek içindir; yalnızca sofistike görünmek için yeni karmaşıklık üretmemelidir.

18. Trade-off Soruları

Senior seviyede mülakat yapan kişiler tek bir doğru cevap aramaz. Küçük ve düşük riskli bir hotfix ile kapsamlı refactor arasındaki farkı, hızlı teslimat ile sürdürülebilirlik arasındaki ilişkiyi ve teknik borcun ne zaman kabul edilebileceğini açıklamanızı bekler.

“Kritik production hatasında önce düşük riskli küçük bir düzeltmeyle sistemi stabilize edebilirim. Ardından kök mimari problemi ayrı bir iş olarak ele alırım. Kararı verirken public API değişimini, migration riskini, performansı, test kapsamını ve sonraki bakım maliyetini değerlendiririm.”

19. Kendi Projeleriniz Derinlemesine Sorulur

CV’nizdeki her teknoloji için ne yaptığınızı, neden yaptığınızı, hangi alternatifleri değerlendirdiğinizi, neyin bozulduğunu ve sonucu nasıl ölçtüğünüzü anlatmaya hazır olun. “Compose kullandım” dediğinizde recomposition’ı nasıl kontrol ettiğiniz sorulabilir. “Crash’i düzelttim” dediğinizde nasıl reproduce ettiğiniz sorulabilir.

Gerçekte katkınız sınırlıysa abartmayın. Kapsamınızı, kararınızı ve öğrendiğinizi açıkça anlatmak; projeyi tek başınıza tasarlamış gibi görünmeye çalışmaktan daha güçlüdür.

20. Bilmediğinizi Söylemeye Hazır Olun

Her Android API’sini bilmek mümkün değildir. Bilmediğiniz bir konuda tahmin yürütmek yerine bildiğiniz kısmı, varsayımınızı ve araştırma planınızı açıklayın.

“Bu API’nin tam davranışını production’da kullanmadım; bu nedenle kesin konuşmak istemem. Bildiğim kadarıyla lifecycle ile ilişkili, fakat dokümantasyonu ve küçük bir prototype’ı kontrol ederek karar verirdim. Benzer bir problemi daha önce şu yaklaşımla çözmüştüm.”

Bu cevap dürüstlüğü, öğrenme becerisini ve risk farkındalığını gösterir.

21. İletişim Skorunuzu Değiştirebilir

Teknik olarak doğru bir cevap anlaşılmıyorsa değerini kaybeder. Önce kısa cevabı verin, sonra gerekçeyi ve gerçek örneği ekleyin. Soruyu anlamadıysanız varsayımınızı söyleyip netleştirici soru sorun. Jargonla saklanmak yerine kararın kullanıcıya, ürüne ve operasyona etkisini anlatın.

Bir teknoloji adı söylediğinizde iki veya üç seviye takip sorusuna hazır olun. Mülakat yapan kişi ezberlenmiş tanımı değil, gerçek mühendislik deneyimini duymak ister.

22. Güçlü Deneyim Hikâyeleri Hazırlayın

Önceden şu başlıklarda kısa hikâyeler hazırlayın: zor bir production bug’ı, performans iyileştirmesi, mimari anlaşmazlık, başarısız olan bir yaklaşım, uçtan uca sahip olduğunuz bir feature, kısa deadline, mentorluk ve öğrendiğiniz bir hata.

Her hikâyeyi şu sırayla anlatın: Durum → Problem → Araştırma → Karar → Uygulama → Doğrulama → Sonuç. Mümkünse crash oranı, latency, adoption, test kapsamı veya teslimat süresi gibi ölçülebilir sonuçlar ekleyin.

23. Mülakat Yapan Kişiye Sorulabilecek Sorular

Mülakatın sonunda mutlaka soru sorun. Örneğin:

  • Android ekibinin şu anda karşılaştığı en büyük teknik problemler neler?
  • Uygulamanın ne kadarı Jetpack Compose kullanıyor ve kalan View tabanlı ekranlar için stratejiniz nedir?
  • Bu role katılan bir mühendisten ilk üç ila altı ay içinde nasıl bir başarı bekliyorsunuz?
  • Production gözlemlenebilirliği, release süreci ve incident yönetimi nasıl işliyor?

Bu sorular yalnızca teklif almakla değil, gerçek mühendislik ortamını anlamakla da ilgilendiğinizi gösterir.

Pratik Bir Hazırlık Stratejisi

  1. Kotlin, Coroutines, Flow, Compose, lifecycle ve architecture temellerini tekrar edin.
  2. Bir Android projesini baştan sona tasarlayıp nedenlerini açıklayabilecek hâle gelin.
  3. Crash, network failure, offline mode, performance ve memory leak senaryolarını çalışın.
  4. En az beş gerçek deneyim hikâyesi hazırlayın.
  5. Bir arkadaşınızla mock interview yapın ve takip sorularına özellikle çalışın.
  6. Cevaplarınızı ölçülebilir sonuçlar, trade-off’lar ve doğrulama adımlarıyla güçlendirin.
  7. Mülakat öncesinde şirketin ürününü, Android stack’ini ve rolün beklentilerini araştırın.

30 Android Teknik Mülakat Sorusu ve Örnek Cevaplar

1. Yakın zamanda çalıştığınız bir Android projesini anlatır mısınız?

Problemi, kullanıcı etkisini, sizin sorumluluğunuzu, aldığınız teknik kararları ve sonucu anlatırım. Kullandığım teknoloji listesini vermekle yetinmem; neden o yaklaşımı seçtiğimi ve nasıl doğruladığımı açıklarım.

2. Production crash’ini nasıl araştırırsınız?

Crash’i etki ve sıklığa göre önceliklendirir, Crashlytics ve stack trace’i inceler, sürüm ve cihaz bilgilerini karşılaştırır, yeniden üretmeye çalışır, kök nedeni düzeltir, regression testi ekler ve release sonrasında sonucu izlerim.

3. Kritik bir bug’ı düzeltirken hangi ödünleşimleri düşünürsünüz?

Immediate production risk ile uzun vadeli code quality arasındaki dengeyi düşünürüm. Önce düşük riskli bir hotfix, daha sonra ayrı bir refactor gerekebilir. Public API, migration, performans, güvenlik ve test risklerini de hesaba katarım.

4. Jetpack Compose’un geleneksel View’lara avantajı nedir?

Declarative ve state-driven model, daha az boilerplate, tekrar kullanılabilir bileşenler ve ViewModel ile doğal entegrasyon sağlar. Ancak Compose’un otomatik olarak daha hızlı olmadığını; recomposition ve state stability’nin yine doğru yönetilmesi gerektiğini de belirtirim.

5. Compose ile hangi zorlukları yaşadınız?

Dinamik listelerde gereksiz recomposition’ları yönetmek önemliydi. Stable key, immutable UI model, StateFlow ve pahalı hesaplamaları composable dışına taşıma ile liste davranışını iyileştirdim.

6. LazyColumn RecyclerView’dan hızlı mıdır?

Her durumda böyle bir iddia kurmam. RecyclerView da çok iyi optimize edilmiştir. LazyColumn’ın benim için temel avantajı state-driven geliştirmeyi ve list güncellemelerini sadeleştirmesidir; performansı gerçek ölçümlerle karşılaştırırım.

7. Compose migration sonrasında performansı nasıl ölçtünüz?

Gerçekçi büyüklükte dataset ile önceki ve sonraki scrolling, frame davranışı, memory kullanımı ve recomposition sonuçlarını Android Studio araçlarıyla karşılaştırdım. UI ve unit testleri koruyup farklı Android sürümlerinde manuel regression yaptım.

8. Recomposition nedir?

Gözlemlenen state değiştiğinde Compose’un ilgili composable fonksiyonları tekrar çalıştırarak UI’ı güncellemesidir. Normaldir; problem pahalı işlerin her recomposition’da tekrarlanması veya unstable parametrelerin gereğinden büyük bir ağacı etkilemesidir.

9. State hoisting nedir?

State sahipliğini daha üst seviyeye taşımak ve child composable’a value ile event callback vermektir. Böylece bileşen daha tekrar kullanılabilir, test edilebilir ve kontrol edilebilir olur.

10. remember ve rememberSaveable arasındaki fark nedir?

remember recomposition’lar arasında değeri korur; configuration veya process recreation sonrasında koruma garantisi vermez. rememberSaveable desteklenen değerleri saved-state mekanizmasıyla koruyabilir. Business state’i sırf bu araç var diye composable içine koymam; genellikle ViewModel uygun yerdir.

11. Neden ViewModel kullanırsınız?

Ekran state’i ile render işini ayırır, configuration change sonrasında state’i korur ve UI’ın networking veya business logic ile dolmasını engeller. Genellikle immutable UI state’i StateFlow üzerinden expose ederim.

12. Neden MVVM kullanırsınız?

UI sorumluluğu ile uygulama mantığı arasında net bir ayrım sağlar, test edilebilirliği artırır ve coupling’i azaltır. Her feature’a gereksiz katman eklemem; mimariyi gerçek karmaşıklığa göre ölçeklendiririm.

13. Clean Architecture nedir?

Bağımlılıkları daha stabil business logic’e doğru yönlendiren, presentation, domain ve data sorumluluklarını ayıran bir yaklaşımdır. Değeri net sınırlar ve test edilebilirliktir; riskiyse mekanik biçimde uygulandığında overengineering’e dönüşmesidir.

14. StateFlow ve SharedFlow ne zaman kullanılır?

Mevcut değeri olan ekran state’i için StateFlow, current-state semantiğinin gerekmediği yayınlar için SharedFlow kullanırım. Loading/content/error doğal bir StateFlow örneğidir; transient sinyallerde SharedFlow düşünülebilir.

15. Flow ve LiveData arasındaki fark nedir?

LiveData lifecycle-aware geleneksel Android stack’iyle iyi çalışır. Flow daha genel bir asynchronous pipeline ve daha zengin operator seti sunar. Yeni Kotlin ve Compose projelerinde Flow/StateFlow’u tercih eder, mevcut projelerde LiveData’yı da sürdürebilirim.

16. launch ve async arasındaki fark nedir?

launch doğrudan sonuç beklemeden iş başlatır ve Job döndürür. async Deferred döndürür ve sonuç await ile alınır. İkisini structured concurrency içinde kullanırım.

17. Structured concurrency nedir?

Coroutine’lerin net bir sahibi ve yaşam süresi olmasıdır. Child coroutine’ler parent scope’a bağlı olduğundan cancellation ve hatalar kontrol edilebilir biçimde yayılır; Android’de ViewModel ve lifecycle scope’larının değeri buradan gelir.

18. Coroutine exception’larını nasıl yönetirsiniz?

Beklenen exception’ları uygun sınırda domain veya UI sonucuna çeviririm; her şeyi global catch ile saklamam. CancellationException’ın genellikle propagate edilmesi gerektiğini ve programming error ile beklenen failure’ın ayrılması gerektiğini bilirim.

19. Race condition nedir?

Concurrent işlemlerin aynı state’e erişim zamanına göre farklı sonuç üretmesidir. Tek sahiplik, immutable state transition, Mutex, atomic operation, transaction veya workflow’u yeniden tasarlama seçeneklerini probleme göre değerlendiririm.

20. WorkManager’ı ne zaman kullanırsınız?

Process sonlandırılsa bile zaman içinde tamamlanması gereken ertelenebilir işler için kullanırım: synchronization, upload veya periyodik bakım gibi. Ekrana bağlı işlerde lifecycle-aware coroutine, hemen devam etmesi gereken görünür uzun işlerde foreground service daha uygun olabilir.

21. Service ve WorkManager farkı nedir?

Service bağımsız veya devam eden işler için, WorkManager ise ertelenebilir ve sonunda tamamlanması gereken işler için uygundur. İşin hemen başlayıp başlamadığı, uzun sürüp sürmediği, kullanıcıya görünür olup olmadığı ve process termination sonrasında beklenip beklenmediği belirleyicidir.

22. Background audio playback’i nasıl tasarlarsınız?

Player’ı Activity veya composable’dan ayırır, Media3 ve MediaSession kullanır, persistent playback için foreground service kurarım. Audio focus, notification, interruption, buffering, lifecycle ve playback state restoration’ı ayrıca ele alırım.

23. API failure’larını nasıl yönetirsiniz?

Connectivity, timeout, authentication, client ve server hatalarını ayırırım. Her isteği otomatik retry etmem; güvenli retry, exponential backoff, idempotency ve kullanıcıya sunulacak recovery yolunu değerlendiririm.

24. Offline-first Android uygulamasını nasıl tasarlarsınız?

UI’ın local database’i Flow üzerinden gözlemlemesini, network işlemlerinin database’i güncellemesini ve repository’nin iki kaynağı koordine etmesini tercih ederim. En zor kısım Room değil, conflict resolution’dır; server mı client mı authoritative olacak önceden belirlenmelidir.

25. Regression’ları nasıl önlersiniz?

Önce bug’ı reproduce eder ve hangi katmanın izin verdiğini bulurum. Kök nedeni düzeltip unit, integration veya UI seviyesinde en dar güvenilir testi eklerim. Release sonrasında production telemetry’yi de izlerim.

26. Android test stratejiniz nedir?

Deterministic business logic’i hızlı unit testlerle, bileşenler arası davranışı integration testlerle, kritik kullanıcı yolculuklarını UI testleriyle korurum. Testi release öncesi eklenen bir görev değil, feature tasarımının parçası olarak görürüm.

27. Uçtan uca sahip olduğunuz bir feature’ı anlatın.

Gereksinimden release’e kadar sorumluluğu; sınırları, state modelini, teknik kararları, testleri, lifecycle senaryolarını ve release sonrası izlemeyi birlikte anlatırım. Sonuçta hangi problemin çözüldüğünü ve neyin ölçüldüğünü belirtirim.

28. Çözdüğünüz zor bir teknik problemi anlatın.

Problemin neden zor olduğunu, hangi varsayımları test ettiğimi, alternatifleri neden elediğimi, uygulama sırasında hangi edge case’lerle karşılaştığımı ve sonucu nasıl doğruladığımı anlatırım. Hikâyenin sonunda mutlaka öğrendiğim dersi eklerim.

29. Code quality ile deadline arasında nasıl denge kurarsınız?

Trade-off’u görünür kılarım. Correctness, security, kritik path testleri ve bakım yapılabilirlikten ödün vermek yerine kapsamı azaltmayı öneririm. Geçici çözüm gerekiyorsa sınırlamalarını ve takip işini görünür tutarım.

30. Bize sormak istediğiniz bir şey var mı?

Evet. Ekibin şu anki teknik zorluklarını, Compose migration stratejisini, release ve incident süreçlerini ve bu role katılacak mühendisten ilk aylardaki başarı beklentisini sorarım.

Takip Sorularına Nasıl Cevap Verilir?

En büyük hatalardan biri yalnızca ilk cevabı hazırlamaktır. “Performansı iyileştirdim” derseniz “Nasıl ölçtün?”; “StateFlow kullandım” derseniz “Neden SharedFlow değil?”; “Clean Architecture kullandım” derseniz “Bu mimarinin maliyeti neydi?” sorularını bekleyin.

Kullanışlı bir kural şudur: Mülakatta bir teknolojinin adını, onun hakkında iki veya üç seviye takip sorusuna hazır değilseniz kullanmayın.

Hatırlanacak Basit Formüller

Production deneyimi için:

Durum → Problem → Araştırma → Karar → Uygulama → Doğrulama → Sonuç

Teknik kavramlar için:

Tanım → Neden var → Ne zaman kullanırım → Ödünleşim → Gerçek örnek

Mimari için:

Gereksinimler → Kısıtlar → Seçenekler → Karar → Ödünleşimler → Doğrulama

Hata ayıklama için:

Gözle → Ölç → Yeniden üret → İzole et → Düzelt → Test et → İzle

Sonuç

Android teknik mülakatına hazırlanmak, API isimlerini ezberlemekten çok daha fazlasıdır. Gerçek bir uygulamanın state, lifecycle, network, persistence, performance, test ve release problemlerini nasıl ele aldığınızı anlatabilmelisiniz.

Güçlü cevaplar; problemi netleştirir, kararın nedenini açıklar, ödünleşimi kabul eder, sonucu ölçer ve production sorumluluğunu gösterir. Bu şekilde cevap verdiğinizde Android API’lerini ezberlemiş biri gibi değil, Android yazılımını gerçek hayatta işletmiş bir mühendis gibi görünürsünüz.