Joel Test sorusu # 11: "Yeni adaylar görüşmeleri sırasında kod yazar mı?" Yeni adaylardan mülakat sırasında kod yazmasını istemek ve buna karar vermek için yapılan tartışmalar nelerdir?
Yanıtlar:
Eksilerini görmüyorum. Bir röportajın birçok bölümü vardır ve bir adayın birkaç kez 'zinciri yukarı kaldırması' onaylanmalıdır.
Haftada ~ 10 kişiyle röportaj yapıyorum. Gerçekten, gerçekten, İK'nın tüm arka plan işlerini yaptığını ve bana bolca not sunduğunu gerçekten takdir ediyorum. Bana ulaştıklarında, testlerini puanlamamın zamanı geldi.
Testler tamamen pozisyona bağlıdır. Genellikle araştırmaya çalışıyorum:
Genel programlama becerisi. Operatörleri etkili bir şekilde kullanabilir misiniz? 10 olmayan bir yarıçapı olan sayısal bir sistemi kavrayabilir misiniz?
Sizi işe almak için ne yapıyoruz biliyor musunuz?
Listelediğiniz tüm açık kaynaklı projelere yaptığınız katkıların değerlendirilmesi
Kısa ve eğlenceli tutmaya çalışıyorum. Ofise girdiğimde, cevapları alıyorum, onlara bakıyorum ve sonra ikinci bir röportaj yapıyorum. İşe alınabilmek için genellikle üç röportajdan geçmeniz gerekir.
Ayrıca sizi alacak olan ekiple ne kadar iyi uyum sağlayacağınızı da ölçüyorum. O ekip bunu etkili bir şekilde yapmam için bana güveniyor.
Soruları meta formda cevaplamak bir şey, aslında kod üretmek için başka bir şey. Seni işe alacaksam, gerçekten kod ürettiğini görmem gerekiyor.
Scott Whitlock'a özür dileriz:
Eksileri:
Artıları:
Bir hokkabaz kiralayacak olsaydın, senin için hokkabazlık yapmamaya deli olurdun. Ya da seçmelere katılacak bir müzisyen. Aksi takdirde müthiş yo-yo "usta" K-strass gibi şeyler alırsınız .
Bir beyaz tahta üzerinde bir şey yürümek programcılar hızlı bir demo hokkabazlık eşdeğerdir.
Bence çok kullanışlı ve her zaman yapıyorum, ancak faydalar çok iyi karşılandığından sadece (belirgin) negatifleri tartışacağım.
Kod testlerinin size yanlış pozitifler vermesinin pek olası olmadığını düşünüyorum: Aslında kod yazamayan birisinin, en azından artan zorluklarla ilgili bir ölçek sorunuz varsa, bir röportajda sahte yapmayı başarabilme olasılıkları düşüktür. (Belki de en olası senaryo, bir yüz yüze röportaj değilse, bir arkadaşınıza sorarak hile yapmalarıdır.)
Sorunlar yanlış-negatif tarafta daha fazladır: kod testleri sizi en iyi aday olan kişiyi reddetmeye yönlendirir mi?
Sahne korkusu
Gerçekten iyi bir geliştirici olan, ancak bu röportajda çok gergin olan birisine sahip olabilirsiniz ve aslında sahne korkusu alırlar. Baskı altında performans bir dereceye kadar önemlidir, ancak sahne korkusu ile uğraşmak, bir programcı olmanın (diğer mesleklere kıyasla) bu kadar önemli bir parçası değildir ve kötü bir şekilde acı çeken birini reddetmek talihsiz olacaktır. Bu bileşik olabilir: Eğer kişi cevaplaması gerektiğini bildiği bir soruya cevap veremezse, daha sıkı olabilir. Veya bu soruda olduğu gibi , aynı anda konuşamayacaklarını ve kod yazamayacaklarını hissediyorlar.
hafifletme: Teknik sorulara geçmeden önce, geçmişleri, hedefleri vb. hakkında biraz bilgi edinin. Belki biraz daha teknik sorularla başlayın, böylece biraz ivme kazanın. Görüşme sırasında bir dick olma (noktalı virgüllerle ilgili tartışmalar).
Gürültülü bir önlem
İlginç kod sorularının birden fazla doğru yanıtı olabilir. Bir kişi doğru bir cevap, diğeri doğru ve daha verimli bir cevap yazarsa, buna ne kadar ağırlık vermelisiniz?
Bir dereceye kadar bu bazı "bulmaca" soruları ile ilgili sorun gibidir: kişi ya içgörü ya da değil ve neredeyse ikili bir sonuç alırsınız. Zeka muhtemelen bu içgörüye sahip olma olasılığını etkiler, ancak sadece birkaç kez örnekleme size kaba bir önlem verir.
Bu, kod soruları hakkında beni rahatsız ediyor (yine de kullanıyorum.) Düşünebileceğim en iyi hafifletme, mümkün olduğunca çok olası çözümlere sahip olmak: kişi en azından kaba bir kaba kuvvet yanıtı veya bir cevap yazabilir. sorunun bir parçası. Bunun hiçlikten daha iyi olduğunu anlamak iyi bir işarettir. Daha sonra keşfederlerse, daha verimli veya daha zarif bir kod yapabilirler. Mümkün olduğunca ikili yanıtlar alan sorular sormaktan kaçının.
Gerçekten temsili değil
Programlama, birbiri ardına on dakikalık algoritmik problemleri çözme işi değildir: kişilerarası becerilerden hiçbir şey söylemek için daha büyük sistemleri anlama ve tasarlama ve uzun süre konsantre olma konusunda çok daha fazla çalışma vardır. Kod soruları bunu gerçekten test etmez.
Ancak, kod soruları soracağınız tek soru değildir: sürekli çaba, yaratıcılık, kişilerarası becerilere dair kanıt bulmak için geçmişlerine, referanslarına, açık kaynak çalışmalarına (varsa) bakabilirsiniz.
Küçük algoritmik problemlerin nasıl çözüleceğini ve kodlara nasıl indirgeneceğini bilmek gerekli ama yeterli değil bir durumdur: küçük sorunları çözemezseniz ve önemsiz bir kod yazamıyorsanız, dünyadaki tüm büyük resim düşüncesi değil üretken bir geliştirici yapacağız.
Bunu herkes çözebilir
Hayır, görünüşe göre değil. Ünlü FizzBuzz gönderisinin belirttiği gibi , sadece yeni mezunlar değil, yılların endüstri deneyimi olan insanlar için önemsiz tuzak olduğunu düşünebilirsiniz. Neden bilmiyorum. Kod testi zayıf bir önlemdir (bu, olası olmadığını düşünmeme rağmen) veya özgeçmişlerindeki projelere çok fazla katkıda bulunmuyorlardı veya olmayan ve algoritmik kod (mümkün.)
Herhangi bir algoritmik kod yazmadan gerçekten çok şey yapabileceğinizi kabul etmeye değer. Kullanıcılar, değeri grafik veya iş mantığında bulunan ve "programlama" olarak adlandırabileceğiniz uygulamalarda çok para kazanıyor ve bu iyi. Ancak, aslında programcılara ihtiyacınız varsa, bu uygun değildir.
İyi kalibre edilmemiş olabilir
Bir soru bulursanız, cevap sizin için çok kolay görünebilir. Bununla birlikte, maviden başka türlü karşılaştırılabilir bir soru veya kendi özel ilgi alanlarınıza ve arka planınıza çarpık olmayan bir soru sorulursa, çok daha zor olabilir.
hafifletme: Testleri zaten bildiğiniz bazı geliştiriciler üzerinde yapın ve nasıl yaptıklarını görün. Belki de ekibinizde zaten çok akıllı olduğunu bildiğiniz biri bunlardan biriyle sorun yaşayacaktır ve onu ayarlamayı düşünebilirsiniz. Belki daha iyi veya farklı bir cevap düşüneceklerdir.
Trivia'ya çok benziyor
İnsanların ezbere API'ları ezbere bildikleri konusunda ısrar ederseniz veya sözdizimini mükemmel hale getirirse veya önemsiz bir algoritmanın tam tanımını hatırlarsanız, kod sorularının kesinlikle trivia'ya girebileceğini düşünüyorum. Bunların hepsi, almak için dokümanlara, web aramalarına veya derleyici hatalarına güvenmek için makul ve gerçek uzmanlıkla çok az korelasyona sahip. API'nın nerede olması muhtemel olduğunu bile bilmemek, belki de kişinin son zamanlarda kullanmadığı bir ipucudur, ancak özgeçmişlerinde yatmadıkları sürece bu bir sorun olmak zorunda değildir.
Bunun cevabı oldukça basit: önemsiz sorular sormayın ve önemsiz hatalara kapılmayın. Adayın API'nın ne olduğunu hatırlatın veya aramalarına izin verin; sözdizimi hatalarını düzeltmek; veri yapısı tanımlarını ezberleyen insanları test etmeyin.
Nasıl karşılaştırıyorsunuz?
İki adayınız varsa ve her ikisi de soruları iyi cevaplıyorsa, aralarında nasıl seçim yaparsınız? En hızlı bitireni seçebilirsin, ama belki de kaplumbağalar üzerinde tavşan toplamaya başlarsın. Başka bir tur yapabilir ve çok daha zor sorular sorabilirsiniz ama bundan da emin değilim. Belki de her ikisine de bir A + verin ve diğer kriterler arasında aralarından seçim yapmaya çalışın (veya her ikisini de işe alacak parayı bulmaya çalışın.)
Düşünebileceğim bir con diğer insanların önünde "yüksek sesle kodlamak" zor olmasıdır. Omzuma bakan biriyle yazmak bile zor ve yalnız değilim. Birisi beni bir şeye yardım etmek için iş istasyonuna çağırdığında, aniden yazım hataları yapmaya, yanlış kod tamamlamayı seçmeye, hatta düpedüz hatalar yapmaya başladığını fark ediyorum - hiçbiri orada oturmamış olsaydım. Cehennem, insanların sadece gözlem altında oldukları için kesme ve yapıştırma işlemleri için menüyü kullanmaya başladığını gördüm. Bu normal bir davranış değil ve bahsettiğim kodlayıcılar mükemmel programcılar ve oldukça akıllı.
Kısa bir süre önce, görüşmecinin bana belirli bir operasyonu nasıl kodlayacağımı sorduğu bir röportaj yaptım ve "Bana sadece matematiği göster" dedi. Sorunu matematiğe girmeden önce düşünmek zorunda kaldım, bu yüzden hemming ve hawing yaptım. İlk başta beyaz tahtaya koyduğum utanç vericiydi ve o noktada kaybettiğimi hissettim. Sonunda A-ha anını aldım ve cevabı buldum (aslında nihayet bana gerçekten ne istediğini ortaya çıkardığında ), ama oraya varmadan önce yaptığım "karışıklık" beni çok rahatsız etti. Bununla birlikte, işi aldım, ancak görüşmeci daha az sabırlı olsaydı, olmayabilirdim.
Görüşülen kişilere bir kodlama görevi verirseniz, bir bilgisayarda, belki de aşina oldukları IDE'de bile çalışmak için onlara biraz zaman verin. Bırakın kodu sizin için yazsınlar ve sonra onun hakkında konuşsunlar. Onlara işleri neden belirli bir şekilde yaptıklarını ve başka bir yolun daha iyi olup olamayacağını sorun. Bu tür bir süreçten, önünüzdeki bir bardağa (mecazi olarak konuşarak) işemelerini istemekten daha fazlasını öğreneceksiniz.
Eksileri: Yok. Bir PC kurmak, bir kod testi tasarlamak ve incelemek için harcadığınız her zaman, gelecekte açıklanamayan baş ağrısını kurtaracaktır.
Artıları: "Güven, ama doğrula" - Ronald Regan. Birçok kez insanları gördüm ve duydum, sonunda röportajda bir rock yıldızı aldığını düşündüğün bir pozisyondan ayrıldım. Kanıt, puding içerisindedir; Ne yapabileceklerini görmek istiyorum. Birini işe almak ve onlara yeni bir proje yapıştırmak için zaman ve para yatırdığınızda ne olacağını temsil edecektir.
Eksileri:
Artıları:
Mevcut işim için görüştüğümde, işe alan kişi tarafından kod yazmam için bir soru listesi verildi. Çok etkilendim çünkü sorular açıkça SQL hakkında derin bilgiye sahip biri tarafından yazıldı, bu yüzden her iki şekilde de çalışıyor.
Sen gerçekten röportajda kişi yazma koduna sahip istiyoruz - hatta daha iyi, (rahatça zaman / işgücü içinde göze neyse) zamanın X tutar için takımda bir üyesiyle çifti programına onları.
Bu kişinin kod yazıp yazamayacağını anlamanın tek yollarından biri.
Takım çalışmalarını göstereceği için çift programlamayı biraz tercih ediyorum, onlara çalışmak için gerçek bir IDE veriyor ve 'gerçek' bir problem üzerinde çalışmalarına izin veriyorum (çiftteki diğer kişi, görüşülen kişinin çevresel özelliklerin ötesinde onlara rehberlik edebilir) asla makul bir şekilde bilmiyordu).
Bu işe alım politikasını kullanmaya başladık ve sonuçlardan gerçekten memnunuz.
Bir kuşu tüyleriyle ve bir programcıyı koduyla değerlendirirsiniz.
Çalıştığım şirket ile başladığımda, bazı ikili girişin parite bitini üreten veya kontrol eden bazı kodlar yazmamı istediler (kodlama veya kod çözme işleminize bağlı olarak). Bu bir röportaj sorusuydu, çünkü bu tür sorunlar çalışma sırasında çözüldü. Tabii ki parite kontrolünü değil daha düşük düzeyde çalışmayı düşünüyorum.
Şimdiye kadarki tüm cevaplar (okuduğum) Joel Test'in girişimciler için en iyi uygulama listesi DEĞİL ( potansiyel bir işveren değerlendirmenizi kolaylaştırmak için bir kontrol listesi ) olduğu gerçeğini ele almamıştır .
Mesele şu ki ... eğer adaylarını iyice test ederlerse, muhtemelen eşyalarını bilen insanları işe alırlar ... bu senin için
peşinden gidermek yerine ...
Şöyle söylerdim:
Artıları
Eksileri
Reverseyöntem veya benzeri olduğunda veya yazılı testler için" sınıfın Fooyönteminin argümanları nelerdir "gibi şeyler Bar, herhangi bir aptal Google'ı kullanabilir veya belgeleri kullanabilirse), mimari / tasarım sorularının aksine aday işlerini yapabilir ve iş sorunlarını çözebilir .Bir profesyonel, birisinin programlama veya herhangi bir temel bilgiye sahip olduğunu gösteriyor (son karşılaştığımda, SQL sorununun ne kadar temel olduğuna şaşırdım). Aynı zamanda, adayın neden böyle bir şey yaptığını ve nasıl geliştirilebileceğini soran teknik bir tartışma için temel oluşturabilir.
Başka şeyler için kullanılabilecek olan röportajda zaman alır. Dahası, bir beyaz tahtaya kod yazmak doğal bir ortam değildir ve bazı insanlar onunla gittikçe daha az ciddi sorunlara sahip olacaktır. Normal araçlar veya referanslar olmadan gergin olan bir geliştiriciyi kaçırmanıza neden olabilir.
Programlama, bir grup net "çıktı" ile oldukça teknik bir beceridir. Bir aday onları teslim edebilir veya teslim edemez. Dolayısıyla teknik sorular sormanın bir "eksileri" yoktur. Tamamen, "bana bu uygulama için bazı kod göster, ya da" bana Zaten yazdığınız bir uygulamanın kodunu göster "demek için.
Bunu yapmamak aşağıdaki gibi bir sonuca yol açabilir: Zengin bir adam çocuklarına satranç oynamayı öğretmek için bir öğretmenle görüştü (zihin genişletici bir egzersiz olarak). Eğitmen bir damalı tahta açtı ve 64 kareden bahsetmeye başladı ama bir satranç parçasına dokunmadı. Zaman için bastırılan baba yine de öğretmeni tuttu. Ve öğretmen çocuklara CHECKERS oynamayı öğretti.