Apakah "White-Board-Coding" tidak sesuai selama wawancara? [Tutup]

Ini adalah pertanyaan yang agak subyektif tapi saya ingin mendengar umpan balik / pendapat dari salah satu pewawancara / orang yang diwawancarai tentang topik tersebut.

Kami membagi wawancara teknis kami menjadi 4 bagian. Tulis Kode, Baca & Analisis Kode, Sesi Desain & Kode di papan tulis.

Untuk bagian terakhir yang kami minta orang yang diwawancarai lakukan adalah menulis potongan kode kecil (4-5 baris) di papan tulis dan menjelaskan ketika mereka menjalaninya. Biar saya perjelas tujuannya bukan untuk menangkap orang. Kami tidak mencari sintaks yang sempurna. Sialan itu bahkan bisa berupa pseudo-code. tetapi intinya adalah memberi mereka masalah yang sangat sederhana dan melihat apakah otak mereka dapat mengkomunikasikan solusinya kepada kita. Dengan masalah sederhana yang saya maksud "Membalikkan string", "FizzBuzz" dll ...

Perhatikan bahwa kami selalu meminta bahasa eksplisit terlebih dahulu. Kami adalah .NET C # house. kami hanya mengatakan "pseudo-code" di mana seseorang telah blanking / benar-benar berjuang dengan kode tersebut.

Pertanyaan saya adalah "Apakah tidak pantas / tidak masuk akal untuk mengharapkan seorang programmer untuk menulis potongan kode di papan tulis selama wawancara?"

Menurut saya, ini sangat tepat. Jika Anda menginginkan pekerjaan untuk melakukan keterampilan tertentu, maka sangat tepat untuk diharapkan menunjukkan keterampilan itu saat wawancara.

Efek teknik ini pada proses rekrutmen sangat terlihat. 90% kandidat gagal dalam tugas ini. tetapi pengembang yang direkrut baik, dan pengembang akan dihormati di dalam perusahaan.

Jika sebagai kandidat menghadapi teknik ini, pertama-tama rileks. Ini tentang menilai Anda sebagai seorang programmer dan proses pemikiran Anda. Ini bukan tentang sintaksis sempurna Anda. Jika Anda membuat kesalahan sintaks maka saya mungkin memainkan peran kompiler dan memberi tahu Anda bahwa kode gagal dikompilasi pada baris tertentu, dan memberi Anda pesan kesalahan, dan melihat bagaimana Anda merespons. Begitu juga jika Anda menambahkan; ke loop atau pernyataan if yang akan dikompilasi, saya akan memainkan debugger dan berbicara Anda melalui satu langkah melalui kode. Sekali lagi, ini bukan tentang kesalahan, ini tentang bagaimana Anda akan mengatasi kesalahan, dan apakah proses berpikir Anda baik.

Pertanyaan saya adalah "Apakah tidak pantas / tidak masuk akal untuk mengharapkan seorang programmer untuk menulis potongan kode di papan tulis selama wawancara?"

Sangat masuk akal. Alternatif untuk papan tulis bisa berupa laptop dan beamer, karena programmer lebih terbiasa menulis kode pada keyboard daripada pada papan tulis. Pastikan saja lingkungan pengembangan seperti Eclipse atau VS atau Idle sudah berjalan dengan proyek kosong ketika kandidat mulai, jadi dia tidak perlu membuang waktu mencari melalui aplikasi yang diinstal.

Ini tidak pantas, tetapi ketahuilah bahwa itu TIDAK selalu mengungkapkan wawasan yang sebenarnya tentang kemampuan pemrograman atau pemecahan masalah dari orang yang Anda wawancarai. Dan saya kira itulah yang Anda cari.

Kedua, perhatikan bahwa selalu ada rasa takut akan kegagalan, terus-menerus menjelekkan otak orang itu. "Bagaimana jika saya mengacau?", "Bagaimana jika saya melakukan kesalahan konyol". Bagian yang lebih besar dari otak seseorang sibuk terus-menerus memeriksa bagaimana mereka keluar - hanya sedikit yang bisa menahan saraf.

Jadi, dalam situasi seperti ini, bahkan yang terbaik sekalipun mungkin akan goyah.

Untuk bagian terakhir yang kami minta diwawancarai lakukan adalah menulis potongan kode kecil (4-5 baris) di papan tulis dan menjelaskan ketika mereka melewatinya

Tidak apa-apa. Tetapi sekali lagi, hanya karena seseorang tidak dapat menjelaskan sesuatu dengan baik tidak berarti mereka tidak mengetahuinya dengan baik. (Penjelasan adalah seni berbicara).

Jika saya jadi Anda, saya akan melakukan ini Untuk bagian terakhir ...

Pekerjakan mereka untuk proyek yang sangat kecil (tapi realistis). Lihat bagaimana mereka membuat kode, mengambil keputusan, mengasimilasi kondisi kerja dan anggota tim, dll., Dan kemudian berdasarkan itu, buat keputusan akhir.

Bukan tidak pantas, tetapi ingat bahwa beberapa orang (dan mungkin bagian yang lebih besar dari kerumunan programmer) dapat sangat tertekan dalam sebuah wawancara. Saya pikir sebagian besar dari kita mengenal pria dari kantor yang merupakan pembuat kode yang brilian dan orang yang sangat dapat dipercaya, tetapi dia akan luluh dalam situasi seperti itu. Penampilannya tidak bisa diukur dalam tes seperti itu, jadi jangan lakukan ini sebagai tes go / no go.

Saya pribadi berpikir bahwa ini adalah salah satu hal terbaik yang dapat Anda lakukan. Seperti yang Anda katakan Anda tidak mencari sintaks yang benar atau sesuatu yang serupa, bagian terpenting di sini adalah untuk melihat apakah seseorang dapat berkomunikasi ... Saya telah melihat begitu banyak pengembang yang baik yang hanya dapat bekerja sendiri di dalam ruang mereka sendiri ... Sayangnya ini tidak mungkin dalam jumlah besar kasus sehingga memiliki orang yang terampil yang juga mampu MENGATAKAN apa yang dia pikirkan dengan cara yang jelas dan ringkas adalah anggota tim yang lebih berharga daripada seseorang yang berpikir: "Mereka tidak akan memahaminya Lagi pula, saya akan melakukannya sendiri dan menunjukkannya nanti ".

Komunikasi, komunikasi, komunikasi adalah sesuatu yang merupakan dasar dari setiap proyek berukuran sedang hingga besar (bahkan lebih kecil jika membutuhkannya)

Saya pikir itu bukan hal yang masuk akal. Kami mencoba mencari kandidat, yang bagus dalam tugas yang kami inginkan. Menulis kode di papan tulis bukan salah satunya dan saya pikir itu bukan filter yang valid untuk menemukan kandidat yang baik.

• Kode yang baik tidak ditulis, melainkan ditulis ulang. Papan tulis cukup abadi, karena sulit untuk berubah setelah Anda menulisnya. Seharusnya semudah mungkin untuk mengubah pikiran Anda segera setelah Anda memahami masalahnya dengan lebih baik.
• Berada dalam sebuah wawancara adalah situasi yang menegangkan, tidak perlu memberikan tekanan tambahan pada kandidat. Banyak orang komputer tidak memiliki tulisan tangan yang baik. IDE modern menyediakan banyak alat yang biasa Anda gunakan. Dan dapat mencari sesuatu di Google begitu Anda membutuhkannya juga merupakan bagian dari gaya kerja kebanyakan programmer. Mengapa mengambil semua hal ini dan menciptakan lingkungan buatan, bahwa mereka tidak akan pernah harus bekerja jika Anda mengajukan penawaran?
• Kami juga sangat tertarik dengan kemampuan untuk menulis tes yang baik, bahkan mungkin melakukan TDD. Ini tidak mungkin dilihat selama pengkodean papan tulis.

Sebagian besar petunjuk bahwa Anda bisa keluar dari sesi pengkodean papan tulis Anda juga bisa keluar dari sesi pemasangan - Dan saya percaya, pemasangan adalah alat yang jauh lebih baik untuk mendapatkan perasaan, bagaimana seorang kandidat memecahkan masalah dan cara kerjanya. Dia dapat membawa komputernya sendiri dan bekerja di lingkungan yang nyaman baginya. Dan itu jauh lebih mudah untuk diterapkan pada tugas yang Anda ingin mereka lakukan begitu mereka bergabung. Kami misalnya memiliki basis kode warisan yang besar, jadi kami meminta mereka untuk memperbaiki beberapa kode yang diekstraksi untuk proyek nyata. Dan kami benar-benar berpasangan sebanyak mungkin dalam pekerjaan sehari-hari kami, jadi sangat cocok.

Sementara sesi papan tulis mungkin membantu untuk menyaring kandidat yang buruk, itu mungkin juga menyaring banyak programmer yang baik.

Secara pribadi, saya akan meninggalkan pewawancara yang meminta saya melakukan FizzBuzz. Saya tidak tahu kapan ini menjadi standar industri baru, tetapi ini benar-benar buang-buang waktu. FizzBuzz adalah filter yang dapat digunakan sebelum wawancara, meskipun secara pribadi saya pikir jika saya harus memilih dari N kandidat yang cukup memiliki beberapa kode sumber terbuka atau blog yang dapat saya lihat, saya pasti lebih suka itu sebagai filter .

Sederhananya, saya pikir dalam wawancara untuk posisi pemrograman (kecuali mungkin untuk junior atau magang), seharusnya sudah ditetapkan / ditentukan bahwa orang yang diwawancara dapat memprogram.

Tapi ya, papan tulis sempurna, meskipun saya pikir Anda harus mengambil serangkaian masalah yang berbeda. Lemparkan mereka masalah dunia nyata dan minta mereka menggambar percekcokan UML-ish untuk menjelaskan strategi keseluruhan mereka untuk menyelesaikan masalah itu. Beri mereka komputer dengan internet, sehingga mereka dapat mencari perpustakaan pihak ketiga yang bisa mereka gunakan sebagai kotak hitam di squibblescape mereka.
Dalam beberapa menit, Anda akan benar-benar melihat bagaimana mereka mengatasi masalah. Anda benar-benar dapat menjadikan ini hal yang sangat menarik, dengan memilih masalah yang belum tentu Anda miliki solusinya dan berusaha untuk "menyelesaikannya" bersama-sama, untuk melihat seberapa baik mereka berkomunikasi dan seberapa baik mereka dapat memasukkan input (namun tidak akan mendorong mereka terlalu keras - beberapa orang mungkin akan membeku jika Anda melakukannya). Dan kemudian tambahkan beberapa persyaratan dengan cepat. Ini semacam pengembangan perangkat lunak seperti tanpa implementasi dan - yang paling penting - tanpa debugging, jadi 15 menit adalah waktu yang banyak.

Izinkan saya menjawab dengan pertanyaan lain:

Apakah menulis kode pada papan tulis menawarkan keuntungan nyata dalam menilai kemampuan pemrograman, dibandingkan dengan mengetik dan mengeksekusi kode pada komputer?

Saya pikir sangat tepat untuk meminta seorang kandidat untuk menulis kode dalam sebuah wawancara. Namun, bagi saya, dapat mengeksekusi kode adalah bagian penting dari loop umpan balik yang membentuk pemrograman. Di papan tulis, Anda mengikat satu tangan di belakang, dan Anda tidak mendapatkan gambaran lengkap tentang cara saya mengatasi masalah.

Tidak, tetapi IMO pendekatan yang lebih baik adalah dengan menggunakan papan tulis untuk tujuan yang dimaksudkan dan menggunakan UML / sketsa / catatan untuk beberapa proyek fiktif, daripada yang lama "tulis saya kueri sql untuk mendapatkan semua catatan" atau "tulis metode yang membalik sebuah string ".

Salah satu wawancara terbaik yang saya miliki adalah menghabiskan waktu 20 menit untuk berdiskusi dengan pengembang utama arsitektur (non-software) untuk rumah ilmuwan gila (lengkap dengan tempat persembunyian rahasia, sinar kematian dan kandang anjing). Dia harus melihat pendekatan saya dalam memecahkan masalah, dan masalahnya adalah sesuatu yang menyenangkan bukan pemrograman hafalan tipikal 101 hal yang telah dipecahkan oleh bahasa modern ribuan kali lipat. Kebetulan saya juga melakukan sepotong kode seperti ini sebelumnya, tetapi saya merasa jauh lebih "di bawah tekanan" daripada dengan bagian arsitektur.

Saat ini, banyak pemrograman dilakukan dalam tim. Agar tim dapat bekerja, orang harus dapat berkomunikasi. Sebagian besar dari ini adalah mampu berkomunikasi di depan papan tulis (brainstorming, mentoring, ulasan kode perbaikan yang diusulkan, dll.)

Saya akan mencari apakah kandidat menjelaskan cara mencari solusi untuk masalah pemrograman menggunakan kode papan tulis untuk membantu. Jika penjelasannya cukup baik, programmer lain yang baik di dalam ruangan akan secara otomatis mengoreksi kesalahan ketik / kesalahan di papan tulis.

Untuk sebagian besar jenis posisi tim, tidak masuk akal untuk TIDAK mengharapkan seorang kandidat untuk dapat menjelaskan dan menuliskan upaya mereka pada solusi.

Tidak, itu adalah hal yang baik untuk kode untuk wawancara, tetapi Anda harus mengizinkan kode dalam bahasa yang masuk akal karena biasanya lebih mudah untuk melatih seorang pengkode yang kompeten dalam bahasa lain daripada mendapatkan kode yang begitu-begitu dalam bahasa yang Anda inginkan, naik ke tingkat yang kompeten.

Saya akan mengatakan itu tepat, tetapi dalam banyak kasus itu bukan cara yang efisien untuk mengetahui siapa yang baik dalam pemrograman dan siapa yang tidak. Jika Anda ingin pekerjaan dilakukan (= merekrut seseorang yang mampu), maka wawancara harus fokus pada pengukuran keterampilan kehidupan nyata. Sejauh ini wawancara terbaik yang pernah saya lakukan seperti ini:

• Salam, selamat datang oleh HR.
• Beberapa kata tentang saya, tentang perusahaan, dll ... dan dia menjelaskan sisa wawancara.
• Dia memberi saya laptop dengan program yang melewatkan beberapa bagian, gagal dalam tes unit karena itu. Bagian-bagian yang hilang dikomentari di sana sebagai teks, itu tentang mengimplementasikan tugas dasar, seperti membuat koneksi antara beberapa kelas, dan memperkenalkan logika bisnis sederhana.
• Jika semuanya berjalan dengan baik, unit test menjadi hijau.
• Ucapkan selamat tinggal, dan persetujuan untuk kembali dalam beberapa hari.
• Pada hari itu pemimpin bertemu dengan saya, dan bertanya tentang program yang sudah selesai, apa yang saya lakukan, dan mengapa.
• Pemimpin ini juga bertanya tentang pengalaman masa lalu saya, dan beberapa pertanyaan lainnya.

Jadi, ringkasnya: jika Anda mencari tenaga kerja ke dalam kode produksi, uji keterampilan mereka di lingkungan nyata. Jika Anda ingin tahu tentang pengetahuan teoretis mereka, lebih baik bertanya kepada mereka tentang hal-hal ini. Jika Anda dilucuti dari IDE, atau Anda gugup karena Anda harus memprogram di papan tulis di depan seseorang, saya bisa mengerti, terutama di TI orang kadang-kadang tertutup dan banyak dari kita tidak bisa menangani situasi ini dengan baik, jadi putih papan efisiensi kita akan terlihat lebih buruk daripada yang sebenarnya.

Saya tidak menganggapnya tidak masuk akal kecuali orang yang diwawancarai memiliki tulisan tangan yang buruk (atau saya harus mengatakan tulisan tangan) :-). Selain itu satu-satunya perbedaan dalam pendekatan Anda adalah penggunaan papan dan spidol. Dalam beberapa kasus pewawancara melakukan hal ini tetapi mereka memberikan kertas dan pena sebagai gantinya. Jika ada 3-4 orang yang melakukan wawancara, saya akan mengatakan pendekatan Anda akan jauh lebih baik dan cocok.