yoklateknik mülakat

Mobil Senior Mülakat Soruları

1468 doğrulanmış Mobil Senior 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 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 3
Bir backend ekibi, artık tüm istemcilerin yeni sürümü kullandığına inanarak bir API yanıtından bir alanı kaldırıyor. Bir hafta sonra, eski bir uygulama sürümündeki kullanıcılar boş ekran bildirmeye başlıyor. En olası atlanan şey neydi?
  • aBazı kullanıcılar henüz güncellememişti ve eski uygulama sürümü hâlâ kaldırılan alana bağımlıydı.
  • bMağaza güncellemeyi reddetti, bu yüzden hiçbir kullanıcı yeni istemciyi hiç almadı.
  • cKaldırılan alanın çökmeyle ilgisi yoktu, gerçek neden bir signing sertifikası uyuşmazlığıydı.
  • dBoş ekran, kademeli rollout'un duraklatılmasından kaynaklanıyor.
Açıklama:Senaryodaki kök neden geriye dönük uyumluluk boşluğudur: bazı kullanıcılar henüz güncellememişti ve eski istemcileri hâlâ kaldırılan alana bağımlıydı. Senaryoda mağaza reddi, signing veya duraklatılmış rollout'a işaret eden hiçbir şey yok.
Mobile Distribution CiZorluk 3
İki sürüm karşılaştırılıyor: A sürümü 100 session üzerinde %0.3 çökme oranına sahip, B sürümü 50.000 session üzerinde %0.5 çökme oranına sahip. Bir ekip hangi çökme oranının bir rollback kararı için daha güvenilir kanıt olduğuna karar veriyor. Hangi akıl yürütme doğru?
  • aA sürümünün oranı daha düşük, bu yüzden örneklem büyüklüğünden bağımsız olarak her zaman daha güvenli sürüm olmalı.
  • bİki sürümün de aynı pazarlama harcaması olmadıkça hiçbir oran anlamlı değildir.
  • cSession'lar farklı günlerde toplandıysa çökme oranı sürümler arasında karşılaştırılamaz.
  • dB sürümünün daha büyük örneklemi, oranı istatistiksel olarak daha güvenilir kılıyor.
Açıklama:Sadece 100 session ile A sürümünün oranı istatistiksel olarak gürültülüdür ve birkaç çökme daha ile büyük ölçüde değişebilir; B sürümünün 50.000 session'dan gelen oranı, yüzdesi daha yüksek olsa da çok daha kararlı bir tahmindir. Pazarlama harcaması ve takvim günü bu karşılaştırmayla ilgisizdir.
Mobile Distribution CiZorluk 3
Bir gönderim şu inceleme notuyla reddediliyor: 'Metadata ekran görüntüleri mevcut uygulama işlevselliğini yansıtmıyor.' Ekibin sürüm kontrol listesi şunları içeriyor:
[x] Otomatik testleri çalıştır
[x] Code signing'i doğrula
[ ] Arayüz değişikliklerinden sonra mağaza listesi varlıklarını güncelle
[x] 24 saatlik çökmesiz oranı kontrol et

Hangi kontrol listesi eksikliği bu spesifik reddedilme nedenini en iyi açıklar?
  • aOtomatik testler maddesi, çünkü başarısız testler tam olarak bu reddedilme mesajını üretir.
  • bCode signing maddesi, çünkü süresi dolmuş imzalar tam olarak bu reddedilme mesajını üretir.
  • cArayüz değişikliklerinden sonra mağaza listesi varlıklarını güncelleme maddesinin işaretlenmemiş olması.
  • dÇökmesiz oran maddesi, çünkü çökme izleme bu listede kontrol edilmiş ama liste içeriğiyle ilgisizdir.
Açıklama:Reddedilme özellikle ekran görüntülerinin mevcut işlevsellikle eşleşmemesiyle ilgili — bu doğrudan işaretlenmemiş 'mağaza listesi varlıklarını güncelle' maddesine karşılık gelir. Test başarısızlıkları ve signing sorunları tamamen farklı reddedilme nedenleri üretir; çökmesiz oran maddesi liste içeriğiyle ilgisiz olsa da bu kontrol listesinde zaten tamamlanmış (işaretlenmiş) durumda.
Mobile Distribution CiZorluk 3
Bir ekibin yayın pipeline'ı uçtan uca otomatik, ama bir yayın, kullanılan signing anahtarının önceki tüm yayınlarda kullanılanla eşleşmemesi nedeniyle yayınlanmadan hemen önce başarısız oluyor. Bu uyuşmayan build yine de zorla yayınlansaydı en olası sonuç ne olurdu?
  • aCihazlar, signing kaynağı artık eşleşmediği için güncellemeyi reddedebilir.
  • bUygulama, mağaza tarafından orijinal anahtar kullanılarak otomatik olarak yeniden imzalanır.
  • cSadece uygulamanın ikonu doğru görüntülenemez.
  • dKademeli rollout yüzdesi otomatik olarak %100'e sıfırlanır.
Açıklama:Mevcut cihazlarda güncelleme kurulumu tipik olarak önceki yayınlarla aynı signing kimliğini gerektirir; uyuşmayan bir anahtar bu güven zincirini kırar ve cihazlar güncellemeyi reddedebilir. Mağazalar build'leri orijinal anahtarla otomatik yeniden imzalamaz; uyuşmazlık kozmetik bir ikon sorunuyla veya rollout yüzdesi sıfırlanmasıyla sınırlı değildir.
Mobile NavigationZorluk 3
Bir deep link, uygulamanın hiyerarşisinde normalde üç seviye derinlikte olan bir ekrana işaret ediyor (Ana Sayfa → Kategori → Ürün). Uygulama deep link üzerinden doğrudan Ürün'e açıldığında back stack ile ne yapmalı?
  • aÜst ekranları stack'e sentezleyerek eklemeli, doğal hiyerarşiyle eşleşecek şekilde
  • bYalnızca Ürün ekranını göstermeli ve o oturum için geri kontrolünü tamamen devre dışı bırakmalı
  • cHedef ekranın derinliğini yok saymalı ve her zaman uygulamanın varsayılan ana ekranını açmalı
  • dÜrün'ü boş bir stack ile açmalı, böylece ilk geri basışında uygulamadan çıkılır
Açıklama:Geri navigasyonunu tutarlı tutmak için uygulama, kullanıcı oraya normal şekilde gitmiş gibi stack'i kurmalıdır (önce Ana Sayfa, sonra Kategori, sonra Ürün); böylece geri basmak beklenmedik çıkış yerine hiyerarşide yukarı adımlar. (b) temel bir navigasyon imkanını ortadan kaldırır; (c) deep link'in amacını boşa çıkarır; (d) ilk geri basışında rahatsız edici bir çıkışa yol açar.

2400 soruluk Mobil bankasında kendini sına.

Mülakata başla