Bu yazıyı yazma amacım fikirlerimi ve deneyimlerimi metodolojik olarak ifade etme isteğinden fazlası değil, doğrusu bu gibi bir önerme yapma niyetim yoktur. Bununla birlikte sık yapılan yanlışları belirtmek istiyorum.
Bu yazıyı yazmaya sosyal medyada gördüğüm bir paylaşımdan sonra karar verdim (maalesef linki bulamadım). Meâlen aktarıyorum, “en iyi mülakat sorusu tarayıcıya falanca bir websitesine yazıp enter’a bastığımızda ne oluyor diye sormak ve cevap ne kadar derine kadar iniyor diye bakmak”. Teknik bilgiyi sadece sözlü olarak ölçmek acaba yeterli olur mu? Veya her şirket için yeterli ve geçerli olabilir mi? Bence bazı pozisyonlar ve şirketler dışında yeterli olmayacaktır. Bu soruyu beğenmekle birlikte, sadece diyalogu ısıtma amaçlı yöneltmenin daha isabetli olacağını düşünmekteyim.
İş görüşmesi süreçlerinin birçok aşaması var, teknik seviyeyi ölçme hedefli görüşmeler bunlardan sadece biri. Hedefli dedim zira diğer süreçler gibi, teknik süreçlere hazırlanarak olduğundan daha iyi görünmek mümkündür. Fakat mülakatın yanıltıcı olabilme ihtimalinden çekinerek hiç mülakat yapmamak bir seçenek olmamalı. Dolayısıyla ne yapacağımızı ve nasıl yapacağımızı tartışalım ama mutlak bir teknik mülakat yapalım görüşündeyim. Referanslar, kariyer, önceki proje deneyimleri bana göre yalnızca kararı tamamlayıcı nitelikte olmalı. Elbette bunun için teknik mülakatın diğer unsurların tamamlayıcı öğe görülmesini sağlayacak şekilde yapılması gerekir.
Teknik mülakatlar geniş anlamda iki temel başlığa ayrılıyor, bunları Türkçeye çevirmeden yazmak gerekirse 1) Domain Specific Interview (DSI) 2) Computer Science Fundamental Interview (CSF). Yani ilki pozisyonuna özgü olarak yapılacak mülakat, ikincisi de deneyimden çoğunlukla bağımsız olarak yapılabilecek temel bilgi mülakatı. Bu başlıklara, önereceğim yöntemler içerisinde referans vereceğim. Şimdilik kenarda dursun.
Sınıflandırma Yöntemine Giderken
Önerilerime geçmeden önce, biraz süreçten bahsetmek istiyorum: Meslek yaşantımın son yıllarında masanın diğer tarafına geçme durumu söz konusu oldu. Ve gördüm ki, mülakatı yapan taraf olmak da belli hazırlıkları içermesi gereken ve başka örneklerden kopyalanamayacak kadar önemli bir süreç. Hatta daha köşeli ifade etmek gerekirse, kopyalanmaması gerek.
Her yazılım şirketinin ya da yazılımcı işe alacak her şirketin birbirinin benzeri mülakat içeriklerini izlemesi ve bunu da çok önemli iş yapıyor gibi düşünerek izlemesi en nihayetinde sektörün tümüne zarar veriyor. Neredeyse tüm pozisyonlar için elinde internetten alınmış 10-15 hazır soruyu sormak veya farklı seviyelerdeki yazılımcılara sadece aynı algoritma sorusunu sormak uygulanabilir bir yöntem değil. Bununla birlikte, son dönemde popüler olmuş birkaç başlıkla (genelde popüler bir architecture pattern) bir ödev istemek de bence işin kolayına kaçmak.
Bana göre mülakat süreçlerini şirketlere göre sınıflandırmak sonra da amaca daha uygun şekilde uygulanmasını sağlamak mümkündür. Gördüğüm kadarıyla mülakat yapma şekli bakımından şirketleri 3 ayrı kategoriye ayırabiliriz. Tekrar ediyorum, şirketleri üçe ayırmıyorum, mülakat yapma şekillerine göre üç ayrı şirket tipi olabileceğini söylemek istiyorum:
1) Proje şirketleri
2) Know-How birikimi olan şirketler
3) Teknoloji şirketleri
Her bir sınıflandırmanın detaylarını ilgili bölümde açıklayacağım.
1) Proje Şirketleri
Kuruluş amacı anahtar teslim (hisse veya ortaklık da olabilir) proje üretmek olan şirketler. Yazılım ajansı da diyebiliriz isterseniz. Bunun üzerine birkaç tespit yapmak gerekirse: Bu ve benzeri şirketler için, içeride hem proje hem de yazılımcı sirkülasyonu yüksek olur. Öte yandan sürekli yeni proje yapılsa da izlenmesi artık kaçınılmaz olan adımlar ortaya çıkmıştır. Yine işin niteliği açısından, birincil amaç işi teslim etmek veya jargonuna uygun söylersek ‘canlıya almak’ olduğunu söylemek mümkündür. Yani şirket içerisinde hız temelli baskı kaçınılmazdır.
Dolayısıyla bir proje şirketi mülakat yaparken öncelikle buna odaklanmalı diyebiliriz: Yazılımcı mevcut projeyi (veya projeleri) en kısa sürede devralmalı. Yeni projelerin başlangıç süreçlerinde hızlı çözüm üretmeli. Kendini sık tekrar edebilecek projelerde ölçülebilecek birinci kriter bence best-practice aşinalığı ve bunu uygulayabilme becerisidir. Dolayısıyla mülakatı da buna göre yapmak bence en uygun olanı.
Proje şirketinde mülakat süreçlerini belirleme olanağım olsa, tek aşaması teknik olan iki aşamalı bir mülakat kurgulardım: İlk aşamayı sadece tanışma, karşılıklı deneyimlerden konuşma ve beklentiler olarak tutardım. Elbette bu aşama için İK profesyoneli ile kurgulamak daha doğru olacaktır. Amacım ikinci aşamada harcanabilecek zamanı maliyetini göze alarak, ikinci aşamaya olabilecek en uygun yazılımcıları dahil etmek.
Geçiyorum ikinci aşamaya: Şirket içerisinde farklı zamanlarda ve ayrı projelerde çözülmüş bir problemi prototipleştirerek, yazılımcıya bunu ödev olarak iletir makul bir süre içerisinde yapmasını beklerdim. Farklı seviyelere aynı ödevi göndermemek için ise aynı yöntemle hareket edip farklı ödevler ortaya çıkartırdım. Gelen çözüme bağlı olarak, son kez yapılacak ve kapsamı ödev kadar olacak bir teknik görüşme de söz konusu olabilirdi. Bu adımı da yalnızca birkaç yazılımcıdan birini seçmek zorunluluğu olduğunda tercih ederdim. Bu ilk önerim.
İkinci önerim ise, proje devralacak ya da var olan bir projeye yeni yazılımcı olarak katılacaklar için biraz daha uygun. Bu süreci uygulamanın ilkinden daha zor ve zaman açısından maliyetli olduğunu biliyorum: Yayına hazır bir demo projeye eklenecek yeni bir modülün mevcut proje yapısına bağlı kalarak yapılması. Kapsamı farklı roller için detaylar azalır veya artar. Bu şekilde kod okuma alışkanlığı, tanımlı bir işin ne kadar detaylı düşünüldüğüne ve eğer gerekirse hangi adımlarda soru sorduğuna da bakabilmek mümkün olur.
Not: Önerilerimin içinde CSF (computer science fundamental) ölçümü sadece ödevin içeriğine bağlı olarak var. Bunun da kısıtlı bir ölçüm olacağının ve hatta bazen ölçemeyeceğinin farkındayım. Bu noktada okuyanların önerilerini dinlemek isterim.
Peki neden ayrı CSF için bir mülakat eklemedim? İlk sebebi tespitlerde söylediğim sirkülasyonun yüksek olmasıyla ilgili. Yani birkaç ayrı mülakat yaparak seçilen yazılımcının potansiyel olarak çok uzun süre çalışmayabileceği ihtimali. İkincisi ise bunu destekleyecek başka bir gözlem: Proje şirketlerine, çoğunlukla kariyerinin erken dönemlerinde olan yazılımcılar başvuruyor ve hatta bu başvuruları da ikincil tercih olarak görebiliyor. Yani hiç olmazsa bu olsun veya biraz burada çalışayım, ilk fırsatta diğer opsiyonları yeniden değerlendiririm düşüncesi baskın oluyor. Eğer burada bir teknoloji şirketi gibi mülakat yaparsanız (3. maddede daha net anlatacağım bu noktayı), şirketin adının ve mülakat tarzıyla birlikte kulaktan kulağa olumsuz bir şekilde yayılması mümkün. Bu kadar mülakatı bu işler için mi yaptık gibi bir olumsuzluktan söz ediyorum.
Bu başlık altında son söz: Eğer meramımı anlatmama rağmen, adımız çıkmasın diye temel bilgi ölçmeyelim mi diye sormak isterseniz, cevabım tekrar bu konuya dair başka önerileri, uygulamaları dinlemek ve öğrenmek istediğim olur.
2) Know-How Şirketleri
Kavram sadece benim zihnimde bir şeyler canlandırmış olabilir, o yüzden biraz açmak istiyorum: Sadece kendi projesini/ürününü yapan şirketleri kastetmiyorum, bununla birlikte bir alanda hazır teknolojileri kullanarak, bunun üzerine kendi çözümlerini üretmiş veya bu çözümleri geliştirmek üzerine çalışan şirketler odak noktam. Bu şirketlerin genelde B2B veya B2E işler yaptığını ürettiğini görürüz. Şirket ismi vermeden örnek vermek gerekirse, video player yapan şirketler, sosyal medya analiz aracı yapan şirketler gibi.
Benzeri şirketlerde çalışmış ve çalışan tanıdıkları olan bir yazılımcı olarak, mülakat sürecine geçmeden önce yine birkaç tespit yapmak istiyorum: Şirketten şirkete değişmekle birlikte, içeride İK diliyle departmanların ufaktan oluşma vakti gelmiştir. Artık olumlu ya da olumsuz kurulacak olan cümleler, tüm yazılımcılar için değil belli takımlara yönelik olarak kurulmaya başlamıştır. Bu tip şirketlerde, farklı dönemlerde dahil olan ve başlığını attığım know-how’ı bünyesinde tutan yazılımcı(lar) olur. Bu yazılımcılar, işten ayrılma zamanı geldiğinde sadece projeleri ve sahip olduğu yetkileri değil, bilgileri de aktarır. Dahil olacak yazılımcıdan da önce bu know-how’ı öğrenmesi ve beraberinde şirketin problem çözme şeklinin algılanması ve buna göre çalışması beklenir.
Geçiyorum önerime. Anlattığıma benzer bir şirkette yazılım mülakat sürecine dair karar alma imkanım olsa süreci iki ya da üç aşamalı olarak düşünürdüm. Süreç içerisinde mutlaka ilgili ekipten yazılımcıları kullanırdım. Yani yönetme sorumluluğu olmayan yazılımcıları kastediyorum. Yönetme sorumluluğu olanların zaten bu sürece dahli genelde kaçınılmaz oluyor. Neden dahil etmek istediğime gelirsek: Yazılımcının sadece teknik olarak değil, kültürel olarak da kabul görmesi ve ekibin kalanında rıza üretmesi gerekiyor. Cultural fit başlığı özelinde, bazı şirketler sadece bu işi yapan profesyonelleri tercih edebiliyor. Benim önerim, bu olsa dahi ekipteki yazılımcılarla tanıştırmak ve mülakat sürecine dahil etmek.
Teknik tarafta ise, şirket yapısı gereği, şirket içerisinde çözümü bulunmuş ve ticarileştirilmiş problemi, kısıtlı bir sürede yazılımcının çözmesini beklemek gerçekçi olmayacaktır. Burada tercih edilmesi mümkün olan seçenek çözümün başlangıç adımları olabilecek noktaları, biraz detaylı prototiplendirerek daha geniş bir zaman içerisinde çözülmesini beklemek olabilir. Dolayısıyla hem yazılımcıyı içeride karşılacağı olası problemlerle yüzleştirmek mümkün olacak. Hem de çözümün hazır örnek ve kod parçalarından ziyâde doküman üzerinden yapılacak okuma ve araştırmalarla mümkün olduğu durumlarda nasıl bir çözüm geldiğini görebileceğiz.
Bu tip mülakatı tercih eden şirketlerde genelde başvuran yazılımcıların bir kısmının farklı sebeplerle (sadece teknik değil) devam etmediğini gözlemek mümkündür. Dolayısıyla bu aşama bence ilk aşama olmamalı, ikinci aşama olmalı. Bu yüzden iki veya üç aşamalı mülakat olmalı demiştim. Bence ilk aşama yazılımcının önceki deneyimlerinden yola çıkarak, yani geçmiş deneyimleri üzerinden sözlü teknik mülakat yapmak. Yeri gelmişken söylemek isterim: Hazır soruları derleyip bunları yöneltmenin çoğunlukla yanlış olduğunu düşünüyorum.
Geliyorum bazen opsiyonel olabilecek üçüncü aşamaya. Gönderilen ödevden sonra olabilecek bu mülakatta, yazılımcının katılacağı ekibin üyelerinden ikisi ile ödev üzerinde bunu neden yaptın, şunu neden tercih etmedin, acaba şöyle olabilir miydi kapsamıyla sınırlı bir teknik görüşme yapılabilir. Bu aşama kararın az çok netleştiği, detaylara dair soru işaretlerini gidermek olarak görülebilir.
3) Teknoloji şirketleri
Zannediyorum ne olduğu en açık kategori burası :). Klasik tanımdan farklı bir şey söylemek gerekirse: 1. ve 2. kategori (özellikle 2. kategori) tarafından kullanılan ürünler üzerinde çalışan şirketleri bu kategoriye dahil ediyorum. Yazılımcılar açısından baktığımızda ise hayali kurulan, ilan ilan takip edilen şirketlerdir.
Bu kategoriye dair söyleyeceklerim daha kısa olacak. Başvuru sayısının çok olma kabulünden hareketle; belirli seviyenin üstündeki yazılımcılarla devam etmek amacıyla, önceden hazırlamış soruları ilk aşamalarda (belki de otomatik olarak) kullanabilecek bununla birlikte farklı zamanlarda hem DSI hem de CSF mülakatını uçtan uca yapması beklenecek yegâne şirketlerin bu şirketler olabileceğini düşünüyorum.
Diğer şirketlerin, bu kategorideki şirketlerden öğrenmesi gereken çok şey olduğu gerçek. Yazıyı getirmek istediğim yer de tam burası: Teknoloji şirketlerinin bir probleme yaklaşımlarını ve bu problemin çözümlerini bir ürün olarak alıp kullanabiliyor olmakla, mülakat süreçlerini alıp uygulayabiliyor olmak aynı şeyler değildir. X şirketinin yazılım mülakatını çok iyi yapıyor olması, herhangi bir şirketin de bunu uygulaması gerektiği anlamına gelmez. Tabii eğer o şirketin yazılımcıya sunacağı olanakları, karşılaşacağı ortamı (hem teknik hem de kültürel) siz de vermiyorsanız.
Bu önerilerin ardına son olarak şunu eklemek istiyorum: Şirketlerin büyük çoğunluğu olumsuz sonuçlanan süreçlerde yazılımcıya dönüş yapmamayı tercih ediyor. Hatta buna tercih diyerek ben biraz yumuşattım, aslında zamanını size, şirkete ve verilen ödeve ayırmış bir insana dönüş yapmak zorunluluktur. Söz konusu cevap teşekkür ve başarı içeren birkaç cümleden ibaret diye düşünüyorum.
Sonraki yazıda bu başlıklardan çok uzaklaşmayarak, yazılımcılar için hazırlanan iş ilanlarına dair eleştiri ve önerilerimi yazmak istiyorum. Buraya kadar okuyanlara teşekkür ediyorum, bu yazıya benzer şekilde, iş deneyimlerimden deneyimlerden hareketle yazdığım başka bir yazıyı önermek isterim.
