Apa cara terbaik untuk membedakan programmer yang sangat baik dalam wawancara kerja?


82

Dalam pengaturan wawancara: Apa cara terbaik untuk mengidentifikasi andal ketika seseorang adalah programmer yang sangat baik . Maksud saya, dia adalah salah satu dari mereka yang 10-15 kali lebih efisien / cepat / lebih baik daripada rekan-rekannya di bagian bawah spektrum.

Banyak dari kita telah mendengar tentang Masalah FizzBuzz sebagai cara untuk menyingkirkan yang lemah. Tentu saja, mengambil 5-10 menit untuk menyelesaikan masalah itu merupakan indikator serius bahwa seorang pelamar adalah kandidat yang lemah. Saya berpendapat bahwa indikator yang baik adalah mampu menyelesaikannya secepat Anda dapat menulis. Ini sepertinya tidak cukup.

Apakah itu mungkin sesuatu seperti memberinya program kereta yang cukup rumit, dan melihat seberapa cepat ia bisa menggosoknya dan mengidentifikasi semua masalah dengan itu?


Pertanyaannya mengasumsikan bahwa hal itu dapat dilakukan dengan andal.
Anthony


belum tentu. jawaban yang sah adalah 'tidak ada jalan sama sekali'
Claudiu

Jawaban:


65

Saya minta maaf kepada siapa pun yang tidak peduli dengan jawaban yang panjang, tapi saya pikir itu sangat penting untuk memenuhi syarat kandidat Anda sebelum Anda mempekerjakan mereka. Siapa pun yang melakukan sejumlah besar wawancara di industri ini tahu bahwa sebagian besar kandidat tidak akan bertahan selama 15-30 menit pertama wawancara, sehingga sebagian besar daftar ini tidak diperlukan. Hanya perlu diingat betapa mahalnya (baik secara finansial dan emosional) untuk memecat seseorang sebelum Anda mengabaikan daftar saya sebagai pembunuhan berlebihan. Saya sudah mencoba daftar topik wawancara saya di sini dengan urutan kepentingan.

Kecerdasan Umum (permainan asah otak / teka-teki logika)

Pengetahuan Ilmu Komputer

Latihan pemrograman

  • GCD , Factorial , Fibonacci , Menara Hanoi
  • String dan pembalikan daftar
  • Tentukan apakah daftar yang ditautkan sendiri memiliki satu lingkaran (dapatkah Anda melakukannya hanya dengan dua petunjuk?)
  • Temukan bug

Pengetahuan tentang teknik pemrograman berorientasi objek dan pola desain umum

Analisis algoritma (run-time O (n) kompleksitas dan persyaratan penyimpanan)

Penggunaan alat dan metodologi

Pengetahuan tentang kerentanan dan serangan keamanan umum

Matematika Dasar

  • Sistem angka (mengkonversi dari satu basis ke basis lainnya)
  • Teori probabilitas
  • Jarak antara dua titik pada bidang Cartesian (teorema Pythagoras)
  • Akar kuadrat (Heron of Alexandria, perkiraan yang berurutan)

Kriptografi

  • Kriptografi kunci publik
  • Kriptografi kunci-simetris
  • Fungsi hash
  • Protokol kriptografi (berbagi rahasia, bukti tanpa pengetahuan)

Matematika Terpisah

  • Logika
  • Tetapkan teori
  • Teori grafik
  • Teori informasi
  • Kombinatorik
  • Bukti (seperti keberadaan bilangan irasional, bilangan prima tak terbatas)

Anda mungkin juga ingin melihat buku Pemrograman Wawancara Terkena . Ini referensi yang bagus untuk topik ini.


10
Fiuh, itu pasti wawancara panjang.
Rick Minerich

8
Hari ini saya berusaha menyelesaikan "Crossing Bridges" dengan rekan setim kompetisi Pemrograman ACM saya. Satu-satunya perbedaan adalah bahwa kita harus menyelesaikannya untuk sejumlah orang. Kami membutuhkan waktu sekitar 30 menit untuk menyelesaikan untuk sejumlah N orang .. tetapi dalam pengaturan wawancara saya merasa seperti teka-teki adalah metrik yang buruk.

52
Dalam sebuah wawancara, teka-teki menghisap karena orang yang diwawancarai gugup, tidak berpikir jernih, dll. Selain itu, banyak teka-teki a-ha! ketik hal-hal yang benar-benar tidak memberi tahu Anda apa pun tentang kandidat.

11
Saya menemukan masalah matematika dengan kesulitan tinggi. Setelah Anda menyelesaikan gelar Ilmu Komputer selama 10 tahun, bagaimana Anda bisa mengingat bagaimana cara membuktikan angka irasional dan semacamnya?

14
Masalahnya dengan teka-teki adalah kebanyakan orang belum memecahkannya; mereka baru saja melihat jawabannya sebelumnya. Jadi, kandidat yang paling cerdas akan berpura-pura tidak melihat mereka dan mengerjakan jawaban yang sudah mereka ketahui dengan terbata-bata. Jika tujuan Anda adalah merekrut orang pintar, bukan orang yang menipu, maka teka-teki adalah pilihan yang buruk.
Kyralessa

28

Ah, pertanyaan abadi.

Saya melakukan banyak wawancara tahun ini (saya memiliki dua kandidat dijadwalkan besok), dan dalam pengalaman saya, mempekerjakan lebih banyak tentang perasaan perut dan keterampilan orang, dan lebih sedikit tentang pengetahuan teknis.

  1. Luangkan waktu Anda dengan Riwayat Hidup. Beberapa CV dapat ditolak dalam hitungan detik, beberapa membutuhkan waktu setengah jam. Terkadang saya berpikir tentang kandidat berdasarkan CV jauh lebih lama daripada saya mewawancarainya. Beberapa kali saya menyiapkan pertanyaan wawancara khusus untuk kandidat itu, meskipun saya biasanya tidak menyiapkan pertanyaan.

  2. Pengetahuan teknis - ada minimum yang saya inginkan, dan ini biasanya cukup mudah untuk diceritakan. Jika ragu, selama wawancara, bicarakan proyek yang ia sebutkan di CV, dan lakukan sedalam yang Anda butuhkan. Ini biasanya lebih dari cukup untuk memberi tahu Anda apa yang dia tahu dan apa yang membuatnya berdetak. Pendidikan tidak penting, masalah pekerjaan sebelumnya, kemungkinan proyek pribadi mendapat skor tinggi.

  3. Tanyakan tentang apa yang ingin ia lakukan dan ke mana ia ingin pergi dengan kariernya - apakah Anda membutuhkan apa yang ia miliki, dan dapatkah Anda memberikan apa yang diinginkannya? Juga, menjelang akhir wawancara, saya biasanya bertanya tentang gaji pilihan. Jika dia di luar jangkauan saya, atau jika saya tidak akan membayar sebanyak itu untuk apa yang dia tahu, di situlah kita mengakhiri wawancara.

  4. Yang paling penting, kandidat harus cocok dengan tim, dan saya harus merasa yakin bahwa kami akan dapat bekerja sama. Saya tidak perlu menyukainya, tetapi saya harus bisa menanganinya, dan dia harus bisa menanganiku. Jika bukan itu masalahnya, saya akan lulus, karena saya tidak akan dapat menggunakan pengetahuan teknisnya. Di sisi lain, jika ini masalahnya, dan jika dia cepat belajar, kurangnya pengetahuan teknisnya tidak akan mencegah saya mempekerjakannya.

Saya telah melatih gadis-gadis dari HR untuk memberikan saya beberapa CV segera setelah mereka mendapatkannya; Saya menjadwalkan wawancara secara pribadi, secepat mungkin (idealnya lusa setelah menerima CV untuk CV yang baik). Kemudian dia mendapat wawancara setengah jam atau satu jam dengan saya dan setidaknya satu rekan kerja (biasanya bos atau anggota tim saya), di mana saya mengenalnya dan menjawab pertanyaan apa pun. Bahkan jika saya menolak lamarannya saat itu juga, dia mendapat tur 20-30 menit dari perusahaan dan saya berbicara tentang apa yang kita lakukan dan bagaimana kita melakukannya. Lalu saya mengirimnya ke HR untuk tes psiko dan sedikit kertas benar-benar dasar coding / SQL. Kedua tes hampir tidak pernah memainkan peran penting dalam keputusan saya, itu lebih merupakan verifikasi yang saya nilai dengan benar dalam wawancara. Setelah hasil, itu adalah pembicaraan selama 15 menit di mana saya mengajukan tawaran kepadanya, dan jika kami menegosiasikan persyaratan yang kami berdua sukai, ia dipekerjakan.

Ini adalah proses yang harus saya perjuangkan melalui birokrasi perusahaan, setelah kehilangan beberapa kandidat hebat, dan yang berhasil karena saya yang memutuskan untuk merekrut (walaupun saya mendengarkan saran dari SDM dan rekan kerja, saya kata itu final). Lebih banyak pembuat keputusan, proses yang lebih lama. Semakin lama prosesnya, semakin Anda harus menjadi Google untuk mendapatkan yang terbaik.

Segera setelah saya yakin itu tidak cocok, saya mengakhiri wawancara, dia mendapatkan tur perusahaan dan sudah berakhir. Ini mungkin sesingkat dua menit di telepon saat menjadwalkan wawancara. Bahkan jika Anda menolak seorang kandidat, jual perusahaan tersebut. Jika Anda melakukan pekerjaan dengan baik, upah yang baik dapat datang dari mulut ke mulut dari kandidat yang ditolak.

Juga, satu tip. Kirim surat penolakan (atau email) untuk setiap aplikasi yang Anda dapatkan. Di perusahaan saya saat ini, saya biasanya menyerahkannya kepada HR (terlepas dari yang saya katakan saat wawancara), tetapi pada satu titik, tak ternilai harganya mendapat tanggapan yang menyenangkan dari kandidat yang ditolak di baris "TERIMA KASIH! Anda adalah perusahaan pertama yang sebenarnya menjawab bukannya membuatku bertanya-tanya apakah mereka akan membalas suatu hari! "


Pengujian psikologis?

5
@ Ink-Jet: tidak, pengujian psiko benar - kandidat diminta untuk menulis kode yang akan dikelola oleh seorang pria yang kejam yang juga tahu alamat rumahnya.

Itulah yang saya baca sebagai yang pertama kali, jujur.

@ Grundlefleck - ya, itu sudah benar. :)
Domchi

2
Jika saya mendapat surat penolakan Anda, saya akan berterima kasih. Saya ditolak melalui keheningan setelah melakukan wawancara telepon, dan itu menegangkan.
01d55

24

Jawaban ini sedikit di luar kotak, tapi saya pikir itu poin yang berharga.

Pemrogram terbaik jarang mewawancarai. Mereka tidak harus melakukannya . Jika perusahaan Anda secara khusus mengubah dunia, atau secara rahasia diselimuti kerahasiaan, atau beberapa programmer yang mereka hormati telah pergi ke sana, maka mereka mungkin melamar, tetapi biasanya programmer hebat mendapatkan pekerjaan melalui jaringan rekanan mereka, bukan dengan mengirimkan resume.

Jadi: cara terbaik untuk memberi tahu programmer yang hebat dalam wawancara kerja adalah dia tidak ada di sana .


2
sangat benar ... poin bagus. :)
Arnis Lapsa

5
Jadi .... "siapa yang kamu kenal" daripada "apa yang kamu lakukan"? Programmer yang benar-benar mengerikan juga mendapatkan pekerjaan mereka melalui teman dan keluarga. Oh, maafkan saya "jaringan rekan".
Philip

17

Setiap jawaban harus menyertakan contoh kode. Menyewa seorang programmer tanpa melihat kodenya menyukai mempekerjakan seorang koki tanpa mencoba memasaknya.


11

Mungkin seorang programmer "luar biasa" tidak datang kepada Anda untuk wawancara. Anda mungkin harus mencuri dia dari orang lain.


lakukan! jawaban ini tampaknya menjadi populer. Sama seperti saya harus mulai pergi keluar dan melamar pekerjaan ...
interstar

9

Salah satu cara untuk memberi tahu programmer yang bersemangat dari programer "Saya hanya ingin pekerjaan" adalah dengan menanyakan buku apa yang mereka baca minggu ini. Kemudian tanyakan kepada mereka tentang buku-buku yang telah mereka baca dalam beberapa minggu terakhir.

Saya telah menemukan bahwa pemrogram yang penuh gairah SELALU membaca, dan biasanya daftar akan menyertakan beberapa pemrograman / Komp. Sci. buku dalam daftar terbaru.

Ini bukan hanya tentang menjaga "dengan profesi" - programmer yang bersemangat memiliki keinginan dan cinta untuk pemrograman, dan cenderung melahap materi tentang berbagai topik - tidak hanya bahasa apa pun yang mereka gunakan sekarang, tetapi metodologi, bahasa lain (terutama baru atau "aneh" atau kuno), aspek lain IT (mungkin robot, atau AI, atau game, atau ...)

Jika mereka tidak memiliki daftar buku baru sama sekali, maka mereka mungkin bukan programmer, menurut pengalaman saya.

Tepuk tangan,

-R


8
Daftar buku terbaru saya hampir selalu fiksi. Bacaan teknis terbaru saya hampir seluruhnya online, karena itu lebih terkini.

1
Lebih baik lagi, tanyakan pada mereka buku apa yang mereka tulis bulan ini. :)

7

Ada skala waktu yang berbeda di mana seseorang bisa "cepat": beberapa orang pintar dapat memecahkan teka-teki sulit dalam hitungan detik, tetapi beberapa orang pintar menghasilkan banyak kode yang baik dalam sebulan, meskipun mereka mungkin tidak secepat itu dalam pertanyaan wawancara.

Tanyakan kepada para kandidat apakah mereka aktif dalam proyek open source mana pun di mana Anda dapat meninjau beberapa kode mereka, dan meluangkan waktu membaca arsip milis proyek-proyek tersebut dan melakukan log. Itu akan memberi tahu Anda jauh lebih banyak daripada apa pun yang dapat ditunjukkan oleh kandidat dalam wawancara. (Tentu saja ini tidak dapat menggantikan wawancara, karena tidak semua coders yang baik melakukan pekerjaan open source.)


7

Buku " Smart and Gets Things Done: Panduan Ringkas Joel Spolsky untuk Menemukan Bakat Teknis Terbaik " dapat membantu menemukan jawaban.

Daftar Isi:

  • pengantar
  • Bab 1: "Menekan Nada Tinggi"
  • Bab 2: "Menemukan Pengembang Luar Biasa"
  • Bab 3: "Panduan Lapangan untuk Pengembang"
  • Bab 4: "Menyortir Resume"
  • Bab 5: "Layar Ponsel"
  • Bab 6: "Panduan Gerilya untuk Wawancara"
  • Bab 7: "Memperbaiki Tim Suboptimal"
  • Lampiran: "Tes Joel"

Artikel oleh Joel "Panduan Gerilya untuk Wawancara (versi 3)" juga bisa membantu.

Dan artikel "Done, and Gets Things Smart" oleh Steve Yegge tentang topik tersebut.


4

Ajukan mereka serangkaian pertanyaan yang mengharuskan mereka membuat kode, dan minta pertanyaannya semakin sulit. Jika mereka tampaknya menikmati tantangan, Anda mungkin memiliki tantangan langsung.

Jika mereka tidak dapat menjawab pertanyaan mudah pertama, seperti "menulis loop untuk" atau sesuatu yang sangat mudah, maka Anda tahu orang ini tidak dapat membuat kode.


4

Minta mereka kode di papan tulis. Hanya dengan cara itu Anda dapat mengetahui apakah mereka tahu cara menulis kode.


Tidak tahu mengapa ini diturunkan. Jika seorang programmer tidak dapat menulis kode di papan tulis, apa yang membuat Anda berpikir mereka akan dapat menulisnya di komputer?
Kristopher Johnson

3
@ Kristopher: Jika seorang programmer dapat menulis kode yang bagus di komputer, apa yang membuat Anda berpikir mereka akan bisa menulisnya di papan tulis? Itu adalah lingkungan yang sangat berbeda.
David Thornley

"Tes papan tulis" tidak dimaksudkan untuk mensimulasikan pengkodean aktual. Ini adalah kesempatan untuk melihat bagaimana kandidat berpikir, apakah kandidat dapat menggambarkan apa yang mereka lakukan, seberapa cepat kandidat membentuk solusi di kepala mereka, dll. Seseorang yang hanya menatap papan tulis tanpa tahu apa yang harus ditulis mungkin akan memiliki masalah yang sama di komputer.
Kristopher Johnson

3

Anda terutama harus menilai pekerjaan yang telah mereka lakukan. Kode atau ide apa pun yang dihasilkan seseorang selama wawancara yang diliputi kecemasan adalah proxy yang buruk untuk apa yang sebenarnya dapat mereka hasilkan dalam tim.

Untuk melakukan tantangan pengkodean, gunakan IM dengan sesuatu seperti codepad.com dan biarkan mereka melakukannya dari kenyamanan rumah mereka sendiri. Apakah Anda menulis banyak kode di papan tulis di depan bos Anda, dengan tenggat waktu 30 menit dan bonus Anda di telepon? Bukan saya.

Jadi, apakah wawancara itu sia-sia? Tidak, tetapi penekanannya harus pada mereka menjelaskan apa yang telah mereka lakukan dan apa yang telah mereka kontribusikan.

Anda juga akan tunduk pada semua jenis bias psikologis setelah Anda bertemu seseorang secara langsung. Jangan sengaja menyewa seorang programmer karena mereka melakukan kontak mata yang lebih baik atau lebih tinggi daripada orang lain. Untuk rute sekitar ini, saya akan melakukan sebanyak mungkin wawancara melalui IM / email sebelum Anda bertemu mereka secara langsung.


Anda dapat membalikkan efek ini dengan melihat bias psikologis orang lain dalam kandidat yang mempekerjakan sejarah. Orang pendek yang pernah memiliki posisi senior dan mencapai sesuatu mungkin benar-benar sangat baik. Orang jangkung dengan sejarah yang sama akan, rata-rata tidak begitu baik dan bertahan pada poin halo.
Tim Williscroft

2

Bahasa tidak masalah. Logikanya. Maksud saya IDE dan compliers sangat bagus hari ini sehingga setiap programmer yang baik dapat mengambil bahasa apa pun (ok mungkin bukan assembler) dalam seminggu; menjadi layak dalam beberapa minggu dan menjadi sangat baik dalam beberapa bulan.

Ini otaknya yang harus Anda konfirmasi. Dan Anda melakukan itu pembicaraan saya. Saya meminta mereka untuk memecahkan masalah sederhana. Bukan dengan menulis kode tetapi dengan melangkah melalui logika mereka untuk mencari solusi.

Tapi saya akui, jika dia tidak bisa menulis satu putaran sederhana menghitung 1 sampai 10, Anda punya masalah.


1

Pertama-tama, ada satu cara Anda bisa mendapatkan ide sebelum wawancara dimulai:

Jika mereka memiliki blog atau berkontribusi pada satu atau lebih proyek sumber terbuka, lihat saja kode dan artikel yang mereka tulis. Pertama-tama, jika mereka telah melakukan semua ini maka mereka memiliki inisiatif untuk menyelesaikan sesuatu. Anda juga dapat membandingkan hal-hal ini dengan pengalaman kerja yang telah mereka daftarkan di resume mereka dan mendapatkan ide jika mereka pulang dan belajar lebih banyak setelah bekerja, atau jika mereka pulang dan melupakan pekerjaan setelah jam 5 sore.

Pada dasarnya, Apakah mereka memiliki hasrat tentang pemrograman atau tidak? Itu pertanyaan sebenarnya.


1

Memiliki programmer yang baik hadir dalam wawancara adalah yang terbaik menurut saya.

Hanya seorang ahli yang dapat menilai apakah pelamar hanya tahu banyak pertanyaan wawancara atau apakah dia benar-benar memikirkan masalah dan dapat menjelaskan secara terperinci. Ingat, Anda tidak ingin mempekerjakan orang untuk menyelesaikan teka-teki wawancara, Anda ingin mempekerjakan mereka untuk menyelesaikan pekerjaan yang sebenarnya.

Teka-teki adalah untuk mengecualikan orang yang tidak mendapatkan dasar-dasarnya dengan benar. Jika Anda ingin menguji keterampilan, siapkan beberapa hal yang Anda (atau "programmer baik") Anda dapat perincian dan fokus pada yang harus dipikirkan oleh pelamar untuk sementara waktu. Bagaimana dia mendekati masalah yang dia tidak segera tahu solusinya?


1

Saya tidak berpikir bahwa Anda harus berbicara tentang hasrat dalam wawancara. Terus terang, ini terdengar seperti sebuah perusahaan yang mencari 'hasrat' yang benar-benar berarti 'bekerja tanpa uang untuk ide'.

Gairah bahkan tidak menjamin keunggulan. Maksudku, aku menghabiskan hampir seluruh pemrograman hidupku, membaca tentang pemrograman, belajar bahasa-bahasa gila seperti Erlang atau Clojure dan aku tidak dibayar untuk semua itu. Namun saya payah dalam pemrograman.

Saya pikir programmer yang sangat baik harus memiliki jejak proyek yang sukses mereka telah terlibat aktif. Dengan demikian membuat programmer menulis apa pun di atas dasar FizzBuzz tidak perlu dalam wawancara. Bicara tentang proyek masa lalu mereka dan apa yang mereka lakukan. Apakah Anda mempekerjakan programmer untuk memecahkan kubus Rubik dan menghitung kelereng atau bekerja pada proyek perangkat lunak yang panjang dan besar dan melelahkan lebih dari 50 garis coe?


1

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

Dari artikel:


Kriteria dalam peluru

Jadi, secara ringkas, berikut adalah beberapa indikator dan indikator tandingan yang akan membantu Anda mengenali programmer yang baik.

Indikator positif :

  • Bergairah tentang teknologi
  • Program sebagai hobi
  • Akan membicarakan masalah teknis Anda jika didorong
  • Proyek sampingan pribadi yang signifikan (dan seringkali banyak) selama bertahun-tahun
  • Pelajari teknologi baru sendiri
  • Diakui tentang teknologi mana yang lebih baik untuk berbagai penggunaan
  • Sangat tidak nyaman dengan gagasan bekerja dengan teknologi yang dia yakini tidak "benar"
  • Jelas pintar, dapat melakukan percakapan hebat tentang berbagai topik
  • Memulai pemrograman jauh sebelum universitas / pekerjaan
  • Memiliki beberapa "gunung es" tersembunyi, proyek pribadi besar di bawah radar CV
  • Pengetahuan tentang berbagai macam teknologi yang tidak terkait (mungkin tidak ada di CV)

Indikator negatif :

  • Pemrograman adalah pekerjaan harian

  • Tidak benar-benar ingin "berbicara toko", bahkan ketika didorong untuk melakukannya

  • Pelajari teknologi baru dalam kursus yang disponsori perusahaan

  • Senang bekerja dengan teknologi apa pun yang Anda pilih, "semua teknologi baik"

  • Sepertinya tidak terlalu pintar

  • Mulai pemrograman di universitas

  • Semua pengalaman pemrograman ada di CV

  • Berfokus terutama pada satu atau dua tumpukan teknologi (mis semuanya terkait dengan pengembangan aplikasi java), tanpa pengalaman di luarnya


maukah Anda menjelaskan lebih lanjut tentang apa yang dilakukannya dan mengapa Anda merekomendasikannya untuk menjawab pertanyaan yang diajukan? "Jawaban khusus tautan" tidak diterima di Stack Exchange
agas

0

Seorang programmer yang baik akan dapat bekerja dengan rekan-rekan spektrum yang lebih rendah juga. Selama mereka dapat melakukan tes dan tidak berkubang dalam ego mereka maka Anda memiliki kandidat yang bagus, bukan?

Tes fizzbuzz itu agak lucu. Solusi yang bisa saya pikirkan menggunakan operator modulo. Yang saya hanya tahu dari bekerja koordinat pemetaan karakter-lembar (tidak pernah disebutkan di sekolah atau perguruan tinggi). Apakah programmer rata-rata bahkan tahu tentang itu atau apakah saya memiliki pendidikan omong kosong?


Saya terkejut bahwa Anda tidak menemukan operator modulo. Saya diperkenalkan dengan berbagai bahasa yang telah saya pelajari sepanjang tahun.

2
Jika Anda mengambil jurusan CS di perguruan tinggi, operator Modulo adalah Programming 101

secara mengejutkan hal-hal seperti bit-shift dan modulo dilewatkan di perguruan tinggi
Claudiu

Saya pikir itu tergantung pada hal-hal apa yang mereka coba ajarkan kepada Anda di perguruan tinggi. Saya tidak berpikir saya pernah menggunakan modulo dalam masalah dunia nyata, atau mengajarkannya secara eksplisit. Tapi itu sangat umum dalam latihan semacam ini (dan dalam soal-soal ujian).
interstar

2
Sebenarnya, mereka berdua umumnya diajarkan di sekolah dasar; pada tahap itu mereka disebut sebagai "sisanya" dan "dikalikan dengan 10".
intuited

0

Salah satu kriteria yang saya gunakan adalah untuk melihat 'jenis' bahasa dan alat yang telah ia kerjakan, baik dalam proyek akademis atau profesional dan apa yang sebenarnya ia capai. Apakah dia selalu bekerja di level aplikasi menggunakan perpustakaan standar (selalu orang C # atau VB6?) Atau apakah dia pernah melakukan proyek menggunakan C di Linux berurusan dengan hal-hal hardcore seperti pointer, manajemen memori, rekursi, proses sinkronisasi, saling pengecualian, peristiwa dll Jika dia selalu menggunakan konsep inti dan fundamental ini di bawah lapisan abstraksi, saya akan ragu.

Ini jelas di samping membuatnya menulis kode. Tidak ada yang bisa menggantikan itu. Namun saya memenuhi kenyataan bahwa beberapa orang dapat menulis kode lebih cepat daripada yang lain, dan orang-orang memiliki waktu respons yang berbeda ketika dalam sorotan wawancara.


rekursi, sinkronisasi proses, saling pengecualian. Teknologi-teknologi itu sama pentingnya apakah Anda bekerja dengan C #, VB.NET, C atau bahasa assembly.

-1 - Ini salah besar. 'Jenis' bahasa dan alat adalah 100% 'tidak relevan'.
Morgan Herlocker
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.