Jalan malas
Dengan meminta insinyur perangkat lunak untuk melakukan tugas tertentu, seperti menulis algoritme pembuatan faktorial (sangat umum) atau menyortir daftar tertaut tunggal atau ganda yang mudah diingat, Anda tidak akan mendapatkan ide apa pun tentang keterampilan kandidat, selain kemampuan menjejalkan. Anda mungkin juga menanyakan kode ASCII dari karakter 'A'.
Solusi terperinci untuk banyak masalah mudah ditemukan dalam berbagai bahan referensi, seringkali dalam buku, yang menjelaskan solusi algoritmik dan spesifik untuk semua masalah yang umum dalam wawancara pemrograman.
Saya bekerja untuk sebuah perusahaan dan di sana saya berbicara secara rinci dengan seorang kolega tentang seperti apa wawancara dengan hedge fund yang besar itu. Dia dengan hati-hati mengingat semua pertanyaan teknis dari buku pertanyaan dan jawaban wawancara yang tersedia secara luas, yang kemudian diteruskan oleh karyawan sebagai sumber dari semua pertanyaan wawancara.
Untungnya, kolega saya adalah seorang insinyur yang berpengalaman, tetapi dia setuju untuk menjalani latihan yang sangat monoton dan biasa-biasa saja ini untuk mempertahankan pekerjaannya. Dia tidak perlu melakukan ini - wawancara tersebut tidak hanya membuang-buang waktu berharga, tetapi tidak ada artinya bagi perusahaan perekrutan untuk menentukan kemampuannya. Seorang kolega pergi setelah satu tahun, lelah dengan tingkat teknis yang rendah dalam hal perekrutan dan manajemen yang tidak efektif ...
Penyimpanan
Argumen yang sama berfungsi saat Anda menulis algoritme dalam bahasa tertentu. Pada proyek nyata, tidak ada insinyur perangkat lunak yang akan menulis bagian kode tanpa semacam alat pemeriksa sintaks (misalnya, pelengkapan kode bawaan di editor), tanpa referensi ke beberapa jenis dokumentasi teknis, atau hanya tanpa menyalin solusi yang sudah jadi, di mana itu mungkin. Tidak ada gunanya menciptakan kembali roda.
Saya yakin sebagian besar kode yang berjalan pada sistem dunia saat ini berasal dari respons terhadap Stack Overflow.
Untuk semua kepraktisannya, bekerja dengan sintaks bahasa pemrograman tertentu dimulai dengan keakraban dan penerapan. Orang yang mewawancarai Anda mungkin berpikir bahwa menguji pengetahuan Anda tentang nuansa bahasa tertentu sedang menguji pemahaman Anda tentang bahasa tersebut. Misalnya, saya dapat dengan tegas menyatakan bahwa meskipun saya telah menulis dalam C selama hampir 30 tahun, saya selalu melewatkan sintaksnya.
Faktanya, seiring dengan kemajuan karir saya dan saya menjadi lebih mengenal bahasa yang saya minati, saya terus-menerus bingung tentang nuansa sintaks, katakanlah, C, C ++ dan Objective-C. Bukan karena saya seorang insinyur perangkat lunak yang buruk (meskipun beberapa mungkin tidak setuju ...), tetapi karena hanya pengetahuan yang dapat Anda pegang di kepala Anda dan segera diingat kembali setiap saat disimpan dalam memori Anda.
Seorang insinyur yang baik sering kali tidak segera mengetahui jawaban atas pertanyaan tertentu, tetapi dia pasti tahu di mana mencarinya. Mungkin Anda ingin bertanya di mana tempat terbaik untuk mendapatkan informasi tentang pertanyaan wawancara?
Tugas umum
Sesuatu yang telah saya sentuh: ini adalah sebuah pepatah - jangan menemukan kembali roda. Misalnya, jika Anda bekerja di C dan memerlukan rutin port serial, jangan menulisnya dari awal kecuali situasinya mengharuskannya. Mungkin Anda memerlukan pengurai JSON, persyaratan yang sangat umum - kecuali jika Anda menulis kode pada papan tertanam dengan sumber daya terbatas, untuk satelit di orbit geostasioner atau di Malbolg ; maka mungkin Anda harus mengeluarkan apa yang sudah Anda tulis dari perpustakaan. Kemungkinan besar, kode telah digunakan untuk waktu yang lama, sepenuhnya diuji dan memiliki dokumentasi yang terperinci (dan benar). Itu bisa diandalkan.
Tidak mungkin bahwa dalam rekayasa perangkat lunak modern akan ada tugas umum yang belum otomatis di perpustakaan, atau yang algoritmanya sulit ditemukan.
Jika Anda seperti saya, dan di atas segalanya Anda bekerja karena cinta untuk subjek tersebut, maka Anda akan secara aktif mencari posisi di mana Anda menerapkan apa yang telah Anda tulis sebelumnya: mencari dunia baru yang aneh, kehidupan baru, peradaban baru ...
Sebenarnya, konsep insinyur perangkat lunak di masa depan yang jauh telah lebih dari sekali disamakan dengan arkeolog kode, di mana insinyur pada dasarnya menggunakan kembali kode yang ada dan menghabiskan waktu yang relatif sedikit untuk mengembangkan dan memprogram algoritma baru dan baru.
Diskusi. Diskusi. Diskusi
Saya mendukung untuk mengetahui bahwa orang yang Anda pekerjakan mengetahui bisnis mereka. Tetapi metode di atas sama sekali tidak berguna menurut saya. Saya tidak ingin menyinggung siapa pun, saya mengatakannya apa adanya.
Misalnya, hanya berbicara tentang paradigma pemrograman dalam rekayasa perangkat lunak modern, apakah bahasa akan menjadi pilihan yang baik untuk implementasi tertentu, atau apakah metodologi rekayasa perangkat lunak tertentu (Agile, saya sedang melihat Anda) adalah topik yang jauh lebih berguna dan relevan untuk diskusi.
Pimpin diskusi untuk menyoroti area yang memiliki kesamaan, lihat bagaimana kandidat memahami masalah baru, dan kemungkinan cara alternatif baru untuk menyelesaikan masalah lama. Bagaimana kandidat melihat perkembangan sesuatu, bagaimana mereka akan mulai menyelesaikan sesuatu. Tetap terbuka, jauhi detail dan hal-hal sepele.
Kuncinya di sini adalah diskusi. Saya terus-menerus kagum bahwa banyak perusahaan yang dianggap "berwawasan ke depan" dan "pemimpin di bidangnya" masih menggunakan metode perekrutan yang kuno, monoton, dan dapat diprediksi sepenuhnya, karena mereka hampir tidak menghargai nadi teknis yang sebenarnya.
Sering dikatakan bahwa pencari kerja harus mewawancarai perusahaan dengan cara yang sama seperti perusahaan mewawancarainya. Saya sepenuhnya setuju.
Mewawancarai seseorang dengan daftar pertanyaan teknis yang tepat selalu menjadi peringatan, terutama ketika orang tidak ingin berlarut-larut dalam diskusi tentang satu masalah. Hal ini sering kali menunjukkan bahwa orang yang diwawancarai mungkin tidak sepenuhnya memahami apa yang dia tanyakan, dan jawaban apa pun yang tidak sama persis dengan yang tertulis di naskah akan dianggap salah.
Mari kita simpulkan
Beberapa perusahaan telah beralih ke metode perekrutan yang lebih baik, yang lain - yah, mereka gagal. Di sinilah saya mendorong Anda sesama programmer untuk tidak terlibat dengan perusahaan yang mempekerjakan dengan cara lama dan bersikeras pada tes dan latihan pemrograman. Apalagi untuk yang lama!
Saya pernah mendengar cerita tentang perusahaan yang meminta proyek diselesaikan pada tenggat waktu kandidat, seringkali memakan waktu berhari-hari.
Yang lain memiliki "tes bakat" generik untuk bahasa tertentu, tes pilihan ganda, di mana dalam waktu terbatas, sedikit kabut di kepala Anda berarti Anda telah gagal dalam wawancara!
Jika Anda seorang pemula, Anda mungkin tidak dalam posisi untuk melewatkan wawancara, dan saya sangat memahami Anda, tetapi saya melihatnya sebagai pengalaman belajar. Silakan, bangun pengalaman, pelajari sebanyak mungkin, dan jika pekerjaan mengecewakan Anda, lanjutkan saja. Ke depan, Anda akan mendapatkan lebih banyak kepercayaan diri, pengetahuan, dan pengalaman. Bagaimanapun, perusahaan mendapatkan keuntungan dari Anda, jadi Anda harus mendapatkan keuntungan yang sama dari perusahaan.
Jika Anda, seperti saya, lebih tua dan lebih berpengalaman, biarkan perusahaan perekrutan berbicara dengan Anda. Kami memiliki banyak pengalaman, kami telah melihat dan melakukan banyak hal, kualifikasinya terlihat jelas di resume dan CV. Dan saya marah karena saya diarahkan ke jalur perekrutan umum dan kemampuan saya diuji beberapa kali.
Jika Anda merasa Anda adalah pemberi kerja yang layak dan tidak tahu mengapa kandidat yang tampaknya hebat pergi dan pergi, perhatikan baik-baik cara Anda mempekerjakan orang.
<>
Profesi dan kursus lainnya
</>