yoklateknik mülakat
GelişimGeçmiş

Mobil Mid Mülakat Soruları

1977 doğrulanmış Mobil Mid mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Mobile Distribution CiZorluk 2
Bir ekip, sürüm takvimine gün ekleyen inceleme döngülerinden kaçınmak istiyor. Hangi gönderim-öncesi kontrol yaygın bir reddedilme nedenini erken yakalar?
  • aBuild'in en güncel derleyici sürümüyle derlendiğini doğrulamak.
  • bİstenen her iznin, o izni kullanan çalışan ve ulaşılabilir bir kod yolu olduğunu doğrulamak.✓
  • cUygulama ikonunun önerilen piksel boyutlarıyla tam eşleştiğinden emin olmak.
  • dSürüm notlarının olabildiğince çok dile çevrildiğinden emin olmak.
Açıklama:İnceleyenler, işlevsel ve ulaşılabilir bir kullanımı olmayan izin talepleri olan uygulamaları sıkça reddeder. Derleyici sürümü, ikon boyutu ve çeviri eksiksizliği tipik reddedilme nedenleri değildir.
Mobile Distribution CiZorluk 2
Bir ekip bir build gönderiyor ve giriş ekranı test hesabı olmadan geçilemediği için reddediliyor; inceleyen kişi ekranı aşamıyor. Ekip gelecekteki gönderimlerde bunu önlemek için neyi değiştirmeli?
  • aHer gönderimden önce giriş ekranını tamamen kaldırmak.
  • bGirişten sonraki ekran sayısını azaltmak.
  • cİnceleyenlerin kilidi geçebilmesi için bir demo hesap sağlamak.✓
  • dUygulama açıklamasına giriş gereksinimini açıklayan bir not eklemek.
Açıklama:İnceleyenlerin uygulamaya gerçekten girebileceği bir yola ihtiyacı vardır; demo hesap veya atlama yolu kök nedeni çözer. Giriş ekranını kaldırmak ya da sadece metin notu eklemek inceleyene çalışan bir yol sağlamaz.
Mobile Distribution CiZorluk 2
Bir ekip yeni bir sürümü kullanıcıların %5'ine dağıtıyor. Birkaç saat içinde, önceki sürümün taban çizgisine göre çökme raporları keskin biçimde artıyor. Uygun acil eylem nedir?
  • aRollout'u durdurmak ve etkilenen kullanıcılar için geri dönmek.✓
  • bDaha hızlı çökme verisi toplamak için rollout'u hemen %100'e genişletmek.
  • cİnceleme ekibinin etkilenen build'i reddetmesini beklemek.
  • dÇökme yaşayan kullanıcılardan uygulamayı yeniden yüklemelerini istemek.
Açıklama:Taban çizgisine göre keskin bir çökme artışı, tam olarak kademeli rollout'un erken yakalamak için tasarlandığı sinyaldir; daha fazla kullanıcıya ulaşmadan durdurmak/geri almak etki alanını sınırlar. Genişletmek zararı artırır; inceleme reddi veya yeniden yükleme isteği regresyonu çözmez.
Mobile Distribution CiZorluk 3
Bir rollout konfigürasyonu şu şekilde ayarlanmış:
release:
  version: 4.2.0
  rollout_percentage: 10
  halt_on_crash_rate_increase: true

Uygulamanın 200.000 aktif kullanıcısı varsa, rollout bu aşamadayken yaklaşık kaç kullanıcı 4.2.0 sürümünü almış olur?
  • aYaklaşık 2.000 kullanıcı.
  • bYaklaşık 20.000 kullanıcı.✓
  • cYaklaşık 180.000 kullanıcı.
  • d200.000 kullanıcının tamamı, çünkü rollout yüzdesi sadece güncelleme görünürlük zamanlamasını etkiler, toplamı değil.
Açıklama:200.000'in %10'u 20.000'dir. Rollout yüzdesi, bu aşamada nüfusun ne kadarının yeni sürümü aldığını doğrudan kontrol eder, sadece görünürlük zamanlamasını değil.
Mobile Distribution CiZorluk 2
Yayından kısa süre sonra, bir ekip yeni yayınlanan bir özellikte kullanıcı şikayetlerine neden olan bir hata keşfediyor. Özellik bir feature flag arkasında gönderilmişti. Yeni bir build göndermeden sorunu azaltmanın en hızlı güvenli yolu nedir?
  • aMağazaya acil bir yeni sürüm göndermek ve hızlandırılmış inceleme beklemek.
  • bKullanıcılardan işletim sistemlerini güncellemelerini istemek.
  • cBir sonraki planlanan sürümde özelliğin kodunu kaldırmak.
  • dKullanıcılar için özelliği devre dışı bırakmak üzere feature flag'i uzaktan kapatmak.✓
Açıklama:Özellik zaten mevcut build'de gönderilmiş bir flag ile kontrol edildiğinden, uzak flag'i kapatmak anındadır ve yeni bir gönderim gerektirmez. Yeni bir build göndermek yine inceleme süresi gerektirir; diğer seçenekler hatayı hızlıca çözmez.
Mobile Distribution CiZorluk 2
Bir ekibin yayın pipeline'ı, süresi dolmuş bir signing sertifikası hatasıyla imzalama adımında başarısız oluyor. Bu başarısızlığın en doğrudan sonucu nedir?
  • aUygulama normal şekilde yayınlanır ama kullanıcılara bir uyarı bandı gösterir.
  • bGeçerli bir sertifika olmadan yayınlanamaz ya da güvenilir sayılamaz.✓
  • cUygulama azaltılmış performansla yayınlanır.
  • dMağaza inceleme süreci otomatik olarak atlanır.
Açıklama:Süresi dolmuş bir signing sertifikası, güvenilir bir build olarak yayınlamayı/kurulumu tamamen engeller — bu kozmetik bir uyarı, performans sorunu ya da incelemeyi atlama yolu değil, sert bir kapıdır.

Konular

Fl Dart Async Isolates 75Fl Dart Language Null Safety 75Fl Flutter Persistence Storage 75Fl Flutter Platform Channels Lifecycle 75Fl Flutter Rendering Widget Tree 75Fl Flutter State Management Widgets 75Ios Core Data Swiftdata Persistence 75Ios Lifecycle Background Execution 75Ios Memory Management Arc 75Ios Swift Concurrency Structured 75Ios Swift Type System Optionals 75Ios Swiftui State Rendering 75Kt Android Lifecycle Background Execution 75Kt Android Memory Context Leaks 75Kt Android Room Persistence 75Kt Jetpack Compose State Recomposition 75Kt Kotlin Coroutines Flow 75Kt Kotlin Type System Null Safety 75Mobile Distribution Ci 75Mobile Navigation 75Mobile Networking Offline 75Mobile Performance Battery 75Mobile Security Storage 75Mobile State Data 75Mobile Testing Automation 75Mobile Ui Lifecycle 75Rn Javascript Typescript Fundamentals 75Rn Native Bridge Modules 75Rn Navigation Lifecycle 75Rn Networking Persistence Offline 75Rn Performance Rendering 75Rn React Hooks State Management 75

Uzmanlığa göre

Android (Kotlin) 450Flutter 450iOS (Swift) 450React Native 450

Kıdeme göre

Mobil JuniorMobil MidMobil Senior

Diğer alanlar

BackendFrontendFullstackDevOps / CloudAI EngineerVeritabanıGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2400 soruluk Mobil bankasında kendini sına.

Mülakata başla