Yazılım Mülakatı Nasıl Hazırlanmaz?
Yaklaşık on yıla yaklaşan profesyonel kariyerimde, genellikle yazılım teknolojileri ile çalışan bir geliştirici olarak pek çok kez iş değiştirdim ve pek çok işe alım sürecine dahil oldum. Bu makalede sizlere, yaptığım gözlemlerden öğrendiklerimle birlikte, işe alım sürecinin insan kaynakları tarafında hiç dokunmadan, doğrudan teknik mülakat sürecini eleştirecek ve yanlış uygulamaları ortaya koyacağım.
Teknik mülakat eleştirime başlamadan, hangi sebeplerle “insan kaynakları” tarafıyla alakalı bu yazıda bir eleştiride bulunmayacağımı açıklamak istiyorum. Bunun bir kaç sebebi var;
(a) Bu konuda yazılmış pek çok eleştiri mevcutken, aynı şeyleri söyleyen bir başka yazı yazmak istemiyorum.
(b) İşe alım uzmanları ve yazılımcıların doğaları gereği birbirlerinden kopuk olabildiklerini, bir yazılımcının işe alım uzmanını ya da bir işe alım uzmanının bir yazılımcıyı eleştirirken gerçeklikten kolaylıkla kopabildiklerini düşünüyorum. Bu nedenle ben eleştirilerimi doğrudan yazılımcılar tarafından yazılımcıların yeterliliklerini ölçmek üzere hazırlanan teknik mülakatlara yapacağım.
Eleştirilerime açıklık getirirken, pek çok pratik sebepten ötürü bunları farklı başlıklar altında toplamayı uygun gördüm. Bununla birlikte, sıkı bir Yanlışlanabilirlik yanlısı olduğum için, neyin doğru olduğuna odaklanmadan, doğrudan doğruya yanlışlara yönelmek amacını güdüyorum. Makalenin başlığının ve içeriğinin bu doğrultuda olmasının sebebi de bununla alakalıdır.
Artık, sıkça yapılan -ancak nadiren fark edilen- ve ne yazık ki teknik mülakatların standardı haline gelmiş yanlışları irdelemeye geçebilirim.
Top-Class Developer Arayışı Hatası
Teknik mülakatlarla birlikte bizler, mülakata katılan adayın alanında ne kadar bilgi sahibi olduğunu anlamaya çalışıyoruz. Tabii olarak mülakatı yapan taraf -ki bu taraf genellikle bir ticari organizasyonu temsil eder- bulabildiği en bilgili adayla birlikte -ki bu adayı top-class developer olarak adlandırabiliriz- çalışmak isteyecektir. Adayın alanında yeterince bilgi sahibi olmadığı her konunun hem aday hem de mülakatı yapan taraf için dezavantaj oluşturacağı aşikardır.
Ancak bu top-class developer arayışı hatalı bir yaklaşımdır. Öncelikle, mülakatı yapan taraf da tıpkı aday gibi top-class company değilse, top-class developer’ın söz konusu mülakatta bulunma olasılığı düşük olacaktır. Hayatın doğal akışı gereği, top-class developerlar, top-class şirketlerde çalışacaklardır. Dolayısıyla teknik mülakatı hazırlayan tarafın bu durumu iyi tespit etmesi gerekecektir. Alanında çok iyi bir adayın, daha düşük profilli bir şirket için çok iyi bir kazanım olacağını kabul etmekle birlikte, iki tarafın anlaşmasının olasılığının düşük olduğunu düşünüyorum.
Tüm bunlara ek olarak, her teknik mülakatın amacı takım içerisindeki bir pozisyonu doldurmaktır ve her pozisyondan beklentiler büyük oranda bellidir. Biz ise teknik mülakatlarda, pozisyon beklentilerini göz önünde bulundurmadan, adayın seviyesini belirlemeye çalışıyoruz. Ben teknik mülakatlarda ilgili pozisyonda en iyi verimle çalışabilecek adayı bulmanın, en iyi developerı bulmaya çalışmaktan daha önemli olduğu kanısındayım. Aşağıdaki grafikte göstermeye çalıştığım gibi, en iyi developerın bulunması, onunla anlaşılabileceği anlamına gelmeyecektir.
Tüm bu sebepler dolayısıyla, bir teknik mülakatta aslında hiç kullanmadığınız ve kullanma ihtimalinizin zayıf olduğu teknoloji, araç ya da alanlarda, ilgili adayın yeteneklerini ölçmek, hem mülakatı yapan hem de mülakatta sınanan aday için kaynak israfı olacaktır.
Algoritma Sorularıyla Sınama Hatası
Bu başlık ile ifade etmek istediğim; teknik mülakatlarda kolaydan başlamak üzere zorluğu giderek artan algoritma sorularıyla adayın seviyesinin tespit edilmesinin yanlışlığıdır. Bu yöntemin genel olarak sektörde kabul görmüş bir yöntem olduğunu, hatta bu yöntemi savunan argümanların da haklılık payı olduğunu kabul ediyorum. Ancak algoritma sorularıyla sınama, her ne kadar çeşitli zorluklar neticesinde ortaya atılmış kullanışlı bir yöntem olsa da, zaman içerisinde etkinliklerini kaybetmiştir. Ben bu yöntemin artık mevcut sorunları çözemediğini ve hatta oldukça yanlış bir sınama yapmaya başladığını savunuyorum.
Bu yöntem, hızlı bir şekilde pek çok adayı sınamak için ortaya çıkmış bir yöntem ve bu yöntemle birlikte hem sınama hem de değerlendirme süreci hızlı bir şekilde gerçekleştirilebiliyor. Bu hız faktörünün günümüzde bir avantaj değil, dezavantaj olduğunu düşünüyorum. Bugün geldiğimiz noktada, hemen hemen tüm teknik mülakatlarda karşılaşabileceğiniz sorulara ulaşmanız mümkün. Çok hızlı bir şekilde çözülebildikleri için, bir adayın belirli bir zaman içerisinde bu sorulara çalışarak -gerekirse her birini ezberleyerek-, tüm algoritma sorularını yüksek bir başarı oranıyla çözmesi de mümkün. Böyle bir yöntemin uygulanabilir oluşu, bu sınama türünde sınanmaya çalışılan algoritma çözme becerisi en yüksek adayın seçilmesini saf dışı bırakarak, algoritma sorularını en çok çözmüş ve bu işe en çok zamanı ayırmış adayın seçilmesine imkan tanıyor.
HackerRank gibi algoritma çözme pratiği sağlayan sitelerin sayısının ve kullanım oranlarının günden güne artmasını da, burada iddia ettiğim duruma kanıt olarak öne süreceğim. Her geçen gün teknik mülakatlara -bu sınama yöntemi özelinde- hazırlanma süresinin artması, teknik mülakatların nasıl kazanılacağının yolunu gösteren kitapların varlığı gibi çeşitli göstergeler, bize bu sınamanın artık çok farklı bir özelliği sınamaya başladığını gösteriyor.
Ancak bizim yaptığımız iş sadece belirli bir zaman içerisinde daha önceden çözdüğümüz bir problemi en hızlı bir şekilde çözmek midir? Yoksa ilk defa karşılaştığımız bir probleme de çözüm getirebilmek midir? Şüphesiz her iki yöntemin günlük pratiklerde uygulanabilir tarafları olsa da, ben yaptığımız işin ikincisine daha yakın olduğunu savunuyorum ve algoritma sorularıyla sınama yönteminin ikinci tanımda adı geçen yetenekleri sınamakta başarısız olacağını iddia ediyorum.
Yine de tüm bu savlarımdan algoritma testlerinin tamamen yararsız olacağı ya da developerın kalitesini ölçmek için kullanışsız bir araç olacağı sonucu çıkarılmaması gerekir. Algoritma sorularıyla sınamalar gerçekleştirirken, problemle ilk defa karşılaşılıyor olmanın muazzam bir değeri olduğunu düşünüyorum. Benim ileri sürdüğüm sav; adayın algoritma sınamalarına yaptığı hazırlıkların oranıyla, algoritma ile sınamanın verimliliği arasında ters bir ilişki olduğudur.
Belirsiz Sınama Hatası
Olimpiyat komitesinin sporcuları bir olimpiyat stadında toplayarak “Haydi altın madalya kazanın!” dediğini, ancak sporculara hangi branşlarda ve hangi kurallarla yarışılacağının söylenmediğini hayal edelim. Bu metafor bize Belirsiz Sınama Hatası’nın ne olduğuyla alakalı güzel ipuçları veriyor.
Bu hatanın teknik mülakatlarda sıkça yapıldığı kanısındayım. Her ne kadar teknik mülakatlar için bir doküman hazırlansa ve bu doküman içerisinde adaydan talep edilen kabul kriterleri açıklansa da, teknik mülakat açıklamaları sıkı bir kurallar silsilesi olmaktan çok uzak. Açıkçası, bir teknik mülakatın dokümanının sıkı bir kurallar bütünü olmamasında bir sorun görmüyorum. Çünkü bu şekilde bir davranış, adaya mülakat anında özgürlük tanır ve adayın kendi tercihlerini gösterme fırsatını sağlar. Benim burada sorun olarak gördüğüm daha çok adayın tercihlerinin bir sınama aracı olarak kullanılmasıdır.
Basit bir teknik mülakat düşünelim; bir adaydan bir buton tasarımı yapmasını istiyoruz ve React kullanması konusunda bir şartımız olduğunu belirtmişiz. Bunun yanında, kırmızı renkte bir buton istediğimizi belirttiğimizi de varsayalım. Aday, bizim şart koştuğumuz gibi React kullanarak kırmızı renkte bir buton tasarladığında, ortaya çıkan sonucu görerek neden butonun renginin parametrik olarak ayarlanamadığını sorgulamak belirsiz sınama hatasıdır.
Bu tarz bir sınama ile neyi ölçmeye çalışıyoruz? Eğer adayın telepatik yeteneklerini ölçmek isteniyorsa karşı çıkmayacağım. Bu tarzda bir sınav pekala adayın telepatik yeteneklerini ölçmeye yarayabilir, çünkü söylemediğimiz bir şeyi anlamasını bekliyoruz. Yok eğer, ölçmeye çalıştığımız şey; adaya bir iş verildiğinde ilgili adayın sadece o anı değil, uzun vadeli düşünüp düşünemediğini ölçmekse, benim bu ölçüm yöntemine ciddi itirazlarım olacak.
Öncelikle; yapılacak her iş için mükemmelliğe ulaşmak harcanan zamanla doğru orantılıdır. Butonun renginin parametrik olarak geliştirilmesi için gereken geliştirme zaman, belki o takım ve o an için görmezden gelinebilir bir zamanı ifade ediyor olabilir. Bununla birlikte, butona bir “loading” davranışı kazandırmak da pekala güzel bir özellik olabilmesine rağmen, parametrik renk seçiminden daha fazla zaman gerektirecektir. Bu durumda, belirli bir takım için, belirli bir anda parametrik renk için gereken geliştirme zamanı “makul” olarak görülebilirken, “loading” özelliği için gereken zaman, “zaman kaybı” olarak nitelendirilebilir. Burada sınır nereye konulmalıdır?
Ant Design kütüphanesindeki <Button> komponentinin tam 13 tane parametresi var. Bir komponent tam olarak ne zaman yeterli mükemmelliğe ulaşabilir?
Basit bir buton, üzerinde harcanacak zamanla doğru orantılı olarak mükemmele yakınlaşacak ancak asla mükemmel olmayacaktır. Burada, aklı başında olan takımlar çeşitli parametrelere göre “makul bir mükemmeliyet” belirler ve takım bu seviyeyi -her ne kadar yazılı bir kural olmasa bile- bilir ve bu durum göz önünde tutularak geliştirme yapılır. Bu seviye seçimine göre de Apple ya da Xiaomi olabilirsiniz. Günün sonunda her iki şirket de gelir elde edebilir. Bu sadece ve sadece bir üslup farkından ibarettir. Fakat bizler kendi üslubumuzun en doğru üslup olduğuna yürekten inanıyoruz ve piyasada bulunan on binlerce takımın farklı farklı üslupları ve ihtiyaçlarını olduğunu unutuyoruz.
Tekrardan, yarıda bıraktığımız teknik mülakat safhasına dönelim. Biz eğer adayın kendi hayatındaki kalite tercihini görmek istiyorsak bu tarz bir sınama yararlı olacaktır. Ancak, adayın özgür bırakıldığında tercih ettiği kalite seviyesi sabit ve değişmez bir seviye değildir ve bu seviye, aday, sadece ve sadece yalnız çalışırken gözlemlenebilir. Benim de itirazımı temel sebeplerden birisi budur.
Her developer, içerisinde bulunduğu takıma ve o takımın kültürüne göre geliştirme kalite seviyesini arttırır ya da azaltır. Hayatın doğal akışına uygun olarak, insanlar beraber yürüdükleri anda, ortak hızı yakalar. Hızlı olan bir miktar yavaşlayabilir, yavaş olan bir miktar hızlanabilir ve sonuç olarak bir grup yürüyüşü meydana gelir. Her aday, birlikte çalıştığı her takımda, takımın kültüründen etkilenir.
Adayın mükemmeliyet seviyesi tercihini görmek için bu tarz bir sınama gerçekleştirmek yerine, doğrudan adayla diyalog kurmak hem daha basittir hem de aynı amacı gerçekleştirecektir. Ben, eğer takımın talebi daha yüksek kaliteyse ve aday beklenildiği -ve doğal olarak beklentilerin açıkça ifade edildiği- anda bu talebi karşılayacak geliştirmeyi yapabiliyorsa, bu adayın takım için uygun olduğunu ve bu tarz bir sınamayla aday elemenin fevkalade yanlış olduğu kanısındayım. Bu tarz sınamalarda tıpkı bir bulmaca gibi, adaydan takımın kalite tercihlerini -bir şekilde- tahmin etmesini bekliyor, eğer aday doğru tercihi yaparsa onunla çalışıyor, yapamazsa belki de takım için değerli olabilecek bir adayı eliyoruz.
Ek olarak; mülakatı yapan tarafın açıkça belirtmediği durumlarda bile, her zaman için her mülakatın bir zaman kıstası vardır. Mükemmel yapılmış ama zaman kıstasını tutturamamış bir teknik mülakat çalışması istenilen etkiyi yapamayacaktır. Bu sadece teknik mülakatlar için değil, aynı zamanda takımların pazara çıkış sürelerinde de geçerlidir. Mükemmel ama bir türlü pazara çıkamayan bir ürünün çok değerli olduğunu iddia etmenin doğru olmadığını düşünüyorum. Bu nedenle takımlar genellikle her işin kabul kriterlerini belirleyerek öngörülen zaman içerisinde ürünü tamamlamayı hedefler. Kabul kriterleri belirlenen zaman içerisinde tamamlandığı takdirde kalitenin arttırılmasında da hiçbir sakınca olmayacaktır. Eğer teknik mülakatta yazılı olarak talep edilenlerin kabul kriterleri olduğunu kavrayabilirsek, kabul kriterlerini karşılayan ama -özellikle zaman kıstası nedeniyle- kalitesi üst seviyelere çıkarılamamış çalışmalar için adayı eleme yöntemine gitmek takım için doğru adayı bulma amacından ayrıldığını gösterecektir. Teknik mülakat direktiflerinde açık bir şekilde kabul kriterlerinin tanımlandığından emin miyiz?
Yukarıda da belirttiğim üzere, sınamalar ile tam olarak neyi ölçmeyi hedeflediğimizi netleştirmemiz gerekiyor. Amacımız ekibe katılacak kişinin kendisinden beklenen görevleri yerine getirilebilmesi ve takıma uyum sağlayabilmesi ise; sınamanın ekip kültürü ve günlük iş yapış rutini ile birlikte düşünülmesi gerekiyor. Eğer geliştirme safhalarında bir code-review süreci varsa, ve adayın yapması gereken ama gözden kaçırdığı ya da yapmaması gerekip yaptığı herhangi bir şey code-review sürecinde tespit edilip yeniden düzenlenebiliyorsa, sınamanın değerlendirme aşaması da bir code-review temsilinden ibaret olduğundan, buradaki sorunun tam olarak ne olduğunu sormamın bir sakıncası olmadığını düşünüyorum. Çünkü böyle bir durumda aday zaten görev beklentilerini yerine getirebilecek durumdadır ve takım Belirsiz Sınama Hatası nedeniyle faydalı bir şekilde çalışabilecekleri bir adaydan hem mahrum kalmış hem de zaman -ve dolayısıyla para- kaybetmiş olacaktır.
Belirsiz sınamalar uyguladığınızda, sadece -genellikle şans eseri olarak- ekiple yakın kalite seviyesi olan adayları seçebilirsiniz. Eğer amaç buysa, bu yönteme hiçbir itirazım yok. Ancak ekiple birlikte çalışabilme uyumunu gösterecek, takım kültürüne adapte olabilecek ve verilen görevleri tamamlayabilecek adayı arıyorsanız, bu yöntemin kullanılması sakıncalıdır.
Öneriler
Yukarıda ana başlıklar altında topladığım eleştirileri birlikte değerlendirdiğimde, teknik mülakatlardaki asıl sorunun; adayın genel profilinin değerlendirilmesi, ancak pozisyon ve aday özelinde bir değerlendirme yapılmaması olduğunu söyleyebilirim. Bu nedenle, bizim de TalentGrid bünyesinde aktif olarak kullandığımız pozisyon ve aday ilişkisinin sınanmasının daha aklı yatkın bir sınama yöntemi olduğunu savunuyorum. Mükemmel bir CV’ye sahip bir aday, ilgili pozisyonun kriter ve beklentilerine uymadığı müddetçe, pozisyon için son derece yanlış bir adaydır.
Tüm bunlar yerine, pozisyon beklentileri düşünülerek oluşturulacak iş tanımlarıyla, söz konusu adayın, doğrudan üzerinde çalışacağı proje ya da projelere davet edilerek, rutin geliştirme programına göre nasıl bir geliştirme yolu izlediği gözlemlenebilirse, aday ve pozisyon arasındaki uygunluğun tespiti o denli kolay olacaktır. Bu yöntemin özellikle büyük ölçekli şirketler için oldukça zor olduğunu tereddütsüz kabul etmekle birlikte, yukarıda saydığım hataların kabullenilmesi ve teknik mülakat hazırlayan kişilerce farkında olunması, gelecekte daha efektif yöntemlerin ortaya konulabilmesi için gereklidir.
Sonuç
Eleştirilerimi topladığım bu üç ana başlığa daha fazlasının da eklenebileceğini düşünüyorum. Ancak bu noktada bırakacağım.
Burada anlatmak istediğimi ve temel olarak eleştirilerimi şu noktada toplayabilirim; teknik mülakatların amacı adayın 0–100 arasındaki yazılımcı başarı puanını belirlemek değildir. Teknik mülakatların amacı; söz konusu pozisyonda çalışmak için niyetli olan adayın, pozisyonun beklentilerini karşılayıp karşılayamacağının tespitidir. Yukarıda bahsettiğim üç ana hatanın ortak noktası, adayın genel başarı puanını belirlemeye yönelik olması ve adayın takıma/pozisyona uygunluğunun büyük oranda göz ardı edilmesidir.
Eğer gerçekten verimli bir teknik mülakat yapmak istiyorsanız, söz konusu pozisyon için günlük işlerden bir iş seçim adayın söz konusu işi tamamlamasını bekleyebilirsiniz. Böyle bir sınama, adayın pozisyon ile olan uyumluluğunu ölçmek için daha yararlı olabilir. Bu yöntemin -özellikle büyük şirketler için- ciddi bir zaman problemi yaratacağını ve uygulamada zorluklar olabileceğini kabul ediyorum. Ancak bu durumda dahi, benim burada bahsettiğim hataların mazur görülmemesi gerektiğini, çünkü söz konusu hataların teknik mülakat sürecine ciddi şekilde zarar verdiğini, mülakatı yapan tarafın doğru adaylara ulaşamadığını ve seçtiği adayları genellikle yanlış özellikleriyle seçtiğini, en iyi ihtimallerde dahi şans eseri doğru adaya ulaştıklarını düşünüyorum.
