Jadi, mengingat bahwa ini adalah pertanyaan wawancara dan bukan skenario kehidupan nyata yang sebenarnya, saya percaya pendekatan yang benar (dan mungkin apa yang pewawancara cari) adalah mengajukan pertanyaan klarifikasi, atau menulis "Tidak bisa dilakukan "dan terus maju. Inilah sebabnya.
Apa yang Pewawancara Bertanya:
Tulis fungsi yang dijamin tidak akan pernah mengembalikan nilai yang sama dua kali. Asumsikan bahwa fungsi ini akan diakses oleh beberapa mesin secara bersamaan.
Apa yang Dibutuhkan Pewawancara:
Apakah kandidat ini secara efektif mengevaluasi persyaratan dan mencari input tambahan saat diminta?
Jangan pernah berasumsi.
Ketika seorang insinyur diberikan persyaratan (melalui SOW atau Spesifikasi atau dokumen persyaratan lainnya), beberapa sudah jelas, dan yang lain sama sekali tidak jelas. Ini adalah contoh sempurna dari yang terakhir. Seperti yang ditunjukkan oleh jawaban sebelumnya, tidak ada cara untuk menanggapi persyaratan ini tanpa membuat beberapa asumsi utama baik (a) mengenai sifat pertanyaan atau (b) seperti sifat sistem, karena persyaratan tidak dapat dipenuhi seperti yang tertulis (tidak mungkin).
Sebagian besar jawaban membuat satu upaya atau yang lain dalam memecahkan masalah melalui serangkaian asumsi. Seseorang secara khusus merekomendasikan untuk menyelesaikannya dengan cepat dan membiarkan pelanggan khawatir tentang hal itu jika itu salah.
Ini benar-benar pendekatan yang buruk. Sebagai pelanggan, jika saya memberikan persyaratan yang tidak jelas, dan insinyur pergi dan membuat saya solusi yang tidak berhasil, saya akan marah karena mereka pergi bekerja dan menghabiskan uang saya tanpa repot-repot bertanya kepada saya terlebih dahulu. Pengambilan keputusan yang berani seperti itu menunjukkan kurangnya kerja tim, ketidakmampuan untuk berpikir kritis, dan penilaian yang buruk. Ini dapat mengarah pada segala bentuk konsekuensi negatif, termasuk hilangnya nyawa dalam sistem kritis keselamatan.
Mengapa Mengajukan Pertanyaan?
Intinya jika latihan ini mahal dan menghabiskan waktu untuk membangun persyaratan yang ambigu. Dalam kasus OP, Anda telah diberi tugas yang mustahil. Tindakan pertama Anda harus meminta klarifikasi - apa yang diperlukan? Tingkat keunikan apa yang dibutuhkan? Apa yang terjadi jika suatu nilai tidak unik? Jawaban atas pertanyaan-pertanyaan ini dapat berupa perbedaan antara beberapa minggu waktu dan beberapa menit. Di dunia nyata, salah satu pendorong terbesar biaya dalam sistem yang kompleks (termasuk banyak sistem perangkat lunak) adalah persyaratan yang tidak jelas dan kurang dipahami. Hal ini menyebabkan bug yang mahal dan memakan waktu, desain ulang, frustrasi pelanggan dan tim, dan memalukan liputan media jika proyek tersebut cukup besar.
Apa Yang Terjadi Ketika Anda Menganggap?
Mengingat latar belakang saya di industri kedirgantaraan, dan karena sifat kegagalan kedirgantaraan yang sangat terlihat, saya ingin memunculkan contoh dari domain ini untuk menggambarkan poin-poin penting. Mari kita periksa sepasang misi Mars yang gagal - Mars Climate Orbiter dan Mars Polar Lander. Kedua misi gagal karena masalah perangkat lunak - karena insinyur membuat asumsi yang tidak valid, sebagian, karena persyaratan yang tidak jelas dan kurang dikomunikasikan.
Mars Climate Orbiter - kasus ini biasanya dikutip sebagai apa yang terjadi ketika NASA mencoba mengkonversi bahasa Inggris ke satuan Metrik. Namun, itu adalah representasi yang terlalu sederhana dan buruk dari apa yang sebenarnya terjadi. Benar, ada masalah konversi, tetapi itu karena persyaratan komunikasi yang buruk di tahap desain dan skema verifikasi / validasi yang tidak tepat. Lebih lanjut, ketika dua insinyur berbeda memperhatikan masalah ini karena jelas dari data lintasan penerbangan, mereka tidak mengangkat masalah ke tingkat yang tepat karena mereka menganggap itu adalah kesalahan transmisi. Seandainya tim ops misi disadarkan akan masalah ini, ada cukup waktu untuk memperbaikinya dan menyelamatkan misi. Dalam hal ini, ada kondisi logis yang mustahil yang tidak dikenali apa adanya, yang menyebabkan kegagalan misi yang mahal.
Mars Polar Lander- kasus ini sedikit kurang terkenal, tetapi mungkin lebih memalukan karena kedekatan temporal dengan kegagalan Mars Climate Orbiter. Dalam misi ini, peranti lunak itu mengendalikan pendaratan roket ke permukaan Mars. Pada titik 40 meter di atas permukaan, kaki pendarat dikerahkan untuk persiapan pendaratan. Ada juga sensor pada kaki yang mendeteksi gerakan (untuk memberi sinyal ketika mereka berdampak) untuk memberitahu perangkat lunak untuk mematikan mesin. Tebakan terbaik NASA tentang apa yang terjadi (karena ada beberapa kemungkinan kegagalan dan data yang tidak lengkap) adalah bahwa getaran acak di kaki akibat penyebarannya secara bersamaan dan secara tidak tepat memicu mekanisme penutupan 40 m di atas permukaan, yang mengakibatkan tabrakan dan penghancuran $ 110 Pesawat ruang angkasa M Kemungkinan ini diangkat dalam pengembangan, tapi tidak pernah disapa. Pada akhirnya, tim perangkat lunak membuat asumsi yang tidak valid tentang bagaimana kode ini perlu dijalankan (salah satu anggapan tersebut adalah bahwa sinyal palsu akan terlalu pendek untuk diambil, meskipun tes menunjukkan sebaliknya), dan asumsi tersebut tidak pernah dipertanyakan sampai setelah faktanya.
Pertimbangan Tambahan
Mewawancarai dan mengevaluasi orang adalah bisnis yang sulit. Ada beberapa dimensi calon yang ingin dieksplorasi oleh pewawancara, tetapi salah satu yang paling penting adalah kemampuan individu untuk berpikir kritis. Karena berbagai alasan, tidak terkecuali bahwa berpikir kritis tidak didefinisikan dengan baik, kami memiliki waktu yang sangat sulit untuk mengevaluasi keterampilan berpikir kritis.
Sebagai instruktur teknik, salah satu cara favorit saya untuk mengevaluasi kemampuan siswa untuk berpikir kritis adalah dengan mengajukan pertanyaan yang agak ambigu. Siswa yang lebih tajam akan mengambil premis yang salah dari pertanyaan, mencatatnya, dan entah menjawab premis atau menolak untuk menjawab sama sekali. Biasanya, saya akan mengajukan pertanyaan yang serupa dengan yang berikut:
Anda mengambil gambar dari tumpukan pekerjaan Anda. Gambar itu berisi berbagai info yang berbeda, tetapi poin paling penting ke permukaan horizontal dan mengatakan "Sempurna datar". Permukaannya 5 "lebar 16" panjang, dan bagian terbuat dari aluminium. Bagaimana Anda akan mengolah bagian untuk membuat fitur ini?
(Ngomong-ngomong, Anda akan terkejut dengan seberapa sering spesifikasi yang buruk seperti itu muncul di tempat kerja.)
Saya berharap bahwa siswa akan mengenali bahwa tidak mungkin untuk membuat fitur yang sempurna, dan bahwa mereka akan menyatakan ini dalam jawaban mereka. Saya biasanya akan memberikan poin bonus jika mereka mengatakan akan kembali ke desainer dan meminta klarifikasi sebelum membuat bagian. Jika seorang siswa melanjutkan untuk memberi tahu saya bagaimana mereka akan mencapai .001 planaritas atau nilai-nilai lainnya, saya memberikan nol poin. Ini membantu saya menunjukkan kepada siswa saya bahwa mereka perlu memikirkan gambaran yang lebih besar.
Intinya
Jika saya mewawancarai seorang insinyur (atau profesi serupa), saya mencari seseorang yang dapat berpikir kritis dan mempertanyakan apa yang telah ditempatkan di depannya. Saya ingin seseorang yang mengajukan pertanyaan, "Apakah ini masuk akal?" .
Tidak masuk akal untuk meminta bagian yang benar-benar rata, karena tidak ada yang namanya sempurna. Tidak masuk akal untuk meminta fungsi yang tidak pernah mengembalikan nilai duplikat, karena tidak mungkin untuk membuat jaminan seperti itu. Dalam pemrograman, kita sering mendengar ungkapan "sampah masuk, sampah keluar." Jika Anda diberikan sampah untuk persyaratan, itu adalah tanggung jawab etis Anda untuk berhenti dan mengajukan pertanyaan apa pun yang membantu Anda memperoleh maksud sebenarnya. Jika saya mewawancarai seorang kandidat, dan saya memberi mereka persyaratan yang tidak jelas, saya akan mengharapkan pertanyaan klarifikasi.