Yazılım Mülakat Rehberi
Mülakatlarda sizi neler bekliyor ve nasıl hazırlanmalısınız?
Sınavlar, mülakatlar, testler herkesin gözünde büyür. Bilinmezlik insanı geriyor. Bu bilinmezliği biraz gidermek için, mülakatlarda nelerle karşılaşacağınızı ve sorulara nasıl yaklaşmanız gerektiğini göstermek istiyorum.
Her firma farklı mülakat süreçlerine sahip. Fakat tüm durumlarda geçerli bazı genel hususlar ve dikkat edilmesi gereken noktalar var:
Disiplinli ve bilinçli bir hazırlık gerekiyor.
Bol bol mülakata girin, başarısız olsanız bile bir şeyler öğrenmiş ve tecrübe kazanmış olacaksınız.
Güvenilir ve birlikte çalışmanın keyif verdiği biri olduğunuzu gösterin. Buluşmaya geç kalmayın, dakik olun. Kibar olun.
Düz bir text editöründe veya beyaz tahtada algoritmik problem çözme pratiği yapın.
Sistem tasarlama ve nesne yönelimli tasarım gibi ucu açık konulara hazırlanın.
Teknik sorulara hazırlandığınız kadar, davranışsal sorulara da hazırlanın.
"Cracking the Coding Interview" kitabı güncelliğini koruyor, mutlaka okuyun ve içindeki örnekleri çözün.
İnsan Kaynakları
Çoğunlukla ilk görüşmeler İK'dan biri ile yapılır ve en fazla yarım saat sürer. Bu görüşmede yapmanız gerekenler:
Kendinizi tanıtın; kariyer ve tecrübelerinizden bahsedin.
Sizi neler bekliyor anlamaya çalışın. Sorabileceğiniz sorular:
çalışma şartları; ofiste mi olacaksınız remote mu, mesai saatleri, ofisin yeri vs.
ekip; kaç kişisiniz, nelerden sorumlusunuz
rolün detayları, sizden kabaca neler beklendiği
organizasyon şemasındaki yeriniz
şirketin hedefi ve vizyonu
Peki ya siz bu rolden neler bekliyorsunuz; anlatın. Hedeflerinizden bahsedin. Rol hedeflerinizle örtüşüyor mu anlamaya çalışın.
Maaş konusu gündeme gelecektir. Eğer piyasaya hakimseniz, maaş beklentinizi söylemekte bir sakınca yok. Piyasa şartlarını bilmiyorsanız, bir şey söylememeyi tercih edebilirsiniz. Kim bilir, belki de gelecek teklif kafanızdakinden daha iyidir.
İK görüşmesinde en önemli şey, beklentilerinizi netleştirmiş olmanızdır. Ne istediğinizi bilin, ve bunu karşı tarafa net biçimde iletin.
Teknik Mülakatlar
İşinize yarayacak bazı temel kurallar var, bunlara uyduğunuz sürece başarı şansınız artar.
Teknik görüşmelerde sürücü koltuğunda siz varsınız. Sorular sorarak belirsizlikleri ve açık uçlu konuları netleştirin.
Sesli düşünün ki karşı taraf problemleri nasıl çözdüğünüzü müşahede edebilsin. Yaptığınız varsayımları özellikle belirtin.
Mülakatı yapan kişinin yönlendirmelerine kulak verin, tavsiyelerini göz önünde bulundurun. Ufak tüyolar verip sizi sonuca yönlendirebilirler.
Aklınıza ilk gelen çözüme dalmayın. Alternatifleri sabır ve dikkatle değerlendirin. Çözüme gitmek için acele etmeyin.
30 dakikanız olduğunu varsayalım. Bunun ilk 5-10 dakikasını problemi net biçimde tanımlamaya, sonraki 5-10 dakikasını tasarlamaya ve kalan süreyi de çözümü yazmaya ve artılarını/eksilerini değerlendirmeye ayırın.
Teknik mülakatlar genelde üç kategoride yapılıyor:
Problem Solving (problem çözme)
Object Oriented Design (nesne yönelimli tasarım)
System Design (sistem tasarımı)
Bu görüşmeler genelde bir saat sürüyor. Bir saat içinde, soruların derinliğine de bağlı olarak bir veya iki soru çözmeniz gerekebilir. Unutmayın ki, bu kadar kısa süre ve kısıtlı şartlar altında (beyaz tahta veya bir text editör kullanacaksınız) sizden çok detaylı ve mükemmel bir çözüm beklenmiyor.
Karşı taraf aslında şunları öğrenmeye çalışıyor:
probleme yaklaşımınız
belirsizlikleri nasıl giderdiğiniz
tavsiyeleri, alternatifleri ve ipuçlarını nasıl değerlendirdiğiniz
iletişiminiz: bulduğunuz çözümü nasıl aktardığınız
farklı çözümlerin eksi ve artı yönlerini nasıl karşılaştırdığınız
Problem Çözme
Kolları sıvayıp kodlama yaptığınız aşama bu. Kısa bir tanımı olan, çözümü de öyle çok dallanıp budaklanmayan, ama kafanızı da çalıştırıp motoru biraz ısıtacak bir problem çözeceksiniz.
Eğer “leetcode” veya “hackerrank” tarzı platformlarda idmanlıysanız, bu aşamayı rahatça geçersiniz. Array, linked list, stack, queue, hash table, heap, trie, tree ve graph gibi veri yapılarına çalışın.
Çözüm ezberlemeyin. Çünkü sorularda ufak farklılıklar olacaktır, ezberlediğiniz şeye denk gelme ihtimaliniz yok denecek kadar az.
Genelde programlama dilinde serbestlik tanınır adaylara. Bu noktadan hareketle, en rahat olduğunuz programlama dilinin hangisi olduğuna karar verin ve çalışırken bu dili kullanın.
Yazdığınız kodda syntax hatası veya ufak tefek yazım hataları olabilir, bunlara bakmazlar. Önemli olan noktalar;
kurduğunuz algoritmada mantık hatası olmaması
istisnai durumları (edge case) nasıl idare ediyorsunuz
çözümünüzün performansını (big O notasyonu) doğru şekilde değerlendirebiliyor musunuz
Koda geçmeden önce basit bir iki örnek uydurup algoritma falan düşünmeden dümdüz çözmeye çalışın. Hangi hamleleri yapıyorsunuz, girdiyi nasıl kullanıyorsunuz bir düşünün. Yavaş yavaş kafanızda bir ışık yanmaya başlayacaktır. Bu noktada algoritmayı kod detayına inmeden kağıda dökmeye çalışın.
Aklınıza pratik bir çözüm hemen gelmeyebilir. Bu durumda brute-force bir çözüm sunup, bunun neden optimal olmadığını açıklayabilirsiniz. En azından elinizde bir çözüm olacak ve kendinize güveniniz gelecektir. Brute-force çözümü inceleyerek nerelerde optimizasyona gidilebilir diye kafa yorun.
Eğer aklınıza güzel bir çözüm gelmiyorsa pratik birkaç tavsiyem var:
bir liste ya da array varsa, elemanları "sort" edip soruya bir de öyle bakın
ya da elemanları bir hash table'a atıp, O(1)'lik hızdan faydalanarak lookup yapın
bazı problemler kendi cinsinden ifade edildiğinde basitçe çözülebiliyor, ihtiyacınız olan çözüm recursion olabilir
Object Oriented Design
OOP (object oriented programming) konusu mülakatlarda karşımıza sıkça çıkar. Verilen problemi mantıksal parçalara bölüp, o parçaları kodda temsil edecek classları (sınıf) oluşturduğunuzu görmek isterler.
Ara sıra design patterns soruları da gelebiliyor. Tecrübeli bir yazılımcıysanız bu konulara muhtemelen girmezler. Ama kariyerinizin başındaysanız bu konulara da hazırlıklı olun. Singleton, Proxy, Builder, Factory, Iterator, Visitor gibi patternların ne işe yaradığını öğrenin.
Probleme yine belirsizlikleri gidererek ve sorular sorup konuyu netleştirerek başlayın. Daha sonra problemdeki özneleri düşünün ve bunların her biri için bir class oluşturun. Örnek, eğer bir market yazılımı yapmanız istendiyse "Müşteri", "Kasa", "Kasiyer", "Ürün", "Reyon" gibi classlarınız olsun.
Nesnelerin birbirleri ile olan ilişkilerini belirleyin, mesela
Bir "Reyon" birden fazla "Ürün" içerir.
Nesnelerin inheritance (kalıtım) durumlarını gözden geçirin. "Kasiyer", "Müşteri"den türetilmiş olabilir; neticede her kasiyer aynı zamanda potansiyel bir de müşteridir.
Nesnelerinizin alabildiği aksiyonları düşünün ve ilgili metodları ekleyin. Örnek olarak, "Kasa" için bir "satış" metodu olabilir:
Kasa.satış(müşteri, List<Ürün> ürünler, ödeme)
Ne kadar detaya indiğinize dikkat edin. Sizden özellikle istenmedikçe, bir konuyu kafaya takıp onunla ilgili aşırı derinlere inmeyin. Mesela yukarıdaki Kasa.satış metodunun implementasyonuna kalkışıp kıymetli vaktinizi orada harcamayın. Graph theory dilinden konuşmak gerekirse; DFS değil, BFS mantığıyla gidin. Derine dalmadan önce, yatayda gidin.
Unutmadan, bana hep denk geliyor, ACID ve SOLID nedir ezberleyin. Bence gereksiz sorular, ama işte soruluyor. Şak diye yapıştırın cevabı.
System Design
En korkulan mülakat türü "sistem tasarımı". Korkmayın :)
Kimse sizden bir saat içinde youtube, facebook veya twitter ölçeğinde ve detayında bir platform tasarlamanızı istemeyecek. Mühendislik matematik değil. Bir problemin sadece bir cevabı yok. Farklı kalitelerde, ölçeklerde ve değişik varsayımlara sahip pek çok cevap üretilebilir.
İlk işiniz ne? Evet, ilk işiniz yine istenen şeyi anlamak, detaylarını netleştirmek. Bunu yaparken bazı varsayımlar yapmanız gerekebilir, bunları açıkça anlatın. Bolca soru sorarak sistemin ne için ve hangi şartlarda kullanılacağını, aktörlerin kimler olduğunu, aksiyonların neler olduğunu belirleyin.
Detaylara inmekte acele etmeyin, önce genel hatlarıyla düşünün kuracağınız sistemi. Sesli düşünerek karşı tarafı da sürece ortak edin, sizi izleyebilme fırsatı verin onlara.
Sistemi tasarlarken yaptığınız tercihleri belirtin ve avantajlarını/dezavantajlarını irdeleyin. Mesela rezervasyon sistemi tasarlarken distributed bir queue kullanacaksanız bunun nedenlerini sayın.
"Ölçeklenebilirlik => sharding". Eğer scalable bir çözüm sunmanız istenirse, çok büyük ihtimalle sharding nedir bilip bilmediğinizi öğrenmeye çalışıyorlardır.
Genel hatlarıyla bir çözüm elde ettiğinizde, artık çözümünüze eleştirel bir bakış getirip eksiklerini masaya yatırmaya başlayın. Sistemin kapasitesi üzerine konuşun; darboğazlar neler olabilir, hangi bileşenler problem çıkarmaya daha müsait anlatın.
Şu konuları tekrar etmenizde fayda var:
vertical vs. horizontal scaling
load balancer, gateway, websockets, CDN
authentication, authorization, security
SQL & NoSQL veritabanları ve partitioning vs. sharding
caching: hangi seviyelerde olur, avantajları ve dezavantajları nelerdir
asenkron işlemler ve bağlayıcı ara elemanlar (distributed queue, pub/sub, streams, object storage vs.)
network latency, bandwidth, throughput
CPU bound vs I/O bound işlemler
multiprocessing
CAP teoremi ve beraberinde gelen "trade-off" (availability, eventual consistency)
Davranışsal Sorular
Problem çözme seanslarında, aralara davranışsal sorular serpiştirip sizin nasıl bir çalışma arkadaşı olduğunuzu anlamaya çalışacaklar. Şöyle sorular gelebilir:
Sizi en heyecanlandıran projeniz neydi?
Sizi en çok zorlayan projeniz neydi, neden zorlandınız, zorlukları nasıl aştınız?
Teknik bir konuyu, teknik olmayan birine nasıl anlatırsınız?
Geribildirimde bulunurken nelere dikkat edersiniz?
İşleri nasıl önceliklendirirsiniz?
Çalışma arkadaşlarınızla ortaya çıkan anlaşmazlıkları nasıl çözersiniz?
Zaman baskısının olduğu ve geciken bir projede çalıştınız mı? Bu durumu nasıl yönettiniz?
Bu sorulara uydurma cevaplar vermeye çalışmayın. Uydurmasyon olduğunu anlamak çok da zor olmuyor. O riske girmeyin. Bunlara geçmiş tecrübelerinizden bazı cevaplar bulup mülakat öncesi tekrar etmenizde fayda var. Çünkü soru bir anda sorulunca mülakatın da stresiyle insan öylece kalabiliyor. Özellikle yakın zamandaki deneyimlerinizin üzerinden bu ve benzeri sorular ışığında bir geçin.
Kapanış Notları
"Cracking the Coding Interview" kitabını okuyup, soruları çözün
Bol bol mülakata girin, idmanlı olun
İş arayışında olmasanız bile, fırsatlar çıktıkça mülakatlara girip teklif almak özgüveninizi artırır ve sizi imposter sendromundan uzaklaştırır
Sorular sorun, problemleri netleştirmeden çözüm yollarına dalmayın
Soruların tek bir cevabı yok, mükemmel bir çözüm bulacağım derken elinizin boş kalmasındansa orta şeker bir çözüm sunabilmek ve bunun eksilerini/artılarını açıklamak daha iyi