Bagaimana cara memeriksa atau menilai keterampilan men-debug seseorang? [Tutup]

Keterampilan apa yang menentukan seseorang yang mampu men-debug kode dengan mudah? Beberapa waktu yang lalu teman saya melakukan wawancara dengan programmer yang relatif baik. Si programmer dipekerjakan. Dia bisa menulis kode yang baik, memahami kerangka kerja dan pola desain. Hal yang hilang adalah - keterampilan debugging. Dia tidak bisa men-debug sama sekali dan menemukan masalah dengan kodenya atau orang lain sangat menyakitkan baginya.

Sejak itu kami berpikir tentang bagaimana kami dapat menilai atau memperkirakan keterampilan debugging seseorang.

Jadi pertanyaan pertama adalah: keterampilan apa yang menentukan apakah seseorang dapat secara efektif men-debug perangkat lunak?

Dan yang kedua: bagaimana cara menguji keterampilan tersebut selama wawancara?

Jika hal pertama yang orang ingin lakukan adalah melihat kode dan melangkah melaluinya dengan debugger orang itu bukan pemecah masalah besar.

Jika Anda belum memiliki rencana aksi dan menyelam ke dalam debugger blind, Anda pada dasarnya adalah Easter Egging. Ini berlaku untuk jenis pemecahan masalah APAPUN.

Dalam situasi wawancara seseorang yang bertanya bagaimana sistem beroperasi dan bertanya tentang sejarah sistem akan menjadi seseorang yang mungkin menjadi pemecah masalah yang baik. Seseorang yang berpikir sistem pertama dan mekanik kedua bisa menjadi pemecah masalah yang baik.

Ini berlaku untuk sistem yang kompleks.

Saya berpendapat bahwa ukuran terbaik dari pengembang perangkat lunak yang baik dalam bahasa atau kerangka kerja tertentu adalah kemampuan untuk menganalisis secara kritis masalah yang rumit dan untuk memiliki keterampilan debugging yang baik dalam bahasa atau kerangka kerja. Mereka harus dapat menunjukkan debugging tingkat rendah serta kecakapan dalam debugging tingkat tinggi dengan alat debugging umum.

Ini berarti membuat skenario untuk mereka yang menunjukkan kecakapan tinggi alat debugging di IDE yang mereka pilih. Anda harus mencari hal-hal seperti:

• Menjalankan aplikasi atau server berpasir dalam mode debug atau membangun aplikasi dengan simbol untuk debugging

• Menyediakan dan menunjukkan port debugging jarak jauh atau debugging aplikasi non-kotak pasir yang dibangun dengan simbol (jika berlaku untuk bahasa)

• Penggunaan breakpoint secara strategis

• Properti khusus breakpoints, ekspresi kondisional pada breakpoints (jika berlaku untuk bahasa)

• Penggunaan ekspresi atau jam tangan variabel untuk memantau nilai atau referensi variabel

• Penggunaan nilai variabel ad-hoc atau manipulasi pointer atau pointer secara real time

• Tunjukkan kemampuan untuk masuk, keluar dan keluar dari aliran aplikasi

• Evaluasi kritis tumpukan panggilan

• Debugging aplikasi multi-utas dan pahami ini.

Strategi debugging lain tanpa alat harus ditunjukkan juga, seperti menganalisis log dan kode sumber, serta kemampuan untuk melakukan beberapa debugging tingkat rendah tanpa menggunakan IDE juga.

Saya akan mengatakan menyaring bug yang Anda miliki di sistem Anda untuk sesuatu yang dapat dibahas dalam konteks wawancara. Jalankan debugger dan biarkan dia melakukannya.

Tanyakan padanya pertanyaan seperti ini:

1. Bagaimana Anda mengatasi masalah?

2. Apa salah satu proyek kompleks yang Anda lakukan dan bagaimana Anda mencapainya?

3. Alat debugging apa yang Anda gunakan?

4. Apakah Anda memiliki preferensi untuk alat tertentu?

5. Berikan contoh skenario Anda sendiri dan tanyakan padanya bagaimana ia akan mengatasinya?

6. Bagaimana Anda menilai kemampuan Anda untuk masuk ke kode orang lain?

Anda dapat mengatasi masalah Anda dengan mengajukan pertanyaan. Selalu ada risiko dia mungkin atau mungkin tidak baik dalam keterampilan tertentu. Tetapi jika dia adalah pembelajar yang baik, itu akan banyak membantu.

Jika Anda ingin melihat apakah seorang programmer dapat melakukan debug, berikan mereka kode untuk diperbaiki. Ini pendekatan yang sama jika Anda ingin melihat apakah mereka dapat menulis kode. Beri mereka masalah dan minta mereka menulis kode.

Sekarang, saya bingung tentang programmer ini yang tidak memiliki masalah menulis kode tetapi gagal total ketika diminta untuk debug. Apakah orang ini memuntahkan contoh kode atau hanya menempel pada bidang yang ia miliki pengalaman seperti membaca dan menulis ke database? Kecuali jika mereka mendapatkan kode yang benar pertama kali, mereka tidak dapat memperbaikinya?

Mungkin orang itu tidak suka debugging dan tidak berusaha? Saya tidak pandai dalam hal ini jadi berhentilah meminta saya untuk melakukannya - belajar ketidakberdayaan.

Bekerja pada basis kode yang ada membutuhkan melihat melalui kode, dokumentasi dan mungkin membuat beberapa catatan dan desgins Anda sendiri.

Saya tahu kita menganggap debugging sebagai memperbaiki kode produksi yang gagal, tetapi saya perlu men-debug kode saat saya sedang menulisnya. Entah orang ini bukan programmer yang sangat baik atau mereka hanya lebih suka menulis kode baru. Bukankah kita semua.

Dengan cara yang sama Anda akan menentukan kemampuan pengkodean seseorang, ajukan pertanyaan tentang debugging.

Tanyakan kepada mereka "bagaimana" mereka akan melacak bug dalam situasi tertentu.

Ambil satu langkah lebih jauh dan duduk di depan komputer dan lihat mereka men-debug suatu masalah.

Saya sering memberi kandidat situasi hipotetis ... misalnya, sistem produksi telah berhenti merespons. Apa yang kamu kerjakan? Mereka mungkin menjawab "periksa log" dan saya katakan "log menunjukkan tidak ada yang abnormal, kecuali bahwa tidak ada yang tertulis di dalamnya sejak masalah mulai terjadi". Dan itu terus berlanjut, sampai saya puas bahwa saya telah menilai kemampuan kandidat untuk memecahkan masalah.

Biasanya orang-orang dengan bakat bagus juga adalah orang dengan keterampilan debugging yang baik.

Selama wawancara, (tergantung pada senioritas mereka), Anda dapat memberi mereka tugas seperti puzzle seperti beberapa algoritma atau lebih. Itu cara sederhana.

Jika Anda bisa, Anda dapat mencetak kode dari beberapa pekerjaan, tanyakan orang tersebut apakah ada yang salah di sini dan jika demikian bagaimana cara memperbaikinya.

Saya tidak begitu suka mengajukan pertanyaan wawancara yang membingungkan yang cenderung berfokus pada kemampuan orang untuk membaca dan memperbaiki sintaksis.

Selama wawancara, minta mereka untuk memberi tahu Anda tentang bug yang mereka perbaiki di masa lalu dan langkah-langkah yang mereka gunakan dalam debugging.

Buat mereka memberi tahu Anda tentang apa yang telah mereka lakukan dalam pekerjaan terakhir mereka, tugas pekerjaan rumah, dll. Dan apa yang mereka lalui dalam menemukan masalah.

Saya akan berbagi pengalaman bersama dengan perspektif rekrutmen tentang uji keterampilan kandidat dalam debugging. Saya terpaksa melakukan wawancara yang memiliki tiga tahap. Tahap kedua adalah "kasus praktis". Saya tidak tahu lebih banyak pada saat itu. Sementara di sana saya diberitahu ada sistem yang berhenti bekerja dan mereka tidak tahu. Beberapa bug ada di belakang.

Itu diatur sebagai desktop jarak jauh ke lingkungan pengujian yang lama. Mungkin ke lingkungan yang tidak terhubung atau terisolasi. Proyek ini adalah beberapa bentuk web dengan beberapa kontrol ASP.NET dan kode-file kode terkait. Filefile disebut semacam lapisan bisnis yang saya hanya punya dll, tidak ada kode sumber dan deskripsi metode. Bentuk Web melakukan fungsi CRUD yang dapat Anda harapkan. Juga fungsi pencarian kecil. Lapisan bisnis, pada gilirannya, berbicara dengan Views dan SP di server sql.

Mereka memecah beberapa bagian pada tingkat yang berbeda. Saya diberi kertas dengan gejala. "Tidak dapat mencari" "Bidang 'wilayah' menghilang setelah pembaruan terakhir" dan semacamnya. Seperti yang dapat Anda terima dari pengguna Anda.

Saya tidak ingat semua detail tetapi setidaknya bidang tabel diganti namanya, yang mengarah ke SP yang rusak, yang digunakan oleh fungsi pencarian. Itu berarti tidak ada kesalahan dalam VS dan tidak ada kode sumber BL untuk melacak nama bidang. Parameter SELECT terhadap Sqlcommand salah eja dan menyebabkan webform tidak berfungsi. Juga bidang dihilangkan yang merupakan bidang yang hilang di GridView (Autogeneratecolumns). Tombol ASP.NET dirujuk ke sesuatu yang harus dimaksudkan sebagai metode duplikat, disempurnakan, dan "lupa" untuk mengarahkan tombol ke metode baru.

Juga hal sepele seperti menggunakan judul dalam tag html yang tidak mengizinkannya. Tag ALT yang berlawanan juga dihilangkan dalam kontrol yang mengharuskannya. Ada juga beberapa kesalahan dengan tag html tertutup yang tidak benar tetapi tidak berfungsi. Tidak yakin apakah semua itu adalah kesalahan playhouse-project-murni atau mungkin proyek yang sama untuk perekrutan yang berbeda. Saya tidak pernah bertanya. Tingkat kesulitan tentu saja harus sesuai dengan kebutuhan perekrutan.

Tes semacam itu mungkin harus disaring (tidak diikuti) untuk melihat, setelah wawancara, bagaimana debugging dilakukan. Bagi saya sendiri pada tahap itu, saya menemukan tes itu sedikit konyol, tetapi itu juga akan menjadi poin besar. Jika itu benar atau tidak, harus bernilai banyak memiliki kandidat di tempat yang tepat.

* Saya pikir tes itu membuktikan para kandidat / keahlian saya untuk *
* Menganalisis sistem asing
* Menggunakan informasi minimal untuk menemukan kesalahan dan bug
* Di bawah tekanan waktu dan tanpa seseorang membantu Anda, kode dianggap koreksi
* Tingkat pengetahuan yang berbeda;
** sql db dan prosedur tersimpan,
** penggunaan dll dalam proyek,
** teknik asp.net,
** arsitektur berlapis
** aspek berorientasi masalah

Tetapi juga hal-hal yang lebih jelas seperti menangani lingkungan pengembang, menemukan dan memahami alat Manajemen Server Db. Tentunya ada kandidat yang terlihat sangat bagus di atas kertas tetapi, dalam praktiknya, bisa terjebak pada tugas-tugas seperti itu.

Saya memilih masalah aktual yang saya temui yang relevan dengan posisi dan saya menyajikannya kepada kandidat seperti yang disajikan kepada saya. Tentu saja saya menawarkan mereka beberapa latar belakang umum, dan sejumlah kecil dokumentasi yang relevan seperti potongan kode atau diagram skematik.

Saya memberi tahu mereka bahwa tugas mereka adalah menyelesaikan masalah dan saya menawarkan untuk menjawab setiap pertanyaan teknis yang mereka miliki dan memberi tahu mereka hasil dari setiap percobaan yang ingin mereka lakukan. Jika mereka berkata, "Saya akan menempatkan probe lingkup di sini," maka saya akan membuat sketsa jejak apa yang mungkin mereka temukan. Jika mereka ingin memasukkan sebuah printfloop, saya akan memberi tahu mereka bahwa itu tidak pernah keluar (!) Atau mencetak "7" dan kemudian berulang kali "5". Jika mereka pergi begitu jauh di rumput liar sehingga saya tidak bisa memberikan jawaban yang berarti saya akan mengakui bahwa kita berada di jalur yang salah dan kembali ke tempat lain. Jika mereka menjadi macet, saya akan mengajukan pertanyaan atau memberikan petunjuk sampai kita bisa melanjutkan.

Yang ingin saya lihat adalah proses pemikiran yang tertib, tekad untuk mencapai solusi, pertanyaan dan eksperimen yang dipertimbangkan dengan baik, dan idealnya merupakan identifikasi masalah yang berhasil. Kadang-kadang saya memilih masalah yang terlalu rumit bagi seseorang untuk di-debug sepenuhnya dalam wawancara satu jam dan pada akhirnya saya memberi mereka jawaban nyata. Pada saat itu saya sedang mencari reaksi yang menunjukkan bahwa mereka terlibat dengan masalah dan pengalaman yang "aha" saat dan kepuasan untuk mencapai penyebabnya. Kandidat terbaik akan secara spontan mengajukan pertanyaan lanjutan pada saat itu, mencoba menghubungkan peta mental mereka dengan apa yang sebenarnya terjadi.

Duduk di komputer dengan beberapa simbol biner (dengan debug) sederhana yang segfault dengan referensi pointer nol atau + kode sumber + gdb dan lihat apakah mereka dapat menemukan penyebab crash?

Jika Anda meminta kandidat Anda melakukan tes kode pendahuluan, minta mereka untuk memodifikasi kode selama wawancara untuk memecahkan bug atau menambahkan fitur baru atau lebih baik dari keduanya. Jika Anda membuat spesifikasi tes kode cukup kabur, itu akan membuatnya lebih mudah untuk membuat test case dengan "bug" di dalamnya.

Menemukan "bug" dalam cuplikan kode kecil adalah situasi yang sangat artifisial. Saya kira itu mungkin membantu dengan cara yang sama seperti teka-teki dan permainan asah otak.

Pendekatan yang lebih komprehensif akan mengajukan pertanyaan perilaku tentang bagaimana kandidat telah melakukan debugging di masa lalu mengutip insiden spesifik dan kemudian menindaklanjuti dengan pertanyaan.

Seseorang yang pandai dalam pemecahan masalah akan dapat berbicara lebih dari sekedar fasilitas debug di IDE. Bagaimana dengan ... alat pelaporan bug, interaksi pengguna akhir, mereproduksi bug, analisis logfile, verifikasi?

Ada JAUH LEBIH BANYAK untuk debugging daripada menelusuri melalui blok kode dan setiap evaluasi keterampilan seseorang dalam debugging harus refect itu.

Berikan seseorang kode yang luar biasa yang dijalankan perusahaan Anda dalam produksi. Minta mereka untuk memperkenalkan bug halus. Tanyakan kepada mereka mengapa mereka memilih yang itu. Tanyakan kepada mereka bagaimana mereka akan menemukan dan memperbaikinya.

Poin bonus jika mereka menemukan bug dalam kode asli.

Gandakan poin bonus jika mereka dapat memperbaiki bug di kode asli.

Saya cenderung meminta orang untuk menjelaskan kepada saya bug paling sulit yang pernah mereka lacak dan perbaiki dan apa yang mereka lakukan untuk menemukannya dan memperbaikinya. Saya juga tahu bahwa jika bug yang paling sulit adalah sesuatu yang Anda harapkan hanya seorang pemula untuk menemukan kesulitan, maka kemungkinan mereka bukan pemecah masalah yang baik (kecuali ini adalah wawancara untuk level pemula). Jika itu adalah sesuatu yang benar-benar sulit dan mereka menggambarkan proses pemikiran mereka ketika mereka mencoba untuk melacaknya, maka saya bisa merasakan apa tingkat keahlian mereka. Yang membuat saya kagum adalah banyaknya orang yang melihat "rusa di lampu depan" dan tidak bisa memikirkan satu contoh pun dari sesuatu yang mereka lakukan yang rumit. Yah maaf seseorang yang meninggalkan masalah sulit bagi orang lain untuk memperbaikinya bukanlah seseorang yang saya tertarik untuk apa pun kecuali yang langsung putus sekolah,

Saya akan mengajukan beberapa pertanyaan agnostik teknologi seperti berikut:

• Bawa saya melalui semua langkah yang Anda ambil untuk mengidentifikasi penyebab utama dan memperbaiki bug (cacat)
• Bagaimana Anda menggunakan Call Stack saat men-debug aplikasi multi-threading

Ini bekerja sangat baik khususnya dalam wawancara telepon karena Anda hanya perlu orang itu untuk memberi Anda jawaban yang meyakinkan yang menunjukkan bagaimana dia benar-benar melakukan sesuatu sementara memecahkan masalah.