Teka-teki logika yang rumit - Apakah mereka benar-benar berguna dalam menilai keterampilan pemrograman? [Tutup]


88

Dalam wawancara terakhir yang saya hadiri, saya diminta untuk memecahkan sebuah teka-teki di mana saya diharapkan untuk mengukur persis bla liter air yang diberikan dua ember dengan kapasitas - bla dan bla masing-masing. Saya tidak dapat menyelesaikan puzzle dalam waktu yang diberikan (~ 5 menit).

Pewawancara agak kecewa dan mengatakan seorang programmer harus memiliki keterampilan "ini". Saya tidak mendapatkan keterampilan apa yang dia bicarakan.

Saya selalu merasa aneh dengan teka-teki semacam ini yang biasanya ditanyakan pada pemrograman wawancara kerja. Saya tidak mengerti apa, jika sama sekali, hubungan antara teka-teki dan pemrograman seperti itu. Tepatnya keterampilan apa yang ingin dinilai oleh pewawancara dengan teka-teki seperti itu?


20
sepertinya Die Hard 3 jug puzzle youtube.com/watch?v=lZ64IR2bz5o
JF Dion

64
Satu masalah besar dengan pertanyaan semacam itu adalah bahwa mereka sering mengukur apakah pemohon telah melihat masalah itu sebelumnya, dan "telah melihat banyak teka-teki logika" bukanlah kriteria perekrutan yang benar-benar bagus.
David Thornley

37
Ini hanya praktik perekrutan voodoo. Orang lain menanyakan pertanyaan-pertanyaan ini sehingga mereka merasa seperti yang seharusnya. Mereka tahu bahwa tidak menjawab pertanyaan itu "buruk" dan menjawab itu "baik", tetapi mereka tidak bisa memberi tahu Anda mengapa di luar non-jawaban seperti "pengembang membutuhkan keterampilan ini". Mereka membuang-buang waktu dan indikator bahwa pewawancara bukanlah pewawancara yang kompeten.
Rein Henrichs

5
Ya, tes ini tidak sebaik itu. Tapi, itu bagus ketika seorang programmer setidaknya memiliki sedikit minat pada teka-teki ini. Saran saya: pelajari saja teka-teki, lulus wawancara, dan kemudian putuskan apakah Anda ingin bergabung.
Pekerjaan

10
Saya akan menanyakan hal ini selama wawancara dengan harapan dapat menemukan kandidat yang bertanya, "Apa hubungan ini dengan pemrograman?" dan membuat mereka tawaran sebelum mereka keluar dari tempat parkir.
JeffO

Jawaban:


97

Beberapa orang meminta mereka untuk mengukur kemampuan dan pendekatan Anda dalam memecahkan masalah. Secara pribadi, saya tidak berpikir bahwa teka-teki seperti itu memberikan indikator yang akurat. Di "dunia nyata", Anda memiliki lebih dari lima menit untuk mencari tahu apakah Anda berurusan dengan nampan pengemasan vs masalah back pack , misalnya. Awalnya, kadang-kadang mudah salah paham masalah yang dihadapi sampai Anda berada di tengah menerapkan solusi yang salah. Itu terjadi pada orang dengan pengalaman 1, 5, 10 atau bahkan 20 tahun.

'Teka-teki' wawancara terbaik adalah yang Anda duduki di depan komputer untuk menyelesaikan masalah di domain tempat Anda mengklaim keahlian. Saya juga tidak suka pemikiran "Yah, seorang programmer harus bisa ..." karena tidak mempertimbangkan bahwa orang menjadi cemas ketika dipukul dengan sesuatu yang tidak terduga dalam pengaturan yang sudah membuat stres. Tentu, Anda bisa menyelesaikannya jika Anda punya waktu untuk memikirkannya .. dan mungkin Anda bisa menyelesaikannya lebih cepat jika Anda menyadari bahwa hidup Anda akan berakhir jika Anda tidak. Apakah Anda ingin bekerja di suatu tempat di mana hidup Anda akan berakhir jika Anda tidak dapat menyelesaikan masalah dalam lima menit ? Apakah Anda akan dipecat jika tidak bisa ?

Haruskah semua programmer hebat juga menjadi juara pemecah sudoku? Saya yakin banyak, tetapi tidak seperti prasyarat untuk kompetensi.

Saya tidak mengatakan bahwa Anda tidak harus diuji pada bagaimana Anda mendekati masalah, tetapi tes harus menyenangkan dan mengundang 'yang terbaik' yang harus diberikan pelamar, mengingat bidang keahlian mereka. Membuktikan bahwa Anda adalah sebagai cerdas sebagai karakter yang Bruce Willis menggambarkan tampaknya agak sia-sia, mengingat produsen menghabiskan jumlah yang cukup untuk mendapatkan adegan hanya tepat.

Dengan kata lain, jika Anda mendeteksi bahwa Anda sedang diwawancarai oleh seseorang yang kurang memahami apa yang sebenarnya akan Anda lakukan , maafkan diri Anda untuk pergi ke kamar kecil dan tidak pernah kembali.


8
Ini adalah perspektif yang harus dimiliki semua pewawancara. Selesaikan masalah di domain Anda dan komentar Anda tentang stres dan pertanyaan tak terduga setara!
Chris

20
+1 untuk Di "dunia nyata", Anda memiliki lebih dari lima menit untuk mencari tahu , jawaban yang bagus!
Semut

7
juga menyukai kenyataan bahwa mereka biasanya disajikan seolah-olah pewawancara berasal pertanyaan itu dan menyelesaikannya sendiri :)
RyBolt

10
Aku tertawa sangat keras excuse yourself to go to the restroom and never return!
Florian Margaine

Ya, saya selalu berusaha membuat pelamar merasa senyaman mungkin, jadi saya benar-benar dapat mencoba mencari tahu seberapa baik orang itu untuk pekerjaan itu. Meminta "kekuatan Anda" bukannya "apa yang Anda sukai?" dan teka-teki konyol alih-alih mengkode filosofi tidak akan memberi saya indikasi tentang seberapa baik orang itu untuk pekerjaan itu.
winkbrace

56

Microsoft mulai menggunakan pertanyaan-pertanyaan ini di awal 1980-an. Ketika Microsoft menjadi sangat sukses, perusahaan lain mulai menyalinnya, tetapi beberapa poin kunci hilang dalam terjemahan.

Pada saat itu, Microsoft berusaha untuk mengisi banyak posisi teknis tetapi non-pemrograman: penulis teknis, penguji, dukungan telepon, dll. Ini bukan pekerjaan umum pada masa itu, dan orang-orang dengan pengalaman aktual di bidang ini sulit untuk Temukan. Sebagai alternatif, Microsoft berpikir mereka dapat merekrut orang yang benar-benar pintar, pintar, fleksibel, dan melatih mereka dalam pekerjaan. Karena orang-orang ini tidak memiliki latar belakang pemrograman, mengajukan pertanyaan pemrograman kepada mereka dalam wawancara tidak ada gunanya. Teka-teki dipilih untuk mencoba dan menunjukkan orang-orang yang pintar dan memiliki keterampilan analitis yang sangat baik. Pemrogram umumnya diberi masalah pemrograman papan tulis, meskipun mereka mungkin juga diminta teka-teki saat makan siang atau makan malam.

Pertanyaan-pertanyaan ini tidak pernah dimaksudkan untuk lulus-gagal. Mereka dimaksudkan untuk menjadi awal pembicaraan tentang bagaimana Anda akan mengatasi masalah, dan bagaimana Anda memikirkan masalah yang belum pernah Anda lihat sebelumnya. Satu-satunya cara pasti untuk "gagal", adalah menolak untuk mencoba menyelesaikan masalah. Pada saat ini, ini adalah strategi baru, dan Anda tidak bisa hanya melihat pertanyaan di Google.

Sunting:

Beberapa saat setelah menulis jawaban ini saya membaca The Computer Boys Take Over , sejarah komputasi institusional pada 1950-an dan 1960-an. Rupanya praktik meminta permainan asah otak dan teka-teki kandidat untuk pekerjaan pemrograman sudah ada sejak tahun 1950-an. AS sedang mencoba untuk mengomputerisasi sistem pertahanan udaranya dan IBM memperkirakan bahwa mereka akan membutuhkan beberapa ribu programmer untuk melakukan pekerjaan itu. Responsnya mengejutkan dan gelisah: hanya ada beberapa "pemrogram profesional" di seluruh dunia. Beberapa pendekatan telah dicoba: tes kemampuan pemrograman abstrak, merekrut ahli matematika sebagai programmer, merekrut pemain catur dan pemecah teka-teki silang, dan menyaring pelamar dengan teka-teki dan permainan asah otak.

Mereka akhirnya berhasil merekrut cukup programmer untuk menyelesaikan proyek, tetapi kesimpulannya adalah bahwa tidak ada metode skrining yang lebih baik daripada kesempatan untuk mengidentifikasi calon yang kemudian menjadi sangat sukses sebagai programmer.


49

Apakah ini bermanfaat? Tidak terlalu. Mereka dulunya sangat umum di Microsoft, mereka bahkan disebut "pertanyaan Microsoft", dan ada banyak buku yang ditulis tentang mereka, yang ini sebenarnya cukup bagus dibaca ..

Ada 2 masalah dengan mereka. Pertama, jika pelamar melakukan penelitian (dan membaca buku) mereka akan tetap mengenal mereka dan kedua, bahkan jika mereka dapat menyelesaikannya bagaimana hal itu menunjukkan bahwa itu akan menjadi dev / test / PM yang baik.

Untuk alasan ini mereka jarang diminta lagi di Microsoft. Jauh lebih baik untuk mengajukan pertanyaan pengkodean, atau pertanyaan pemecahan masalah yang tidak memerlukan jawaban "tipuan". Dengan kata lain Anda perlu mengajukan pertanyaan yang memungkinkan Anda untuk mengeksplorasi keterampilan dan perilaku pelamar saat mereka mencoba dan mengatasi masalah - sebagai pewawancara saya ingin mereka mengajukan pertanyaan, mencari solusi dan kemudian melacak kembali ketika mereka mencari tahu sebuah masalah, mungkin bahkan tidak menemukan solusi dalam waktu yang mereka miliki tetapi setidaknya menyelesaikannya dengan cara yang masuk akal. Itu mencerminkan pekerjaan kehidupan nyata. Saya tidak pernah harus mengukur 3 liter menggunakan 2 ember dan seekor ayam (atau apa pun pertanyaannya).

Yang mengatakan, saya diminta beberapa pertanyaan jebakan di waktu saya, dan sekarang saya menganggap diri saya sebagai ahli dalam mengangkut ayam dan rubah di perahu kecil dan menghitung masa hidup seekor lalat yang hidup di kereta. Saya tidak pernah menggunakan informasi ini, tetapi siapa tahu, mungkin suatu hari ....


26

Anda mungkin ingin membaca buku Bagaimana Cara Memindahkan Gunung Fuji? . Ini masuk ke alasan bahwa banyak orang menggunakan teka-teki dalam wawancara, dan pendapat saya adalah bahwa itu adalah kombinasi dari perilaku pemujaan kargo ( "Microsoft melakukannya, dan jika kita ingin menjadi sesukses mereka, maka kita lebih baik melakukan apa yang mereka inginkan). do " ) dan perpeloncoan bersaudara ( " ya ampun !, saya harus menjawab pertanyaan-pertanyaan itu dan Anda lebih baik percaya pria berikutnya harus menjawabnya! " ).

Sejarah pertanyaan-pertanyaan ini sebagai praktik wawancara dimulai dengan William Shockley pada 1950-an. Mereka adalah pertanyaan wawancara Lembah Silikon yang cukup umum yang ditanyakan oleh pewawancara karena pewawancara lain melakukannya (dan mungkin mereka tahu sesuatu yang tidak diketahui pewawancara ini?). Shockley dimaksudkan mereka sebagai tes kecerdasan, dan pertanyaan dengan 2 ember adalah pada salah satu tes IQ Stanford Binet asli kembali pada tahun 1916.

Sangat mungkin, orang-orang yang melakukan wawancara sebenarnya ingin melihat bagaimana Anda mencari jawaban, sehingga mereka tidak mungkin menghitung pertanyaan, seperti berapa banyak pompa bensin yang ada di kota Anda. Masalah-masalah semacam ini adalah Masalah Fermi . Dua posting blog menarik dari Jeff tentang hal ini adalah The Hardest Interview Puzzle Question Ever dan How Good an Estimator are You? Bagian III .

Secara pribadi, saya memiliki pendapat yang rendah tentang pertanyaan-pertanyaan semacam ini karena umumnya digunakan oleh pewawancara yang tidak tahu apa yang mereka lakukan, atau bagaimana mencari pengembang. Kecuali jika Anda akan bekerja untuk sebuah perusahaan yang membuat teka-teki / teka-teki, mereka termasuk dalam tumpukan sejarah bersama dengan "apa kelemahan terbesar Anda" (jawab kebenaran ini dan Anda mengakhiri wawancara Anda dengan cara yang buruk) atau "mengapa adalah penutup lubang bundar "(tidak semuanya).


3
+1, Tidak dapat menyetujui lebih banyak dengan paragraf terakhir!
missingfaktor

+1 untuk tautan masalah Fermi: agak menarik untuk melihat apakah seseorang dapat membuat taksiran dengan batasan kesalahan yang masuk akal. Anda juga bisa meminta rentang kepercayaan tentang "berapa banyak negara di sana?" Namun, saya pikir mengetahui tentang berpikir dengan cara ini, walaupun mengagumkan dan bermanfaat, tidak terlalu penting untuk pengembangan. Ini seperti pengembang yang mengetahui kalkulus atau statistik: itu bagus, tetapi mengatakan lebih banyak tentang latar belakang mereka daripada apakah mereka akan bagus dalam pekerjaan itu.
poolie

17

Yang lain telah memberikan jawaban yang telah saya pilih sebagai keharusan . Alasan saya menulis jawaban lain adalah karena apa yang ingin saya katakan mungkin tidak cocok dalam komentar, dan karena sesuatu harus dikatakan tentang bagaimana wawancara pekerjaan pemrograman yang baik bisa seperti.

Dalam wawancara bagus pertama yang saya ingat, kami banyak berbicara, tanpa terburu-buru. Pertama selama satu jam, di telepon, tentang desain berorientasi objek dan pro dan kontra dalam mengimplementasikannya di C ++. Kemudian, di situs, saya berbicara dengan beberapa orang tentang praktik pengembangan perangkat lunak mereka, integrasi, pengujian, kontrol versi, dan manajemen konfigurasi, tentang tim dan tanggung jawab, tentang teknologi dan tentang desain. Itu adalah wawancara sepanjang hari yang mencakup makan siang dengan orang-orang yang mewawancarai saya. Kalau dipikir-pikir, itu semua tentang apakah saya secara produktif akan cocok dengan apa yang sudah mereka lakukan.

Sejak itu, wawancara yang baik telah lama, satu hingga dua jam percakapan tentang pengembangan perangkat lunak. Tidak ada pertanyaan pemecahan masalah, tidak ada teka-teki, dan tidak ada tantangan pengkodean.

Jika saya akan mewawancarai seseorang untuk pekerjaan pemrograman hari ini, saya akan melanjutkan suka. Saya akan meminta pendapat tentang berbagai topik, dan mengesampingkan kedalaman:

  1. Apa preferensi bahasa pemrograman Anda? Mengapa?
  2. Bagaimana cara mendekati penanganan eksepsi?
  3. Bukankah manfaat dari desain berlapis mitos?
  4. Bukankah integrasi berkelanjutan merupakan beban efisiensi?
  5. Siapa yang menulis sepotong kode harus memilikinya, bukan?
  6. Apa yang Anda lakukan untuk masuk ke "aliran".
  7. Bagaimana seharusnya cacat yang dilaporkan dimasukkan dalam rencana proyek?
  8. ...

Itu adalah pertanyaan dengan lebih dari satu jawaban, dan itu semua adalah tentang topik yang harus dimiliki oleh pengembang perangkat lunak. Saya sepenuh hati setuju dengan jawaban yang menyebutkan masalah nyata sebelumnya yang dialami sebagai topik pembicaraan (bukan sebagai pertanyaan).

Studi yang lebih ilmiah tentang pengembangan perangkat lunak yang efektif sejak Peopleware mengatakan bahwa programmer terbaik adalah mereka yang memahami dinamika pengembangan perangkat lunak, bahkan jika mereka tidak memiliki IQ tertinggi. Saya lebih suka mengambil pemula yang ingin belajar daripada seseorang dengan npengalaman bertahun- 1tahun yang berulang tahun pengalaman berulang n. Bias pribadi saya adalah terhadap kandidat yang cenderung berpikir di luar kotak, dan pada saat yang sama tahu bagaimana masuk ke dalam kotak (saya) saat ini.


Jawaban yang sangat bagus. Offtopic: Contoh pertanyaan Anda # 3 membuat saya penasaran. Saya tertarik mengetahui lebih banyak tentang pendapat Anda tentang desain berlapis.
missingfaktor

2
@missingfaktor # 3, sebagaimana dinyatakan, adalah pertanyaan jebakan untuk memicu percakapan tentang hal-hal yang dilakukan dengan cepat versus hal-hal yang dilakukan dengan benar. # 4 dan # 5 sama. # 7 mungkin yang paling sulit, dan hanya cocok untuk peran kepemimpinan.
Apalala

1
@missingfaktor I, sekali lagi, memberikan jawaban untuk pertanyaan yang berbeda. Artikel Wikipedia ini, yang terkait, dan tautan eksternal menyediakan banyak informasi tentang mengapa pemisahan masalah sangat penting dalam desain dan konstruksi sistem yang kompleks: en.wikipedia.org/wiki/Modularity
Apalala

Masuk akal. Terima kasih banyak! :-) Sekali lagi, jawaban yang bagus. Membuat banyak poin bagus yang tidak disebutkan dalam jawaban lain di sini.
missingfaktor

Secara pribadi saya juga akan menambahkan pertanyaan tentang tooling. Orang yang peduli dengan alat yang mereka gunakan, cenderung menjadi programmer yang lebih baik. Sebagai pengguna Emacs, saya lebih suka pengguna vim daripada seseorang yang hanya mengangkat bahu dan tidak peduli.
Singletoned

13

Mereka dapat berguna dalam menilai keterampilan pemecahan masalah , yang tentu saja merupakan salah satu aspek kunci dari pemrograman.

Sebagai pewawancara banyak orang selama bertahun-tahun, saya biasanya tidak mengajukan pertanyaan jenis gotcha seperti yang Anda uraikan, tetapi saya mungkin bertanya sesuatu dan bertanya "bagaimana Anda memecahkan ...".

Harapan saya dalam hal ini adalah untuk mendengar Anda mengartikulasikan pendekatan Anda terhadap masalah tersebut. Data apa lagi yang ingin Anda kumpulkan? Bagaimana Anda menguji hipotesis Anda, dll.


1
Saya telah melakukan hal yang sama saat mewawancarai banyak orang. Inti pertanyaannya adalah untuk melihat bagaimana mereka bekerja menuju solusi, tidak harus jika mereka mendapatkan jawaban yang benar. Anda dapat melihat pemrogram yang baik cukup cepat hanya dengan menonton proses ini.
Dave Wise

2
@Dave, coba aku. Ketika saya memecahkan teka-teki seperti itu, saya biasanya mengambil selembar kertas, menggambar grafik, atau tabel, atau mencoret tokoh yang mewakili aktor, atau menulis angka yang entah bagaimana terkait dengan proses penyelesaian masalah di pikiran saya; Saya melakukan ini semua dalam keheningan yang kadang-kadang dipecahkan oleh gumaman yang tidak bisa dibedakan. Jadi, apakah saya seorang programmer yang baik?
P Shved

4
Heisenberg tidak akan menyetujui. Seseorang mungkin dapat menemukan solusi yang baik untuk suatu masalah tetapi tidak pandai mengkomunikasikan proses internal yang mereka gunakan. Meminta mereka untuk melakukan itu tidak hanya menguji kemampuan mereka dalam keadaan di mana mereka biasanya tidak akan bekerja tetapi juga akhirnya menjadi bias oleh kemampuan atau ketidakmampuan mereka untuk menjelaskan kepada orang lain bagaimana proses berpikir mereka bekerja. Mereka bahkan mungkin tidak menyadari bagaimana cara kerjanya sendiri.
Jason

4
Beberapa orang percaya bahwa hanya karena mereka ekstrovert maka setiap orang harus menjadi ekstrovert. Tim saya saat ini adalah sekelompok introvert dan sejauh ini tim terbaik yang pernah saya senang bekerja sama.
Dunk

2
@ Charles Apa yang saya katakan adalah bahwa orang introvert umumnya perlu MEMPIKIRKAN masalahnya sebelum mereka dapat menemukan solusi yang memuaskan mereka dan kemudian mereka dapat menjelaskan kepada orang lain. Itu sangat berbeda dari "Tidak dapat berkomunikasi". Orang ekstrovert umumnya perlu BERBICARA dengan mereka melalui penyelesaian masalah. Poster asli jelas mengharapkan gaya ekstrovert untuk menyelesaikan masalah.
Dunk

8

Ini hanya praktik perekrutan voodoo. Orang lain menanyakan pertanyaan-pertanyaan ini sehingga mereka merasa seperti yang seharusnya. Mereka tahu bahwa tidak menjawab pertanyaan itu "buruk" dan menjawab itu "baik", tetapi mereka tidak bisa memberi tahu Anda mengapa di luar non-jawaban seperti "pengembang membutuhkan keterampilan ini". Mereka membuang-buang waktu dan indikator bahwa pewawancara bukanlah pewawancara yang kompeten.


5

Itulah alasan lama-skool bahwa Anda harus memiliki keterampilan logika dasar; apa pun bisa diajarkan. Tapi itu tidak sepenuhnya benar. Membaca logika Boolean , kondisi dan loop, tidak sama dengan mampu memecahkan teka-teki logika .

Yang mengatakan, pada masa bahasa prosedural, mungkin benar bahwa seseorang yang dapat memecahkan masalah ini akan memiliki kecenderungan yang lebih tinggi untuk dapat menerapkan masalah dalam hal saklar. Tetapi menurut saya, pemrograman OO / Fungsional membutuhkan pola pikir teknik, yang sangat berbeda (meskipun tidak kontradiktif).

Secara pribadi, saya tidak yakin saya ingin pekerjaan di perusahaan yang masih menganggap logika lebih penting daripada keterampilan pemrograman praktis.

Penafian: Saya sangat pandai teka-teki logika dan mungkin tidak akan memulai pekerjaan ini tanpa alasan ini.


2

Pewawancara pasti merujuk pada pemecahan masalah dan keterampilan logika, yang merupakan bagian dari pekerjaan sehari-hari seorang programmer. Ketika diberi masalah, Anda harus dapat menganalisisnya, membagi, dan menulis solusi untuknya dengan menggunakan pendekatan yang paling optimal.

Anda bisa memperdebatkan seberapa baik puzzle seperti itu mewakili kemampuan Anda untuk melakukan ini. Saya tidak melihat manfaat mengajukan pertanyaan teka-teki alih-alih hanya menanyakan masalah pemrograman kehidupan nyata.


1

Pemrograman bukan tentang menulis baris kode, ini tentang menyelesaikan masalah untuk dan dari orang lain (pelanggan, pengguna, dll).

Kebetulan bagi pemrogram solusinya berbentuk program.

Jadi itu sebabnya penting untuk memiliki kemampuan pemecahan masalah dan mengapa itu diuji.

Yang sedang berkata, saya tidak yakin memecahkan teka-teki yang rumit adalah cara terbaik untuk menilai seseorang.


1

Teka-teki dalam wawancara terbagi dalam dua kategori: "teka-teki logis" (seperti yang Anda tanyakan) dan kategori "berpikir secara berbeda". Kategori berpikir berbeda (saya tidak yakin apakah mereka juga disebut teka-teki lateral?) Biasanya jenis ini: Berapa banyak daun yang ada di pohon itu? atau Berapa banyak penjahit yang hadir di kota Anda?

Saya baik-baik saja dengan "Teka-teki logis" karena mereka memiliki satu atau mungkin dua solusi paling banyak dan dapat dicapai dengan logika langsung. Dan saya percaya bahwa teka-teki logis bagus sampai batas tertentu karena proses yang diperlukan untuk menyelesaikannya adalah cara yang harus dipikirkan oleh pembuat kode dalam kehidupan nyata.

Jenis "berpikir secara berbeda" menggangguku tanpa akhir karena mereka memaksamu untuk membuat asumsi, dan kemudian, membuat beberapa perhitungan berdasarkan asumsi. Sederhananya, jika pewawancara Anda setuju dengan logika Anda tetapi tidak dengan asumsi Anda, atau sebaliknya, Anda telah kehilangan. Ada terlalu banyak ruang bagi pewawancara untuk tidak setuju dengan solusi Anda.

Ketika saya melakukan wawancara saya tidak meminta teka-teki logis. Alasan: Sebagian besar kandidat bahkan mereka yang memiliki 3-4 tahun pengalaman, gagal atau menyerah ketika saya meminta mereka untuk kode masalah buku teks sederhana seperti seri Fibonacci atau palindrom.

Masalah dengan teka-teki, bagaimanapun juga adalah bahwa programmer yang tidak begitu baik tahu bahwa hanya dengan mencari solusi untuk teka-teki umum seperti itu di internet mereka dapat mengesankan pewawancara. Sangat sedikit orang akan cukup jujur ​​untuk mengatakan bahwa mereka sudah tahu solusinya.


Dengan palindrom, apakah maksud Anda masalah yang sangat sulit untuk menemukan substring palindrom terpanjang dalam string input dalam waktu linier? :-)
b_jonas

1

Dua poin:

  1. Pemrograman terutama berbeda dari pemecahan teka-teki. Hal ini dijelaskan oleh Steve McConnell di "Code Complete":

    Apa? Anda tidak harus menjadi superinten? Tidak, tidak. Tidak ada yang cukup pintar untuk memprogram komputer. Memahami sepenuhnya sebuah program rata-rata membutuhkan kapasitas yang hampir tak terbatas untuk menyerap detail dan kapasitas yang sama untuk memahaminya pada saat yang bersamaan. Cara Anda memfokuskan kecerdasan Anda lebih penting daripada seberapa banyak kecerdasan yang Anda miliki. Seperti yang Bab 5 sebutkan, pada Turing Award Lecture 1972, Edsger Dijkstra menyampaikan makalah berjudul "The Humble Programmer." Dia berpendapat bahwa sebagian besar pemrograman adalah upaya untuk mengkompensasi ukuran tengkorak kita yang sangat terbatas. Orang-orang yang pandai pemrograman adalah orang-orang yang menyadari betapa kecil otak mereka. Mereka rendah hati. Orang-orang yang paling buruk dalam pemrograman adalah orang-orang yang menolak untuk menerima kenyataan bahwa otak mereka tidak setara dengan tugas. Ego mereka membuat mereka tidak menjadi programmer yang hebat. Semakin banyak Andabelajar untuk mengimbangi otak kecil Anda, semakin baik seorang programmer Anda . Semakin rendah Anda, semakin cepat Anda akan meningkat.

  2. Teka-teki semacam itu dapat berguna selama wawancara, tetapi Hanya jika pewawancara melihat Proses , bukan hasil itu sendiri.

Tapi idealnya teka-teki harus lebih rumit dan terkait pemrograman (seperti proyek kecil 2 jam), menurut saya. Masalahnya adalah bahwa pewawancara adalah orang-orang dan tidak memiliki "keterampilan wawancara" yang sempurna.


Bisakah Anda mengatakan apa yang salah dengan jawaban saya jika Anda memilih -1?
klm123

1
+1, karena itu jawaban yang bagus. Saya akan memutarnya bahkan sebaliknya, hanya untuk membatalkan downvote yang tidak dapat dijelaskan.
missingfaktor

0

Ada beberapa cara berbeda untuk memeriksa masalah tersebut:

  1. Mengetahui solusi sebelumnya. Di film ... Die Hard with a Vengeance ... jelaskan ini padaku ...? menjadi contoh mengetahui solusi untuk kasus di mana bla masing-masing 4,3 dan 5. Beberapa orang akan dapat dengan cepat memanfaatkan pengetahuan internal mereka tentang solusi masa lalu dan mengadaptasinya jika diperlukan. Ini biasanya apa yang saya percaya pewawancara harapkan atau mungkin bukan ide yang baik.

  2. Keahlian improvisasi kreatif. Ini akan menjadi kasus jika Anda tidak tahu solusi sebelumnya atau bahkan mengenali masalah sebagai sesuatu yang bisa dimodelkan sebagai persamaan Diophantine. Jadi pertanyaannya adalah seberapa cepat Anda dapat menggunakan apa yang diberikan dan menemukan solusi untuk masalah secara kreatif bersama dengan menjelaskan mengapa apa yang Anda miliki adalah solusi yang valid untuk masalah tersebut.

Entah bisa apa yang membuat satu melewati pertanyaan dengan cara yang memuaskan meskipun dalam setiap kasus ada juga sedikit tes keterampilan komunikasi seseorang karena seseorang juga dapat mencoba menjawab, "Apakah ini benar-benar relevan dengan posisi yang saya melamar? Kapan keterampilan ini terakhir digunakan? " yang mungkin mengarah pada dialog yang menarik jika pewawancara akan terbuka tentang apa sebenarnya yang mereka inginkan untuk melihat bahwa mungkin suatu pendekatan alternatif dapat dilihat lebih efektif di sini.


0

Ini bukan masalah yang sangat rumit. Hanya tiga langkah yang diperlukan, dan hanya ada dua pilihan di setiap langkah. Saya akan terkejut jika ada rekan saya yang tidak dapat menyelesaikannya dalam waktu yang sangat singkat. Kami tidak menghadirkan masalah seperti itu dalam wawancara, tetapi saya pikir masuk akal untuk mengajukan pertanyaan seperti itu. Mereka tentu lebih berguna daripada pertanyaan terperinci tentang sintaks atau perpustakaan.

OTOH, saya pikir masalah pemrograman lebih berguna.


0

Anda harus ingat bahwa tidak ada cara untuk mengetahui dengan pasti bahwa seseorang akan pandai dalam pekerjaan. Terutama pekerjaan CS karena banyak tantangan yang mungkin ada di toko tidak dapat diprediksi.

Jadi majikan potensial harus menebak kinerja masa depan Anda.

Derajat, rekomendasi, dan IPK dapat diperoleh dengan waktu / upaya dan rekayasa sosial, pengalaman kerja dapat diperindah dan / atau salah, dan tes standar sejujurnya terlalu mendasar untuk terlalu menunjukkan kemampuan. Jadi resume dapat memberikan beberapa indikasi tingkat upaya / komitmen dalam sejarah Anda, tetapi tidak ada yang akan berbicara dengan kemampuan Anda yang sebenarnya untuk memecahkan masalah-masalah sulit yang muncul dalam dunia ilmu komputer. Saya tidak bisa memikirkan cara yang lebih baik untuk memprediksi kemampuan semacam itu daripada beberapa teka-teki logika / matematika / CSy yang bagus.

Ingat itu adalah permainan tebak-tebakan, dan kenyataannya adalah bahwa semua hal yang sama dari kita lebih suka mempekerjakan seseorang yang mampu memecahkan teka-teki itu daripada yang tidak bisa.

Ya, Anda bisa mempelajari teka-teki wawancara, tetapi saya pikir Anda akan merasa terbakar jika teka-teki yang diberikan tidak cocok dengan yang Anda pelajari ... dan selama Anda tidak menghafal teka-teki dan solusinya, mungkin mempelajari teka-teki itu. sendiri akan membuat Anda menjadi orang yang lebih pintar dengan cara yang nyata, seperti halnya pendidikan yang sebenarnya.


3
Saya tidak tahu tentang Anda, tetapi ketika wawancara, saya lebih suka menggambarkan masalah sulit yang sebenarnya muncul di dunia perusahaan kami baru-baru ini, dan melihat bagaimana orang yang diwawancarai akan mendekatinya. Lucunya, belum lama ini ada klien yang melibatkan kami untuk mengukur jumlah air menggunakan dua ember. Kebanyakan yang kami lakukan melibatkan pemrograman komputer.
Carson63000

@ Carson63000 bukan bahwa masalah nyata yang ditemui perusahaan Anda akan menjadi ide yang buruk, tetapi sering kali menjadi penghalang waktu karena kekhasan masalah dunia nyata dan implementasi solusi. Itulah mengapa teka-teki yang melibatkan ember sangat bagus karena biaya masuknya sangat kecil, dan langsung ke bagian yang menarik.
8steve8

Saya membayangkan Anda dapat melihat analogi antara masalah bucket dan, katakanlah, menulis perangkat lunak untuk menyelesaikan tugas sambil menggunakan jumlah minimum pencarian disk, atau permintaan http.
8steve8
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.