Teknoloji şirketlerinin ihtiyaç duydukları yazılım pozisyonlarını en doğru şekilde doldurmaları, hem yazılımcılar hem de şirketlerin verimliliği ve ekip-içi motivasyonları açısından giderek artan bir öneme sahip.

Bu yazımızda, bir yazılım pozisyonu için mülakat yaparken karşılıklı başarıyı artırabilmek için nerelere dikkat etmek gerektiğini irdeleyeceğiz.

Günümüzde çoğu yazılım şirketinin bir yazılımcı adayını değerlendirirken kullandığı yaklaşım şu;

1. Bir ödev/challenge/proje/görev hazırla,
2. Adaya gönder,
3. Gelen sonucu incele ve aday hakkında işe alınabilir ya da alınamaz kararını ver.

Böyle bir metod işletince şunları kaçırıyoruz:

• Aday verilen görevi tam olarak ne kadar sürede tamamladı?
• Görev hangi yöntemlerle, nasıl aşamalardan geçerek çözüldü?

Öyleyse biz, sürecin kendisine odaklanmak yerine, eldeki sonucu tek değerlendirme kriteri kabul etmenin ne kadar yanlış bir yöntem olduğundan bahsedeceğiz!

"Sürece odaklanmayıp sadece sonuçla ilgilenme" yaklaşımı yerine tartışılagelen birkaç metod ve teknik var, onları inceleyelim:

Unutmayın! Bu konuda önerdiğimiz yöntemler, uygulanacak şirketin yapısına, kültürüne ve diğer pek çok pratik özelliğe göre dönüşüm geçirmeli ve belli ölçüde özelleşmelidir. O nedenle, bu yaklaşımları uçlarını açık bırakıyoruz.

# Hedef

Bir yazılım mülakatı için onlarca yöntem olmasına rağmen çoğunlukla aynı amaçlar etrafında toplanıyoruz:

• Aday ekibe dahil olduğunda, sorunsuz ve yüksek kalitede yazılımlar üretebilecek mi?
• Birlikte çalışacağı diğer yazılımcılarla ve diğer ekip arkadaşlarıyla üretilen yazılımı ve problemleri tartışabilecek mi? Aynı dili konuşabilecek mi? Kültür olarak yakın mı?
• Ekibin çalışmaktan keyif alacağı biri mi, uyumlu biri mi?

Demek ki, en önemli nokta; verilen görev üstünde çalışan adayın nasıl ilerlediğini iyi gözlemlemek, yani; "takip edebilmek".

Mülakat bittiğinde "Aday X görevini Y sürede tamamladı" çıkarımından daha öteye gidip, bütünleştirici bir bakış açısına sahip olabilmeli ve aşağıdaki sorulara cevap verebilmeliyiz:

# Hmmm, aday yaptığı çalışmaya ne kadar hakim?

• Aday verilen görevi çözerken doğru sonuç almasını sağlayacak bir karar verdiğinde, bu kararı vermesinin altında mantıklı bir açıklama var mı yoksa tamamen şans mı?
• Verilen görevi çözmek için deneyeceği yöntemi mülakatı yapanın anlayabileceği bir şekilde tartışabiliyor/anlatabiliyor mu?
• Görev için ürettiği yazılıma/çözüme ne kadar hakim, gerektiğinde kolayca değişiklik yapabiliyor mu yoksa kodun içinde mi kayboluyor?

# Oops! Adayın çalışmasında hatalar var! Ne güzel 😃

Her yazılımcı hata yapar. Peki bu hata;

• Kolayca yapılmış bir hata mı yoksa hepimizin bu görevi tamamlarken yapabileceği olası bir hata mı?
• Adayın görevi üstün körü ele almasından mı kaynaklanıyor yoksa probleme yabancı olmasından mı?
• Aday yaptığı hatayı ne hızda toparlayabiliyor/düzeltebiliyor?

Adayın işe uygun olup olmadığı kararına ancak, bu soruları tam karşılayacak cevaplar verebildiğimizde varabiliyoruz.

# Taktiksel Hedef

Bu konu biraz "detaylar" ile ilgili (örn: Android için hangi layout tipini kullanıyor?) olduğundan mülakatı tasarlarken yardımcı olabilecek bazı olguları inceleyelim:

# Gerçekçilik

Asıl test etmek istediğimiz şey; aday ekibe dahil olduğunda içinde bulunacağı ortamda karşılacağı durumların üstesinden gelme/uygulaması gereken şeyleri gerçekleyebilme kabiliyeti olmalıdır. Mülakatta verilen görevinin zorlayıcılığı günlük çalışma hayatı içinde karşılacağı zorluklarla eş olmalıdır.

Hiçbirimiz günlük işi içerisinde beyaz tahtaya kod yazıp sonrasında refactor etmiyor ya da X API'sinin Y metodunu ezberden yazıp kullanmıyor. O nedenle, bu tarz isteklerin bulunduğu mülakat yöntemlerinden uzak durmak iyi olur.

Mülakat çerçevesi içinde, adayın kendi yazdığı kodu yeni bir amaç için kullanmak üzere refactor edebilmesini ya da hali hazırda bulunan bir kodu debug ederek gördüğü hataları düzeltebilmesini ölçümlemek güncel olarak kullanılan "bize şunu yapan bir uygulama yaz" mülakatlarından daha fazla verim sağlayacaktır.

*"Zorlayıcı olan her şey gerçekçi değildir"

Aynı zamanda unutulmaması gereken; "zorlayıcı olan her şey gerçekçi değildir". Gerçekçi bir mülakat yöntemi; adayın görevi gerçekleştirmeye çalışırken çok ince detaylarda boğulmamasını sağlamak ve gereksiz detaylar için çözüm beklememektir.

# Açıklayıcılık

Evet, adaya verilen görev zorlayıcı olmalı ve yetkinlik seviyesini açığa çıkarmalıdır. Ama geri kalan her nokta belirli ve açıklayıcı olmalı, adayın görevde başarılı olmasını sağlayacak her şey hazırlanmış olmalıdır.

Yazılımcı adayı kesinlikle "bu mülakatta ne amaçlanmış, neyi tamamlamam bekleniyor?" belirsizliğine düşmemeli, yapılması istenilen her şey detaylıca ve anlaşılabilir bir şekilde belirtilmiş olmalıdır.

*Her şirket çalışma ortamının iyi olduğunu iddia eder. Mülakatı yapan kişi iyi bir çalışma ortamı algısının aslında mülakat anından başladığını bilmelidir.

Adayın mülakat esnasında verilen görev için yapabileceğinin en iyisini yapmasını beklemek doğru olur. Eğer bir adayı geri çevireceksek, verilen bütün eforlara rağmen bu görevi tamamlayamadığından tamamen emin olmalıyız. Bu sürecin olumsuz sonuçlanmasının sebebi verilen görevin belirsizliği miydi, adayın yetersizliği miydi, yoksa mülakatı yapanın başarısızlığı mıydı gibi belirsizliklere düşmememiz gerekir. Öyle ise mülakat ortamı ve koşulları da çalışma ortamı gibi iyi ve destekleyici olmalıdır.

Değerlendirdiğimiz her adayın iyi bir mülakat tecrübesi geçirmesini sağlamak zorundayız. Çünkü bizim bir adayı değerlendirdiğimiz kadar aday da bizi değerlendiriyor. Gelecekteki iyi uyum ve yüksek verim için taraflar birbirini tartıyor!

# Zamanlama

Yazılımcı adayına verilen görevi boyunca ayrılabilecek zaman, gerek kod yazarken olsun, gerekse görevin içeriğini tartışırken yeterli seviyede tutulmalıdır.

Aday mülakat esnasında verilen görev üstünde uğraşırken, mülakatı gerçekleştiren kişi yönlendirme amaçlı müdahalelerde bulunabilir fakat verilen görev eksik aktarılmamalı ve bunu toparlamaya bağlı zaman kayıpları önlenip adaya zaman kazandırılmalıdır.

# Kısıtlamalar

Genel ve taktiksel hedeften bahsettikten sonra biraz da mülakat sırasında oluşabilecek kısıtlamalar ve amaçlanmaması gereken durumlardan bahsedelim:

# Şans faktörü

Bir mülakat sırasında rastgele oluşabilecek durumlar her zaman yaşanır, bunların daha kontrollü yaşanmasını sağlamak mümkündür.

Diyelim ki bir yazılımcı adayına mülakat sırasında bir görev verdik ve aday görevi hiç zorlanmadan hızlı bir şekilde çözdü. Bunun birkaç sebebi olabilir:

• Aday programlama tecrübesini verilen görevi çözebilmek için kullandı ve hızlı bir şekilde çözüme ulaştı.
• Aday bu görevin aynısıyla veya çok benzeriyle daha öncesinde karşılaşmıştı ve bu tecrübeyi kullanarak hızlı bir şekilde çözüme ulaştı.
• Aday buna benzer bir görev içeriğiyle daha önce karşılaşmamasına rağmen görevin kapsadığı alanda (dynamic programming, OOP vs.) ilgiye sahipti, bu birikimle hızlı bir şekilde çözüme ulaştı.

Yukarıda bahsettiğimiz durumlardan hangisi üzerinden adayın görevi tamamladığını ayrıştırmak oldukça zor. Fakat bu rastgeleliği azaltmanın yöntemleri mevcut:

• Geliştirilen görevin çözümü için birden fazla yaklaşım olabilir.
• "Verdiğimiz görev için spesifik bir algoritmayı (örn. travelling salesman) nasıl kodlamış?" sorusundan ziyade "Aday genel olarak iyi kod yazıyor, yazdığı kodu tartışabiliyor, analiz edebiliyor ve refactor edebiliyor mu?" üzerine düşülebilir.

# Zaman kısıtlaması

Yazılım mülakatları genellikle 40 dakika ila 1 saat arasında değişir. Bu zaman kısıtlaması hem aday için hem de mülakatı yapan için sıkıntılı durumlar oluşturabilir. Adaylar verilen süre biraz daha uzun olsaydı daha verimli bir sonuç çıkarabileceklerini savunurken, mülakatı hazırlayanlar da verilen bu kısıtlı sürede neyi tam olarak ölçeceklerini belirlemede problem yaşayabilir.

Tabii ki ideal bir yazılım mülakatı daha uzun soluklu olmalıdır fakat işi pratiğe döktüğümüzde aşağıdaki durumlarla karşılaşıyoruz:

• Adayın hali hazırda tam zamanlı bir işi olabilir ve tam bir gününü mülakata ayırması zor ayarlanabilir bir durum olabilir.
• Aday birden fazla şirket ile mülakat sürecinde olabilir.
• Mülakatı hazırlayanların tam zamanlı bir işi olduğundan bu iş için fazladan zaman ayırmalarını istemek zor bir durum yaratabilir.

Bu problemlerin önüne geçmek için birkaç şey denenebilir:

• Mülakat için verilen görev adaya bir ev ödevi gibi verilebilir. Ama yine aday ve mülakatı yapan için aynı zaman kısıtlamaları olacaktır.
• Daha önce çalıştığımız yerlerden tanıdığımız kişileri işe almayı deneyebiliriz. Ama bu da çok kısıtlı sayıda adaya tekabül edecektir.
• Adayın açık kaynaklı paylaştığı kodlar üstünden incelemeler yapılabilir. Ama her aday açık kaynak kod yazma konusunda ılımlı olmayabilir veya belki de zaman ayıramamıştır.

Sonuç olarak adayı ideal olarak net bir şekilde değerlendirmemizi sağlayacak bir yol yok. Ayrılabilen zaman kısıtlı, o nedenle bu zamanı aday hakkında en fazla şeyi öğrenebileceğimiz şekilde harcamlıyız.

# Amaçlanmaması gerekenler

# Spesifik bir algoritmanın yazılması

Adaylara mülakat için verilan çoğu görev algoritmik bir çözüme yönelik olsa da mülakatı yapanın amacı hiçbir zaman adayı görevi bitirmeye ve problemi çözmeye yöneltmek olmamalıdır.

Yazılım mülakatı bir çark gibidir, amaç bir yere ulaşmak değil adayı gözlemleyip analiz edebilmek için sürekli çalışır durumda tutmaktır. Genellikle şans faktöründen ötürü adayın mülakatı ne kadar sürede tamamlandığının adayın ne kadar başarılı olduğu üzerinde çok fazla etkisi yoktur.

# Aday üstünde baskı yaratmak

Sadece yazılım mülakatlarında yaşanmayan bu baskı kurma yaklaşımının ne kadar doğru olduğu tartışılır.

Adayın ne yapması gerektiğinde belirsiz kalmak, görev üstünde çalışırken gereksiz yere adayı bölmek ve genel olarak mülakat esnasında adaya karşı cephe alan bir duruş sergilemek uygulanmaması gereken yöntemler diyebiliriz.

Mevcutta istenilen gerekliliklerde "baskı altında doğru kararlar alabiliyor olması" gibi bir "garip düşünce" var. İyi, uyumu ve verimi yüksek bir ekibi sürdürmek ve büyükmek istiyorsak "baskı" bizim için belirleyici yöntem olmamalı. Ya da siz iş ortamınızın yüksek stres içerdiğini düşünüyorsanız, mülakatları da öyle yapabilirsiniz. Ne kadar işe yarar, bilemiyoruz!

# Detaylarda kaybolmak

Yazılım mülakatı esnasında fazla detaya inmemek gerekir. Çünkü mülakat ortamının, genellikle 60 dakika içinde tamamlanması gereken bir görevin olduğu, adayın normal iş hayatında kullandığı araçların bulunmadığı ve aşina olmadığı (belki de ilk kez gördüğü) problemlerin verildiği bir ortam olduğunu unutmamak gerekir.

Bu nedenle aşağıda belirtilen küçük detayları görmezden gelebiliriz:

• Noktalı virgülün unutulması
• camelCase ile snake_case gibi kullanımların karıştırılması
• Anlam taşımayan variable isimlendirmeleri
• Bir metotun hata fırlatma durumunu unutmak

Yazılım mülakatında çok da takılmamamız gerekirken, günlük iş hayatında bu tarz detaylar çok önemlidir. Sağlıklı ve uzun ömürlü bir codebase oturtabilmek adına hepsinin belirli prensiplere oturtulmuş şekilde uygulanmasını beklemek gerekir.

Bu kısmı burada sonlandırıyoruz, bir nefes alalım çok uzun oldu. Bir sonraki yazıda inceleyeceğimiz başlıklar;

• Mülakat öncesi
• Mülakata başlarken
• Mülakat sırasında
• Mülakat sonrasında

süreçleri olacak.