İş ilanı, işten önce yazılmış bir spec'tir

6. Sorma becerisi nasıl ölçülür?

"Soru sorabilen insan arıyoruz" demek kolay; ama bu cümle ilana yazılamaz, çünkü ölçülemez. Ölçülemeyen şey işe alım sürecinde yok sayılır. Bu yüzden bu bölüm yazının en pratik bölümü: Katman 3'ü Katman 1 kadar somut hale getirmek.

Katman 3'ün iki yarısı vardı: sormak ve anlamak. Anlamak da kendi içinde ikiye ayrılır: tanımadığın bir şeyi anlamak ve yanlış olan bir şeyi fark etmek. Aşağıdaki üç format bu üç parçayı sırayla ölçer:

Bu üç durum, AI ile çalışan bir mühendisin gününün neredeyse tamamını oluşturur. Talep eksik gelir; üretilen kod çoğu zaman tanımadığı bir kütüphaneyi ya da deseni kullanır; ve bu kodun bir kısmı akıcı ama yanlıştır. Beceri listesi bunların hiçbirini ölçmez, çünkü üçü de adayın zaten bildiği şeyin dışında olur.

6.1 Ortak iskelet

Ayrıntılara girmeden önce, üç formatı birbirine bağlayan dört ilke.

Cevabı değil, izi ölçersin. Adayın vardığı yer ikincildir. Ölçülen şey oraya giderken bıraktığı izdir: hangi soruları hangi sırayla sordu, neyi varsaydı ve neyi varsaydığını söyledi mi. Bu yüzden aday baştan sesli düşünmeye davet edilir ve mülakatçı sonucu değil, süreci not alır.

Gizli bağlam kartı. Her formatta mülakatçının elinde adayın görmediği bir kart vardır: eksik spec'in cevapları, kodun gerçek davranışı, AI cevabındaki hatanın yeri. Kart yalnızca adayın sorduğu şeyi açığa çıkarır. Bu gerçek hayatın bir modelidir: kurumlarda bilgi çoğu zaman vardır, ama birinin kafasında yaşar ve ancak sorulursa ortaya çıkar.

Mülakatçı jüri değil, bilgi kaynağıdır. Mülakatçının görevi adayı sıkıştırmak değil, her soruya dürüstçe ve yalnızca sorulduğu kadar cevap vermektir. Fazladan ipucu ölçümü bozar; soruyu geçiştirmek adayı cezalandırır. Bu rolün kendisi öğretilmesi gereken bir beceridir; formatlar mülakatçı eğitimi olmadan çalışmaz.

Rubrik önceden yazılır ve davranışa bağlanır. "İyi soru sordu" bir puan değildir. "Silme işleminin geri alınabilir olup olmadığını sordu" bir puandır. Her formatın rubriği, gizli karttaki maddelere ve 8. bölümde anlatacağım üç basamaklı sorgulama merdivenine bağlanır: kabul et → sorgula → neyin sorulmaya değer olduğunu seç.

6.2 Eksik spec mülakatı

Kurulum. Adaya sıradan görünen, tek cümlelik bir iş verilir. Cümle bilerek eksiktir, ama eksiklik göze batmaz. İyi bir eksik spec'in ölçütü şudur: ilk okumada "bunun neresi zor?" dedirtmeli, ikinci okumada en az beş ayrı mayın ortaya çıkmalıdır. Bu mayınların cevapları mülakatçının kartındadır.

Örnek.

Görünüşte bu, bir cron job ve tek bir DELETE'tir. Zayıf aday tam olarak bunu yazar:

DELETE FROM users
WHERE deleted_at < now() - interval '30 days';

Güçlü aday kod yazmadan önce sorar. İlk sorusu çoğunlukla şudur: "Burada silmek ne demek? Geri alınabiliyor mu?" Bu tek soru, işin bir DELETE değil bir veri yaşam döngüsü problemi olduğunu açığa çıkarır. Ardından gelen sorular kartı madde madde açar.

Çarpıcı olan şudur: kartın tamamını açmak için özel bir bilgi gerekmez. Yasal bir yükümlülüğe uymak için saklanması gereken verilere dair istisnası da dahil, GDPR'ın 17. maddesini ezberden bilmeniz gerekmez. Gereken şey, "kullanıcının verisi" ifadesinin kaç farklı şeye karşılık gelebileceğini merak etmektir. Bu formatta Katman 1 neredeyse hiç işe yaramaz; Katman 3 her şeydir.

Ne ölçülür?

• Kaç mayın soruyla açıldı? Varsayılarak geçilen her mayın, gelecekteki bir üretim olayıdır.
• Soruların sırası. Güçlü aday önce anlamı ("silmek ne demek?"), sonra kapsamı ("hangi veri?"), en son uygulamayı ("hangi saatte çalışsın?") sorar. Sıra, adayın problemi nasıl kavradığını gösterir.
• Sesli söylenen varsayımlar. Zaman baskısı altında her şeyi soramazsınız. Güçlü aday sormadığı şeyi söyler: "Yedekleri kapsam dışında varsayıyorum, ama bunun ayrıca konuşulması gerekir." Söylenmiş bir varsayım bir karardır; söylenmemiş bir varsayım bir kusurdur.
• Ne zaman duracağını bilmek. Sonsuza kadar soru soran aday da başarısız olur. Yeterince şeyin netleştiğini ve geri kalanın iş sırasında çözülebileceğini ayırt etmek, merdivenin en üst basamağıdır: neyin sorulmaya değer olduğunu seçmek.

6.3 Yabancı kod okuma

Kurulum. Adaya, özgeçmişinde olmayan ve muhtemelen hiç görmediği bir dilde 10–15 satırlık bir kod verilir. O dili biliyorsa kod değiştirilir. Soru basittir: "Bu ne yapıyor?" Katman 1 bilerek sıfırlanmıştır. Geriye kalan, tanımadığı bir şeyi tanıdık şeylere benzeterek anlamlandırma becerisi ve benzetmenin nerede kırıldığını görebilmektir.

Örnek. JavaScript, Java ya da Python geçmişli bir adaya şu Erlang kodu verilir:

loop(Balance) ->
    receive
        {deposit, Amount, From} ->
            From ! {ok, Balance + Amount},
            loop(Balance + Amount);
        {withdraw, Amount, From} when Amount =< Balance ->
            From ! {ok, Balance - Amount},
            loop(Balance - Amount);
        {withdraw, _Amount, From} ->
            From ! {error, insufficient_funds},
            loop(Balance)
    end.

İlk tur okuma turudur. Güçlü aday şöyle bir iz bırakır:

Bu izde üç şey dikkat çeker. Aday her çıkarımı bir benzetme üzerine kurar (switch, gönderme, döngü). Emin olmadığı çıkarımı emin değilim diye işaretler. Ve benzetmenin kırıldığı yeri, yani mutasyonun yokluğunu, bir tuhaflık olarak not eder. Bu tuhaflığı fark etmek, okumanın en değerli anıdır.

İkinci tur çarpıcı olan turdur. Mülakatçı sorar:

Java ya da Python geçmişli bir aday için refleks cevap race condition'dır: iki thread bakiyeyi aynı anda okur, ikisi de yeterli görür, hesap eksiye düşer; o halde bir kilit gerekir. Kodda kilit yoktur. Aday ya bir kilit eklemeyi önerir ya da takılıp kalır.

Kartta yazan gerçek cevap: race condition yoktur. Bu fonksiyon bir Erlang sürecinin gövdesidir. Süreç, mesajlarını posta kutusundan birer birer alır; iki withdraw mesajı aynı anda gelse bile sırayla işlenir. Kilit yoktur, çünkü paylaşılan bir değişken yoktur. Güvenliği kilit değil, mimari sağlar.

Aday bunu bilemez; Katman 1'i sıfırlanmıştır. Ölçülen şey bilip bilmediği değil, oraya soruyla varıp varamadığıdır. Güçlü aday refleksini askıya alır ve sorar: "Bu kod birden fazla thread'de aynı anda çalışabiliyor mu? receive mesajları birer birer mi alıyor?" Bu soru sorulduğunda kart açılır ve aday, refleksinin başka bir dünyanın varsayımı olduğunu görür.

Üçüncü tur, merdivenin tepesi içindir:

Kartta iki cevap vardır. Birincisi: tanınmayan bir mesaj, örneğin {balance, From}, hiçbir dala uymaz ve posta kutusunda sonsuza kadar kalır. Posta kutusu sessizce büyür. İkincisi: bir withdraw için Amount'un pozitif olduğunu kontrol eden hiçbir şey yoktur. Eksi bir tutar çekmek bakiyeyi artırır. İkinci cevabı bulmak için hiç Erlang bilmek gerekmez; yalnızca kodun niyeti ile yaptığı arasındaki boşluğu sormak gerekir.

Ne ölçülür?

• Benzetmenin kalitesi. Aday bilinmeyeni bilinene bağlayabiliyor mu? Bunu yaparken bağın nerede zayıf olduğunu görebiliyor mu?
• Belirsizliği işaretlemek. Her çıkarım aynı güvenle söylenmez. "Bu kesin", "bu tahmin" ve "bunu doğrulamam lazım" ayrımını yapabilen aday, AI çıktısıyla çalışırken de aynı ayrımı yapar.
• Refleksi askıya almak. Kendi dünyasının bir varsayımını (kilit gerekir) yeni bir dünyaya taşımadan önce sorgulayabiliyor mu? Bu, formatın en ayırt edici ölçüsüdür.
• Neyi arayacağını bilmek. Bir varyasyon: adaya "şimdi bir LLM'e ya da dokümantasyona tam olarak bir soru sorabilirsin; ne sorardın?" denir. O sorunun kalitesi, okumanın kalitesini özetler. "receive nasıl çalışır?" orta karar bir sorudur. "Bir Erlang süreci posta kutusundaki mesajları birer birer mi işler, eşzamanlı mı?" çok daha iyi bir sorudur, çünkü tek kritik bilinmeyene iğne gibi iner.

6.4 AI çıktısı denetimi

Kurulum. Adaya bir soru ve bir LLM'in o soruya verdiği cevap gösterilir. Cevap akıcı ve özgüvenlidir, kod çalışır ve testleri geçer; ama içinde üretimde sessizce patlayacak bir hata vardır. Çerçeve şudur: "Bunu bir takım arkadaşın gönderdi ve merge etmek üzere. Ne dersin?"

Hatanın seçimi formatın kalbidir. Sözdizimi hatası olmamalıdır; derleyici onları zaten bulur. Hata, kodun doğruluğunun kodun dışındaki bir şeye bağlı olduğu türden olmalıdır: veriye, şemaya, zamana, ölçeğe.

Örnek. Soru ve cevap:

SELECT id, email
FROM customers
WHERE id NOT IN (SELECT customer_id FROM orders);

Cevaptaki her şey doğru görünür. İndeks önerisi mantıklıdır, sorgu okunaklıdır ve test veritabanında doğru sonucu döndürür.

Kartta yazan hata: orders.customer_id nullable'dır, çünkü şirket altı ay önce üye olmadan alışverişi (guest checkout) açmıştır. Misafir siparişlerinin customer_id'si yoktur. SQL'in üç değerli mantığında x NOT IN (1, 2, NULL) hiçbir zaman doğru olmaz; en iyi ihtimalle bilinmez olur. Alt sorgu tek bir NULL döndürürse, sorgu hiçbir satır döndürmez.

Hata yok. Uyarı yok. Boş bir liste. Pazarlama ekibi sorguyu "hiç sipariş vermemiş müşterilere" kampanya göndermek için kullanır; liste boştur; kimse bir şeyin yanlış gittiğini fark etmez; kampanya kimseye ulaşmaz. Bu, 7. bölümde anlatacağım sessiz hatanın küçük ölçekli bir provasıdır.

Cevapta ikinci, daha sığ bir sorun da vardır: "genellikle daha performanslıdır" iddiası dayanaksızdır. PostgreSQL NOT EXISTS'i bir anti-join'e dönüştürebilir ve çoğu durumda en az onun kadar iyi sonuç verir. Bu sorun bilerek yerleştirilmiş bir tuzaktır: sığ bir denetim burada durur, performans iddiasını düzeltir ve cevabı onaylar. Asıl hata altta kalır.

Bu örnek, 8. bölümdeki merdivenin üç basamağını neredeyse birebir ayırır:

• Kabul eden aday: "Temiz görünüyor, indeks önerisi de iyi. Onaylandı." Cevabın özgüveni, adayın özgüveni olur.
• Sorgulayan aday: performans iddiasını yakalar ya da NOT IN'in NULL'larla sorunlu davrandığını hatırlar ve NOT EXISTS önerir. Hatayı bulmuştur; ama bir kural olarak bulmuştur.
• Neyin sorulmaya değer olduğunu seçen aday: önce sorar: "customer_id nullable mı? Bir siparişin müşterisinin olmadığı bir durum var mı?" Cevap geldiğinde hatayı bulur, ama orada durmaz: "Bu sorgunun doğruluğu şemaya bağlı. Şema altı ay önce değişmiş ve kimse fark etmemiş. Bir sonraki değişikliği kim fark edecek?" Sorguyu düzeltmenin yanında, içinde NULL müşterili bir sipariş bulunan bir test önerir. Sorguyu değil, sorgunun yanlış olabileceği koşulu korumaya alır.

Bu üç yanıt arasındaki farka dikkat edin. İkinci aday Katman 1'i kullandı: bir kural biliyordu. Üçüncü aday Katman 3'ü kullandı: kuralı bilmese bile doğru soruyla aynı yere varırdı; ve oraya vardıktan sonra dersi hatanın kendisinden değil, hatanın nasıl mümkün olduğundan çıkardı.

Ne ölçülür?

• Aramaya nereden başladı? Sözdiziminde mi, mantıkta mı, yoksa kodun dışındaki varsayımlarda mı? Güçlü aday "bu kod neyi varsayıyor?" sorusuyla başlar.
• Özgüvene direnç. Akıcı, kendinden emin bir metin okuyanı onaya iter. Adayın bu baskıya ne kadar dayandığı, AI ile çalışırken ne kadar güvenilir bir denetçi olacağının en iyi göstergesidir.
• Tuzakta durdu mu? Denetimi bulduğu ilk sorunda bitiren aday, gerçek hayatta da bulduğu ilk sorunda durur.
• Düzeltmek mi, korumak mı? Hatayı düzeltmek bir basamaktır; tekrarlanmasını imkânsız ya da görünür kılmak bir üst basamaktır.

6.5 Tasarım riskleri

Bu formatların da zaafları var; onları bilmeden uygulamak, beceri listesinden daha kötü sonuç verebilir.

Sızma. Formatlar bilinir hale geldiğinde adaylar hazırlanır. Bu bir sorun değil, amacın ta kendisidir: eksik spec'te önce soru sorma alışkanlığını edinerek hazırlanan aday, aranan beceriyi zaten edinmiştir. Asıl sorun içeriğin sızmasıdır. NOT IN örneği yayınlandığı anda yandı; bu yazıda olduğu gibi. Bu yüzden format sabit kalır, içerik döner. İyi bir ekip her çeyrekte kendi üretim olaylarından yeni bir örnek çıkarır. Kendi hatalarınızdan daha iyi mülakat malzemesi yoktur.

Mülakatçı yükü. Beceri listesini bir ATS denetleyebilir. Bu formatları ancak eğitilmiş bir insan yürütebilir. Kartı iyi bilmeyen, fazla ipucu veren ya da sessizliğe tahammül edemeyen bir mülakatçı ölçümü bozar. Bu, formatların maliyetidir ve 7. bölümde anlatacağım direncin gerçek bir kaynağıdır.

Kaygı ve dil. Sesli düşünmek herkes için eşit derecede kolay değildir. Anadili mülakat dilinden farklı olan ya da baskı altında donan bir aday, Katman 3'te güçlü olduğu halde zayıf görünebilir. Hafifletmenin yolu, adayı formata önceden hazırlamak ve bir ısınma sorusuyla başlamaktır. Formatın sürpriz olması gerekmez; sürpriz olması gereken yalnızca içeriktir.

Kalibrasyon. Aynı kartı kullanan farklı mülakatçıların aynı adaya aynı puanı verip vermediği ölçülmelidir. Vermiyorlarsa sorun adayda değil, rubriktedir.

Üç format da yapılandırılmıştır ve bu tesadüf değildir. "Bu kişi iyi soru soruyor mu?" sorusu yapılandırılmadan sorulduğunda, mülakatçının hoşlandığı adayı seçmesine dönüşür. Yapılandırılmış mülakatın hem 1998'de hem 2022'de zirveye çıkmasının ve yapılandırılmamış mülakatın revizyonda 0,19'a düşmesinin nedeni budur. Katman 3'ü ölçmek, Katman 1'i ölçmekten daha fazla disiplin ister; daha az değil.