Mengapa wawancara teknik SW sulit secara proporsional (vs wawancara penelitian)? [Tutup]

40

Pertama, beberapa latar belakang pada saya. Saya memiliki gelar PhD di CS dan memiliki pekerjaan sebagai insinyur perangkat lunak dan sebagai ilmuwan riset R&D, keduanya di Perusahaan Sangat Besar, Anda Tahu Sangat Baik. Saya baru saja berganti pekerjaan dan mewawancarai untuk kedua jenis posisi (seperti yang telah saya lakukan di masa lalu).

Pengamatan saya: Wawancara pekerjaan insinyur SW adalah cara, jauh lebih sulit daripada wawancara pekerjaan peneliti CS, tetapi pekerjaan peneliti lebih tinggi bayarannya, lebih kompetitif, lebih bermanfaat, lebih menarik, dan memiliki sisi atas yang lebih tinggi.

Berikut ini lingkaran wawancara khas untuk peneliti:

Wawancara telepon untuk melihat apakah penelitian saya sejalan dengan penelitian laboratorium
Secara langsung: berikan presentasi tentang penelitian terakhir saya selama satu jam (yang mungkin mewakili pekerjaan selama 9 bulan) dan jawab pertanyaan dari audiens
Wawancara tatap muka langsung dengan sekitar 5 peneliti, di mana mereka mengajukan pertanyaan yang sangat masuk akal pada pekerjaan / publikasi / paten saya, termasuk: pertanyaan teknis, di mana pekerjaan saya cocok dengan pekerjaan terkait, dan bagaimana saya dapat memperluas pekerjaan saya ke area baru

Inilah loop wawancara tipikal untuk insinyur SW:

Wawancara telepon di mana saya ditanya pertanyaan tentang algoritma dan mungkin melakukan pengkodean. Cukup standar.
Wawancara langsung di papan tulis tempat mereka mengebor F *** keluar dari Anda dengan minutia C ++ esoterik (mis. Bagaimana cara kerja panggilan fungsi virtual polimorfik), algoritme (membuat algoritma jalur semua-pasangan-terpendek bekerja untuk simpul 1B) , desain sistem (desain penyeimbang beban basis data), dll. Ini berlangsung selama enam atau tujuh wawancara. Konyol.

Mengapa ada orang yang mau tahan dengan ini? Apa gunanya bertanya tentang C ++ trivia atau menulis kode untuk membuktikan diri Anda? Mengapa tidak menjadikan wawancara SE lebih seperti wawancara peneliti tempat Anda memberikan ceramah tentang apa yang telah Anda lakukan?

Bagaimana wawancara kerja teknis untuk bidang lain, seperti fisika, kimia, teknik sipil, teknik mesin?

interview

— stackoverflowuser2010
sumber

12

Saya akan menebak dan mengatakan bahwa Anda mewawancarai di Google?

— Pemdas

2

@ Ethel: Jika Anda melihat di glassdoor.com, di mana orang-orang memposting gaji mereka secara anonim, Anda dapat melihat bahwa posisi peneliti membayar sekitar $ 10K hingga $ 20K / tahun lebih dari insinyur SW yang sebanding (lokasi yang sama, bidang yang sama). Secara anekdot, saya tahu gaji saya sekitar $ 25K / tahun lebih banyak daripada teman-teman saya yang lulus dengan gelar MS CS dari sekolah pascasarjana saya pada waktu yang bersamaan. Dan itu bukan hanya gaji; Saya telah melihat bahwa PhD memiliki lintasan karir yang lebih tinggi daripada yang tidak. Saya tidak memiliki bukti langsung, tetapi saya telah melihat bahwa PhD lebih mudah dipekerjakan ke tingkat CTO / VP.

— stackoverflowuser2010

3

Ini gila, tetapi tampaknya tidak meluas ke profesi teknik 'nyata'. Saya kenal banyak insinyur sipil dan mereka terkejut dengan apa yang saya katakan kepada mereka tentang beberapa wawancara saya di masa lalu ... banyak yang mengatakan apa yang Anda lakukan: "mengapa Anda tahan dengan itu?"

— red-dirt

3

@el fuser - Tergantung pada atasan. Wawancara teknik elektro yang saya miliki semua meminta saya untuk melihat kode PLC, menulis kode PLC, dan / atau melakukan sesuatu dengan diagram listrik. Pada satu, pertanyaan pertama adalah, "Apa hukum ohm?" Itu setara dengan tes fizzbuzz ... jika Anda hanya mengambil 4 tahun teknik listrik dan Anda tidak bisa mendapatkan yang benar, wawancara sudah selesai.

— Scott Whitlock

1

Scott: "jika Anda hanya mengambil 4 tahun teknik listrik dan Anda tidak bisa mendapatkan yang benar, wawancara sudah selesai." Saya khawatir saya mungkin gagal dalam beberapa dari mereka karena saya tertawa, atau dihina. Saya kira berasal dari lingkungan penelitian Anda menerima kompetensi dasar begitu saja.

— Omega Centauri

45

Hal ini relatif mudah dilakukan jika Anda secara teknis cukup kompeten untuk melakukan penelitian - Anda memiliki publikasi yang dapat dibaca oleh manajer perekrutan dan publikasi tersebut mungkin mengisyaratkan pada orang lain yang dapat mereka ajak bicara untuk memeriksa Anda.

Rekayasa perangkat lunak, di sisi lain, adalah suatu disiplin yang dipenuhi dengan pemborosan ruang yang tidak perlu untuk dilakukan dengan uji tuntas yang memastikan bahwa orang yang Anda pekerjakan sebenarnya dapat menulis kode yang Anda rencanakan untuk mempekerjakannya untuk menulis.

— Wyatt Barnett
sumber

2

untungnya hal-hal seperti github dan bitbucket membuatnya lebih mudah untuk melihat apa yang telah dilakukan orang itu. dapat meringankan (atau sangat mengurangi) kebutuhan untuk mengajukan pertanyaan uji tuntas.

— helloandre

3

tepat pada titik. sangat sulit untuk memisahkan yang baik dari programmer wannabe. bahkan dengan kode yang akan ditampilkan, akan butuh banyak waktu untuk membaca dan memahaminya sampai pada tingkat untuk menilai penulis. makalah penelitian, OTOH, ditulis untuk pembaca, dibutuhkan hanya beberapa jam paling lama untuk benar-benar memahaminya, biasanya yang buruk dapat dikenali dalam beberapa menit.

— Javier

3

Kode untuk ditampilkan adalah tipuan - bagaimana Anda tahu bahwa Joe Interviewee benar-benar menulis kode tersebut sehingga membuatnya benar-benar menulis kode?

— Wyatt Barnett

Saya punya artikel yang diterbitkan, dan sebuah buku di jalan. Biasanya layar teknis bisa hubung pendek karena pengetahuan saya didokumentasikan dengan baik, mereka ingin memastikan bahwa saya bahwa Mike Brown

— Michael Brown

1

Ada juga ketakutan yang sangat nyata di pihak manajer teknis dalam merekrut profesional yang benar-benar pintar dan berpengalaman - mereka yang mungkin tahu sesuatu yang lebih baik daripada mereka, karenanya mungkin berdebat untuk dan menentang solusi yang bukan hanya menjadi robot penulisan kode. Pada akhirnya, merekrut seseorang yang dapat membalikkan daftar tertaut dalam satu menit alih-alih merekrut insinyur yang benar-benar pintar adalah hilangnya semua orang yang menghasilkan keuntungan finansial dari produk tersebut. Seperti yang dikatakan Bjarne Stroustrup, "Sebuah organisasi yang memperlakukan pemrogramnya sebagai orang bodoh akan segera memiliki pemrogram yang bersedia dan mampu bertindak seperti orang bodoh saja."

— Leo Heinsaar

30

Akan mengambil risiko di sini.

Sebagai seorang peneliti dengan gelar PhD, Anda telah membuktikan kepada beberapa organisasi yang diakui nilai dan kualitas minimum Anda sebagai seorang peneliti. Anda berhasil mempertahankan tesis di depan dewan rekan-rekan Anda dan telah meyakinkan setidaknya satu publikasi peer-review untuk menerbitkan karya Anda.

Pengembangan perangkat lunak, di sisi lain, tidak memiliki standar kualifikasi. Orang-orang secara rutin mengembang basis pengetahuan mereka. Akibatnya, wawancara pengembangan perangkat lunak harus melakukan semua pekerjaan yang pertahanan PhD dan peer review dilakukan di dunia akademis. Mereka membuat Anda membuktikan bahwa Anda benar-benar tahu apa yang Anda bicarakan.

— Ryan Michela
sumber

17

Pertimbangkan ini sejenak.

Jika saya mencoba melamar pekerjaan peneliti CS ini, saya tidak akan melihat CV / Resume saya. Saya tidak akan memulai wawancara. Saya akan mendapatkan surat standar "tanpa gelar lanjutan" yang memberi tahu saya bahwa saya bahkan tidak memenuhi syarat untuk melihat CV saya.

Pertanyaan saya adalah ini: "Mengapa begitu sulit untuk mendapatkan gelar PhD?" Dan "Mengapa saya perlu PhD untuk menjadi peneliti CS?" "Mengapa begitu banyak penghalang dan rintangan?"

Mengapa ada orang yang mau tahan dengan ini?

Apa gunanya melakukan semua pekerjaan kursus itu dan membuat penelitian dicetak dalam jurnal dan konferensi? Mengapa saya tidak bisa melakukan riset saja dan mendapat bayaran lebih dari yang saya lakukan untuk teknik?

Mengapa mengandalkan sekolah pascasarjana dan publikasi untuk membangun kredensial? Mengapa tidak menjadikan wawancara penelitian lebih seperti wawancara SE di mana semuanya tergantung pada apa yang dapat Anda ingat saat wawancara?

— S.Lott
sumber

Saya agak mengerti apa yang Anda katakan. Jenis wawancara yang tepat harus sesuai dengan jenis pekerjaan yang tepat? Apakah itu interpretasi yang benar?

— stackoverflowuser2010

5

@ stackoverflowuser2010: Tidak. Saya hanya mengeluh bahwa dunia akademis jauh, jauh lebih sulit untuk didobrak daripada dunia rekayasa perangkat lunak. Anda mendapat wawancara sebagai SE. Saya bahkan tidak bisa masuk ke pintu di akademia. Perspektif Anda sangat buruk sehingga Anda tidak melihat perbedaan. Akademisi jauh lebih sulit.

— S.Lott

6

Saya punya teori. Penelitian biasanya dibayar dengan hibah, sehingga persediaan uang tunai tinggi. Mereka memiliki seember uang untuk dibelanjakan, dan mereka hanya perlu menemukan seseorang untuk dibelanjakan. Apakah Anda benar-benar mencapai sesuatu dalam posisi itu atau tidak, perusahaan / institusi tidak mencatat kerugian bersih karena itu hanya merupakan pengeluaran-biar bagaimanapun. Ada sedikit risiko dalam merekrut orang yang salah. Skenario kasus terburuk adalah mereka membuang semua yang Anda lakukan.

Di sisi lain, keberhasilan atau kegagalan produk yang ada ada di pundak pengembang sehari-hari. Khususnya jika Anda dalam pengembangan produk, Anda adalah pusat laba untuk perusahaan. Pengembang yang baik atau buruk memiliki dampak besar yang jauh melampaui biaya gaji mereka. Pengembang yang buruk sebenarnya menyebabkan kerusakan. Mereka dapat mengatur kembali tim, peluncuran produk, dll. Konsekuensi mempekerjakan insinyur SW yang buruk jauh lebih tinggi.

— Scott Whitlock
sumber

4

+1 Bahkan, uang yang dihabiskan untuk penelitian dibenarkan oleh makalah yang diterbitkan, jadi jika seorang kandidat memiliki daftar yang baik dari masa lalu, kemungkinan besar ia dapat menghasilkan lebih banyak, yang kemungkinan besar akan memuaskan siapa pun yang kebetulan memeriksa untuk apa dana penelitian digunakan.

— Péter Török

@ Péter Török: Ya !!! Dana yang memberikan hibah kemudian harus mengajukan laporan dan hal utama yang mereka lihat adalah jumlah makalah yang diterbitkan.

— sharptooth

5

Perusahaan kami juga "mengajukan banyak pertanyaan sulit" dan saya akan menjelaskan alasannya. Kami peduli apakah Anda benar-benar tahu bagaimana panggilan fungsi virtual dilakukan, tetapi bukan karena itu sangat diperlukan untuk pekerjaan yang akan Anda lakukan.

Sebaliknya, kami peduli karena kami perlu tahu seberapa cepat Anda dapat mempelajari hal-hal mendasar. Anda mengklaim pengalaman X tahun? Oke, kami akan mengajukan pertanyaan sulit untuk menemukan apakah Anda memiliki pengetahuan yang kuat.

Anda tidak tahu bagaimana panggilan fungsi virtual dibuat di bawah tenda, tetapi tahu segalanya tentang pembuatan profil dan optimalisasi? Bagus, kami kemungkinan akan mempekerjakan Anda - Anda telah memperoleh pengetahuan yang kuat di satu bidang dan karenanya Anda pasti akan mendapatkan pengetahuan yang kuat di bidang lain.

Anda mengklaim X tahun pengalaman "mengembangkan, men-debug dan memperbaiki kode C ++" dan tidak dapat menjelaskan dengan kata-kata sederhana bagaimana penunjuk menunjuk ke suatu objek? Maaf, kami tidak dapat mempekerjakan Anda - jika Anda tidak dapat melakukannya bagaimana Anda akan menjelaskan masalah yang lebih sulit ketika kami perlu membuat keputusan teknis yang rumit?

— sharptooth
sumber

Itu adil, tetapi apakah Anda memasang jaring yang cukup lebar saat melakukan komponen teknis atau fokus pada area tertentu?

— rjzii

@Rob Z: Kami mencoba mengajukan pertanyaan yang sangat sederhana tentang C ++ - sebagian besar tentang petunjuk dan rekursi, kami memberikan potongan sekitar lima baris kode yang diformat dengan baik dan meminta detail tentang apa dan bagaimana cara mereka melakukannya. Tentunya kita tidak pernah bertanya tentang pewarisan maya ganda dan urutan inisialisasi kelas dasar dalam hal pewarisan maya.

— sharptooth

Mengapa pertanyaan fungsi virtual begitu populer? Sepertinya kadang hanya itu yang harus dipelajari seseorang ...

— Jé Queue

@ Xepoch: Saya kira karena mereka sangat sederhana dan pengetahuan tentang pekerjaan batin mereka menunjukkan dengan baik apakah Anda peduli dengan apa yang terjadi di dalam atau hanya menyisipkan baris kode bersama-sama.

— sharptooth

Saya pikir saya memiliki keberuntungan dalam karier saya. Jarang saya pernah melihat cut & paste coder. Saya sudah tahu kode praktik buruk (termasuk saya sendiri), tetapi setidaknya itu adalah desain mereka sendiri :)

— Jé Queue

5

Jawaban singkat: ada banyak orang di pasaran yang mengaku tahu pemrograman, tetapi tidak bisa memprogram.

Komentar sampingan: Saya terkejut bahwa tidak ada yang memposting tautan ke esai FizzBuzz .

— Nikita Barsukov
sumber

Benar, tetapi di sana Anda dapat mengetahui dengan cepat apakah seseorang dapat atau tidak dapat memprogram berdasarkan satu atau dua masalah papan tulis. Masalah papan tulis tidak sama dengan menanyakan berbagai pertanyaan buku teks yang muncul selama beberapa wawancara.

— rjzii

3

Saya akan mengambil rute yang berbeda dan mengatakan bahwa masalahnya mungkin tidak terlalu banyak sehingga wawancara rekayasa perangkat lunak secara inheren lebih sulit, tetapi sektor yang berbeda mencari hal-hal berbeda yang menunjukkan gaya wawancara mereka.

Saya telah mewawancarai berbagai sektor yang cukup luas (misalnya perusahaan pemula, perusahaan kecil, perusahaan besar, departemen TI internal, perusahaan perangkat lunak, organisasi penelitian) dan mereka semua memiliki cara wawancara yang berbeda yang menurut saya biasanya cenderung ikuti pola berikut:

Start-up cenderung khawatir mengetahui bahwa Anda dapat mulai menulis kode sekarang dan dapat menangani lingkungan yang serba cepat. Karena itu, mereka cenderung khawatir dengan seberapa banyak Anda tahu dari kepala Anda karena mereka tampaknya tidak ingin melihat Anda menghabiskan banyak waktu mencari apa pun yang mereka anggap sebagai pengetahuan "inti". Mengakui Anda tidak tahu sesuatu mungkin bukan hal yang baik di lingkungan ini jika itu adalah sesuatu yang mereka harapkan Anda tahu.
Perusahaan kecil cenderung mencari hal yang sama dengan perusahaan baru dalam hal seberapa banyak yang Anda ketahui, tetapi tidak begitu peduli dengan seberapa baik Anda menangani lingkungan yang serba cepat (tergantung pada pekerjaan) dan lebih banyak lagi dengan jenis soft skill apa yang Anda miliki. bawa dan seberapa baik Anda akan cocok dengan perusahaan.
Perusahaan besar dan departemen TI internal tampaknya lebih peduli dengan memastikan bahwa Anda memiliki standar pengetahuan teknis, tetapi tidak begitu peduli jika Anda tidak tahu segalanya dari atas kepala Anda karena mereka mengantisipasi bahwa akan ada beberapa waktu yang diperlukan untuk melatih Anda tentang apa yang diharapkan perusahaan. Dengan demikian, ini adalah lingkungan di mana mengakui Anda tidak tahu sesuatu tetapi mau belajar dan belajar dapat dilihat sebagai manfaat.
Dalam lingkungan penelitian (yaitu dukungan pengembangan perangkat lunak bagi para ilmuwan dalam pengalaman saya) mereka cenderung peduli jika Anda dapat menulis perangkat lunak, tetapi lebih dari itu jika Anda bersedia melakukan apa yang diperlukan untuk memastikan bahwa Anda dapat mempelajari apa yang mereka lakukan sehingga mereka tidak harus memegang tangan Anda saat Anda mencoba menyelesaikan masalah. Karena ini juga merupakan lingkungan penelitian, mereka juga tampak tertarik pada seberapa tertarik Anda mempelajari hal-hal baru.

Sekarang, saya lupa menyebutkan perusahaan perangkat lunak (yaitu Google, Microsoft) karena mereka cenderung melakukan hal-hal mereka sendiri dan tergantung pada seberapa matang perusahaan itu dan kelompok apa yang Anda wawancarai, mereka mencari hal-hal yang berbeda.

Namun pada akhirnya dan seperti kebanyakan hal dalam hidup, semuanya tergantung. Secara pribadi saya telah menemukan bahwa beberapa perusahaan sangat fokus pada "pengetahuan buku" yang mungkin datang dengan mengorbankan kemampuan untuk benar-benar menyelesaikan masalah tingkat yang lebih tinggi di mana sebagai perusahaan lain tampaknya sangat peduli dengan seberapa baik Anda menangani masalah tingkat yang lebih tinggi (yaitu Anda dapat merancang skema untuk x ) dan beroperasi dengan asumsi bahwa mereka bersedia berinvestasi tiga hingga enam bulan untuk membuat Anda sepenuhnya mempercepat sebelum Anda menjadi sepenuhnya produktif.

— rjzii
sumber

3

Saya seorang pengembang perangkat lunak (c / c ++) dengan lebih dari 20 tahun di bidangnya. Jenis wawancara yang secara rutin kita lihat sekarang (permainan asah otak, penerapan struktur data, algoritma pencarian, dll. Di papan tulis) tidak biasa terjadi banyak kecuali untuk lulusan baru. Jika seseorang bekerja di perusahaan terkemuka untuk jangka waktu yang wajar, itu dianggap sebagai bukti kemampuan seseorang untuk menulis kode. Sekarang menjadi sangat sekolah dan saya tidak yakin mengapa. Sungguh, hal-hal khas yang mereka minta Anda kode, BISA dihafal begitu melakukannya di papan tulis benar-benar tidak membuktikan apa-apa. Pada proyek kerja, Anda akan menggunakan internet untuk meneliti sesuatu dan Anda tidak akan menulis btrees atau daftar yang ditautkan dari awal.

Saya pikir ini adalah mode manajemen lain - seperti scrum - dengan yang ini mungkin dimulai oleh google, amazon dan microsoft. Semua orang disalin sama seperti yang mereka lakukan dengan pangkat dan tarik Jack Welch ... ingat GE?

Jika Anda seorang manajer perekrutan yang membaca komentar saya, apa yang HARUS Anda tanyakan kepada kandidat adalah BAGAIMANA mereka akan menyelesaikan masalah tertentu. Alih-alih meminta mereka untuk membuat kode tabel hash, beri mereka masalah yang melibatkan tabel hash dan tanyakan bagaimana mereka akan menyelesaikannya.

Saya juga setuju dengan pengembang di atas posting ini yang mengatakan "memberi mereka masalah dunia nyata yang harus diselesaikan perusahaan"!

"tapi saya cenderung mengebom pertanyaan OOP / Warisan. Mengapa? Karena begitu dukungan untuk templat ditambahkan, saya telah menggunakan C ++ hampir secara eksklusif untuk Generic Programming."

Saya juga setuju dengan yang di atas. Ketika Anda bekerja untuk sebuah perusahaan, Anda menulis kode dengan cara MEREKA. Saya kadang-kadang masih berjuang untuk mengingat panggilan C ++ dengan sintaks referensi dari atas kepala saya karena arsitek senior di perusahaan tempat saya bekerja selama 15 tahun, lebih suka menggunakan pointer, bukan referensi. Dia adalah seorang programmer C lama. Jadi itulah yang kita semua gunakan.

— tamu
sumber

2

Sekali lagi, wawancara teknologi sewenang-wenang dan berubah-ubah.

Ada perbedaan besar antara memanggang seseorang di minutiae vs melihat apakah mereka tahu CS mereka. Seperti yang saya katakan di atas, saya memiliki lebih dari satu dekade pengalaman dengan C ++, tapi saya cenderung mengebom pertanyaan OOP / Warisan. Mengapa? Karena begitu dukungan untuk templat ditambahkan, saya telah menggunakan C ++ hampir secara eksklusif untuk Pemrograman Generik .

Saya telah mewawancarai beberapa perusahaan BigHouseHoldNameTech di Bay area & Seattle, dan salah satu wawancara terbaik melibatkan pertanyaan nyata yang harus mereka tangani saat bekerja, melibatkan struktur data dan algoritma [yaitu: Anda memiliki 300 miliar titik data terdiri dari XYZ. Bagaimana Anda menyimpan & mencari secara efisien? ]

Itu cukup banyak membuat Anda tahu bagaimana seorang kandidat bisa masuk dan membantu memecahkan masalah nyata yang Anda hadapi. Yang lebih buruk juga dengan perusahaan BigHouseHoldNameTech yang lain, tetapi mereka mengajukan pertanyaan berjam-jam yang sangat luar biasa sehingga Anda benar-benar harus mencari di manual [ yaitu menggambarkan perbedaan utama antara PCB di windows vs Linux - dan ini bukan t untuk posisi level kernel ]

Hedge fund adalah aneh dengan niat mereka untuk menyiksa ... berharap 8 jam menyelesaikan masalah tipe ransel di papan tulis.

— kotoran merah
sumber