Gerçek hazırlık: sadece algoritma çalışmaktan fazlası
Sağlam bir hazırlık, mülakatın spesifik formatını araştırmakla başlar: bazı şirketler klasik algoritma ve veri yapısı sorularına (diziler, ağaçlar, graflar) odaklanırken, bazıları sistem tasarımına, eve götürülen (take-home) projelere veya gerçekçi kod üzerinde eşli programlamaya (pair programming) yönelir. Seni ne beklediğini öğren — Glassdoor gibi platformlardaki aday yorumları veya işe alım ekibine doğrudan soru sormak genelde formatı ortaya çıkarır. Teknik hazırlık için sadece bir hafta sonu değil, birkaç hafta ayır: rastgele çalışmak yerine günde 1-2 soruyu bir kategori içinde çöz (önce diziler, sonra string'ler, sonra ağaçlar). Bir o kadar önemlisi: ana aracının (dil, framework, veritabanı) temellerini tekrar et, çünkü mülakatçılar sıkça değiş tokuşlar (trade-off) hakkında soru sorar — örneğin 'neden dizi yerine hash map?' Çözümü bilip gerekçesini bilmeyen adaylar, kod doğru olsa bile açıklama yaparken kararsız görünür.
Canlı kodlama: düşünce sürecini sesli anlat
Güçlü ile zayıf bir canlı kodlama performansı arasındaki en büyük fark, nadiren kodun kendisidir — asıl fark süreç boyunca kurulan iletişimdir. Mülakatçılar zihnini okuyamaz: on dakika boyunca sessizce yazmak, sonuç doğru olsa bile çoğu değerlendirici için bir kara kutu gibi görünür. Bunun yerine net bir rutin oluştur: problemi kendi cümlelerinle tekrarla, netleştirici sorular sor (girdi boyutu nedir? tekrar eden değerler var mı? girdi sıralı mı?), kodlamaya başlamadan önce 1-2 olası yaklaşımı zaman ve alan karmaşıklığıyla birlikte sesli olarak özetle, ve kod yazarken ne yaptığını ve nedenini kısaca anlat. Bu yapı — netleştir, planla, uygula, test et — ilk çözümün optimal olmasa bile sistemli düşündüğünü gösterir. Sıkça göz ardı edilen bir adım: sonunda 1-2 test senaryosunu (boş girdi, tek eleman, negatif sayılar gibi bir uç durum dahil) aktif olarak gözden geçirmek.
Takıldığında: özgüvenle nasıl tepki verirsin
Neredeyse her teknik mülakatta çözüm yolunun hemen belli olmadığı bir an yaşanır — bu beklenen bir durumdur, alarm sinyali değil. Önemli olan buna nasıl tepki verdiğindir. Sessizliğe gömülme, takıldığın noktayı sesli ifade et: 'İç içe döngüyle ilk yaklaşımım O(n²) olurdu — bunu bir hash map ile O(n)'e indirip indiremeyeceğimi düşünüyorum.' Bu, mülakatçıya seni doğru yöne yönlendirme fırsatı verir; bu zaten birçok sürecin doğal bir parçasıdır. İpuçlarını bir başarısızlık gibi görmek yerine aktif olarak kullan: bir ipucunu alıp hızla ilerleyen adaylar öğrenme becerisini ve iş birliğini gösterir — özellikle takım rolleri için bu ikisi kilit kriterlerdir. Sistem tasarımı sorularında da benzer bir mantık geçerlidir: mimari çizmeden önce gereksinimler ve varsayımlarla başla (kullanıcı sayısı, okuma-yazma yükü) ve tek bir 'mükemmel' cevap aramak yerine değiş tokuşlar (tutarlılık ve erişilebilirlik dengesi, SQL ve NoSQL) hakkında sesli düşün.
Güçlü adayların bile yaptığı yaygın hatalar
En yaygın hata, problemi tam olarak anlamadan hemen kod yazmaya başlamaktır — bu genelde yarı yolda tüm yaklaşımı çöpe atmak zorunda kalmaya ve değerli zaman kaybına yol açar. Bir o kadar riskli olan diğer hata: uç durumları (boş listeler, null değerler, çok büyük girdiler) tamamen göz ardı etmek — mülakatçılar bunları sen kendin belirtmezsen aktif olarak sorar. Bir diğer klasik hata ise aşırı mükemmeliyetçiliktir: önce çalışan bir kaba kuvvet (brute-force) çözümü sunup sonra optimize etmek yerine, optimal çözümü uzun süre cilalamaya çalışmak — çalışan ama optimal olmayan bir çözüm, hiçbir çözüm olmamasından neredeyse her zaman daha iyidir. Ayrıca değiş tokuş sorularını gerekçesiz 'duruma göre değişir' gibi belirsiz cevaplarla geçiştirmekten kaçın — bunun yerine somut ol: 'küçük bir veri kümesinde X'i seçerdim, ama milyonlarca kayıtta Y'ye yönelirdim çünkü...'. Son olarak, kapanışı hafife alma: takıma sorulacak 2-3 düşünceli soru hazırla (teknoloji yığını, kod inceleme süreci, dağıtım sıklığı) — bu gerçek bir ilgiyi gösterir ve birçok işe alım sürecinde açıkça değerlendirilir.
Kısaca
Mülakatın spesifik formatına sistemli hazırlan, düşünce sürecini baştan sona sesli anlat, ipuçlarını bir geri adım değil fırsat olarak aktif kullan ve önce çalışan bir çözüm sun, sonra optimize et.