Apa pro dan kontra untuk majikan dari pertanyaan kode selama wawancara? [Tutup]
16
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?
Tulis kode seperti secara fisik tuliskan dengan pensil dan tangan Anda atau tulis seperti pada kode jenis di mesin?
Chris
Yang utama adalah mengajukan pertanyaan bodoh atau tidak berguna dan berpikir Anda melakukannya dengan benar. Seperti komentar seseorang tentang diminta untuk menulis linked_list.
Jawaban:
13
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.
Hmmm ... Saya menganggap diri saya sebagai pengembang yang berkualitas. Selama tiga wawancara terakhir saya, ketika saya ditanya tentang sesuatu seperti "apa yang dilakukan metode tertentu", atau hal serupa, saya memutuskan untuk menyerah. Karena saya tidak pernah mencari pekerjaan, di mana saya seharusnya melakukan sesuatu yang saya ketahui dengan baik. Itu tidak menarik. Seperti yang dikatakan mantan bos saya: "Programer yang dapat digunakan kembali harus dapat digunakan kembali, program - mungkin".
Duros
@duros Maaf mendengarnya. Pewawancara yang baik harus dapat membuat prosesnya menyenangkan .. dan harus menyadari bahwa programmer lain membenci tes.
Tim Post
Bukannya saya tidak merasa nyaman saat diuji. Saya baru menyadari peluang mana untuk belajar dan mencoba sesuatu yang baru yang akan saya miliki, jika mereka akan mempekerjakan saya sebagai pembuat kode ... Selama yang terakhir saya mengirim pewawancara untuk membaca javadocs ...: - / Mungkin, saya ' saya salah ...
duros
10
Saya pernah ditanya dalam sebuah wawancara untuk menulis aksesor untuk daftar tertaut di Perl. Dalam 8 tahun saya bekerja dengan Perl, saya belum menemukan satu pun program produksi yang menggunakan daftar tertaut. Tentu saja, saya mengacaukan dan menghasilkan, di atas kertas, memasukkan () dan menghapus () metode dan objek berbasis hash yang saya pikir akan melakukan pekerjaan itu. Hal pertama yang pewawancara katakan ketika dia melihat kertas itu adalah "Kamu kehilangan beberapa titik koma"
leed25d
1
itu lain untuk benar-benar menghasilkan kode - ini sangat, sangat, benar. Saya berulang kali terkejut oleh orang-orang yang menggambarkan algoritma yang masuk akal tetapi bahkan tidak bisa mulai menguranginya menjadi kode. Itu, atau mereka telah melakukan beberapa langkah non-algoritmik yang tidak dapat dihindari ketika Anda menulis kode.
poolie
34
Dengan permintaan maaf kepada Scott Whitlock:
Cons:
tidak ada
Pro:
Menghemat BANYAK waktu dan sakit hati di jalan jika Anda mencegah mempekerjakan seseorang yang tidak dapat memprogram
Membutuhkan Anda untuk memiliki orang teknis dalam wawancara
Dapatkah "mengharuskan Anda memiliki orang teknis dalam wawancara" dianggap penipu?
Yeikel
2
Itu tergantung jika Anda mencoba mengisi peran atau hanya mengisi kursi, saya kira. Tapi IMO tidak, itu tidak bisa dianggap sebagai penipu.
Armand
19
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.
+1 untuk tautan. Saya masih berpikir bahwa juggling tidak mengingat hal-hal seperti tanda tangan metode, atau yang serupa, tetapi hanya mampu berpikir dan memecahkan masalah yang belum pernah Anda temui sebelumnya ...
duros
4
Kecuali bahwa juggling adalah keterampilan langsung dengan hanya beberapa varian, sering dilakukan di depan penonton. Pemrograman adalah tugas yang berat dan mendalam, jarang dilakukan seperti itu. Ini juga jauh kurang produktif di atas kertas atau papan tulis. Yang mengatakan, tes kode semu (atau mengabaikan bug sedang sepele) bisa sangat berguna.
Bruce Alderson
10
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.
Tapi tidak apa-apa. Tujuan dari pertanyaan wawancara coding bukan untuk menguji kemampuan mengetik atau bahkan pengetahuan yang sempurna tentang API. Kesalahan ketik dan yang lainnya dapat diabaikan dan sebagai gantinya Anda fokus pada proses berpikir kandidat dan mengenal dasar-dasar pemrograman. Sebagai contoh, saya pernah menjadi bagian dari wawancara yang menunjukkan ketidakmampuan kandidat untuk berpikir beberapa langkah ke depan (mereka akan memperbaiki satu masalah kecil, menyadari bahwa menciptakan masalah lain, dll.).
Adam Lear
2
"Sulit untuk kode di depan orang lain"? Baik. Saya hanya mempekerjakan orang yang bisa melakukan hal-hal sulit. Salah satunya adalah dapat membahas kode (yaitu program) dengan (di depan) orang lain.
kevin cline
1
@kevin cline: Anda melewatkan poin saya. Apakah Anda peduli bagaimana orang mendapatkan hasil, atau Anda hanya ingin mereka mendapatkan hasil sesuai dengan keinginan Anda? Banyak orang dapat membuat kode dengan baik di lingkungan tim, tetapi membutuhkan "waktu sendiri" untuk menghasilkan efisiensi puncak. Anda terdengar seperti tipe pria yang tidak akan mempekerjakan Mark Zuckerberg karena dia perlu "terhubung" untuk produktivitas maksimum.
Robusto
1
@ Ragusto: Saya tidak mengajukan pertanyaan mendalam dalam sebuah wawancara. Saya hanya perlu melihat seseorang memecahkan masalah sederhana dalam beberapa menit. Dan saya butuh orang yang bisa bekerja dalam tim. Ini berarti kemampuan dan kemauan untuk berbicara tentang kode. Tentu, saya mungkin kehilangan programmer hebat yang tidak bisa menangani tekanan wawancara. Tidak apa-apa. Tapi upah yang buruk itu berbahaya.
kevin cline
6
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.
Jika Anda mewawancarai pengembang tanpa melibatkan orang-orang teknis, Anda pasti akan celaka.
David Thornley
@ David: Saya setuju, saya pikir pro di sini jauh lebih besar daripada kontra, tapi itu satu-satunya "penipu" yang bisa saya pikirkan.
Scott Whitlock
4
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.
+1 untuk pengujian pasangan: membuktikan kemampuan untuk bekerja dengan rekan satu tim / dan / kemampuan untuk kode.
Bruce Alderson
2
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
kurang sakit kepala dan juga
meningkatnya peluang untuk belajar sesuatu dari rekan kerja Anda
Menunjukkan calon memiliki setidaknya pengetahuan pemrograman yang lumayan, karena resume dapat dibuat / diperindah
Jika pewawancara membahas kode dengan kandidat, sebagai lawannya lebih seperti tes tertulis, bisa menjadi indikator yang baik tentang bagaimana Anda "menyatu" secara sosial dan jika kandidat tersebut cocok untuk perusahaan / perusahaan dan tim yang baik cocok untuk kandidat
Cons
Bisa menghina kandidat jika pertanyaannya adalah hafalan / sepele omong kosong yang tidak akan pernah muncul selama pekerjaan (misalnya "Menulis semacam gelembung" ketika semua kerangka kerja modern yang akan digunakan pada pekerjaan memiliki penyortiran bawaan, "Balikkan string" "ketika ada metode built-in 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 .
Saya pikir "Membalikkan string" adalah pertanyaan awal yang sangat baik dalam wawancara pengkodean. Jika mereka tidak tahu harus mulai dari mana (dan sejumlah besar orang tidak tahu), Anda mungkin tidak ingin mempekerjakan mereka. Jika mereka menggunakan metode bawaan, itu bagus - ini memberitahu Anda bahwa mereka tidak akan mencoba membuat roda sendiri jika disediakan - tetapi kemudian menyajikan situasi hipotetis di mana metode bawaan memiliki bug sehingga mereka perlu menulis sendiri. Anda kemudian dapat menggunakan kode mereka sebagai titik awal untuk mengajukan pertanyaan lain seperti cara memperbaiki bug, penggunaan memori, waktu berjalan, dll.
Gabe
0
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.
Yang akan lebih mengejutkan Anda adalah berapa banyak orang yang tidak bisa menjawab pertanyaan mendasar itu daripada siapa yang bisa.
HLGEM
0
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.
Itu hanya menunjukkan contoh pewawancara yang tidak kompeten, bukan keharusan untuk benar-benar bermain catur dalam sebuah wawancara. Orang kaya itu bisa saja bertanya 'jelaskan Castling' kepada saya, atau sesuatu yang serupa, dan segera mendapatkan gagasan tentang apa yang diketahui oleh tutor itu.
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.
sumber
Dengan permintaan maaf kepada Scott Whitlock:
Cons:
Pro:
sumber
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.
sumber
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.)
sumber
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.
sumber
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.
sumber
Cons:
Pro:
sumber
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.
sumber
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.
sumber
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.
sumber
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 ...
sumber
Saya akan mengatakan:
Pro
Cons
Reverseatau serupa, atau untuk tes tertulis hal-hal seperti" Apa argumen untukFoometodeBarkelas ", 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 .sumber
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.
sumber
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.
sumber