Apakah rekayasa berlebihan merupakan tanda peringatan? [Tutup]

Jadi kami menyajikan latihan coding langsung ke kandidat baru dengan beberapa persyaratan yang jelas. Kadang-kadang kita menerima solusi yang tidak benar-benar menyelesaikan masalah yang dihadapi, tetapi direkayasa berlebihan untuk memecahkan masalah yang dirasakan - seringkali di luar batas latihan.

Sekarang pertanyaan saya adalah, apakah ini tanda peringatan?

EDIT: Cukup banyak diskusi didasarkan pada tes yang cacat - yang merupakan poin yang adil. Seperti yang saya jelaskan dalam komentar, premis dasar dari tes ini adalah untuk menunjukkan bagaimana Anda dapat membaca data dari file dengan cara yang masuk akal (dan Anda akan kagum dengan berbagai pendekatan yang kita lihat), dan bagaimana mencocokkannya dengan item sebelum menghitung latensi antara pembaruan. Agar ini berfungsi, asumsi tertentu harus dibuat tentang data, dan kami mencari asumsi ini, dan kami juga menyatakan secara eksplisit bahwa kami ingin melihat pendekatan yang Anda ambil (termasuk pendekatan OO, dll.) Semua ini dalam dua jam jangka waktu.

IMHO, ketika saya mewawancarai itu adalah latihan paling lengkap yang saya temui.

Skenario khusus yang saya renungkan adalah di mana seorang kandidat, daripada membaca dari file, menerima input "jaringan" dalam aplikasi multi-threaded, yang jelas-jelas tidak berada dalam ruang lingkup.

Masalahnya adalah tes miring. Anda meminta seseorang untuk menunjukkan kemampuan mereka untuk menulis perangkat lunak tingkat perusahaan yang kompleks menggunakan latihan sederhana hanya dalam beberapa menit. Ada pewawancara lain di perusahaan lain yang mengeluh bahwa kandidat tidak menunjukkan keterampilan yang cukup dalam desain berorientasi objek dengan latihan-latihan ini, sehingga orang cenderung memberikan kompensasi yang berlebihan. Itu tidak selalu berarti kandidat Anda tidak dapat menggunakan kode yang lebih sederhana ketika situasi menjaminnya.

Jika Anda ingin tahu apakah itu yang terjadi dengan kandidat Anda, minta mereka untuk mengulanginya, berikan mereka beberapa pedoman khusus. Katakan, "Saya bisa melihat Anda memamerkan keterampilan desain berorientasi objek, tetapi tampaknya terlalu sulit untuk masalah yang begitu sederhana. Bisakah Anda menulis ulang hanya menggunakan dua fungsi kecil?"

Saya akan mengatakan bahwa ini adalah tanda peringatan yang jelas, tetapi tidak harus mendiskualifikasi kandidat.

Ada dua masalah terpisah yang tampaknya dimiliki oleh para kandidat:

1. Ketinggalan latihan - Ini cukup mengkhawatirkan. Semua keterampilan pemrograman di dunia tidak akan menciptakan hasil yang baik jika seseorang tidak dapat mengatasi masalah yang mereka selesaikan dengan benar. Saya telah menemukan bahwa insinyur yang paling produktif adalah yang mampu mengidentifikasi masalah sebenarnya yang harus dipecahkan, bahkan jika itu bukan masalah yang ditimbulkan. Memiliki kemampuan untuk berpikir kritis tentang pertanyaan yang diajukan, dan mungkin merumuskannya kembali menjadi sesuatu yang lebih mudah untuk dipecahkan adalah keterampilan yang sangat penting. Kehilangan poin ketika masalah dinyatakan dengan jelas harus menjadi bendera merah besar.
2. Overengineering the solution - Ini adalah masalah sekunder dan seringkali merupakan hasil dari masalah pertama. Ada beberapa patologi berbeda yang dapat memiliki hasil ini. Pertama, tidak memahami masalah dengan benar, atau melemparkannya terlalu luas dapat menghasilkan solusi yang terlalu rumit. Ini jelas terkait dengan poin pertama di atas. Kedua, mencoba untuk "memamerkan" dengan memikirkan skenario masa depan yang mungkin tidak benar-benar relevan. Ini bisa menjadi masalah karena itu menunjukkan bahwa kandidat belum memahami nilai kesederhanaan dalam solusi dan menunda kompleksitas sampai itu benar-benar diperlukan. Ini adalah sesuatu yang dapat diperbaiki dengan panduan yang baik, tetapi harus diwaspadai ketika membawa seseorang ke dalam organisasi.

Saya akan menyarankan untuk menindaklanjuti dengan kandidat tentang jawaban mereka selama proses berlangsung. Daripada hanya melihat hasil mereka, cobalah untuk memastikan apa yang menuntun mereka pada hasilnya, dan memberikan beberapa panduan, bagaimana mereka akan merespons dan mengubah jawaban mereka. Ini mungkin akan lebih mengungkapkan tentang kemampuan mereka daripada hanya tanggapan langsung mereka terhadap masalah tersebut. "Mengapa" pendekatan mereka dapat memberi Anda perasaan apakah mereka tidak mendapatkannya, atau apakah pemahaman mereka sedikit berbeda dalam cara mereka memilih untuk merespons. Jenis tindak lanjut ini juga akan mengungkapkan lebih banyak tentang pendekatan keseluruhan mereka untuk pemecahan masalah.

Juga, periksa kembali masalah itu sendiri dan lihat apakah mungkin tidak jelas dan mungkin menyebabkan orang salah jalur ketika mereka merumuskan jawaban mereka.

Tidak, tidak selama wawancara kerja. Terlalu banyak pewawancara melakukan hal-hal seperti secara sengaja merinci persyaratan dan mengharapkan orang yang diwawancarai untuk mengajukan pertanyaan lebih lanjut, atau melihat perhatian pada masalah-masalah dunia nyata yang tidak disebutkan secara eksplisit.

Berikut adalah beberapa hal, di luar kepala saya, bahwa persyaratan Anda mungkin tidak menyebutkan:

• Standar pengkodean

• Komentar

• Penanganan pengecualian

• Nama deskriptif variabel, kelas, metode

• Mengikuti penggunaan bahasa secara idiomatis

• Desain berorientasi objek yang tepat

• Perhatian terhadap kemungkinan masalah konkurensi

• Menulis kasus uji untuk kode

Apakah Anda memperhatikan satu dari hal-hal ini tanpa secara eksplisit menyatakannya? Bagaimana kandidat tahu yang mana yang Anda pedulikan, dan mana yang tidak Anda pedulikan?

Wawancara adalah lingkungan yang sangat buatan. Pewawancara sering mencoba untuk "menipu" kandidat sedikit untuk mempersulit orang yang diwawancarai untuk mengatakan kepadanya apa pun yang ingin dia dengar, dan orang yang diwawancarai mencoba menebak apa yang sebenarnya diinginkan pewawancara .

Secara umum, membuat kesalahan pada tebakan itu sangat berbeda dari membuat kesalahan pada keputusan desain dunia nyata. Jika Anda ingin tahu apakah seseorang over-engineer hal-hal yang Anda mungkin harus berbicara tentang desain daripada melihat latihan pengkodean yang sangat buatan.

IMHO jawabannya jelas ya , itu adalah tanda peringatan, jika

• latihan coding memiliki tugas yang jelas
• memiliki persyaratan yang jelas (ans juga ditulis dengan baik),
• para kandidat memiliki kesempatan untuk mengajukan pertanyaan untuk memastikan mereka memecahkan masalah yang benar.
• Anda menginginkan orang yang cerdas dan menyelesaikan sesuatu dalam tim Anda, bukan astronot arsitektur .

Tanda peringatan hampir tidak sebesar tidak menyelesaikan masalah . Fakta bahwa dia gagal dalam kuis dan tidak memberikan solusi yang benar adalah tanda peringatan. Itu belum tentu skenario no-go karena tergantung pada bagaimana dan mengapa dia tidak memberikan solusi yang benar.

Sering kali pertanyaannya benar-benar omong kosong dan tidak bisa dijawab. Jangan berpura-pura bahwa pewawancara tidak pernah melakukan kesalahan. Dia masih gagal menjelaskan mengapa pertanyaan itu omong kosong. Jika Anda mempekerjakan seorang insinyur yang diharapkan membantu membuat persyaratan, ini merupakan masalah. Jika Anda mempekerjakan seorang pembuat kode, Anda hanya tidak berharap dia melakukan itu.

Menganggap bahwa latihan pengkodean tidak kacau, tampaknya cara dia gagal itu salah mengartikan masalah dan pergi ke gulma mencoba untuk memecahkan masalah yang tidak ada. Ya, itu pertanda peringatan.

Mungkin.

Tidak menyelesaikan masalah tentu saja merupakan tanda peringatan yang jelas bahwa ada sesuatu yang salah. Apa yang salah? Entah mereka salah memahami masalah, atau mereka membuat solusi yang buruk. Solusi buruk untuk sesuatu yang sederhana adalah tanda yang jelas bahwa kandidat itu miskin.

Jika mereka salah memahami masalahnya, maka perhatikan persyaratan Anda. Bahkan hal-hal yang tampak jelas bagi Anda mungkin tidak jelas bagi orang lain yang tidak terbiasa dengan domain, atau dari latar belakang yang berbeda (lokal, usia, asuhan). Jika kandidat ada di sana bersama Anda, atau menawarkan kesempatan untuk mengajukan pertanyaan dan masih gagal, saya akan menganggap itu sebagai kegagalan mereka. Jika persyaratan dilemparkan ke dinding, saya kemungkinan akan memberi mereka keuntungan dari keraguan (dan berpikir tentang memperbaiki proses wawancara).

Jika solusinya benar, maka itu menjadi kurang jelas. Secara pribadi, saya berpikir bahwa sejumlah orang mengambil YAGNI terlalu jauh. Jika Anda dapat mengambil masalah tertentu dan membuat solusi umum tanpa meningkatkan kompleksitas atau merusak pemeliharaan, mengapa tidak membuat solusi umum? (Pikirkan membalikkan string vs membalikkan koleksi apa pun) "Rekayasa berlebihan" semacam itu menurut saya bagus.

Yang lainnya adalah jalan tengah kelabu itu. Apakah solusi mengatasi kemungkinan perubahan? Apakah solusi menambah kompleksitas atau membahayakan pemeliharaan? Menambahkan sedikit kompleksitas untuk menyelesaikan masalah di masa depan yang hampir dijamin akan menang. Membahayakan pemeliharaan yang besar untuk memperhitungkan sesuatu yang sama sekali tidak mungkin tidak.

Menjadi insinyur perangkat lunak yang baik berarti mencapai keseimbangan yang tepat di sini. Menjadi pewawancara yang baik berarti melakukan penilaian / kesimpulan yang tepat tentang bagaimana dan mengapa kandidat memilih keseimbangan itu, sering menggunakan bagian wawancara yang lain untuk mengevaluasi.

Mungkin tetapi pertimbangkan hal berikut:

• Wawancara sulit: Orang-orang di bawah tekanan. Ini harus sangat diperhitungkan dalam masalah yang Anda berikan pada seseorang

• Panjang Persyaratan: Berapa lama dan lurus ke depan persyaratan? Apakah Anda membuat mereka ekstra bertele-tele untuk memastikan Anda memasukkan semuanya. Akibatnya, mereka mungkin jelas bagi Anda tetapi persyaratan mungkin direkayasa berlebihan! Saya melakukan wawancara kerja untuk masalah satu jam sekali dengan sekitar 3 halaman teks untuk masalah yang relatif sederhana. Terkadang semua teks itu sulit dibaca dan diinterpretasikan dalam sebuah wawancara dan bisa disalahartikan juga.

• Terkadang Less is More: Saya lebih suka memiliki beberapa poin, kalimat, dan atau contoh yang menunjukkan persyaratan utama dan kemudian diskusi dengan seseorang untuk mengajukan pertanyaan dan mungkin menjangkau sepanjang jalan jika diperlukan. Saya kira apa yang saya coba katakan adalah Anda harus terlebih dahulu memeriksa persyaratan tes Anda tidak terlalu rumit untuk masalah sederhana.

• Keterampilan Komunikasi: Anda harus menguji kemampuan kandidat untuk berkomunikasi dan mengajukan pertanyaan cerdas tentang masalah terlebih dahulu dan begitu Anda tahu bahwa mereka telah menunjukkan bahwa mereka memahami masalah maka Anda dapat mengarahkan mereka pada implementasi mereka.

• Intinya: Jika Anda belum memeriksa bahwa masalahnya dipahami daripada Anda benar-benar tidak tahu apa yang harus dilakukan dari rekayasa berlebihan. Seperti yang orang lain katakan itu bisa menjadi hal yang baik atau buruk tetapi jika Anda tidak memeriksa pemahaman atau berkomunikasi dengan kandidat tentang masalah di muka, akan lebih sulit untuk mengetahui pemahaman umum mereka tentang masalah dan apa yang harus dilakukan.

Banyak dari ini dapat dikaitkan dengan bagaimana Anda mengucapkan pertanyaan dan bagaimana Anda telah menempatkan seluruh wawancara ke dalam perspektif.

Itu seperti, "Mari kita lihat seberapa kreatif Anda. Apa itu 2 + 2?" Empat? Yang bisa Anda temukan adalah jawaban yang paling sederhana, jelas, dan akurat? Pengembang muda / pemula yang sangat bersemangat untuk mengesankan selama wawancara akan mengambil "Kami ingin menguji keterampilan pengkodean Anda atau melihat seberapa baik seorang programmer Anda." berarti "melakukan sesuatu yang sangat canggih." Kita semua suka berpikir sederhana itu yang terbaik kecuali kalau itu membuat segalanya lebih sulit.

Ada beberapa cara untuk melihat apakah seseorang cenderung selalu melakukan rekayasa berlebihan. Berikan contoh kode dari sesuatu yang terlalu rumit dan minta solusi yang lebih sederhana. Ketika seseorang memberikan solusi yang menurut Anda tidak akan berhasil, ini adalah kesempatan bagus untuk melihat bagaimana mereka bereaksi terhadap kritik. Secara pribadi, saya ingin melihat seseorang terbuka untuk ide-ide baru dan rekonsiliasi solusi yang lebih baik daripada seseorang yang akan membuat kesalahan yang sama berulang kali.

Dan pada kenyataannya, bukankah kita selalu memiliki kesempatan untuk mengubah kode kita ketika itu tidak berhasil? Anda dapat di bawah desain atau desain lebih pada awalnya. Setelah Anda mengenali solusi sederhana, bukankah seharusnya lebih mudah diterapkan?

Itu tergantung, tetapi umumnya tidak.

Desain pada umumnya adalah keterampilan yang dipelajari dengan pengalaman. Deskripsi Aaronaught tentang perkembangan yang dihubungkan oleh Marjan umumnya bagus.

Komunikasi dalam bentuk apa pun juga sangat tergantung pada konteks. Apa yang tampaknya sangat jelas berarti satu hal dalam satu konteks, mungkin dengan jelas berarti sesuatu yang lain dalam konteks yang berbeda. Mengetahui pertanyaan mana yang harus ditanyakan juga merupakan sesuatu yang disertai dengan pengalaman.

Proses pemikiran mereka dan bagaimana mereka bernalar tentang keputusan mereka jauh lebih penting daripada solusi mereka. Tanpa meninjau solusi mereka dan keputusan mereka dengan Anda, Anda tidak dapat sepenuhnya menilai konteks yang dikembangkannya.

Mengingat perkembangan di atas, seorang kandidat dengan solusi over-engineered mungkin lebih jauh daripada kandidat dengan yang sederhana.

Juga: Posisi level apa yang Anda rekrut? Over-engineering keluar dari kandidat tingkat menengah atau masuk lebih sedikit masalah daripada over-engineering dari kandidat tingkat senior.

Jika pemrogram tidak menyelesaikan masalah, maka semua kode tambahan adalah upaya pembuat kode untuk mengaburkan jawaban yang tidak dijawab. Ini adalah teknik yang sama yang digunakan pada tes esai oleh seorang siswa yang tidak tahu banyak tentang subjek tersebut. Dia akan mengoceh tentang masalah yang menarik, tetapi tidak terkait dengan harapan ketidaktahuannya ditutupi oleh jumlah kata.

Jika programmer memang memecahkan masalah tetapi menambahkan lebih banyak kode, pertimbangkan latar belakang programmer, karena beberapa area pemrograman membutuhkan toleransi yang lebih besar daripada yang lain.

Misalnya, kode yang menjalankan pilot otomatis dalam jet penumpang komersial memiliki toleransi yang jauh lebih kecil untuk kegagalan daripada game Android gratis. Pengembang yang terbiasa memprogram perangkat tertanam yang sulit dijangkau dan hampir tidak mungkin diperbarui akan cenderung memberi kode lebih banyak tentang apa-jika dibandingkan dengan pengembang yang dapat mendorong 15 pembaruan dalam sehari.