iOS (Swift) Developer Mülakat Soruları: Mülakatlarda En Çok Çıkan Konular

iOS mülakat soruları, Swift dilini, SwiftUI ve UIKit arayüz çatılarını, bellek yönetimini ve eşzamanlılık modelini ölçen teknik soru setidir. 2012'den beri web ve mobil projeler yönetiyorum; uygulama tarafında ekip kurarken bu soruları masanın öbür tarafından soruyorum. Bu yazıda soruları konu başlıklarına göre ayırıp kısa yanıtlar ve kod örnekleriyle anlatıyorum.

Amacım ezber listesi vermek değil. Her başlıkta mülakatçının aslında neyi ölçtüğünü de açıklıyorum, çünkü iyi bir yanıt tanımı tekrarlamaz, nedenini gösterir. Yazılımla ilgili diğer içeriklere yazılım kategorisinden ulaşabilirsiniz.

iOS mülakat soruları hangi konuları kapsar?

iOS mülakat soruları beş ana alanı kapsar: Swift dil temelleri, bellek yönetimi ve ARC, SwiftUI ile durum yönetimi, UIKit yaşam döngüsü ve eşzamanlılık. Kıdem arttıkça mimari, test ve performans soruları da devreye girer; bu nedenle hazırlığı temelden mimariye doğru, katman katman kurmanızı öneririm.

Sahada gördüğüm tablo şu: junior adaylara çoğunlukla optional kullanımını ve struct ile class farkını soruyorum. Orta seviyede ARC, closure yakalama listeleri ve SwiftUI property wrapper'ları öne çıkıyor. Senior seviyede ise Swift Concurrency, actor izolasyonu, modüler mimari ve test stratejisi masaya geliyor.

Kaynak olarak ilk adresiniz resmi dokümantasyon olmalı. The Swift Programming Language kitabı dilin tüm temel kavramlarını ücretsiz anlatır. Ayrıca mülakatçıların çoğu soruyu doğrudan bu kitaptaki bölüm başlıklarından türettiğini gözlemliyorum.

iOS mülakat süreci hangi aşamalardan oluşur?

Şirketten şirkete değişse de sahada gördüğüm akış benzer. Aşağıdaki tablo her aşamada neyin ölçüldüğünü özetliyor. Süreler saha tecrübesine dayalı başlangıç aralığıdır, garanti değildir.

Canlı kodlama aşaması için algoritma pratiği de şart. Bu konuda yazılım yazılarımızda egzersiz platformlarını ayrıca ele alıyoruz.

Swift'te optional nedir ve nasıl güvenle açarsınız?

Optional, bir değerin var olabileceğini ya da nil olabileceğini tip sisteminde açıkça ifade eden yapıdır. Mülakatçı burada sizin çökme riskini nasıl yönettiğinizi ölçer. Zorla açma operatörünü (!) refleks olarak kullanan aday genellikle puan kaybeder.

Güvenli açmanın dört yolunu bilmeniz yeterli:

• if let: değer varsa kısa bir blok içinde kullanırsınız.
• guard let: erken çıkış sağlar, fonksiyonun geri kalanında değeri açık hâlde tutar.
• Nil birleştirme (??): değer yoksa varsayılan verirsiniz.
• Optional zincirleme (?.): zincirdeki herhangi bir halka nil ise sonuç da nil olur.

func kullaniciAdi(_ user: User?) -> String {
    guard let user, !user.name.isEmpty else { return "Misafir" }
    return user.name
}

Örneğin guard let ile yazdığınız kodu anlatırken "mutlu yol sola hizalı kalır" demeniz, okunabilirliği önemsediğinizi gösterir. Bununla birlikte implicitly unwrapped optional (String!) sorusu da gelebilir; IBOutlet gibi yaşam döngüsü garanti eden yerlerde kullanıldığını söylemeniz yeterli olur.

Struct ile class arasındaki fark nedir?

Bu soru neredeyse her iOS mülakatında çıkar. Struct bir değer tipidir; kopyaladığınızda bağımsız bir kopya oluşur. Class ise referans tipidir; iki değişken aynı nesneyi gösterir ve birindeki değişiklik diğerine yansır.

İyi bir yanıt burada durmaz. Apple'ın yapı ve sınıf seçimi rehberi varsayılan olarak struct kullanmanızı, kimlik ya da Objective-C uyumluluğu gerektiğinde class seçmenizi önerir. Ayrıca Array ve Dictionary gibi koleksiyonların copy-on-write davrandığını eklerseniz, performans tarafını da düşündüğünüzü gösterirsiniz.

ARC nasıl çalışır ve retain cycle nasıl oluşur?

ARC (Automatic Reference Counting), bir sınıf örneğine kaç güçlü referans olduğunu sayar ve sayı sıfıra düştüğünde belleği serbest bırakır. Çöp toplayıcıdan farkı, işi derleme zamanında eklenen retain ve release çağrılarıyla yapmasıdır.

Retain cycle ise iki nesnenin birbirini güçlü tutmasıyla oluşur. Sayı hiçbir zaman sıfıra düşmez, dolayısıyla bellek sızıntısı ortaya çıkar. Klasik örnek, bir view controller'ın bir closure'ı tutması ve closure'ın da self'i yakalamasıdır.

viewModel.onUpdate = { [weak self] data in
    guard let self else { return }
    self.render(data)
}

Mülakatçı burada genellikle weak ile unowned farkını da sorar. Kısacası weak her zaman optional'dır ve nesne yok olunca nil olur. Unowned ise nesnenin yaşamının en az referans kadar süreceğini varsayar; varsayım yanlışsa uygulama çöker. Pratikte ben adaylardan emin olmadıkları durumda weak seçmelerini ve nedenini söylemelerini beklerim.

Closure'larda escaping ve yakalama listesi ne işe yarar?

Bir closure fonksiyon döndükten sonra çağrılacaksa onu @escaping olarak işaretlersiniz; ağ çağrısı tamamlayıcıları bunun tipik örneğidir. Escaping olmayan closure fonksiyon bitmeden çalışır, bu yüzden self'i açıkça yazmanız gerekmez ve derleyici bazı optimizasyonları yapabilir.

Yakalama listesi ([weak self], [count] gibi) closure'ın dış değerleri nasıl tutacağını belirler. Değer tipini listede yazarsanız closure oluştuğu andaki kopyayı yakalar. Bu ayrıntı mülakatta sık gelen bir tuzak sorusudur:

var sayac = 0
let a = { print(sayac) }
let b = { [sayac] in print(sayac) }
sayac = 5
a() // 5
b() // 0

Bu örneği yanıtlarken neden farklı sonuç çıktığını anlatmanız, ezberden çok modeli anladığınızı kanıtlar. Öte yandan her closure'a refleksle [weak self] eklemenin de gereksiz olduğunu, escaping olmayan closure'larda döngü riskinin bulunmadığını söylemek artı puandır.

Protokol yönelimli programlama neden önemlidir?

Swift, kalıtım yerine protokol ve protokol eklentileriyle davranış paylaşmayı teşvik eder. Protokol eklentisi (extension) ile varsayılan uygulama verirsiniz; böylece struct ve enum da ortak davranışa sahip olur, çünkü bu tiplerde kalıtım yoktur.

Mülakatta sık gelen sorular şunlardır:

1. Protokol ile soyut sınıf arasındaki fark nedir?
2. associatedtype ne işe yarar ve neden bu protokolü doğrudan tip olarak kullanamazsınız?
3. some ve any anahtar kelimeleri arasında ne fark vardır?
4. Protokol eklentisindeki bir metot neden bazen statik dağıtımla çalışır?

Son soru ileri seviyedir. Yani protokol gereksinimlerinde yer almayan, yalnız eklentide duran bir metot statik dağıtımla çalışır ve alt tipteki uygulama devreye girmeyebilir. Bu ayrıntıyı bir kod örneğiyle gösterebilirseniz senior seviyede ciddi fark yaratırsınız.

Generics, some ve any arasındaki fark nedir?

Generics, aynı kodu farklı tiplerle tip güvenliğini kaybetmeden kullanmanızı sağlar. some anahtar kelimesi opak tip bildirir: dönen tip sabittir ama çağırana gizlidir. SwiftUI'daki some View ifadesi bunun en bilinen örneğidir.

any ise varoluşsal tiptir; çalışma zamanında farklı somut tipleri aynı kutuda taşıyabilir. Ancak bu kutulamanın bir maliyeti vardır ve dinamik dağıtım gerektirir. Bu nedenle performans kritik kodda generics ya da some tercih edildiğini söylemek doğru bir yanıttır.

func ilkEleman<T: Collection>(_ c: T) -> T.Element? { c.first }
let sekiller: [any Shape] = [Circle(), Rectangle()]

Mülakatçı burada teoriden çok karar mantığını dinler. Örneğin "Heterojen bir liste gerekiyorsa any, tek tip ama gizli bir dönüş gerekiyorsa some kullanırım" gibi net bir kural cümlesi, uzun bir tanımdan daha çok puan getirir.

Enum ve pattern matching sorularına nasıl yanıt verirsiniz?

Swift enum'ları ilişkili değer taşıyabilir, metot ve computed property içerebilir. Bu yüzden durum modellemede güçlü bir araçtır. Mülakatta genellikle bir ekranın yükleme, başarı ve hata durumlarını enum ile modellemeniz istenir.

enum EkranDurumu {
    case yukleniyor
    case basarili([Urun])
    case hata(String)
}

Ardından switch ile tüm durumları ele almanızı, derleyicinin eksik case için uyarı vermesinin neden değerli olduğunu anlatmanızı beklerler. Ayrıca indirect enum, Result tipi ve if case let sözdizimi de bu başlıkta sık gelir. Kısacası enum'u yalnız sabit listesi olarak değil, geçersiz durumları imkânsız kılan bir tasarım aracı olarak anlatmalısınız.

SwiftUI'da @State, @Binding ve @Observable ne zaman seçmelisiniz?

SwiftUI soruları artık iOS mülakat sorularının merkezinde. Mülakatçı, veriyi kimin sahiplendiğini doğru söyleyip söyleyemediğinize bakar. Kısa kural şudur:

• @State: görünümün kendi sahip olduğu küçük, yerel değer.
• @Binding: üst görünümdeki bir değere okuma ve yazma erişimi.
• @Observable: iOS 17 ile gelen Observation çatısındaki model sınıfları için makro.
• @Environment: görünüm ağacına enjekte ettiğiniz paylaşılan değerler.
• @StateObject ve @ObservedObject: eski ObservableObject modelinde sahiplik ve gözlem ayrımı.

Apple'ın ObservableObject'ten @Observable makrosuna geçiş rehberi yeni modelde görünümün yalnız okuduğu özellikler değiştiğinde yeniden çizildiğini anlatır. Dolayısıyla performans sorusuna bu farkla yanıt vermeniz güçlü bir işarettir. Ayrıca @StateObject yerine @ObservedObject yazıldığında nesnenin her yeniden oluşturmada sıfırlanabileceğini söylemek klasik bir artı puandır.

SwiftUI görünüm yaşam döngüsü ve kimlik nasıl işler?

SwiftUI'da görünümler hafif değer tipleridir ve SwiftUI onları sık sık yeniden kurar. Asıl önemli olan görünüm kimliğidir: yapısal kimlik, görünümün ağaçtaki konumundan gelir; açık kimlik ise id() ya da ForEach içindeki Identifiable değerinden gelir.

Kimlik değişirse SwiftUI görünümü yeni bir görünüm sayar ve @State değerini sıfırlar. Bu yüzden ForEach içinde dizi indeksini kimlik olarak kullanmanın neden hatalı animasyon ve durum kaybı yarattığını mülakatçılar sık sorar.

Yaşam döngüsü tarafında onAppear, onDisappear ve task değiştiricilerini bilmeniz gerekir. Özellikle task değiştiricisi görünüm kaybolduğunda kendi görevini otomatik iptal eder; bu davranışı anlatmanız eşzamanlılık bilginizi de gösterir. Öte yandan body içinde ağır hesap yapmanın neden yanlış olduğunu açıklamak da iyi bir tamamlayıcıdır.

UIKit'te view controller yaşam döngüsü hangi sırayla çalışır?

SwiftUI yaygınlaşsa da kurumsal projelerin büyük kısmı hâlâ UIKit üzerinde duruyor. Bu yüzden UIKit soruları hâlâ gelir. Temel sıralama şudur:

1. loadView: görünüm hiyerarşisini oluşturur.
2. viewDidLoad: yalnız bir kez çalışır, ilk kurulumu burada yaparsınız.
3. viewWillAppear: her gösterimden önce çalışır.
4. viewDidLayoutSubviews: yerleşim hesaplandıktan sonra çalışır.
5. viewDidAppear: görünüm ekrandadır, animasyon başlatmak için uygundur.
6. viewWillDisappear ve viewDidDisappear: ekrandan çıkarken çalışır.

Mülakatçı genellikle "çerçeve boyutuna viewDidLoad içinde güvenebilir misiniz?" diye sorar. Yanıt hayırdır, çünkü Auto Layout henüz yerleşimi hesaplamamıştır. Ayrıca UIViewController dokümantasyonu yaşam döngüsü metotlarının ayrıntılarını ve üst sınıf çağrısı kurallarını anlatır.

Auto Layout ve tablo görünümü sorularında neye dikkat etmelisiniz?

Auto Layout sorularında içerik sıkıştırma direnci (compression resistance) ve içeriğe sarılma önceliği (hugging priority) sık gelir. Örneğin yan yana iki etiketten hangisinin kısalacağını bu öncelikler belirler. Bu ayrımı çizimle anlatabilirseniz güçlü bir izlenim bırakırsınız.

UITableView ve UICollectionView tarafında ise hücre yeniden kullanımı temel konudur. dequeueReusableCell ile gelen hücre önceki içeriği taşıyabilir; bu nedenle prepareForReuse içinde görsel ve durum sıfırlaması yaparsınız. Aksi hâlde hızlı kaydırmada kullanıcı yanlış görselleri görür.

Modern yanıtta diffable data source ve compositional layout'tan da söz edin. Böylece veri değişimini anlık görüntü (snapshot) ile verip animasyonlu güncellemeyi sisteme bıraktığınızı anlatırsınız. Hem UIKit hem SwiftUI bilen aday, iki dünyayı UIHostingController ve UIViewRepresentable ile nasıl birleştirdiğini de açıklayabilmelidir.

Swift'te hata yönetimi sorularına nasıl yanıt verirsiniz?

Hata yönetimi soruları çoğu zaman basit görünür ama adayı hızla ayırır. Swift'te hata fırlatabilen fonksiyonu throws ile işaretlersiniz, çağırırken try kullanırsınız ve do-catch bloğuyla yakalarsınız. try? hatayı yutar ve nil döndürür; try! ise hata oluşursa uygulamayı çökertir.

Mülakatçı genellikle şu ayrımları dinler:

• throws ile Result: senkron akışta throws, depolanacak ya da ertelenecek sonuçta Result daha okunaklıdır.
• Özel hata tipi: Error protokolüne uyan bir enum ile ekranın hangi mesajı göstereceğini netleştirirsiniz.
• Typed throws: Swift 6 ile fonksiyonun hangi hata tipini fırlattığını açıkça yazabilirsiniz.
• rethrows: yalnız parametre olarak gelen closure hata fırlatırsa fonksiyonun da fırlatmasını sağlar.

İyi bir yanıt, hatayı kullanıcıya nasıl yansıttığınızı da anlatır. Örneğin ağ hatasında yeniden dene düğmesi, yetki hatasında giriş ekranına yönlendirme ve beklenmeyen hatada kayıt tutma gibi ayrımlar, ürün düşüncenizi gösterir. Kısacası try? kullanımını her yerde görmek mülakatçı için bir uyarı işaretidir, çünkü hatayı sessizce kaybettiğinizi düşündürür.

Property wrapper, lazy ve computed property farkları nelerdir?

Bu başlık özellikle orta seviye mülakatlarda gelir. Computed property bir değeri saklamaz, her erişimde hesaplar. Lazy property ise ilk erişimde bir kez hesaplanıp saklanır; yalnız var ile tanımlarsınız ve thread güvenli değildir. Bu son ayrıntıyı söylemeniz dikkatli olduğunuzu gösterir.

Property wrapper ise bir özelliğin okuma ve yazma davranışını tekrar kullanılabilir bir tipe taşır. SwiftUI'daki @State ve @AppStorage aslında birer property wrapper'dır. Mülakatta sizden küçük bir örnek yazmanızı isteyebilirler:

@propertyWrapper
struct Kirp {
    private var deger = ""
    var wrappedValue: String {
        get { deger }
        set { deger = newValue.trimmingCharacters(in: .whitespaces) }
    }
}

Ardından projectedValue ile $ önekinin nereden geldiğini açıklarsanız, SwiftUI'daki $isim sözdizimini de mantıkla bağlamış olursunuz. Ayrıca didSet ve willSet gözlemcilerinin ne zaman tetiklendiğini bilmek bu başlığı tamamlar.

Swift Concurrency'de async/await ve actor nasıl çalışır?

Swift 5.5 ile gelen async/await, asenkron kodu tamamlayıcı closure'lar yerine düz akışla yazmanızı sağlar. Actor ise durumunu eşzamanlı erişime karşı koruyan bir referans tipidir; dışarıdan erişim await gerektirir ve derleyici veri yarışını engeller.

actor Sepet {
    private var urunler: [Urun] = []
    func ekle(_ u: Urun) { urunler.append(u) }
}

@MainActor
func yenile() async {
    let liste = try? await api.urunleriGetir()
    ekran.guncelle(liste ?? [])
}

Mülakatta sık gelen konular şunlardır: @MainActor ile arayüz güncellemesi, Task ile bağımsız görev başlatma, async let ve TaskGroup ile paralel iş, görev iptali ve Sendable protokolü. Ayrıca Swift 6 dil modunun veri yarışlarını derleme zamanında hata olarak raporladığını bilmelisiniz. Apple'ın Swift 6 geçiş rehberi bu konudaki en sağlam kaynaktır.

GCD ve OperationQueue soruları hâlâ gelir mi?

Evet, özellikle eski kod tabanına sahip şirketlerde gelir. Grand Central Dispatch sorularında seri ve eşzamanlı kuyruk farkı, main queue üzerinde sync çağrısının neden kilitlenme (deadlock) yarattığı ve DispatchGroup ile birden fazla isteği bekleme konuları öne çıkar.

OperationQueue tarafında ise bağımlılık tanımlama, iptal ve eşzamanlı işlem sınırı gündeme gelir. İyi bir yanıt, iki aracı Swift Concurrency ile karşılaştırır. Örneğin yeni kodda async/await ve actor tercih ettiğinizi, ancak eski modülleri kademeli olarak taşıdığınızı ve withCheckedContinuation ile köprü kurduğunuzu anlatabilirsiniz.

Mülakatçı burada teknolojiye bağlılıktan çok geçiş stratejisine bakar. Dolayısıyla "her şeyi bir haftada yeniden yazarım" yerine riski düşük modülden başlayan, testle korunan kademeli bir plan anlatmanız çok daha güven verir.

MVVM, Coordinator ve TCA gibi mimari sorulara nasıl hazırlanırsınız?

Mimari sorularda doğru yanıt tek bir desen değildir; mülakatçı ödünleşimleri dinler. MVC, UIKit'in varsayılan yaklaşımıdır ama büyük view controller sorununa yol açabilir. MVVM, sunum mantığını test edilebilir bir modele taşır ve SwiftUI ile doğal uyum sağlar.

• MVVM: test edilebilirlik ve SwiftUI uyumu güçlü, ancak model şişebilir.
• Coordinator: gezinme mantığını ekranlardan ayırır, UIKit projelerinde yaygındır.
• VIPER ve Clean Architecture: büyük ekiplerde sorumluluk ayrımı sağlar, küçük projede ağır gelir.
• TCA (The Composable Architecture): tek yönlü veri akışı ve güçlü test desteği sunar, öğrenme eğrisi diktir.

Benim adaylardan beklediğim yanıt şudur: "Ekip büyüklüğüne ve ürünün ömrüne göre seçerim; küçük ekipte MVVM ve basit bir gezinme katmanı yeterli olur." Böylece ideolojiye değil bağlama göre karar verdiğinizi gösterirsiniz.

Test ve hata ayıklama konusunda hangi iOS mülakat soruları çıkar?

Test soruları senior seviyede neredeyse kesin gelir. Bağımlılık enjeksiyonu ile ağ katmanını protokol arkasına almanız, testte sahte (mock) bir uygulama vermenizi isterler. Ayrıca XCTest ile birlikte yeni Swift Testing çatısındaki @Test ve #expect makrolarından söz etmeniz güncel olduğunuzu gösterir.

Hata ayıklama tarafında sık sorulanlar şunlardır:

• Instruments içinde Leaks ve Allocations ile bellek sızıntısını nasıl bulursunuz?
• Memory Graph Debugger ile retain cycle'ı nasıl görürsünüz?
• Time Profiler ile ana iş parçacığını kilitleyen kodu nasıl tespit edersiniz?
• Thread Sanitizer hangi hataları yakalar?

Bu soruları yanıtlarken gerçek bir hatayı nasıl bulduğunuzu adım adım anlatın. Üstelik çözümün ardından tekrarını önlemek için yazdığınız testi de söylerseniz, süreç disiplini olan biri olarak öne çıkarsınız.

Canlı kodlamada iOS mülakat sorularına nasıl yaklaşırsınız?

Canlı kodlamada genellikle bir API'den liste çekip ekranda gösterme, arama kutusuna gecikmeli filtre (debounce) ekleme ya da görsel önbelleği yazma gibi pratik görevler gelir. İlk olarak gereksinimleri tekrar edin ve belirsizlikleri sorun; örneğin hata durumunun ve boş listenin nasıl görüneceğini netleştirin.

Ardından en basit çalışan sürümü yazın, sonra iyileştirin. Kodu yazarken sesli düşünmek, mülakatçının akıl yürütmenizi izlemesini sağlar. Takıldığınızda sessiz kalmak yerine hangi seçenekleri tarttığınızı söyleyin.

Sık yapılan hataları da bilin: arayüzü arka plan iş parçacığında güncellemek, görsel indirmede hücre yeniden kullanımını unutmak ve hata yönetimini tamamen atlamak. Son olarak kodu bitirdiğinizde hangi testleri yazacağınızı kısaca söylemeniz, işi bitirme disiplininizi gösterir.

Ev ödevi projesinde nelere dikkat etmelisiniz?

Ev ödevi projesi, günlük çalışma biçiminizin en gerçekçi göstergesidir. Özellikle şu noktalara dikkat edin: temiz bir klasör yapısı, protokol arkasında ağ katmanı, anlamlı hata mesajları ve birkaç anlamlı birim testi. Bunlar olmadan gösterişli animasyon eklemek puan kazandırmaz.

README dosyası da ayrı bir değerlendirme kalemidir. Hangi mimariyi neden seçtiğinizi, neyi bilerek kapsam dışı bıraktığınızı ve daha fazla zamanınız olsa neyi ekleyeceğinizi kısa maddelerle yazın. Böylece mülakatçı, eksikleri bilinçli bir kapsam kararı olarak okur.

Ayrıca uygulamanın mobil kullanılabilirliğini de unutmayın: Dynamic Type desteği, karanlık mod ve VoiceOver etiketleri küçük ama fark yaratan ayrıntılardır. Mobil arayüz tarafında düşünme biçimini geliştirmek isterseniz mobil öncelikli tasarım yazısına ve arayüz tasarımındaki UX hataları yazısına göz atabilirsiniz.

Sistem tasarımı sorularında iOS tarafında ne beklerler?

Senior adaylara "bir mesajlaşma uygulamasının istemci tarafını tasarlayın" ya da "çevrimdışı çalışan bir haber akışı kurun" gibi sorular gelir. Burada sunucu mimarisi değil, istemci mimarisini konuşursunuz: veri katmanı, önbellek, senkronizasyon ve hata durumları.

Güçlü bir yanıt şu katmanları sırayla ele alır: ağ katmanı ve yeniden deneme politikası, SwiftData ya da Core Data ile yerel depolama, çakışma çözümü, sayfalama ve görsel önbelleği. Ayrıca arka plan yenileme, bildirim akışı ve pil tüketimi gibi platforma özgü kısıtlardan söz etmenizi isterler.

Öte yandan ölçülebilirliği de konuşursunuz. Uygulama içi analitik olaylarını nasıl adlandırdığınızı ve pazarlama ekibinin kampanya ölçümünü nasıl beslediğinizi anlatabilmek, ürün odaklı düşündüğünüzü gösterir. Bu alanda dijital pazarlama KPI'ları yazısı iyi bir arka plan sağlar.

Davranışsal sorularda ve portfolyoda neyi öne çıkarmalısınız?

Teknik yetkinlik kadar, bir anlaşmazlığı nasıl çözdüğünüz ve bir hatayı nasıl üstlendiğinizi de sorarlar. Yanıtlarınızı durum, görev, eylem ve sonuç sırasıyla kurarsanız dağılmazsınız. Rakam vermek zorunda değilsiniz; ancak verdiğiniz her rakamın kaynağını bilin.

Portfolyo tarafında App Store'da yayında bir uygulama büyük avantajdır. Yayında uygulamanız yoksa GitHub'da temiz bir örnek proje de işe yarar. Bununla birlikte kişisel bir web sayfası, projelerinizi tek adreste toplamanın en düzenli yoludur; sayfanın arama sonuçlarında nasıl görüneceğini Google SERP önizleme aracıyla kontrol edebilir, başlık ve açıklamayı meta title yazım rehberine göre düzenleyebilirsiniz.

Eğer kendi uygulamanızı bir işe dönüştürmeyi düşünüyorsanız, tanıtım sitesi ve görünürlük tarafında web tasarım ve SEO danışmanlığı sayfalarımızdan nasıl çalıştığımızı inceleyebilirsiniz.

iOS mülakat sorularına hazırlanmak için nasıl bir plan izlemelisiniz?

Dağınık çalışmak yerine haftalık bir plan izlemenizi öneririm. Aşağıdaki sıra saha tecrübesine dayalı bir başlangıç önerisidir, garanti değildir; kendi seviyenize göre süreleri uzatıp kısaltabilirsiniz.

1. Birinci hafta: optional, değer ve referans tipleri, enum, protokoller ve generics.
2. İkinci hafta: ARC, closure yakalama listeleri, Instruments ile sızıntı bulma.
3. Üçüncü hafta: SwiftUI durum yönetimi, görünüm kimliği ve UIKit yaşam döngüsü.
4. Dördüncü hafta: Swift Concurrency, actor, Sendable ve Swift 6 dil modu.
5. Beşinci hafta: küçük bir örnek proje, testler ve sesli anlatım pratiği.

Her hafta sonunda bir arkadaşınızla deneme mülakatı yapın. Kısacası bilgiyi bilmek ile onu baskı altında anlatmak farklı becerilerdir ve ikincisini ancak pratikle geliştirirsiniz.

Deneme mülakatlarını kayda almanızı da öneririm. Kendi yanıtınızı dinlediğinizde gereksiz tekrarları, dolgu kelimelerini ve eksik bıraktığınız nedenleri çok daha net görürsünüz. Ardından her başlık için tek sayfalık bir not çıkarın: kavramın tanımı, bir kod örneği, bir risk ve bir tercih kuralı. Mülakattan önceki gün bu notları gözden geçirmek, uzun bir listeyi yeniden okumaktan çok daha verimli olur.

Son olarak her mülakattan sonra size sorulan soruları not edin. Böylece birkaç görüşme sonra kendi soru bankanız oluşur ve hazırlığınız, genel listelerden değil gerçek piyasa sorularından beslenir. Başarılar dilerim.