Ana sayfa → Ekip Yönetimi
Teknik Mülakat: Bilgi Yoklaması Değil, Birlikte Çalışma Provası
Adaya beyaz tahtada ağaç dengelemesi sordum. Takıldı, tamamlayamadı, eledik. Altı ay sonra aynı kişi, bizim entegre olduğumuz servisi yazan ekipteydi. O servisin kodunu okudum: bizimkinden temizdi.
- Mülakatın cevaplaması gereken tek soru var: bu kişiyle birlikte çalışmak nasıl olurdu?
- Beyaz tahta algoritması hazırlığı ölçüyor, yeteneği değil. İşe alınan kişi o işi bir daha asla yapmayacak.
- Görev kendi kod tabanından kırpılır. 90 dakika, gerçek bir iş, aday arama yapabilir ve soru sorabilir.
- Sabit görev = karşılaştırılabilirlik. Her adaya farklı soru sorarsan elinde kıyaslanabilir hiçbir şey olmuyor.
- Notlar toplantıdan önce, tek tek yazılır. İlk konuşan herkesi etkiliyor.
- AI sonrası asıl soru değişti: “yazabiliyor mu” değil, “üretileni inceleyebiliyor mu”.
Sahadan: yanlış soruyla elenen aday
O mülakattan çıkarken kendimi iyi hissetmiştim: zor bir soru sormuştuk, aday yapamamıştı, “çıtayı koruduk” diye düşündük. Altı ay sonra o kişinin yazdığı servisle entegre olurken anladım ki çıtayı korumamışız, sadece yanlış yerde tutmuşuz.
Sorduğum soru kötü bir soru değildi. Sorun, o sorunun yaptığımız işle hiçbir ilgisinin olmamasıydı. Biz ödeme akışları yazıyorduk; son bir yılda kimse ağaç dengelememişti. Ölçtüğüm şey adayın mühendisliği değil, o hafta ne kadar mülakat çalıştığıydı.
Daha kötüsü: bu soru bazı insanları sistematik olarak eliyordu. Son iki yıldır gerçek ürün yazan, mülakat çalışmaya vakti olmayan kıdemli biri takılıyordu; yeni mezun ve tazeliğinde olan biri akıcı çözüyordu. Yanlış sinyali yüksek sesle dinliyorduk.
Tek soru ve üç alt sorusu
Mülakatın cevaplaması gereken soru şu: bu kişiyle birlikte çalışmak nasıl olurdu? Altında üç alt soru var ve üçü de gözlemlenebilir:
- Gerçek bir kod tabanında ilerleyebiliyor mu? Yabancı bir kodun içine girip yön bulabiliyor mu, yoksa sadece boş sayfada mı çalışıyor?
- Bilmediği bir şeyle karşılaşınca ne yapıyor? Bu en değerli sinyal. “Bunu bilmiyorum, şuraya bakayım” diyebiliyor mu, yoksa bilmediğini saklamaya mı çalışıyor?
- Geri bildirimi nasıl alıyor ve veriyor? Görev sırasında ona bir öneride bulun. Savunmaya mı geçiyor, düşünüp değerlendiriyor mu, katılmıyorsa gerekçesini söyleyebiliyor mu?
İkinci maddeyi özellikle kolluyorum çünkü işte en sık yaşanan durum bu. Kimse bildiği işi yapmıyor; herkes günün yarısını bilmediği bir şeyi çözerek geçiriyor.
Görev: kendi kod tabanından, 90 dakika
Beyaz tahtayı bırakıp şuna geçtik: kendi kodumuzdan kırpılmış, sadeleştirilmiş, tek başına çalışan küçük bir depo. İçinde gerçek bir işin küçültülmüş hâli var.
ONCEDEN HAZIR : depo klonlanmis, bagimliliklar kurulu, testler kosuyor
(adayin 40 dakikasini ortam kurmaya harcatan mulakat
hicbir sey olcmez)
GOREV : "Bu serviste ayni bildirim bazen iki kez gidiyor.
Once sorunu bul, sonra duzelt, sonra tekrar
etmeyecegini gosteren bir test yaz."
(bizim gercekten yasadigimiz bir olaydan kirpildi)
SURE : 90 dakika, birlikte, paylasimli ekran
SERBEST : internet, dokumantasyon, kutuphane, AI araci
soru sormak (biz de oyle calisiyoruz)
BIZ NE YAPIYORUZ : izliyoruz, takilinca ipucu veriyoruz,
ve bir yerde bilerek bir oneri sunuyoruz
-> geri bildirimi nasil aldigini gormek icin
BITIRMEK SART DEGIL : nasil ilerledigi, bitirip bitirmediginden onemli“Bitirmek şart değil” maddesi değerlendirmeyi tamamen değiştiriyor. Bazı adaylar sorunu 40 dakikada buluyor ve düzeltmeyi yarım bırakıyor; bazıları iki saat sürecek bir yolu düzgün ilerletiyor. İkisi de kabul edilebilir, çünkü işte de öyle.
Sabit soru seti: karşılaştırabilmek için
Aynı görev, aynı dört kapanış sorusu, her adaya. Bu sıkıcı geliyor ama karşılaştırılabilirliğin tek yolu bu — organizasyon teşhisi için 52 görüşmede öğrendiğim şey burada da geçerli: farklı soru sorarsan farklı cevap alırsın ve hiçbirini yan yana koyamazsın.
- “Bu kodda en çok neyi değiştirmek isterdin?”
- “Bunu canlıya çıkarsan neyi izlerdin?”
- “Bir şeyi yanlış yaptığını en son ne zaman fark ettin?”
- “Bugün bir şey olsa, gece seni ne uyandırırdı?”
- Beyaz tahtada algoritma
- Dil/kütüphane trivia’sı (“şu metodun imzası?”)
- “Kaç yıl X deneyimin var?”
- Bilmece soruları
- “5 yıl sonra kendini nerede görüyorsun?”
Değerlendirme: önce yaz, sonra konuş
Uzun süre şöyle yaptık: mülakattan sonra üç kişi bir odaya girer, konuşur, karar verirdik. Sonra fark ettim ki kararı neredeyse her zaman ilk konuşan belirliyordu. İkinci kişi onu yumuşatıyor, üçüncüsü katılıyordu.
Kuralı değiştirdik: herkes, toplantıdan önce, 30 dakika içinde kendi notunu yazar. Not tek satır olabilir ama iki şey içermeli: evet/hayır ve tek cümlelik gerekçe. Toplantı ancak notlar yazıldıktan sonra başlar.
Fark şu oldu: artık toplantının başında masada farklı görüşler oluyor ve tartışma o farkların üstünde yapılıyor. Bu, psikolojik güvenlik yazısında anlattığım “kim önce konuşur” meselesinin mülakat hâli.
AI sonrası: soru değişti
Adayın araç kullanmasını yasaklamak artık anlamsız, çünkü işe aldığın gün onu kullanacak. Asıl soru değişti: “kod yazabiliyor mu” değil, “üretilen kodu inceleyebiliyor mu”.
Göreve bunun için bir adım ekledik: hazır bir çözüm veriyoruz ve “bunu canlıya alır mıydın?” diye soruyoruz. Çözümde bilerek iki sorun var — biri görünür, biri değil. Aradığımız şey adayın onları bulması değil; nasıl aradığı. Bu, kod incelemede aradığımız davranışın ta kendisi ve artık işin en kıymetli kısmı orası.
Ret maili ve ekibe dönüşü
Adayların büyük kısmını reddediyorsun; yani mülakat süreciyle temas eden insanların çoğu için deneyim ret deneyimi. İki şey yapıyoruz: 48 saat içinde cevap veriyoruz ve tek cümlelik gerçek bir gerekçe yazıyoruz.
Bunu nezaket olduğu için değil, geri döndüğü için yapıyoruz. Reddettiğimiz bir aday bir yıl sonra tekrar başvurdu ve mülakatta “geçen sefer yazdığınız şeyi çalıştım” dedi. Aldık. Sessiz ret, o kişiyi bir daha geri getirmez.
Ne izlemeli?
| Ne | Neden |
|---|---|
| İşe alınanların 6. ay değerlendirmesi | Mülakatın tek gerçek testi; işe alım kararını sonuçla eşleştir |
| Aynı görevde adayların dağılımı | Herkes geçiyor ya da herkes kalıyorsa görev ayırt etmiyor |
| Görüşmeciler arası uyum | Notlar hep aynı yöne gidiyorsa ya süreç iyi ya da kimse bağımsız düşünmüyor |
| Süreçten çekilen aday oranı | Yüksekse sorun adayda değil; süreç uzun ya da saygısız |
Bende işe yaramayanlar
- Eve ödev vermek. “Hafta sonu şunu yap” dedik. İki sorun çıktı: işi olan adaylar çekildi, ve gelen çözümün kimin yazdığını bilemedik. 90 dakikalık birlikte oturum aynı bilgiyi daha adil veriyor.
- Beş turlu süreç. Titiz görünüyordu; pratikte iyi adaylar üçüncü turda başka teklif alıp çekiliyordu. Üç tura indirdik: giriş konuşması, teknik oturum, ekip sohbeti.
- “Kültür uyumu” turu. Neyi ölçtüğünü kimse tanımlayamıyordu ve pratikte “bize benziyor mu”ya dönüyordu. Yerine somut bir şey koyduk: adaya ekibin gerçek bir tartışmasını anlatıp ne yapardı diye soruyoruz.
Kontrol listesi
- Sorduğum şeyi bu kişi işe girerse gerçekten yapacak mı?
- Görev kendi kod tabanımızdan mı, genel bir bulmaca mı?
- Ortam hazır mı — aday kaç dakikasını kuruluma harcıyor?
- Her adaya aynı görev ve aynı sorular veriliyor mu?
- Aday arama yapabiliyor, soru sorabiliyor, araç kullanabiliyor mu?
- Görev sırasında bilerek bir öneri sunup tepkisini gördüm mü?
- Notumu ortak toplantıdan önce yazdım mı?
- Ret cevabı 48 saat içinde ve gerekçeli mi gidiyor?
Sonuç
O adayı elediğimizde süreç kusursuz işlemişti: hazırlanmış soru, iki görüşmeci, ortak karar. Kusurlu olan tek şey sorunun kendisiydi ve bunu altı ay boyunca fark etmedik — çünkü mülakat sürecinin geri bildirim döngüsü yok. Reddettiğin insanların ne olduğunu hiç öğrenmiyorsun.
Bu yüzden mülakatı “doğru kişiyi seçme” aracı olarak değil, birlikte çalışmanın provası olarak kurmak gerekiyor. Provayı gerçeğe ne kadar benzetirsen, kararın o kadar isabetli oluyor.
Test basit: mülakatta yaptığın şeyi, işe aldığın kişi ilk haftasında yapacak mı? Cevap hayırsa, ölçtüğün şey o iş değil.