Kodlama testi nasıl oluşturulur

What you'll need

• Bir SkillCort çalışma alanı (ya da bir demo)
• Ekibinizin yazdığı koddan gerçek bir örnek — bir hata, küçük bir özellik, bir yeniden düzenleme
• Görevi ve rubriği tanımlayacak kıdemli bir mühendis
• Hangi dilleri kabul edeceğinize dair bir karar

Step 1: Algoritma bulmacası yerine gerçekçi bir görev seçin

Son bir ayın pull request'lerine bakın ve yinelenenlere benzeyen bir görev seçin: bozuk bir davranış verilmişken bir hatayı düzeltmek, küçük bir fonksiyonu yeni bir durumu karşılayacak biçimde genişletmek, dağınık bir bloğu yeniden düzenlemek ya da bir veri dönüşümü yazmak. Bunlar günlük performansı, bir ikili ağacı ters çevirmekten çok daha iyi yordar.

Yetkin bir işe alım için 30–45 dakikalık odaklanmış çalışmaya göre boyutlandırın. Bir bulmaca onu prova etmiş olanı ödüllendirir; gerçekçi küçük bir görev ise mevcut niyeti okuyabilen, sağlam bir değişiklik yapan ve kodu anlaşılır tutan kişiyi ödüllendirir — işe aldığınız şey de budur.

Rol gerçekten gerektirmedikçe çerçeveye ve şirkete özgü bilgiyi çıkarın ve görevin ihtiyaç duyduğu bağlamı brifingin içinde verin. Sizin teknoloji yığınınıza hiç dokunmamış güçlü bir mühendis yine de size sağlam muhakeme gösterebilmelidir. Beceriyi sınayın, kod tabanınızın malumatına aşinalığı değil.

• Mülakat hazırlık kitaplarında değil, gerçek kod tabanınızda yineleniyor
• Birden fazla makul çözümü var
• Kahramanlık gerektirmeden 30–45 dakikaya sığıyor
• Bir değerlendirici tarafından on dakikanın altında okunabiliyor

Step 2: Soru bankasında kod maddesini oluşturun

Rol için bir klasör açın — örneğin Backend Mühendisi — beceri alanı ve zorluk etiketleriyle birlikte, sonra kod maddesi türünü kullanarak bir madde oluşturun. Adaylar kodu doğrudan yanıt alanında yazıp düzenler; değerlendiriciler de sonradan onu yerinde inceler.

Maddeyi boş bir editör yerine başlangıç koduyla tohumlayın. Tarif edilmiş bir hatası olan kısa bir fonksiyon ya da net bir sözleşmesi olan bir taslak, her adayı aynı başlangıç noktasına bağlar ve değişikliklerini doğrudan karşılaştırılabilir kılar. Gerçek iş neredeyse hiçbir zaman boş bir dosyadan başlamaz; test de başlamamalı.

Step 3: Brifingi editörün yanına yazın

Yan yana uyaran düzenini kullanın: brifing, gereksinimler ve örnek girdi-çıktılar bir tarafta, kod editörü yanında. Aday çözümü yazmak için şartnameden hiç uzaklaşmaz — bir IDE'de bir talep üzerinden çalışmakla aynı biçim.

Brifingi iyi bir talebin okunduğu gibi yazın: mevcut davranış, beklenen davranış, kısıtlar ve iki üç somut örnek. Neyi önemsediğinizi açıkça belirtin — "önce çalışan kod; ayrıca netlik için de okuyoruz" — böylece adaylar gerçekte puanlayacağınız şeye göre eniyileme yapar. Brifingdeki muğlaklık sonuçlarda gürültüye dönüşür.

Step 4: Doğruluktan fazlasını puanlayan bir rubrik kurun

Doğru çıktı gereklidir ama yeterli değildir. Üç ya da dört ölçütü olan düzey temelli bir matris rubrik kurun — genellikle doğruluk, okunabilirlik ve yaklaşım; isteğe bağlı olarak sınır durumlarını karşılama — her biri güçlü, kabul edilebilir ve zayıf kodun neye benzediğine dair çıpalanmış tariflerle. "İsimler niyeti açık ediyor, ölü kod yok" puanlanabilir; "temiz kod" değildir.

Doğruluğu en ağır ağırlıklandırın ama diğer ölçütleri gerçek tutun: kimsenin bakımını yapamayacağı, zar zor çalışan bir çözüm güçlü bir işe alım sinyali değildir. Rubriği iliştirdiğinizde bir anlık görüntüye donar; böylece banka sürümü sonradan gelişse bile koşudaki her aday birebir aynı ölçüte göre incelenir.

Step 5: Builder'da birleştirin ve süre koyun

Değerlendirmeyi bölümler, sayfalar ve bloklar olarak oluşturun ve kod maddesini seçiciden içe aktarın. Pek çok ekip kısa bir ilk bölüm ekler — bir diff okumak, bir parçadaki hatayı bulmak; çoktan seçmeli olarak hızla yapıştırılmış — ve kodlama görevini kendi bölümüne koyar.

Toplam süre sınırını okumaya ve düşünmeye pay bırakacak biçimde ayarlayın ve kodlama sayfasında sayfa başına bir sınır kullanın ki görev denemenin tamamını yutmasın. Kodlama bölümünü en ağır ağırlıklandırın (örneğin ×3) ki Decision Board'daki rol uyumu ısınmayı değil işi yansıtsın. Talimatlarda izin verilen dilleri ve süre biterse ne olacağını yazın.

Step 6: Önizleyin, kontrol listesini geçin ve yayımlayın

"Aday olarak önizle"yi kullanıp görevi kendiniz deneyin; ya da daha iyisi, görevi yazmamış bir mühendis hazırlıksız denesin. On dakikada bitiriyorsa fazla kolaydır; sınırda bitiremiyorsa kapsamı ya da saati gevşetin. Duraksadıkları her yerde brifingi düzeltin.

Sonra yayımlama kontrol listesini karşılayın — puanlama, zamanlama ve talimatlar tamamlanana kadar Yayımla'yı engeller. Rubriği eksik ya da süre sınırı denenmemiş bir kodlama testi bir adaya asla ulaşmamalı ve kontrol listesi ulaşamamasını sağlar.

Step 7: Güvenlik kontrollerini riskle orantılı ayarlayın

Ad ve zaman aralığıyla teslimatı oluşturun, sonra güvenlik seçeneklerini bilinçli seçin. Standart bir işe alım elemesinde kopyala/yapıştır engeli ve makul bir ihlal sınırıyla tam ekran kilidi genellikle yeter. Kamera kaydı, ekran kaydı, ikinci ekran tespiti ve kimlik kontrolleri gerçekten yüksek riskli koşullar için vardır — sertifikasyon, son turlar — varsayılan olarak değil.

Etkinleştirdiğiniz her şey, aday başlamadan önce rıza ve ön kontrol kapısında bildirilir. Güvenlik sinyalleri bir insanın bağlamı içinde inceleyeceği bayraklardır, asla otomatik eleme gerekçesi değil — tam ekrandan çıkmak bir bildirim olabilir, dolandırıcılık değil. Orantılılık, güçlü adayların bir gözetim ağından uzaklaşmasını engeller.

Step 8: Kodu rubrikle inceleyin, yapay zekâ destek olsun

Değerlendiriciler her gönderimi ortak rubriğe göre inceler; her ölçütte — doğruluk, okunabilirlik, yaklaşım — koda uyan düzey kartına tıklar. Sınırdaki ya da yüksek etkili durumlara iki inceleyici koymak ölçütü dürüst tutar ve herkes aynı dondurulmuş rubrik anlık görüntüsüne göre puanladığı için anlaşmazlıklar belirsiz içgüdü farkları olarak değil, belirli ölçüt boşlukları olarak görünür.

Yapay zekâ gönderimin bir özetini taslayabilir ve ölçüt düzeyinde puanlar önerebilir — kodda gerçekten yararlı bir ilk geçiş; model ve sürüm kayda geçer. Ama her puanı adı belli bir mühendis onaylar ya da geçersiz kılar. Yapay zekâ burada karar desteğidir, asla karar verici değil: bir adayın kodu hakkındaki hesap verebilir muhakeme her zaman insandır.