Bagaimana keterampilan yang digunakan dalam pertanyaan wawancara tipikal diterapkan dalam pekerjaan nyata? [Tutup]

Untuk pekerjaan pengembang aplikasi SQL dan C #, pewawancara biasanya mengajukan pertanyaan tentang hierarki pohon, grafik, dan daftar tautan terkait menggunakan C dan pointer murni. Dalam 3 tahun saya telah menghabiskan dalam pekerjaan saya, saya tidak pernah benar-benar harus

temukan jalur ke simpul ke-1 di sebelah kanan simpul yang diberikan yang merupakan kelipatan dari simpul yang diberikan

sebagai contoh

Saya dapat melihat bahwa keterampilan ini dapat digunakan dalam pekerjaan di mana Anda perlu menulis compiler, driver dan bekerja pada kernel OS. Selain itu, di mana lagi keterampilan ini digunakan?

Baca beberapa jawaban Joel di bawah ini.

Terutama perhatikan sesuatu seperti Schmiel si pelukis. Di tempat kerja, Anda mungkin tidak perlu menulis ulang daftar yang ditautkan, tetapi Anda tentu harus tahu di balik kap bagaimana cara kerjanya, sehingga Anda dapat menghindari Schmiel.

Pada dasarnya, jika Anda pergi ke dokter, Anda ingin dokter itu mempelajari anatomi. Meskipun dia hanya meresepkan Anda beberapa AntiHistamine, seorang dokter akan belajar di sekolah kedokteran bahwa obat-obatan tertentu buruk bagi orang-orang dengan 'fraktur kronis diamadabada pada tulang paha inferior' atau apa pun. Jenis pengetahuan mendalam tentang SEMUANYA dalam kekhususan itu kadang-kadang dapat membuat perbedaan antara hidup dan mati, dan dalam Teknologi Informasi antara hidup dan mati produk, atau pekerjaan.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

"... menghabiskan setidaknya satu semester mendekati mesin atau kamu tidak akan pernah bisa membuat kode efisien dalam bahasa tingkat yang lebih tinggi. ..."

"... kau pemrograman berdasarkan takhayul, sejauh yang aku ketahui: seorang dokter medis yang tidak tahu anatomi dasar, membagikan resep berdasarkan apa yang dikatakan oleh tenaga penjualan farmasi yang bekerja."

http://www.joelonsoftware.com/articles/CollegeAdvice.html

Mereka tidak. Banyak wawancara dilakukan oleh orang-orang yang tidak tahu cara mencari pengembang yang terampil , dan tidak tahu pertanyaan apa yang harus atau tidak mereka tanyakan.

Sebagian besar pewawancara tidak menanyakan pertanyaan teknis sama sekali, dan lebih berkonsentrasi pada hal-hal yang tidak berarti tetapi dapat diukur , seperti jumlah proyek yang telah Anda ikuti (lebih banyak lebih baik untuk pewawancara itu) atau gelar sarjana (lebih tinggi lebih baik untuk mereka) ). Mereka senang mempekerjakan seseorang yang menghabiskan waktu lima tahun di perguruan tinggi untuk belajar apa-apa dan kemudian menghabiskan sepuluh tahun melakukan lusinan situs web e-commerce, tetapi mereka tidak akan mempekerjakan seseorang yang meninggalkan perguruan tinggi setelah beberapa tahun dan sedang mengerjakan beberapa proyek-proyek besar yang menantang secara teknis.

Mengajukan setidaknya pertanyaan teoretis lebih baik daripada tidak mengajukan apa pun. Ini memiliki keuntungan memverifikasi bahwa orang tersebut memiliki pengetahuan teoritis yang cukup, dan bukan seorang pembuat kode yang mungkin memiliki pengalaman beberapa tahun dengan pemrograman, tetapi tidak benar-benar mengerti apa yang terjadi di bawah tenda. Pengembang yang tidak memiliki pengetahuan teoretis ini biasanya ¹ tidak tahu perbedaan antara daftar, daftar tertaut, pencarian atau kumpulan hash, dan menggunakannya secara bergantian.

Pertanyaan (teknis) baik, pertanyaan buruk

Selama wawancara, Anda mungkin menemukan pertanyaan mulai dari sangat baik hingga sangat buruk:

1. (Berbahaya) "Berapa panjang baris dari program kerja terpanjang yang Anda tulis dalam bahasa itu?"

   Pertanyaan ini jelas salah. Saya sudah menjelaskan mengapa dalam jawaban lain . Perusahaan tempat pewawancara mengajukan pertanyaan semacam itu memiliki peluang besar untuk mengevaluasi produktivitas pengembang di LOC / bulan. Jika saya harus memberikan saran: Anda tidak perlu pekerjaan seperti itu.

   Contoh ini berbeda dari hal-hal yang tidak berarti tetapi dapat diukur yang saya kutip di awal jawaban saya. Di sini, pewawancara juga menunjukkan bahwa ia bahkan tidak memiliki pemahaman paling mendasar tentang metrik dengan memilih satu yang terkenal berbahaya.

2. (Buruk) "Siapakah Dennis Ritchie?"

   Memiliki setidaknya beberapa budaya memang sangat berguna, tetapi mengajukan pertanyaan itu tidak tepat. Jika perusahaan mencari pengembang berbakat yang mampu menangani proyek pengembangan perangkat lunak dan menulis kode, fakta bahwa mereka tidak tahu nama orang yang menciptakan C dan Unix seharusnya tidak terlalu menjadi masalah.

3. (Baik) "Apa saja fitur baru dari .NET 4.5?"

   Pertanyaan ini jauh lebih menarik daripada pertanyaan tentang Dennis Ritchie. Jika kandidat tidak dapat berbicara tentang fitur baru di .NET 4.5, mengapa dia menyebut dirinya pengembang C #? Kurangnya pengetahuan tersebut:

   • Menunjukkan bahwa orang tersebut mungkin tidak benar-benar tertarik pada bahasa pemrograman, maupun komunitas .NET,

   • Menunjukkan bahwa orang tersebut mungkin kurang memiliki pengetahuan penting tentang fitur C # /. NET yang digunakan pengembang lain jika tidak setiap hari, setidaknya sering.

   Lihat juga jawaban oleh Jerry Coffin yang berisi analisis yang lebih rinci tentang pertanyaan-pertanyaan semacam ini.

4. (Rata-rata) "Yang mana yang lebih cepat, SSD atau RAM?"

   Ini mungkin berguna dan menunjukkan jika orang tersebut memiliki pengetahuan perangkat keras yang cukup, tetapi tetap saja, seorang kandidat yang tidak dapat menjawab pertanyaan ini seharusnya tidak ditolak.

5. (Rata-rata) "Bagaimana tumpukan dan antrian diterapkan?"

   Ini adalah jenis pertanyaan yang Anda bicarakan. Mereka teoretis, mungkin bahkan terlalu teoretis, tetapi mengetahui apa yang terjadi di bawah tenda dapat membantu menulis kode yang lebih baik.

   Saya tidak akan menolak kandidat yang tidak dapat menjawab pertanyaan ini, tetapi akan memeriksa lebih hati-hati jika dia benar-benar mengetahui hal-hal tersebut, misalnya dengan mengajukan pertanyaan terkait tetapi kurang teoretis:

6. (Bagus) "Bagaimana kamu bisa berjalan melewati pohon tanpa menggunakan rekursi?"

   Jika kandidat menjawab pertanyaan ini, berbicara tentang FILO / FIFO dan tentang manfaat dan kelemahan menggunakan tumpukan versus rekursi untuk traversal pohon, tidak masalah bahwa ia tidak dapat menjawab pertanyaan sebelumnya.

   Mengajukan pertanyaan ini juga merupakan cara yang baik untuk mendeteksi kandidat yang menghabiskan bertahun-tahun melakukan gelar CS mereka, tetapi tidak memiliki pengalaman lapangan.

Bagaimana cara mengajukan pertanyaan teknis yang bagus?

Komentar kojiro menarik dan layak untuk jawaban yang lebih panjang:

Terkadang Anda perlu merekrut seseorang karena mereka harus tahu lebih banyak tentang subjek daripada Anda, jadi menurut definisi Anda tidak memenuhi syarat untuk melakukan wawancara. Anda tidak bisa mendapatkan bantuan dengan andal bahkan melakukan wawancara untuk alasan yang sama. Yang terbaik yang dapat Anda lakukan adalah mencoba mengajukan pertanyaan berdasarkan di mana pun pemahaman Anda bersinggungan dengan domain masalah dan berharap Anda beruntung.

Menemukan pertanyaan yang bagus mungkin menantang, terutama ketika Anda mempekerjakan pengembang pertama Anda atau ketika Anda menyewa seorang pengembang yang diharapkan lebih terampil daripada semua pengembang yang benar-benar bekerja di perusahaan.

Berikut adalah tiga petunjuk yang dapat membantu:

1. Temukan teman / kolega yang Anda yakini ahli dan minta dia untuk melakukan review. Ini membutuhkan banyak kepercayaan, tetapi dapat banyak menguntungkan perusahaan Anda.

2. Temukan konsultan yang Anda yakini terampil dan minta dia membantu Anda atau melakukan bagian teknis wawancara.

3. Ketik "pertanyaan wawancara" di Google. Ini bekerja dengan cukup baik, dan biasanya menjelaskan kemungkinan jawaban. Contoh:

   • Python : sepuluh pertanyaan itu sepertinya cukup bagus. Mereka mungkin agak mendasar, tetapi akan membantu menyaring 95% kandidat yang tidak ingin Anda rekrut.

   • SQL oleh Dave Pinal, sangat baik seperti biasa.

   • C # : agak terlalu mendasar, tetapi sekali lagi, mereka akan menyaring 95% kandidat,

   • JavaScript : pertanyaan lebih terbuka, yang mungkin bukan hal yang baik untuk pertanyaan teknis jika Anda ingin wawancara singkat dan menyimpan lebih banyak waktu untuk pertanyaan non-teknis terbuka. Daftar ini masih membantu memfilter dengan mudah kandidat yang tidak memahami konsep dasar dalam JavaScript.

   Kelemahan dari pendekatan ini adalah bahwa kandidat dapat menggunakan teknik yang sama untuk melatih wawancara. Jika dia meninjau setiap pertanyaan dari situs web pertama yang dia temukan di Google, dia mungkin mendapat skor bagus, tanpa benar-benar memiliki keterampilan yang diperlukan.

^{¹ Ada beberapa pengembang yang tidak akan dapat menjelaskan apa itu B-tree (selain itu "beberapa struktur data"), tetapi masih dapat berkembang dengan benar.}

Dari pengalaman saya di perusahaan tempat saya melakukan banyak wawancara, ada peluang bagus bahwa orang yang diwawancarai tidak memiliki petunjuk tentang cara melakukannya dengan benar. Jadi mereka menyiapkan serangkaian pertanyaan teknis dan menghitung skor itu dan menjadikannya sebagai resume Anda. Namun ini memiliki banyak kelemahan dan tidak boleh dilakukan karena alasan berikut:

• Anda meminta pengetahuan titik. Jika programmer tidak pernah melakukan sesuatu di bidang itu, dia mungkin masih merupakan rekan kerja yang sangat baik, tetapi tidak tahu jawaban tertentu. Sebaliknya: jika seseorang telah siap untuk wawancara dan menemukan jawaban untuk pertanyaan tertentu di internet, Anda mendapatkan jawaban yang benar, tetapi orang itu mungkin tidak memiliki petunjuk tentang topik yang sebenarnya sama sekali.

• Orang-orang gugup dalam wawancara kerja. Otak memiliki fitur hebat ini untuk mematikan banyak area tingkat tinggi (seperti logika) jika panik, yang berarti: jika Anda gugup, Anda mungkin tidak memberikan kualitas jawaban yang Anda akan lakukan dalam situasi sehari-hari. Beberapa orang dapat menghadapi situasi yang penuh tekanan seperti wawancara, banyak yang tidak bisa.

• Dengan satu jawaban yang benar, Anda menguji keterampilan orang itu untuk menemukan jawaban tertentu. Ini adalah salah satu dari sekian banyak keterampilan yang dibutuhkan rekan kerja, tetapi bukan keterampilan yang hanya diperlukan. Oleh karena itu satu atau dua dari pertanyaan-pertanyaan itu harus cukup untuk menguji bidang pengetahuan itu, dan kemudian keterampilan lain harus ditanyakan. Wawancara yang hanya berisi pertanyaan pemecahan masalah menguji keterampilan yang sama berulang kali.

Apa pertanyaan tugas pemrograman yang baik?

Pertanyaan-pertanyaan terkenal "Bisakah Anda menulis program pendek" memiliki masalah besar yang kebanyakan programmer tidak dapat menulis satu baris kode tanpa IDE mereka membantu mereka. Tapi itu dalam situasi kerja sehari-hari tidak ada masalah sama sekali, karena programmer selalu memiliki IDE-nya yang membantunya. Jadi, menanyakan hal-hal seperti "Temukan kesalahannya", "Tuliskan 50 baris kode yang melakukan ..." atau bahkan pertanyaan sederhana perlu dipertimbangkan, bahwa pelamar tidak memiliki alatnya (IDE, Google) tersedia.

Saya misalnya dapat menjawab Anda pada dasarnya setiap pertanyaan dalam 1 menit jika saya memiliki Google membantu saya, tetapi tanpa koneksi internet saya tampaknya tidak berdaya. Saya menyebutnya memori outsourcing, dan alih-alih merintangi saya, itu sangat membantu saya untuk fokus pada apa yang benar-benar penting - memahami mekanika yang mendasari - karena segala sesuatu yang lain dapat dilihat. Tetapi jangan tanya saya tentang detail dari sembarang API, karena saya tidak tahu itu, saya punya Google untuk itu.

Yang mengatakan, pertanyaan tugas pemrograman yang baik tidak boleh fokus pada mengetahui API, atau keterampilan pengkodean khusus kecuali jika ini merupakan persyaratan mutlak untuk pekerjaan itu. Pengetahuan bisa diperoleh, jadi lebih baik untuk mengetahui seberapa baik orang itu dalam memperoleh pengetahuan daripada bertanya apa yang sudah dia ketahui.

Pertanyaan yang bagus untuk tugas pemrograman harus pendek, sederhana, dapat dikodekan dalam setiap bahasa hanya dengan beberapa baris kode dan - terutama - harus memberi tahu Anda sebanyak mungkin tentang bagaimana orang tersebut bekerja dan menemukan jawaban. Contoh:

"Tulis fungsi dalam bahasa pilihan Anda yang mengambil array bilangan bulat dan memesan ulang dengan cara yang bilangan bulat pertama adalah setelah yang terakhir, dan semua yang lain bergeser sesuai."

Pelamar pertama yang harus ditanyakan pada saat ini adalah: "Maaf ... bisakah Anda menjelaskan tugasnya?". Karena tidak ada programmer yang diberikan deskripsi yang jelas tentang apa yang harus dilakukan. Ini diikuti oleh penjelasan, bahwa kode dalam pertanyaan harus melakukan pergeseran kiri dari isi array dengan overflow yang ditambahkan ke kanan.

Tugas ini sangat sederhana, bahwa siapa pun yang lulus segala bentuk level pemrograman harus dapat menjawab dengan benar. Ini memperhitungkan bahwa programmer harus bekerja tanpa alat-alatnya dan menjadi gugup mengurangi kemampuan untuk berpikir secara logis. Namun itu masih memberi tahu Anda bagaimana orang memecahkan masalah hanya dari cara pertanyaan itu diucapkan dan dari cara orang mendekatinya, hanya karena pergeseran kiri bertentangan dengan naluri umum 'kiri-ke-kanan' dan memaksa orang untuk berpikir untuk Sebentar.

Ada banyak kemungkinan jawaban untuk pertanyaan ini, jadi mencermati cara kode dikembangkan adalah bagian yang penting, bukan jika solusi tersebut benar-benar berfungsi. Apakah tes pelamar batal? Bagaimana cara overflow disimpan? Apakah loop atau mem-set digunakan? Bagaimana pemohon memverifikasi kebenaran kode? Satu pertanyaan sederhana ini memberi tahu Anda seluruh biografi tentang bagaimana orang itu bekerja.

Apa pertanyaan pengetahuan umum yang bagus?

Pertanyaan yang baik mudah dijawab, memungkinkan sejumlah besar jawaban (disebut 'pertanyaan terbuka') dan memungkinkan Anda untuk belajar sebanyak mungkin tentang pelamar sebanyak yang Anda bisa dalam waktu singkat yang Anda miliki.

Contoh:

(Meminta programmer C ++): "Bahasa lain apa selain C ++ yang Anda ketahui?"

Ini adalah pertanyaan tingkat pemula, yang memberikan pemohon kesempatan yang adil untuk memberikan jaminan pada saat ini jika dia tidak tahu apa-apa tentang topik yang ditanyakan. 'Tidak' pada saat ini lebih baik daripada menyiksanya dengan beberapa pertanyaan lagi yang harus dijawab oleh semua orang: "Maaf, saya tidak tahu apa-apa tentang itu."

Saya juga akan memberi tahu Anda terlebih dahulu tentang semua bahasa lain yang dikenal orang, lebih jauh lagi Anda belajar betapa tertariknya orang itu untuk mendapatkan pandangan yang lebih luas tentang dunia pemrograman, atau jika Anda memiliki seseorang dengan hanya satu bahasa tunggal (dan karenanya fitur / teknik ) lihat.

(Selanjutnya setelah itu, katakanlah dia tahu Java): Apa tiga perbedaan teratas antara C ++ dan Java dalam pendapat Anda? "

Ini adalah pertanyaan terbuka yang memungkinkan banyak jawaban, sehingga pelamar memiliki peluang bagus untuk menemukan setidaknya tiga jawaban. Meminta tiga pendapat (pribadi) tidak hanya membatasi jawaban yang mungkin, tetapi juga memaksa pemohon untuk mengurutkan berdasarkan prioritas. Tetap saja (atau seharusnya) mudah dijawab.

Ini adalah pertanyaan sederhana yang menguji banyak pengetahuan mendalam tentang berbagai bahasa pemrograman. Seberapa dalam pengetahuan tentang topik-topik itu? Dari jawaban-jawaban itu Anda dapat menceritakan banyak hal tentang pengetahuan dan pemahaman aktual tentang mekanisme dasar bahasa pemrograman. Berapa banyak orang yang dihabiskan dengan rincian kotor, atau jika dia hanya seseorang yang menautkan berbagai fungsi API tanpa petunjuk nyata apa yang terjadi di bawahnya.

Konsep pertanyaan tingkat awal yang diikuti oleh pertanyaan pengetahuan mendalam yang sederhana dapat digunakan untuk sebagian besar topik lainnya juga. Selalu dalam skema ini: pertanyaan bail-out, pertanyaan verifikasi, pertanyaan mendalam. Contoh lain (dari wawancara Jawa):

1. "Bagaimana Anda menilai pengalaman Anda dengan pengembangan multi-utas?"
2. "Sebutkan apa yang menurut Anda tiga hal paling penting untuk dipertimbangkan saat mengembangkan aplikasi multi-utas."
3. "Silakan sebutkan tiga kelas dari Java API yang dapat membantu Anda mengembangkan aplikasi-aplikasi itu dan memberikan deskripsi singkat untuk apa mereka digunakan."

Tiga pertanyaan ini akan memberi tahu Anda lebih dari pertanyaan teknis apa yang benar-benar diketahui oleh pelamar tentang topik-topik itu, sementara adil untuk menjawab dengan mempertimbangkan tingkat pengetahuan dan tingkat stres.

Jadi pada saat seseorang bertanya kepada Anda 20 pertanyaan coding berturut-turut, Anda tahu bahwa dia pada dasarnya tidak tahu bagaimana cara mewawancarai seseorang dengan benar. ;)

Peringatan: ini ditulis sebagai (semacam) komentar pada jawaban @ MainMa, tetapi 1) terlalu panjang untuk ditampung dalam komentar, dan 2) Saya pikir ini menambahkan perspektif yang agak berbeda pada pertanyaan-pertanyaan konstruktif sehingga itu adalah jawaban nyata dalam dirinya sendiri. .

Dalam jawabannya, @MainMa mengklasifikasikan "Apa saja fitur baru dari .NET 4.5?" sebagai pertanyaan "baik".

Saya mohon untuk berbeda. Seperti yang dia ungkapkan, saya akan mengatakan ini adalah pertanyaan yang cukup biasa-biasa saja. Pertanyaan yang bagus akan lebih seperti: "Bagaimana kode yang Anda tulis hari ini berbeda dari kode yang Anda tulis N tahun yang lalu?" (untuk beberapa nilai N kurang dari tahun pengalaman yang tercantum dalam resume, lebih disukai sekitar 3 sampai 5).

Seperti yang dia ungkapkan, pertanyaannya adalah tentang menghafal. Sudahkah kandidat ini menghafal daftar fitur sepenuhnya? Secara hak, orang yang mengutip daftar Microsoft paling akurat haruslah pemenang.

Yang harus Anda pedulikan adalah pemrogramannya. Bagaimana ini memengaruhi kodenya? Manakah dari fitur-fitur yang benar-benar dia gunakan ? Lebih penting lagi, apakah ia menampilkan penilaian yang baik tentang kapan harus menggunakan fitur baru mana, dan kapan fitur yang lebih tua sudah cukup baik?

Hanya bisa mengatakan "LINQ" memberi tahu Anda hampir tidak ada yang berguna tentang kandidat. Dapat mengatakan: "LINQ telah membantu membuat kode saya jauh lebih ringkas dan mudah dibaca karena saya dapat mengekspresikan konsep X, Y dan Z secara bersih dan langsung, di mana saya sebelumnya harus melompati lingkaran api berikut untuk melakukan hal-hal itu." (atau yang serupa) memberi tahu Anda banyak tentang kandidat, kode seperti apa yang ia tulis, penilaiannya, fleksibilitas, dan sebagainya. Ini juga memberi Anda lebih banyak peluang untuk pertanyaan lanjutan tentang bagaimana orang ini berpikir tentang masalah, menulis kode, memikirkan kode, dan sebagainya. Akhirnya, ini memberi Anda ide yang jauh lebih baik tentang apakah ini seorang kandidat yang benar-benar memiliki pengalaman N tahun, atau seseorang yang memiliki pengalaman satu tahun, diulang N kali.

Ringkasan: dapat mengutip daftar fitur dari beberapa tahun yang lalu tidak ada gunanya, dan hanya memberi tahu Anda sedikit tentang kandidat yang mungkin bisa digunakan. Kemajuan kandidat sebagai programmer cenderung lebih menarik, jadi jauh lebih baik untuk menanyakannya secara langsung.

Kenyataannya adalah bahwa sebagian besar tugas sehari-hari yang dilakukan sebagian besar pengembang dalam kehidupan profesionalnya sepele; Itu berarti beberapa pertanyaan yang Anda hadapi dalam wawancara kerja mungkin tidak pernah menghadapi Anda dalam kenyataan, tetapi itu tidak berarti tidak ada gunanya mengajukan pertanyaan-pertanyaan itu.

Katakanlah ada posisi terbuka di perusahaan Anda dan saat ini Anda sedang mewawancarai orang-orang. Anda sudah memiliki 20-30 pengembang dalam antrian. Jadi bagaimana Anda memilih kandidat terbaik untuk posisi itu? Katakanlah tugas paling menantang yang harus mereka lakukan dalam pekerjaan itu adalah membuka file dari sistem file, membaca data baris demi baris, sedikit memodifikasinya dan mengembalikannya ke file asli.

Apakah Anda akan bertanya kepada mereka bagaimana Anda membuka file? Saya yakin Anda tidak dapat melihat perbedaan yang sangat besar antara jawaban. Jadi, Anda harus menemukan solusi untuk membedakan antara pengembang yang hanya tahu cara membuka file dan mereka yang bisa mengembangkan aplikasi real-time yang buruk. Meskipun Anda tidak ingin mereka membangun aplikasi seperti itu, tetapi Anda tetap ingin merekrut kandidat terbaik.

Seperti hal lain dalam hidup kita, ada beberapa poin yang Anda sadari bahwa Anda perlu pergi dan belajar lebih banyak. Jika Anda tidak tahu apa itu daftar tertaut, bagi saya sebagai seorang programmer, itu secara harfiah berarti Anda belum benar-benar mencapai titik itu dalam kehidupan profesional Anda untuk merasa bahwa Anda perlu pergi dan mempelajari hal spesifik itu. Mengapa? Hanya karena Anda tidak pernah terlibat dalam proyek yang cukup besar sehingga mengharuskan Anda untuk meningkatkan keterampilan Anda hingga tingkat itu. Jika Anda berada di level pemula, Anda bisa mengatakan saya tidak benar-benar memiliki pengalaman kerja untuk pekerjaan spesifik ini, tetapi tetap saja jika Anda tahu itu berarti Anda cukup termotivasi untuk menempatkan diri Anda pada potongan di atas rata-rata setidaknya.

Keterampilan yang diperlukan untuk melakukan tugas-tugas ini jarang penting. Keterampilan yang ditunjukkan dalam pendekatan untuk menjawab pertanyaan dan dalam dialog berikutnya adalah intinya.

Ketika saya mewawancarai pengembang, saya mencari (a) pintar (b) menyelesaikan sesuatu (c) akan cocok. Ada tingkat dasar pengetahuan teknis yang diperlukan untuk mengisi peran apa pun, yang harus berjalan dengan kemauan untuk belajar dan memperoleh yang baru keterampilan. Wawancara ini tentang memeriksa kotak-kotak itu.

Preferensi saya adalah membaca kode yang ditulis oleh pelamar. Saya tidak suka pertanyaan wawancara kaleng, tetapi mereka memberikan sesuatu untuk dibicarakan tanpa adanya kode. Saya lebih suka bertanya tentang RAII atau IOC atau implementasi IDisposable daripada daftar dan koleksi, tetapi apa pun akan dilakukan selama kita bisa mendapatkannya cukup teknis .

Ketakutan terburuk pewawancara adalah mempekerjakan seseorang yang sebenarnya tidak tahu banyak tentang pengkodean. Anda harus berbicara tentang sesuatu selain pengalaman kerja untuk menghilangkan kepalsuan.

Pertanyaan-pertanyaan ini untuk menyaring orang yang tidak dapat memprogram. Kadang-kadang orang yang tidak dapat memprogram tetapi tahu banyak hal-hal sepele melamar pekerjaan pengembangan, dan meminta mereka menulis sesuatu yang berguna dan non-sepele terlalu memakan waktu untuk wawancara.

Saya dapat melihat bahwa keterampilan ini dapat digunakan dalam pekerjaan di mana Anda perlu menulis compiler, driver dan bekerja pada kernel OS. Selain itu, di mana lagi keterampilan ini digunakan?

Bagaimana dengan menulis mesin pencari, server web, browser web, pengolah kata, spread sheet, editor gambar, program menggambar, server database, bioinformatika, program perdagangan, game, simulator fisika, dan sebagainya dan seterusnya.

Saya akan memberi Anda bahwa sebagian besar pekerjaan perangkat lunak melibatkan menarik data dari basis data, meletakkannya di layar, mengeditnya, menghapusnya dari layar dan memasukkannya kembali ke dalam basis data. Namun, meski begitu, Anda mungkin akhirnya menemukan aplikasi di mana kendala tidak dapat dipenuhi oleh fitur bawaan platform. Pada titik itu Anda bisa menyerah, atau menjangkau kotak alat algoritma dan struktur data dan mencoba memecahkan masalah.

Objek teoretis digunakan untuk kenyamanan karena Anda seharusnya tahu apa yang dimaksud dengan implementasi pohon / grafik / daftar rata-rata sehingga tahu bagaimana menyelesaikan masalah traversal acak, tetapi pertanyaan-pertanyaan ini bukan tentang objek teoritis sama sekali.

Mereka adalah tentang dapat bekerja dengan model abstrak, memahami masalah abstrak dan menyelesaikannya dengan algoritma apa pun. Ini adalah keterampilan pengembangan murni di sana, jadi itu pasti diperhitungkan. Inilah mengapa pertanyaan ini masuk akal, bukan karena mereka seharusnya akurat dalam situasi kehidupan nyata.