Kelanjutan dari kisah bagaimana saya diwawancarai di perusahaan yang berbeda untuk posisi yang berbeda. Kali ini kami akan menutup beberapa pertanyaan dan komentar mengenai bagian pertama dan terus berbicara tentang tugas pengujian dan wawancara teknis.
Yang mengejutkan saya,
artikel sebelumnya tentang wawancara dengan perekrut dan SDM membangkitkan minat yang tak terduga: lebih dari 100.000 pandangan dari semua sumber. Saya mendapat banyak umpan balik positif di PM, mereka menulis kepada saya oleh mantan rekan kerja yang terakhir saya lihat sekitar 5 tahun yang lalu; pahlawan dari beberapa cerita; seorang pria yang saya jual unit sistem melalui OLX beberapa minggu yang lalu
(analog dari Slando, - sekitar per.) ; drummer dengan siapa kami bermain logam di garasi tahun lalu, dan, anehnya, beberapa perekrut yang bertanya kepada saya apa yang saya pikirkan tentang aspek-aspek tertentu dari wawancara dan perekrutan. 250 orang karena alasan tertentu ditambahkan ke saya di LinkedIn :).
Sebelum saya memulai bisnis, saya akan menjawab pertanyaan paling populer dan pesan pribadi serta komentar.
Cara mengatur gaji untuk wawancara
Banyak komentar terkait dengan uang. Saya sengaja tidak memperhatikan hal ini, karena penawaran adalah masalah yang terpisah, namun komentator masih menyinggung dan menunjukkan kekurangan dari strategi saya - misalnya, untuk segera menyebutkan harganya. Berikut adalah dua artikel bagus yang membahas masalah ini secara lebih rinci dan profesional:
Saya sarankan membaca sebelum mencari pekerjaan.
Beberapa pemikiran tentang perekrutan
Sama sekali tidak saya memberi saran kepada perekrut tentang cara melakukan pekerjaan mereka. Saya bukan perekrut profesional, dan saya tidak tahu bagaimana dapur batin mereka bekerja. Ketika saya perlu mencari staf (tidak hanya melakukan wawancara teknis, yaitu mencari dan menyewa - siklus penuh), maka ini adalah posisi junior, masing-masing, saya tidak mengalami kesulitan khusus.
Dalam pesan pribadi, mereka bertanya kepada saya bagaimana membuat pesan pertama tentang tawaran untuk bekerja, sehingga terlihat menarik dan menarik bagi spesialis, bagaimana menarik perhatian pada diri saya sendiri?
Sepertinya saya, sayangnya, tidak ada yang bergantung pada perekrut. Yang dapat dilakukan oleh perekrut adalah menemukan kontak spesialis sebanyak mungkin dari profil yang diperlukan dan mengirim mereka tawaran kepada mereka semua. Setelah ini, Anda harus menunggu dan berharap salah satu dari mereka ragu-ragu atau sedang mencari pekerjaan aktif. Artinya, ada 20% pekerjaan dengan basis dan 80% keberuntungan. Jaringan memiliki banyak materi tentang cara membuat lowongan dengan benar, dan sebagainya, tetapi bagi saya, faktor kuncinya adalah keinginan kandidat untuk berganti pekerjaan.
Perekrutan adalah penjualan lowongan untuk seorang kandidat. Semakin cepat Anda memahami hal ini dan mulai memompa keterampilan salesman Anda, semakin baik. Oh, saya katakan bahwa saya tidak akan memberikan saran :)
Saya juga yakin bahwa selama pencarian kerja, para kandidat perlu mengambil semua lowongan yang lebih atau kurang cocok, karena pada kenyataannya, mencari tahu apa lowongan itu hanya mungkin terjadi selama percakapan dengan spesialis teknis. Dalam pencarian saya, saya praktis tidak memperhatikan apa yang tertulis dalam lowongan, dan menemukan rincian yang diperlukan pada tahap wawancara teknis. Saya percaya bahwa metode ini adalah yang paling benar, karena kemungkinan menemukan proyek keren yang dapat bersembunyi di balik deskripsi abu-abu standar sangat meningkat. Pengalaman saya hanya dengan jelas menegaskan tesis ini. Tidak sekali dalam lowongan itu ditulis secara spesifik apa yang perlu dilakukan. Hanya frasa umum seperti "kode kode, uji tes, gunakan penyebaran."
Terlibat dalam perusahaan atau proyek
Dalam realitas kita - pasti untuk sebuah proyek.
Cara memilih judul
Saya memposisikan diri sebagai kandidat di level Senior Software Engineer dan lebih tinggi - Team / Tech Lead, Principal Engineer, Arsitek Perangkat Lunak, Manajer Proyek, People / Group Manager dan sebagainya. Inilah yang dimaksud "di atas" dengan "+" di "Senior +".
Menurut saya judul itu tidak ada artinya. Satu-satunya hal yang penting adalah apa yang sebenarnya akan Anda lakukan, dan ini hanya dapat ditemukan dari orang yang bekerja sama dengan Anda.
Jadi, hadirin, mari beralih ke wawancara teknis.
Tahap Dua. Wawancara teknis
Pada bagian ini akan ada lebih banyak pengalaman subjektif dan filosofi saya daripada nasihat. Ada banyak informasi tentang apa yang ditanyakan pada wawancara teknis, dan bagaimana mempersiapkannya, di Internet.
disclaimer: penulis bukan turboengineer-olympiad, sehingga beberapa keputusan atau komentar dapat menyebabkan senyum, luka-sakitan, keinginan untuk menunjukkan kepada penulis kesalahannya atau kualifikasi yang rendah. Saya senang mendengarkan konstruksinya.Secara total, saya melalui 15 wawancara teknis, yang, bagi saya, tidak begitu banyak. Saya bisa melalui lebih banyak, tetapi rata-rata saya harapkan seminggu dari kontak pertama dengan perekrut untuk percakapan dengan seorang spesialis teknis. Ini terlepas dari kenyataan bahwa saya praktis tidak punya batas waktu. Hanya sekali saya menjadwalkan wawancara untuk waktu yang sudah saya jadwalkan wawancara lain. Saya juga mencatat bahwa semua perusahaan atau perekrut datang kepada saya sendiri. Saya tidak mengirim CV ke perusahaan mana pun terlebih dahulu. Ini adalah pertanyaan bahwa bukanlah seigneur yang mencari pekerjaan, tetapi pekerjaan - seigneur.
Tugas tes
Banyak perusahaan memberikan tugas tes sebelum beralih ke percakapan untuk menyingkirkan kandidat yang tidak relevan. Terlepas dari kenyataan bahwa banyak yang tidak suka menginvestasikan waktu mereka dalam tugas-tugas tes, terutama jika mereka cukup banyak, saya masih berpikir bahwa ini adalah praktik yang baik. Mari kita pertimbangkan tugas tes apa yang bisa dilakukan.
“Buat proyek dari awal (mungkin menggunakan teknologi spesifik) dan posting di GitHub” - bagi saya, pilihan terburuk. Anda dapat menghabiskan banyak waktu di atas pelat ketel, pada infrastruktur di sekitar solusi, dan pewawancara, sebagai suatu peraturan, akan tertarik pada beberapa detail implementasi kecil yang ditetapkan dalam kondisi tugas. Nah, jika Anda sudah dekat, misalnya, templat proyek dan Anda dapat mengangkat server dalam 5 menit dan dengan cepat mengunduh apa yang Anda butuhkan. Kalau tidak, Anda harus mengingat semuanya dan mulai dari awal. Juga buruk jika tugas memiliki kondisi untuk menggunakan dependensi eksternal, misalnya, database yang tidak tertanam.
Teknisi DevOps Posisi. Mereka mengirim saya tugas untuk membuat konfigurasi Vagrant dari beberapa mesin virtual, di antaranya harus ada server web dengan statika, penyeimbang untuk mereka dan Jenkins. Semua ini harus diinstal dan dikonfigurasi menggunakan Chef. Sekarang bayangkan - Saya tidak pernah menggunakan Vagrant, Chef dan tidak mengkonfigurasi server web yang diperlukan dalam tugas itu. Saya mengerti cara kerjanya, saya berurusan dengan alat serupa, tapi saya tidak pernah menggunakan ini secara khusus.
Saya harus duduk semalaman, memperbaiki semuanya, mengumpulkan banyak garu dan akhirnya menyelesaikan tugas. Kesulitan utama adalah bahwa saya memiliki MacBook Pro tua tahun ke-15, yang secara fisik tidak punya waktu untuk memulai kembali wadah, dan juga saya tidak memiliki pengalaman dengan Vagrant.
Inti dari tugas ini - untuk mengetahui cara memasang apa - mungkin perlu waktu setengah jam. Sisa waktu (7 dengan jam) saya habiskan untuk menginstal semua alat, restart - reboot, mencari-cari di konfigurasi dalam upaya untuk memahami mengapa itu tidak bekerja, dan sebagainya.
Saya mungkin akan melakukan tugas yang sama pada Docker Compose dalam satu jam, bahkan mungkin kurang. Tidak bisakah Anda membatasi kandidat pada alat? Menurut saya itu mungkin.
Apakah pencarian ini bermanfaat bagi saya? Pasti ya! Sekarang saya akan tahu bahwa dari Vagrant dan Chef Anda harus menjauh :)
Waktu yang dihabiskan - 8 jam .
Sayangnya, saya tidak punya cerita lagi tentang jenis tugas ini, karena tidak ada begitu banyak tes yang secara umum :(
"Ini tautan ke situs dengan tes - telusuri" adalah pilihan yang sangat keren. Apa gunanya Ada SaaS yang memungkinkan Anda untuk mengonfigurasikan serangkaian pertanyaan praktis dan teoritis, dan untuk solusi mereka menyediakan REPL dan editor kode langsung di browser, serta memberikan kesempatan untuk menjalankan tes verifikasi. Kemudian Anda tinggal mengerjakan tugas, memperbaiki yang ada atau menulis kode Anda sendiri, menjalankannya dan melihat hasilnya. Tes itu sendiri tersembunyi dari Anda, Anda hanya melihat hasilnya (lulus / gagal) dan deskripsi singkat dari tes, yang pada saat yang sama dapat menjadi petunjuk. Mengapa saya paling suka opsi ini? Karena ada kriteria yang tidak ambigu untuk kualitas penugasan, dan kandidat tahu persis berapa banyak poin yang dia cetak, apakah keputusannya berhasil dan sebagainya. Saya pribadi bahkan tertarik untuk menjalani tugas-tugas ini. Satu-satunya hal yang saya tidak melihat titik dalam masalah teoritis seperti "apa yang akan terjadi jika kode ini dieksekusi" - mereka mudah google.
Posisi Insinyur Perangkat Lunak Ruby. Mereka mengirimi saya tautan ke situs web TestDome , tentu saja, ke tes khusus. Saya klik, masuk ke tes yang sebenarnya. Mereka memberi saya 2,5 jam untuk menyelesaikan seluruh set, 5-20 menit untuk setiap pertanyaan. Padahal, saya sangat menyukainya, saya belum pernah mengalami hal seperti itu sejak lama. Saya terutama menyukai pendekatan TDD: Saya memberi kode, meluncurkan, melihat apa yang jatuh, Anda kode lebih lanjut. Lulus dengan senang hati.
Tugasnya sendiri cukup sederhana: perbaiki kode (Ruby / JS / CSS / HTML), tulis validator (Ruby), implementasikan struktur data (Ruby), tidak ada yang istimewa. Namun, fakta bahwa Anda dapat segera memeriksa apakah solusinya berfungsi banyak membantu.
Saya menyelesaikan tugas untuk 93/100 poin hanya dalam satu jam. Sayangnya, hasil ini tidak membantu saya sama sekali di masa depan.
TDD membantu dalam pengambilan keputusan, tidak perlu menghabiskan waktu untuk meningkatkan infrastruktur, memutar ulang langsung di browser - singkatnya, sangat keren. Demi ini, adalah mungkin untuk menunggu sebulan - pada akhirnya, saya mendapat porsi dopamin (melakukan pekerjaan yang sangat baik) dan adrenalin (jam terus berdetak, waktu hampir habis!).
Waktu yang dihabiskan - 1 jam.
Selain itu, keuntungan besar dari jenis tugas ini adalah verifikasinya otomatis. Kita semua tahu bagaimana pewawancara “suka” memeriksa tugas, dan di sini mesin melakukan segalanya untuk mereka - sangat nyaman, setidaknya Anda tidak perlu mengunduh kode dan mengumpulkannya. Mungkin saya akan menggunakan metode ini saat mempekerjakan di masa depan.
"Ini repositori, ada tugas, kirim Permintaan Tarik dengan solusi" - Saya tidak menemukan opsi seperti itu, tetapi rekan-rekan saya menggunakannya. Saya tidak begitu suka dia, karena Anda bisa melihat bagaimana kandidat lain melakukan tugas (jika mereka).
Kerugian dari metode ini jelas: tester perlu mengunduh kode, mengumpulkan, menonton apa yang ada di sana, panjang dan membosankan. Tentu saja, Anda dapat melihat kode di browser secara dangkal, tetapi mengapa kemudian Anda perlu tugas? Mari kita menulis pada pseudo-code.
"Ini repositori, ada kodenya, refactor sebanyak yang kamu bisa" - variasi dari yang sebelumnya. Ini lebih baik, karena di sini sejak awal kerangka dibuat untuk bekerja. Kerugiannya sama: tidak jelas kapan harus berhenti. Seperti yang dikatakan Egor Bugaenko, program apa pun mengandung jumlah kesalahan yang tak terbatas, dan mereka juga dapat diperbaiki tanpa batas waktu.
Penulis tugas mungkin memiliki sesuatu di kepala mereka ketika mereka menciptakannya, kami kemungkinan besar tidak akan tahu apa hal utama bagi mereka sendiri. Jika tugas itu memiliki kriteria yang jelas, maka itu akan keren. Misalnya, "ada kode, itu menghasilkan hasil pada kecepatan pada perangkat keras seperti itu, refactor untuk bekerja dua kali lebih cepat." Sulit untuk bekerja tanpa kriteria. Dalam kehidupan nyata, dalam pekerjaan nyata, kami selalu memiliki kerangka kerja dan mencari solusi optimal, dipandu oleh kerangka kerja ini dan akal sehat. Pekerjaan utama pengembang adalah merasakan keseimbangan ini dan menemukan solusi yang tepat.
Saya sangat menyesal, tidak ada orang lain yang memberikan tugas tes, jadi pilihan saya sangat kecil. Kecuali saya dapat mengingat tes yang saya lakukan bertahun-tahun yang lalu. Semua dari mereka adalah tipe pertama - sebuah proyek harus dilakukan. Menariknya, saya tampil di masa itu ketika GitHub belum begitu populer dan perlu mengirim solusi di arsip zip melalui pos :)
Rekomendasi saya untuk item tes?
- Jangan menyukainya - jangan. Jika tugas, misalnya, adalah untuk menyelesaikan seluruh situs atau menulis kasar - baik, letakkan di pemandian. Tugas harus singkat dan fokus pada menciptakan konteks untuk diskusi berikutnya, dan bukan hanya tes tentang bagaimana Anda bisa melakukan perancah.
- Jika tugasnya adalah tipe pertama - tambahkan ke repositori readme, di mana secara rinci uraikan instruksi untuk memulai, anotasi singkat tentang mengapa Anda membuat keputusan seperti itu, apa kekurangannya, apa yang Anda suka atau tidak sukai, bagaimana Anda menyelesaikan tugas itu, jika Anda punya lebih banyak waktu, dan sebagainya. Saya tidak tahu apakah ini benar-benar membantu, tetapi sebagai pewawancara, saya pasti akan menyebutkan dokumentasi keputusan tersebut.
- Menulis secara normal, tetapi Anda tidak harus menghabiskan banyak waktu menjilat bagian. Bagi saya, cukup dengan mendaftar di readme saja segala sesuatu yang akan Anda tingkatkan jika itu adalah kode pertempuran.
- Pastikan untuk memikirkan pertanyaan apa yang mungkin Anda miliki tentang implementasi dan baca dokumentasi tambahan tentang API yang Anda gunakan. Misalkan saya sudah lama tidak bekerja dengan konkurensi. Saya sudah lama tidak mempraktekkan ini, jadi setelah keputusan itu saya dengan cepat membahas semua topik terkait, mengingat semua tugas yang khas dan siap untuk percakapan.
Nah, uji satu, saya harap Anda berhasil menyelesaikannya, menyampaikan informasi ini kepada perekrut, dan setelah waktu yang tidak terbatas Anda akan diundang untuk berbicara secara langsung.
Wawancara teknis. Intro
Untuk mulai dengan, sekarang mereka jarang diundang ke kantor untuk wawancara. Saya dipanggil ke kantor hanya beberapa kali - untuk wawancara di posisi Solution Architect, Tech Lead dan sekali - untuk posisi manajerial. Semua wawancara lainnya dilakukan melalui Skype, Zoom, Hangouts. Seperti dalam wawancara sebelumnya dengan perekrut, rekomendasinya sama - kamera yang bagus, headset yang bagus, internet yang bagus. Untuk ini saya juga menambahkan kondisi meraba-raba layar. Karena itu, pastikan bahwa Anda tidak memiliki proyek pekerjaan terbuka (jika ini penting) dan hal-hal pribadi lainnya yang tidak perlu Anda perlihatkan kepada orang-orang pada saat itu. Tetap gunakan browser yang bersih tanpa tab dan REPL untuk pengkodean berjaga-jaga (IDE atau
repl.it ).
Dari semua metode komunikasi, saya paling suka Zoom. Sebenarnya, itu paling sering digunakan.
Tip penting mengenai komunikasi yang tepat di newsgroup: biasakan tidak berbicara atau mengetik di keyboard saat orang lain berbicara, dan berbicara di headset, dan tidak, misalnya, melalui mikrofon laptop eksternal dan speaker eksternal.
Mengapa ini penting? Paling sering, dua orang akan berbicara dengan Anda, masing-masing, mereka tidak akan menggunakan headset. Ketika Anda berbicara, di sisi mereka perangkat lunak termasuk pemotong suara yang mencegah efek umpan balik muncul (latar belakang, peluit, gema). Ketika pembatal kebisingan diaktifkan, mikrofon mereka praktis tidak akan menangkap apa pun, sehingga Anda tidak akan mendengar apa yang mereka katakan kepada Anda.
Saat Anda mengetik di keyboard, itu menciptakan suara yang dikirim ke sisi lain dan juga termasuk pengurangan kebisingan. Sebagai akibatnya, frasa terputus dan kesan koneksi buruk tercipta. Karena itu, Anda harus selalu menunggu hingga orang menyelesaikan pembicaraan. Kalau tidak, Anda tidak akan mendengar apa yang ingin mereka katakan (kecuali ketika lawan bicara juga menggunakan garntiru). Anehnya, banyak orang tidak tahu tentang mekanisme ini. Ini juga berguna untuk membisukan mikrofon saat Anda berbicara sehingga tidak ada suara dari kamar Anda menerobos ke orang. Saya dibesarkan selama bertahun-tahun bekerja di sebuah perusahaan di mana semua orang tahu aturan ini, jadi bagi saya semua ini jelas, tetapi saya telah melihat banyak situasi di mana orang tidak mengikuti aturan dasar ini dan berdosa di Internet yang buruk.
Jika semuanya baik-baik saja, ping telah bolak-balik, maka pembicaraan akan dimulai. Seringkali, pewawancara sendiri mengusulkan rencana percakapan. Kebetulan mereka tidak memiliki rencana, tetapi setidaknya satu topik akan selalu relevan:
"Ceritakan tentang diri Anda dan tentang pengalaman Anda .
"Sebelum wawancara, telusuri lowongan lagi, perhatikan persyaratan yang berlaku untuk kandidat dan siapkan pidato. Saya melakukan wawancara di Tech Lead, DevOps / SRE, Ruby / Java Software Engineer dan dalam setiap kasus saya mengatakan hal-hal berbeda yang, saya pikir, akan lebih menarik bagi pewawancara. Usahakan untuk tidak masuk ke perincian, tetapi berikan informasi yang akan membuat vektor untuk diskusi lebih lanjut. Anda tidak boleh berbicara secara rinci tentang apa yang Anda lakukan 5 tahun yang lalu (kecuali tentu saja ini bukan sesuatu yang luar biasa).
Saya katakan, misalnya, ini: “Selama 8 tahun saya bekerja di kantor perusahaan, terutama dengan Jawa. Kemudian saya pergi ke startup, di sana saya terlibat dalam infrastruktur. Dua tahun terakhir saya sebagian besar menulis di Rails. " Itu saja, pewawancara memiliki informasi yang cukup, dan mereka akan melonggarkan percakapan dalam nada yang menarik bagi mereka.
Dan sekarang fakta yang tidak terduga.
Tidak ada yang membaca resume Anda
Jujur, ini ternyata menjadi penemuan hebat bagi saya. Nah, perekrut tidak membaca profil di LinkedIn, karena itu mungkin tidak diperbarui, SDM memiliki kemampuan untuk melihat CV secara diagonal, dan menyoroti hal utama untuk Anda sendiri. Tetapi orang yang melakukan wawancara teknis, tentu tidak akan membaca resume Anda. Bukan satu, saya tekankan, tidak sekali pun saya tidak merasa bahwa orang-orang paling tidak dengan satu mata memandang apa yang saya tulis di sana. Saya menduga bahwa, sebagai suatu peraturan, mereka mengetahui bahwa mereka perlu melakukan wawancara teknis sehari sebelum wawancara yang sebenarnya, dan memutuskan untuk membaca CV 5 menit sebelum panggilan, dan entah bagaimana sudah ada di sana.
: « , ». , ( , ). , , .
, .
, , 10 . CV, , , .
CV , . , , .
Dan lagi saya akan mengungkapkan ketidaksenangan saya dengan sikap ini. Saya dan Anda, jika Anda sudah menjadi tomat senior, adalah spesialis tingkat yang relatif serius di bidang Anda (saya ingatkan Anda bahwa saya memiliki fitnah dan tumpukan). Tidak banyak orang seperti kita di pasar, jadi tolong tunjukkan rasa hormat dan menjadi terbiasa dengan apa yang saya lakukan. Saya membaca tentang perusahaan, proyek, klien Anda. Saya berharap diperlakukan sebagai pribadi. Mengapa yang sebaliknya terjadi?Tidak ada yang membutuhkanmu
Tapi ini yang paling menggangguku. Dalam 80% kasus, saya berurusan dengan para introvert yang marah, mengantuk, lelah yang jelas-jelas tidak tertarik mempekerjakan orang. Mereka adalah orang-orang yang kompeten secara teknis dan spesialis yang baik, tetapi untuk beberapa alasan mereka tidak memiliki keinginan untuk benar-benar merekrut seorang kolega, mereka tidak memiliki keinginan untuk mengambil insinyur yang baik untuk membantu mereka., , . , , , , -. , , , , , , ? : , , , . , « , ».
Saya hanya memiliki beberapa percakapan dengan para insinyur, yang menunjukkan bahwa ya, mereka benar-benar membutuhkan orang, mereka ingin mempekerjakan spesialis yang baik, mereka punya rencana untuk saya dan sebagainya. Jadi kami beralih ke paragraf berikutnya.Anda tidak akan berbicara dengan bos atau pemimpin tim masa depan Anda
Ini adalah konsekuensi dari yang sebelumnya. Saya sangat yakin bahwa Anda harus berbicara dengan mereka yang kemudian Anda patuhi, baik formal maupun informal. Semua organisasi memiliki semacam hierarki, baik itu tim Scrum atau perusahaan berdarah. Di mana-mana ada seseorang yang akan menjagamu (setidaknya di awal).Sayangnya, Anda tidak bisa berbuat apa-apa. Yegor Bugaenko dalam posnya "Mengapa Saya Tidak Bicara dengan Google Perekrut" menggambarkan situasi ini dengan sangat baik. Jika Anda menuntut percakapan dengan bos masa depan Anda, Anda tidak akan mendapatkan wawancara apa pun.Tampaknya bagi saya sekarang ini adalah salah satu masalah perekrutan terbesar dengan kami. Mungkin ini ditentukan oleh spesifik proyek - outsourcing, di mana orang melakukan sesuatu di sungai. Mungkin budaya komunikasi yang buruk dan mental misantropis yang buruk, saya tidak tahu.Blog berbahasa Inggris sering menulis bahwa mempekerjakan adalah salah satu bidang utama yang vital untuk membangun perusahaan yang sukses. Saya pikir perusahaan kami akan membutuhkan banyak waktu untuk datang ke sini dan membentuk budaya yang tepat. Sementara itu, pelanggan harus melakukan outsourcing ini.. , CTO CEO. , . , , . , .
,
, , , . , .