Pertanyaan Tes Joel # 11 adalah: "Apakah kandidat baru menulis kode selama wawancara mereka?". Apa argumen untuk dan menentang untuk meminta kandidat baru untuk menulis kode selama wawancara dan untuk membuat keputusan?
Jawaban:
Saya tidak melihat kontra. Wawancara memiliki banyak bagian, dan seorang kandidat harus disahkan 'naik rantai' beberapa kali.
Saya mewawancarai ~ 10 orang setiap minggu. Saya benar-benar, BENAR-BENAR menghargai kenyataan bahwa HR telah melakukan semua pekerjaan latar belakang dan memberi saya banyak catatan. Pada saat mereka sampai pada saya, sudah waktunya bagi saya untuk menilai tes mereka.
Tes sepenuhnya tergantung pada posisi. Secara umum, saya mencoba menyelidiki:
Keterampilan pemrograman umum. Bisakah Anda menggunakan operator secara efektif? Bisakah Anda membayangkan sistem numerik yang memiliki radix yang bukan 10?
Apakah Anda tahu bagaimana melakukan apa yang kami rekrut untuk Anda lakukan?
Evaluasi kontribusi Anda ke proyek sumber terbuka apa pun yang Anda daftarkan
Saya mencoba membuatnya singkat, dan menyenangkan. Ketika saya pergi ke kantor, saya mengambil jawabannya, memeriksa dan kemudian melakukan wawancara sekunder. Untuk dipekerjakan, Anda biasanya harus melalui tiga wawancara.
Saya juga mengukur seberapa baik Anda akan berbaur dengan tim yang akan menerima Anda. Tim itu mengandalkan saya untuk melakukannya secara efektif.
Adalah satu hal untuk menjawab pertanyaan dalam bentuk meta, itu adalah hal lain untuk benar-benar menghasilkan kode. Jika saya akan mempekerjakan Anda, saya benar-benar perlu melihat Anda menghasilkan kode.
Dengan permintaan maaf kepada Scott Whitlock:
Cons:
Pro:
Jika Anda akan menyewa seorang pemain sulap, Anda akan menjadi gila untuk tidak memilikinya menyulap untuk Anda. Atau seorang musisi Anda akan memiliki audisi. Kalau tidak, Anda mendapatkan hal-hal seperti K-strass yo-yo yang mengagumkan .
Berjalan melalui sesuatu di papan tulis adalah programer yang setara dengan juggle demo cepat.
Saya pikir ini sangat berguna, dan saya selalu melakukannya, tetapi karena manfaatnya telah tercakup dengan baik, saya akan membahas hanya yang (nampak) negatif.
Saya pikir tes kode tidak mungkin memberikan Anda positif palsu: kemungkinan rendah bahwa seseorang yang benar-benar tidak dapat menulis kode akan memalsukannya dalam sebuah wawancara, setidaknya jika Anda memiliki skala pertanyaan yang semakin sulit. (Mungkin skenario yang paling mungkin adalah mereka berselingkuh dengan bertanya kepada seorang teman, jika itu bukan wawancara tatap muka.)
Masalahnya lebih pada sisi negatif-palsu: akankah tes kode mengarahkan Anda untuk menolak orang yang sebenarnya kandidat terbaik?
Panggung demam
Anda mungkin memiliki seseorang yang sebenarnya adalah pengembang yang sangat baik, tetapi yang sangat gugup tentang wawancara ini, dan mereka pada dasarnya mengalami demam panggung. Berkinerja di bawah tekanan adalah penting sampai batas tertentu, tetapi menangani demam panggung bukanlah bagian penting dari menjadi seorang programmer (dibandingkan dengan profesi lain), dan akan sangat disayangkan untuk menolak seseorang yang menderita parah karenanya. Ini bisa bertambah: jika orang itu tidak dapat menjawab pertanyaan yang mereka tahu harus mereka jawab, mereka mungkin akan lebih tegang. Atau, seperti dalam pertanyaan ini , mereka merasa tidak dapat berbicara dan kode pada saat yang sama.
mitigasi: Mulailah dengan beberapa pertanyaan mengenal Anda tentang latar belakang, tujuan, dll, sebelum Anda beralih ke pertanyaan teknis. Mungkin mulai dengan beberapa pertanyaan teknis yang lebih mudah sehingga mereka mendapatkan momentum. Jangan menjadi kontol selama wawancara (kebawelan tentang titik koma dll).
Ini ukuran yang berisik
Pertanyaan kode yang menarik mungkin memiliki lebih dari satu jawaban yang benar. Jika satu orang menulis jawaban yang benar, dan yang lain menulis jawaban yang benar dan lebih efisien, berapa banyak bobot yang harus Anda masukkan pada itu?
Untuk beberapa hal, ini seperti masalah dengan beberapa pertanyaan "puzzle": orang tersebut memiliki wawasan atau tidak dan Anda mendapatkan hasil yang hampir biner. Kecerdasan mungkin memengaruhi kemungkinan memiliki wawasan itu, tetapi sampel hanya beberapa kali memberi Anda ukuran kasar.
Ini menggangguku tentang pertanyaan kode (meskipun saya masih menggunakannya.) Mitigasi terbaik yang dapat saya pikirkan adalah sebanyak mungkin memiliki jalan keluar dari solusi yang mungkin: orang itu setidaknya dapat menulis jawaban kasar, atau jawaban untuk bagian dari masalah. Menyadari itu lebih baik daripada tidak sama sekali adalah pertanda baik. Kemudian jika mereka menemukan lebih banyak, mereka dapat membuatnya menjadi kode yang lebih efisien atau lebih elegan. Sebisa mungkin, hindari mengajukan pertanyaan yang mendapat respons biner.
Itu tidak benar-benar representatif
Pemrograman bukan pekerjaan memecahkan masalah algoritme sepuluh menit satu demi satu: ada banyak pekerjaan lebih banyak tentang memahami dan merancang sistem yang lebih besar dan berkonsentrasi untuk periode waktu yang lama, untuk mengatakan keterampilan interpersonal. Pertanyaan kode tidak benar-benar menguji ini.
Tetapi, pertanyaan kode bukan satu-satunya pertanyaan yang akan Anda tanyakan: Anda dapat melihat latar belakang mereka, referensi mereka, pekerjaan open source mereka (jika ada), untuk menemukan bukti upaya berkelanjutan, kreativitas, keterampilan interpersonal.
Mengetahui bagaimana menyelesaikan masalah algoritmik kecil dan cara menguranginya menjadi kode adalah syarat yang perlu tetapi tidak mencukupi: jika Anda tidak dapat memecahkan masalah kecil dan Anda tidak dapat menulis kode nontrivial maka semua pemikiran gambaran besar di dunia tidak akan membuat Anda menjadi pengembang yang produktif.
Siapa saja bisa menyelesaikannya
Tidak, sepertinya tidak. Seperti yang ditunjukkan oleh pos FizzBuzz yang terkenal , masalah yang mungkin Anda pikirkan adalah jebakan sepele bukan hanya lulusan baru tetapi orang-orang dengan pengalaman industri selama bertahun-tahun. Saya tidak tahu kenapa. Entah tes kode adalah ukuran yang buruk (yang mungkin, meskipun saya pikir itu tidak mungkin), atau mereka tidak berkontribusi banyak untuk proyek pada resume mereka, atau mereka mendapatkan banyak dilakukan dengan menyalin dan menempelkan non- kode algoritmik (yang dimungkinkan.)
Perlu diakui bahwa Anda benar-benar dapat menyelesaikan banyak hal tanpa menulis kode algoritme apa pun. Orang-orang menghasilkan banyak uang pada aplikasi yang nilainya ada di grafik atau logika bisnis tidak dalam apa yang Anda sebut "pemrograman", dan itu bagus. Tetapi, jika Anda benar-benar membutuhkan programmer, itu tidak cocok.
Mungkin tidak dikalibrasi dengan baik
Jika Anda mengajukan pertanyaan, jawabannya mungkin sangat mudah bagi Anda. Namun, jika Anda mengajukan pertanyaan yang dapat dibandingkan secara tiba-tiba, atau pertanyaan yang tidak condong ke minat dan latar belakang khusus Anda sendiri, itu mungkin jauh lebih sulit.
mitigasi: Jalankan tes pada beberapa pengembang yang sudah Anda kenal, dan lihat bagaimana mereka melakukannya. Mungkin seseorang yang sudah ada di tim Anda, yang Anda kenal sangat cerdas, akan mengalami masalah dengan salah satu dari mereka dan Anda dapat mempertimbangkan untuk menyesuaikannya. Mungkin mereka akan memikirkan jawaban yang lebih baik atau berbeda.
Ini terlalu mirip hal-hal sepele
Saya pikir pertanyaan kode pasti bisa masuk ke hal-hal sepele, jika Anda bersikeras orang tahu API tidak jelas, atau mendapatkan sintaks yang sempurna, atau ingat definisi yang tepat dari algoritma nontrivial. Itu semua masuk akal untuk mengandalkan dokumen, pencarian web, atau kesalahan penyusun untuk mengambil, dan memiliki sedikit korelasi dengan keahlian nyata. Bahkan tidak tahu di mana kemungkinan API berada mungkin merupakan petunjuk bahwa orang tersebut belum menggunakannya baru-baru ini, tapi itu tidak selalu menjadi masalah selama mereka tidak berbohong pada resume mereka.
Jadi jawabannya sangat sederhana: jangan ajukan pertanyaan sepele dan jangan terpaku pada kesalahan sepele. Ingatkan kandidat apa yang disebut API atau biarkan mereka mencarinya; memperbaiki kesalahan sintaksis; jangan menguji orang yang menghafal definisi struktur data.
Bagaimana Anda membandingkan?
Jika Anda memiliki dua kandidat dan keduanya menjawab pertanyaan dengan baik, bagaimana Anda memilih di antara mereka? Anda bisa memilih orang yang selesai paling cepat, tetapi mungkin di sana Anda mulai memilih kelinci daripada kura-kura. Anda dapat melakukan putaran lain dan mengajukan pertanyaan yang jauh lebih sulit, tetapi saya juga tidak yakin tentang itu. Mungkin Anda hanya memberi mereka A + dan mencoba untuk memilih di antara mereka pada kriteria lain (atau mencoba mencari uang untuk menyewa keduanya.)
Satu con saya dapat pikirkan adalah bahwa sulit untuk "kode keras" di depan orang lain. Saya merasa sulit bahkan untuk mengetik dengan seseorang yang melihat ke belakang, dan saya tidak sendirian. Saya perhatikan ketika seseorang memanggil saya ke stasiun kerja mereka untuk membantu sesuatu, mereka tiba-tiba mulai membuat kesalahan ketik, memilih penyelesaian kode yang salah, bahkan membuat kesalahan yang benar - tidak ada yang akan mereka lakukan seandainya saya tidak duduk di sana. Sial, saya telah melihat orang-orang mulai menggunakan menu untuk operasi cut & paste, hanya karena mereka sedang diamati. Ini bukan perilaku normal, dan coders yang saya bicarakan adalah programmer yang sangat baik dan cukup pintar.
Saya baru-baru ini melakukan wawancara di mana pewawancara bertanya kepada saya bagaimana saya akan kode operasi tertentu dan dia berkata, "Tunjukkan saja matematika." Yah, saya harus memikirkan masalah terlebih dahulu sebelum membahasnya, sehingga saya harus bersusah payah. Apa yang saya letakkan di papan tulis pada mulanya memalukan, dan saya merasa saya kalah pada saat itu. Saya akhirnya mendapat saat A-ha dan menemukan jawaban (sebenarnya ketika akhirnya terjadi kepada saya apa yang dia benar-benar bertanya), tetapi "berantakan" Saya dibuat sebelum aku sampai di sana membuat saya merasa sangat tidak nyaman. Meskipun demikian, saya mendapatkan pekerjaan itu, tetapi jika pewawancara kurang sabar, saya mungkin tidak akan melakukannya.
Saya pikir jika Anda memberi tugas coding kepada orang yang diwawancarai, beri mereka waktu sendirian untuk menyelesaikannya di komputer, mungkin bahkan dalam IDE yang mereka kenal. Biarkan mereka menulis kode untuk Anda dan kemudian membicarakannya. Tanyakan kepada mereka mengapa mereka melakukan sesuatu dengan cara tertentu, dan apakah cara lain mungkin tidak lebih baik. Anda akan menemukan lebih banyak dari proses semacam itu daripada meminta mereka untuk (secara kiasan) buang air kecil ke dalam cangkir tepat di depan Anda.
Cons: Tidak Ada. Setiap kali Anda menghabiskan pengaturan PC, merancang tes kode, dan meninjaunya akan menghemat sakit kepala yang tak terhitung di masa depan.
Pro: "Percaya, tapi verifikasi" - Ronald Regan. Berkali-kali saya melihat dan mendengar orang akhirnya melepaskan posisi, di mana dalam wawancara Anda akan berpikir Anda mendapatkan bintang rock. Buktinya ada di puding; Saya ingin melihat apa yang bisa mereka lakukan. Ini akan mewakili apa yang terjadi setelah Anda menginvestasikan waktu dan uang untuk merekrut seseorang dan menempelkan proyek baru di depan mereka.
Cons:
Pro:
Ketika saya mewawancarai untuk pekerjaan saya saat ini, saya diberi daftar pertanyaan untuk menulis kode oleh perekrut. Saya sangat terkesan karena pertanyaan-pertanyaan itu jelas ditulis oleh seseorang yang memiliki pengetahuan mendalam tentang SQL, jadi itu bekerja dua arah.
Anda benar - benar ingin orang tersebut menulis kode dalam wawancara - bahkan lebih baik, buat mereka untuk memasangkan program dengan anggota dalam tim Anda untuk jumlah waktu X (apa pun yang Anda mampu dengan nyaman dalam waktu / tenaga).
Ini cukup banyak satu-satunya cara Anda dapat mengetahui apakah orang itu dapat kode atau tidak.
Saya sedikit lebih suka pemrograman pasangan karena ini akan menunjukkan kerja tim mereka, memberi mereka IDE nyata untuk bekerja dengan dan memungkinkan mereka bekerja pada masalah 'nyata' (orang lain dalam pasangan dapat memandu mereka melewati setiap spesifik lingkungan yang diwawancarai tidak akan pernah tahu tentang).
Kami sudah mulai menggunakan kebijakan perekrutan ini dan kami sangat senang dengan hasilnya.
Anda menilai seekor burung dari bulunya dan programmer dengan kodenya.
Ketika saya mulai dengan perusahaan saat ini saya sedang bekerja untuk mereka meminta saya untuk menulis beberapa kode C yang menghasilkan atau memeriksa bit paritas dari beberapa input biner (tergantung pada apakah Anda sedang encoding atau decoding). Ini adalah pertanyaan wawancara persis karena masalah-masalah semacam ini diselesaikan selama bekerja. Tentu saja saya berpikir untuk tidak mengecek paritas tetapi bekerja pada level rendah.
Semua jawaban sejauh ini (yang saya baca) tidak membahas fakta bahwa Tes Joel BUKAN (hanya) daftar praktik terbaik untuk pengusaha tetapi daftar periksa untuk memudahkan evaluasi Anda terhadap calon majikan .
Masalahnya adalah ... jika mereka benar-benar menguji calon mereka maka mereka mungkin mempekerjakan orang yang tahu barang-barang mereka ... itu berarti bagi Anda
bukannya memperbaiki bug setelah mereka ...
Saya akan mengatakan:
Pro
Cons
Reverseatau serupa, atau untuk tes tertulis hal-hal seperti" Apa argumen untuk Foometode Barkelas ", ketika ada orang idiot yang bisa Google atau menggunakan dokumentasi) yang bertentangan dengan pertanyaan arsitektur / desain yang menunjukkan kandidat dapat menyelesaikan sesuatu dan memecahkan masalah bisnis .Satu pro adalah bahwa itu menunjukkan bahwa seseorang memang memiliki pengetahuan dasar pemrograman atau apa pun (terakhir kali saya temui itu, saya terkejut betapa mendasarnya pertanyaan SQL itu). Ini juga dapat berfungsi sebagai dasar untuk diskusi teknis, menanyakan mengapa kandidat melakukan ini dan itu, dan bagaimana hal itu dapat ditingkatkan.
Memang butuh waktu dalam wawancara, yang bisa digunakan untuk hal lain. Terlebih lagi, menulis kode pada papan tulis bukanlah lingkungan alami, dan beberapa orang akan memiliki masalah yang semakin serius. Ini dapat menyebabkan Anda kehilangan pengembang yang baru saja gugup tanpa alat atau referensi normal.
Pemrograman adalah keterampilan yang sangat teknis dengan banyak "hasil." Entah seorang kandidat dapat atau tidak dapat mengirimkannya. Jadi tidak ada "kontra" untuk mengajukan pertanyaan teknis. Ini sepenuhnya untuk mengatakan, "tunjukkan saya beberapa kode untuk aplikasi ini, atau" tunjukkan kode untuk aplikasi yang sudah Anda tulis. "
TIDAK melakukan hal itu dapat mengakibatkan hasil seperti berikut: Seorang pria kaya mewawancarai guru les untuk mengajar anak-anaknya bermain catur (sebagai latihan yang mengembangkan pikiran). Guru les membuka papan kotak-kotak dan mulai berbicara tentang 64 kotak tetapi tidak menyentuh sepotong catur. Ditekan untuk waktu, sang ayah tetap menyewa tutor. Dan guru mengajari anak-anak bermain CHECKERS.