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


48

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?


14
Saya sebenarnya diberi kode untuk debug, di komputer, pada satu wawancara. Mereka telah memodifikasi kode sumber menjadi tar atau gzip atau sesuatu, dan ingin melihat bagaimana saya akan men-debug-nya.
wkl

4
Satu-satunya cara untuk memastikan adalah membiarkan dia melakukannya "hidup". Beri tahu dia sebelumnya apa lingkungan pengembangan Anda dan bahwa akan ada tes koding dan debug yang sederhana.

Bahkan tidak harus live, @ ThorbjørnRavnAndersen. Saya telah mewawancarai di beberapa tempat yang memberikan saya print-out fungsi kecil, bersama dengan spesifikasi apa fungsi itu, dan kemudian meminta saya untuk "menemukan bug".
quanticle

@quanticle Sama di sini, perusahaan saya memberikan tes pemrograman 5-pertanyaan (sekitar setengahnya adalah debugging) sebelum Anda dipertimbangkan untuk wawancara langsung. Rupanya itu menyingkirkan sebagian besar kandidat ...
Izkata

Berikan dia tumpukan jejak untuk dianalisis :-)
JustMe

Jawaban:


24

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.


1
+1 untuk perspektif yang baik tentang ini. Saya setuju tetapi ketika mereka berpikir mekanik, mereka lebih baik sekarang bagaimana bisa menggunakan alat. Sama seperti di mobil, seorang insinyur yang tidak mengerti atau tidak bisa menggunakan alat mekanik sama sekali bukan insinyur yang berkualitas.
maple_shaft

16
Jawaban ini tidak meninggalkan ruang untuk debugging insting. Seseorang yang bekerja dengan sistem, jenis kode, atau bahasa yang cukup, sering kali dapat "mencium" jalan mereka menuju apa pun yang funky sedang terjadi. Terkadang Anda tidak perlu mengetahui seluk beluk sistem untuk dapat menemukan kekurangannya.
Jordan

Pertama tidak ada yang namanya "debugging instingtual". Ada heuristik (alias "patah kaki petunjuk") yang akan digunakan para ahli. Begitu yakin. Jika ada heuristik yang tersedia maka para ahli akan menggunakannya secara efektif. Tapi heuristik itu bisa menggigit para ahli ini di pantat. Bacalah banyak pekerjaan yang dilakukan para ahli psikologi kognitif dan Anda akan melihatnya. Jadi, seorang ahli yang baik mungkin memiliki ide-ide bagus tentang dari mana harus memulai, tetapi mereka tidak boleh sepenuhnya bergantung pada perasaan itu. Dan mereka harus bisa menjelaskan, setidaknya sampai batas tertentu, perasaan itu.
ElGringoGrande

10
Saya harus tidak setuju 100% dengan hitam dan putih Anda jika hal pertama yang mereka lakukan berkomentar. Saya akan mengatakan bahwa jika seseorang berpikir bahwa menjalankan debugger bukan pilihan pertama yang baik dalam beberapa kasus maka orang itu juga bukan pemecah masalah yang baik. Jika masalahnya komunikasi terhenti, hal pertama yang akan saya lakukan adalah menjalankan debugger dan mencari tahu proses / utas / tugas mana yang diblokir atau berhenti bekerja. Alasan lain untuk menjalankan debugger adalah untuk mencoba dan melihat apakah masalahnya dapat diulang. Setelah Anda tahu cara memecahkan sistem, mencari solusinya menjadi jauh lebih mudah.
Dunk

5
@ElGringoGrande dia menyarankan kebalikan dari itu, dari apa yang saya baca. Intinya adalah bahwa orang secara alami menjadi lebih baik dalam debugging karena mereka menjadi lebih berpengalaman. Alat atau metodologi tidak sepenting seberapa efektifnya mereka. Itu sebabnya jawaban Anda tidak lengkap. Ada banyak cara yang valid untuk men-debug, termasuk menarik kursi dan menjalankan kode, mengajukan pertanyaan, dan lain-lain. Saya telah secara efektif men-debug program PHP besar dengan media cetak. Saya tidak suka melakukannya, tetapi sebenarnya tidak sebanyak tentang alat seperti pengetahuan tentang bagaimana sistem umumnya bekerja.
Jordan

15

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.


+1 daftar yang cukup membantu. Dan satu lagi diterapkan.
Dipan Mehta

8
Saya berpendapat bahwa debugging aplikasi multi-ulir adalah benar-benar berbeda dari debugging aplikasi single-threaded. Berbeda, dan jauh lebih sulit.
Bruce Ediger

20
@JarrodRoberson Brian Kernighan dan Rob Pike menulis dalam The Practice of Programming bahwa mereka masih lebih suka mencetak pernyataan daripada para pengingkar karena kurang sementara. Banyak orang lebih suka sistem logging yang baik yang memberi mereka pandangan rinci tentang jalur kode tanpa menghentikan program yang sedang berjalan. Juga lebih mudah untuk membaca file log kemudian men-debug dump inti. Jadi tes lakmus Anda mungkin menolak beberapa programmer yang baik karena tidak semua orang setuju bahwa debugger sama bermanfaatnya dengan pendekatan debugging alternatif (log, tes unit, pernyataan)
MetricSystem

12
Pernyataan cetak debug baik-baik saja dan dapat lebih baik daripada debugger terutama di mana konkurensi terlibat. Masalah Anda dengan mereka mungkin benar-benar dengan kompiler lambat.
Ricky Clarkson

8

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.


7

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.


6

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.


2
Kita semua debug program kita. Pada awalnya itu mudah karena programnya kecil dan mudah untuk memiliki semuanya di kepala Anda. Tetapi seiring bertambahnya dan semakin rumitnya debugging menjadi semakin sulit. Dan sekarang - beberapa orang masih dapat mengatasinya dan menemukan bug dalam jumlah waktu yang wajar dan beberapa orang hilang begitu saja. Mereka tidak tahu di mana harus fokus dan bagaimana mempersempit untuk menemukannya ...
Michal B.

1
@MichalB .: Kita semua debug program kita, tetapi beberapa orang akan menunjukkan pendekatan berprinsip sementara yang lain hanya secara acak mengubah hal-hal dan melihat apa yang terjadi .
Matthieu M.

Saya tidak mengerti mengapa Anda akan bingung. Menjadi pengembang dan pengelola yang baik adalah keahlian yang sangat berbeda. Paling-paling kebanyakan orang hanya terampil dalam salah satu dari ini atau yang lain, jika mereka terampil sama sekali (yang sayangnya mencakup sebagian besar pengembang).
Dunk

3

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.


3

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.


2

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.


+1 Jawaban bagus! Saya setuju bahwa pengembang perangkat lunak terbaik memiliki keterampilan debugging yang baik dan saya juga merasa bahwa menemukan kesalahan sintaksis tidak banyak menunjukkan. Sebagian besar IDE dan bahkan beberapa editor teks yang baik (Notepad ++) akan mengidentifikasi kesalahan sintaksis dalam bahasa umum. Namun saya tidak setuju bahwa teka-teki menunjukkan keterampilan debugging. Teka-teki menunjukkan pemikiran kritis yang merupakan keterampilan yang berbeda tetapi terkait.
maple_shaft

@maple_shaft terima kasih untuk (lagi +1). Benar, teka-teki tidak terkait langsung dengan debugging . Tapi itu baik untuk menilai bagaimana orang mendekati masalah - suatu hal yang tidak langsung.
Dipan Mehta

2
saya melihat puzzle dan saya seperti ewwwwwwww. Anda benar-benar tidak memiliki hal yang lebih baik daripada barang "gotcha"? dan bagaimana "senioritas" muncul? apakah ppl yang lebih tua seharusnya memecahkan teka-teki yang lebih sulit? apakah semua programmer yang baik (atau debuggers) adalah penggemar sudoku? Anda mungkin akhirnya mengganggu beberapa programmer yang benar-benar baik dan berbicara buruk di seluruh kota. pertanyaan gotcha adalah penghinaan <periode> tolong datang dengan sesuatu yang lebih baik laki-laki.
Chani

@ Scrooge Saya hanya memaksudkannya sebagai teka - teki pemrograman - saya belum pernah memainkan sudoku dengan ratusan wawancara yang saya ikuti.
Dipan Mehta

2

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.


2

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.


2

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.


1

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?


2
Semua ini memberi tahu Anda bahwa orang tersebut dapat menganalisis kode dan binari untuk menemukan referensi pointer nol potensial. Ini sebenarnya tidak menunjukkan keahlian penggunaan alat debugging umum.
maple_shaft

1

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.


1

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.


Saya suka berasumsi bahwa ada bug dalam perangkat lunak yang belum kami temukan. Ini seperti mencari kesalahan seismik. Pertanyaannya adalah bagaimana seseorang mencari tanda-tanda dongeng.
Christopher Mahan

1

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.


1

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,


1

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.