it-swarm-id.com

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

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 saya lakukan di masa lalu).

Pengamatan saya: Wawancara pekerjaan insinyur SW adalah cara, jauh lebih sulit daripada wawancara pekerjaan peneliti CS, tetapi pekerjaan peneliti membayar lebih tinggi, 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 saya baru-baru ini 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 *** out of you pada esoteric C++ minutia (mis. Bagaimana fungsi panggilan fungsi virtual polimorfik bekerja), algoritma (membuat algoritma all-pair-short-path 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?

40

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 melakukan banyak uji tuntas, memastikan bahwa orang yang Anda pekerjakan sebenarnya dapat menulis kode yang Anda rencanakan untuk mempekerjakannya untuk menulis.

45
Wyatt Barnett

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.

30
Ryan Michela

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 mendapatkan 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?

17
S.Lott

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 beban yang diperhitungkan. 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 berada 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.

6
Scott Whitlock

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

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

5
Nikita Barsukov

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? Hebat, kami mungkin 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 bisa 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?

5
sharptooth

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 untuk 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. Apa yang benar-benar dibutuhkan perusahaan saat ini adalah para inovator dan meminta seseorang untuk membuktikan bahwa mereka dapat menulis dari struktur memori dari perguruan tinggi tidak menunjukkan inovasi.

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.

3
guest

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 seperti perusahaan baru dalam hal seberapa banyak yang Anda ketahui, tetapi tidak begitu peduli dengan seberapa baik Anda menangani lingkungan yang bergerak cepat (tergantung pada pekerjaan) dan lebih banyak lagi dengan keterampilan lunak seperti apa yang Anda miliki. membawa dan seberapa baik Anda akan cocok dengan perusahaan.
  • Perusahaan besar dan departemen TI internal tampaknya lebih peduli untuk memastikan bahwa Anda memiliki standar pengetahuan teknis, tetapi tidak 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 bahwa 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 lalai menyebut perusahaan perangkat lunak (mis. 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 mengorbankan kemampuan untuk benar-benar memecahkan 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 akan sepenuhnya produktif.

3
rjzii

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/Inheritance. Mengapa? Karena begitu dukungan untuk template ditambahkan, saya telah menggunakan C++ hampir secara eksklusif untuk Generic Pemrograman.

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

Itu cukup membuat Anda tahu bagaimana seorang kandidat dapat turun tangan dan membantu menyelesaikan masalah nyata yang Anda hadapi. Yang lebih buruk juga dengan perusahaan BigHouseHoldNameTech yang lain, tetapi mereka mengajukan pertanyaan berjam-jam yang luar biasa yang harus Anda cari di manual [ i.e. jelaskan perbedaan utama antara PCB di windows vs Linux - dan ini bukan untuk posisi level kernel]

Hedge fund adalah aneh dengan niat mereka untuk menyiksa ... mengharapkan 8 jam penyelesaian knapsack ketik masalah di papan tulis.

2
red-dirt