Berapa banyak bantuan yang harus saya berikan selama wawancara teknis? [Tutup]

Saya diminta untuk tampil atau duduk selama banyak wawancara teknis. Kami mengajukan pertanyaan logis dan masalah pemrograman sederhana yang diharapkan dapat diselesaikan oleh orang yang diwawancarai di atas kertas. (Saya lebih suka mereka memiliki akses ke keyboard, tapi itu masalah untuk lain waktu.) Kadang-kadang saya merasa bahwa orang tahu cara mendekati masalah, tetapi mereka digantung oleh kegugupan atau menebak pertanyaan kedua ( mereka tidak dimaksudkan untuk menjadi pertanyaan jebakan).

Saya tidak pernah mendengar atasan saya memberikan bantuan atau petunjuk. Dia hanya berterima kasih kepada orang yang diwawancarai atas tanggapannya (tidak peduli seberapa baik atau buruknya) dan beralih ke pertanyaan atau masalah berikutnya. Tetapi saya tahu sesuatu tentang lubang kelinci yang bisa membuat Anda kalah dan gugup, dan bagaimana hal itu melumpuhkan pikiran Anda, dan saya tidak bisa berhenti bertanya-tanya apakah memberikan sedikit bantuan sekarang dan kemudian pada akhirnya akan membantu kami berakhir dengan programmer yang lebih cakap. lebih banyak wawancara yang gagal.

Haruskah saya memberikan petunjuk dan bantuan untuk orang yang diwawancarai yang kebingungan (dan jika demikian, sejauh mana saya harus pergi sementara masih bersikap adil kepada kandidat yang lebih siap)?

Ketika saya berada di posisi yang sama, saya akan mengatakan kepada orang yang diwawancarai: "Berpura-puralah aku Google. Jika Anda perlu mencari sesuatu, katakan saja."

Dalam satu pertanyaan, orang yang diwawancarai harus bisa mengetahui volume sebuah silinder, jadi saya tidak keberatan jika seseorang berkata, "Saya harus ke Google untuk formula untuk volume silinder." Saya tertarik mengetahui apakah mereka tahu cara menyerang masalah, bukan jika mereka menghafal formula. Untuk pekerjaan itu, mereka harus memiliki pemahaman yang baik tentang bagaimana menerjemahkan dunia nyata ke dalam perangkat lunak, jadi itu adalah konsep yang penting.

Di sisi lain saya tidak akan memberi tahu mereka bahwa mereka membutuhkan formula itu.

Anda benar bahwa saraf bisa menjadi masalah, tetapi saya masih berharap orang dapat mengekspresikan proses pemikiran mereka, bahkan jika mereka gugup. Tidak memberikan jawaban tidak bisa diterima.

Anda memiliki dua pendekatan yang berfungsi baik untuk pemecahan masalah dan pertanyaan teknis pendek:

1. Yang pertama digunakan oleh bos Anda: jangan memberikan bantuan apa pun untuk menguji bagaimana orang tersebut berperilaku dalam konteks yang penuh tekanan. Ini adalah pendekatan yang benar-benar valid, dan dapat memberikan beberapa petunjuk tentang orang tersebut. Lagi pula, begitu Anda merekrut orang ini, dia tidak akan dapat menerima bantuan terus-menerus dari semua rekannya.

2. Yang kedua adalah memberikan petunjuk dan dukungan. Tingkat dukungan tidak terlalu penting; satu-satunya hal yang penting adalah bahwa semakin banyak bantuan yang Anda berikan kepada orang tersebut, semakin sedikit Anda harus menghargai kesuksesannya.

Secara pribadi, saya percaya bahwa Anda harus meluangkan cukup waktu untuk memastikan bahwa orang tersebut tidak dapat menyelesaikan masalahnya sendiri dan membuat orang tersebut merasa bahwa ia tidak dapat menyelesaikannya tanpa bantuan. Namun, Anda dapat memberikan bantuan progresif sampai Anda memberi tahu orang itu jawabannya sendiri.

Contoh:

- Dapatkah Anda memberi tahu saya cara membuat properti hanya baca di C #, yaitu properti dengan nilai yang hanya dapat diinisialisasi dalam konstruktor dan tidak dapat diubah kemudian?
- Tentu saja. Saya hanya menggunakan kata kunci readonly.
- Apakah kamu yakin Bisakah Anda jelaskan perbedaan antara properti dan bidang?
- Hm. Properti adalah ... Anda lihat ... dapatkan dan atur ...
- Oke. Jadi suatu bidang adalah variabel yang dideklarasikan di dalam kelas atau struct dan valid dalam lingkup kelas / struct, sementara properti seperti bidang, tetapi juga menyediakan mekanisme untuk membaca, menulis, atau menghitung nilai. Sekarang bagaimana readonly? Apakah ini digunakan dengan properti?
- Saya percaya itu hanya digunakan untuk bidang ...
- Benar. Jadi bagaimana dengan propertinya?
- Mereka tidak dapat dibaca saja.
- Apakah kamu yakin Bagaimana dengan properti yang hanya memiliki getter?
- Mereka hanya baca.
- Apakah ini berarti bahwa nilainya selalu sama?
- Iya.
- Tidak terlalu. Fakta bahwa Anda memiliki properti dengan pengambil bukan berarti nilainya tidak berubah selama umur instance kelas. Jika pengambil merujuk ke bidang yang bertambah setiap kali Anda mengakses properti, nilai yang dikembalikan akan terus meningkat.
- Baik.
- Jadi? Apakah Anda memiliki gagasan tentang cara menerapkan properti dengan nilai yang tidak pernah berubah?
- Tidak.
- Anda dapat menggunakan bidang dukungan yang hanya bisa dibaca. Apakah Anda tahu apa itu bidang dukungan?
[...]

Memberikan jawaban adalah ide yang bagus dalam semua kasus. Ada beberapa kasus ketika orang yang diwawancarai mengomentari jawaban saya dengan cara yang menarik, menunjukkan bahwa meskipun ia tidak dapat menjawab pertanyaan di tempat pertama, ia masih tahu hal-hal terkait.

Selain itu, dengan hanya mengajukan pertanyaan tanpa bantuan lebih lanjut, Anda tidak memiliki terlalu banyak informasi tentang orang tersebut, di samping fakta bahwa dia tahu atau tidak tahu jawabannya . Memberikan bantuan progresif memungkinkan Anda melihat bagaimana orang tersebut memikirkan masalah.

Mungkin juga menunjukkan hal-hal lain yang tidak diketahui orang tersebut. Ambil contoh di atas: jika saya berhenti pada jawaban pertama, saya tidak akan tahu bahwa orang itu tidak dapat menjelaskan perbedaan antara bidang dan properti atau bahwa ia tidak tahu apa bidang dukungan.

Jika orang itu segera menjawab, tidak apa-apa. Jika dia membutuhkan bantuan, tidak ada yang salah dengan ini. Jika Anda akhirnya menjawab sendiri pertanyaan itu, itu pertanda buruk dan semoga orang yang diwawancarai akan dapat menjawab yang lain.

Saya selalu suka membantu orang yang diwawancarai jika mereka terjebak pada hal-hal sederhana (seperti nama pola tertentu jika mereka jelas tahu apa itu), dan membiarkan mereka mengabaikan hal-hal seperti detail membangun koneksi database. Namun, jika mereka mencoba mendesain sesuatu, saya tidak banyak bicara karena saya tidak ingin membimbing mereka atau membuangnya jika mereka memikirkan sesuatu selain ke mana saya menduga mereka akan pergi.

Saya ingat ditanya pertanyaan penyelesaian masalah tertentu dari pewawancara yang memiliki hasil yang sangat spesifik dalam pikiran, tetapi dia tidak dapat mengkomunikasikan pertanyaan dengan jelas kepada saya. Ini menggambarkan situasi yang ditemui banyak orang yang diwawancarai. Terkadang tatapan kosong itu bukan karena orang itu bukan pemecah masalah yang baik, tetapi karena orang yang mengajukan pertanyaan tidak jelas dalam apa yang mereka tanyakan. Dalam hal itu, pendekatan kolega Anda untuk mengatakan dan melakukan tidak hanya membuktikan bahwa kandidat tidak berpikir seperti kolega Anda, atau tidak berada di dalam kepala kolega Anda. Saya pikir memberikan klarifikasi pertanyaan dengan kata-kata yang berbeda mungkin memberikan hasil yang lebih baik untuk semua yang terlibat.

Mengingat bahwa programmer (kebanyakan dari kita setidaknya) tidak bekerja dalam ruang hampa, dan bahwa wawancara cukup menegangkan tanpa batas buatan, saya cenderung menawarkan bantuan sebanyak yang diminta atau dibutuhkan oleh orang yang diwawancarai.

Tetapi pertimbangkan semuanya saat membuat penilaian akhir tentang tingkat kompetensi aktual pelamar.

Seseorang yang mencari posisi senior tetapi membutuhkan banyak bantuan akan membunyikan bel alarm.

Untuk "orang lanjut usia", saya menawarkan pertanyaan singkat dan terbuka dan lebih memperhatikan pertanyaan yang mereka ajukan daripada jawabannya. Saya menemukan orang-orang senior yang mendengarkan, berkomunikasi, menggunakan mendengarkan aktif, mengklarifikasi, kemudian memberikan solusi adalah tipe yang saya sukai.

Untuk "insinyur garis", saya telah menggunakan teknik untuk tes pemrograman di mana Anda memberi pelamar komputer dan masalah dan beberapa jam, lalu Anda kembali. Dalam situasi itu, kami bertanya kepada pemohon terlebih dahulu OS dan alat apa yang mereka sukai (juga merupakan bagian yang menarik dari keahlian seorang programmer). Ketika mereka selesai, sebagai kelompok kami meminta mereka untuk mempresentasikan solusi dan mengapa itu lebih baik daripada solusi lain - tinjauan kode. Semua keterampilan yang saya harapkan dari seorang insinyur yang berpengalaman pada hari 1.

Yang penting, seluruh tim wawancara telah mengambil satu sore untuk melakukan tes yang sama, jadi kami tahu tes itu adil. Kami menghabiskan satu jam memeriksa pendekatan masing-masing orang seperti yang kami lakukan dengan orang yang diwawancarai, yang memberi kami rasa pendekatan yang berbeda.

Teknik kedua ini menemukan kami beberapa programmer "tanpa tanda jasa" terbaik (resume buruk, keterampilan wawancara buruk) yang pernah saya temukan.

Saya lebih suka memulai wawancara dengan pertanyaan membangun kepercayaan yang mudah untuk membuat kandidat merasa nyaman dengan prosesnya. Saat ini berhasil, Anda masih dapat memperoleh informasi sebanyak mungkin dari pertanyaan selanjutnya tanpa memberikan keuntungan kepada kandidat yang memahami bahasa tubuh lebih baik daripada materi terkait pekerjaan.

Kadang-kadang menyediakan minor hintsselama wawancara lisan membantu untuk melihat seberapa baik kandidat memahami topik. Namun, harus ada no hintspada tes standar yang diminta oleh setiap kandidat.

Pada dasarnya, ada two main thingsyang mungkin ingin Anda ketahui tentang kandidat potensial:

a) Karakteristik pribadi - apakah ia cocok dengan perusahaan atau tim Anda

b) Keterampilan teknis - apakah ia memiliki latar belakang teknis yang baik dan minat untuk mengambil hal-hal baru

Untuk mempelajari poin-poin yang disebutkan di atas, Anda harus melibatkan kandidat potensial ke dalam percakapan. Penting juga untuk memastikan bahwa kandidat berada comfortable during the interviewdalam rangka untuk mendapatkan pemahaman maksimum tentang keterampilannya saat ini (baik lunak dan teknologi) serta potensinya untuk melakukan pekerjaan.

Selain itu, keterampilan komunikasi kandidat potensial sama pentingnya dengan keterampilan teknis dan kompetensinya untuk menyelesaikan masalah.

Bagian dari apa yang harus dilihat adalah keterampilan komunikasi. Jika kandidat tidak jelas tentang pertanyaan, ia harus mengajukan pertanyaan untuk menjelaskan. Ini adalah hal yang baik, menurut saya. Terlalu sering, keputusan buruk dibuat karena asumsi tertentu dibuat ketika membaca spesifikasi atau, dalam hal ini, memproses pertanyaan wawancara. Calon dapat menjawab berdasarkan asumsi ini dan benar-benar kehilangan titik yang dimaksud. Pertanyaannya mungkin cacat, atau mungkin kandidat. Dalam kedua kasus, memungkinkan klarifikasi melalui komunikasi menunjukkan keterampilan yang berharga, yang harus dicari oleh pengusaha.

Saya pikir ini pada akhirnya bermuara pada kepribadian Anda sebagai pewawancara, dan apa yang Anda anggap penting dan karena itu benar-benar menilai calon.

Secara pribadi, saya menghargai kemampuan praktis / pragmatis daripada hal-hal sepele akademis / esoteris. Saya jauh lebih tertarik pada seorang kandidat yang dapat datang, mulai bekerja, dan berkontribusi secara efektif dalam beberapa cara yang berharga untuk proyek apa pun yang mereka pekerjakan untuk dikerjakan daripada saya tentang seberapa baik ingatan mereka untuk minutia.

Jadi, saya akan melatih sedikit jika kandidat terjebak pada sesuatu yang esoteris, atau nuansa yang jarang digunakan, atau kasus tepi yang mungkin relevan dalam pertanyaan wawancara dibuat-buat tetapi jarang jika pernah relevan dalam kehidupan nyata. Terutama apa pun yang mereka dapat dapatkan dengan beberapa menit di Google atau dengan referensi meja yang praktis, atau "set dan lupakan saja" ketik hal-hal.

Namun, saya tidak akan melatih mereka tentang hal-hal dunia nyata, umum, umum, mendasar, pekerjaan sehari. Ini adalah hal-hal yang saya ingin menjadi bawaan mereka.

Saya pikir itu tergantung pada situasi wawancara dan pertanyaan. Saya telah menggunakan kedua teknik ini.

Mengapa saya ingin tidak mengajukan pertanyaan tindak lanjut? Ketika saya mencoba mencari tahu respons orang tersebut terhadap stres. Saya telah mewawancarai orang-orang untuk beberapa pekerjaan yang berada di lingkungan yang sangat penuh tekanan dan seberapa baik mereka dapat mengatasi stres adalah faktor penting dalam evaluasi kami, jadi kami mengajukan beberapa pertanyaan yang sangat sulit yang tidak seorang pun dapat menjawab tanpa stres.

Ketika saya mencoba mencari tahu pengetahuan teknis mereka, saya mengajukan pertanyaan lanjutan yang mungkin berisi petunjuk tentang apa yang saya cari. Bertentangan dengan pemikiran manajer yang mengatakan Anda harus mengajukan pertanyaan yang sama kepada semua orang agar adil, saya percaya ini adil selama beberapa persyaratan dipenuhi. Pertama, semua orang ditanyai pertanyaan dasar yang sama. Kedua, Anda sebaiknya tidak mengajukan pertanyaan tindak lanjut untuk membantu hanya satu orang. Jika Anda membiarkan orang lain menggelepar tanpa bantuan, Anda harus membiarkan semua menggelepar tanpa bantuan. Kedua, Anda harus membandingkan kinerja kandidat pada pertanyaan, tidak hanya dalam hal jawaban akhir mereka tetapi dalam hal seberapa sulit untuk menyeretnya keluar dari mereka. Proses ini masih memperlakukan semua orang dengan adil.

Tergantung programmer seperti apa yang Anda inginkan. Seorang introvert yang dapat menulis 20 baris kode di atas kertas akan terlihat bagus untuk bos Anda. Pengembang perangkat lunak yang dapat bekerja berdasarkan jutaan basis kode dalam tim untuk menghasilkan perangkat lunak yang baik secara efisien mungkin tidak akan berhasil dengan baik. Saya suka wawancara semacam ini sebagai kandidat - mereka banyak bercerita tentang bagaimana bos memperlakukan stafnya dan apa budaya kerjanya. Dalam kasus seperti ini, ketika saya meninggalkan wawancara, saya berkata, "Terima kasih - Mari kita selamatkan sedikit waktu, jika tidak menelepon saya, saya tidak akan menghubungi Anda." Ketika ditanya mengapa, saya menunjukkan bahwa saya tidak ingin bekerja untuk perusahaan yang membuat saya gagal.

Pendekatan Anda kemungkinan akan mendapatkan pilihan yang lebih baik untuk pengembangan perangkat lunak. Pendekatan Anda bos akan bekerja dengan baik untuk pengumpul sampah dan orang-orang yang memegang lolipop Stop / Go di pekerjaan jalan.

Pengembangan perangkat lunak adalah upaya tim, bukan permainan solo / membaca pikiran / non-interaktif. Berapa banyak proyek yang gagal karena perangkat lunak melakukan apa yang diminta, bukan apa yang diinginkan.

Saya baru-baru ini dalam situasi yang sama. Arahan yang saya dapatkan dari manajer dan SDM saya adalah bahwa kami harus benar-benar adil kepada semua 6 orang yang diwawancarai, jadi saya harus mengajukan pertanyaan teknis yang sama dengan sedikit bantuan untuk melihat bagaimana kinerja setiap orang yang diwawancarai. Kadang-kadang ketika mereka tahu jawabannya tetapi tetap dengan istilah teknis atau sesuatu, saya membantu mereka secara tidak langsung dengan beberapa pertanyaan yang membimbing mereka ke istilah itu. Ada putaran kedua wawancara setelah putaran teknis tentang kepribadian dan sifat-sifat perilaku jika mereka berhasil melewati putaran pertama.

Bagian dari apa yang Anda inginkan dalam seorang karyawan adalah seseorang yang dapat berinteraksi dengan anggota tim lainnya. Anda membutuhkan seseorang dengan keterampilan yang dibutuhkan, benar. Tetapi Anda juga membutuhkan seseorang yang tahu kapan mereka perlu mencari bantuan dan memiliki pengetahuan diri dan keterampilan sosial untuk melakukan itu. Set terakhir ini akan mengatur akan membangun perusahaan lebih baik dalam jangka panjang daripada Du-jour bahasa komputer tertentu.

Cara saya melihatnya, wawancara adalah sesi rekan kerja percobaan, bukan tes . Saya terutama mencoba menjawab pertanyaan "bagaimana rasanya bekerja dengan orang ini?" Saya kadang-kadang bahkan berpura - pura lupa jawaban atas pertanyaan itu, untuk membuat latihan ini terasa lebih kolaboratif.

Pernahkah Anda bekerja dengan seseorang yang Anda tidak bisa dapatkan di halaman yang sama dengan setiap kali Anda berbicara melalui masalah? Atau seseorang yang terlalu banyak bertanya alih-alih terjun dan menyelesaikan masalah? Dalam sebuah wawancara saya kebanyakan memastikan orang yang saya ajak bicara bukan salah satu dari mereka. Ada unsur kimia yang kuat di sana.

Dalam prosesnya tentu saja saya juga akan belajar hal-hal seperti, "apakah dia menulis kode bersih," "apakah dia akrab dengan konsep-konsep yang diperlukan," dan "bisakah dia dengan cerdik menyodok masalah untuk sampai pada wawasan?" Kandidat akan tetap menjadi satu "mengemudi" dan menulis kode. Tapi sepanjang jalan mudah-mudahan dia akan lebih santai dan saya akan melihat versi dirinya yang lebih dekat dengan apa yang sebenarnya saya lihat sehari-hari sebagai rekan kerja.