Haruskah saya khawatir tentang tugas rekayasa ulang yang diberikan selama proses wawancara? [Tutup]

Baru-baru ini saya melakukan wawancara telepon dengan perusahaan. Setelah wawancara telepon itu, saya diberitahu untuk menyelesaikan tugas pemrograman pendek (program kecil; tidak boleh lebih dari tiga jam). Saya hanya diinstruksikan secara langsung untuk menyelesaikan tugas dan menyerahkan kode. Saya diberi kebebasan penuh untuk menggunakan bahasa apa pun yang saya inginkan dan tidak diberi tahu cara memasukkan kode.

Segera saya berencana untuk melemparkannya ke Github, menulis test suite untuknya, menggunakan Travis-CI (integrasi berkesinambungan gratis untuk repositori Github publik) untuk menjalankan suite tes, dan menggunakan CMake untuk membangun file Linux untuk Travis-CI. Dengan begitu, saya tidak hanya dapat menunjukkan bahwa saya memahami cara menggunakan Git, CMake, Travis-CI, dan cara menulis tes, tetapi saya juga dapat dengan mudah menautkan ke halaman Travis-CI sehingga mereka dapat melihat output dari tes tersebut. Saya pikir itu akan membuatnya sedikit lebih nyaman bagi pewawancara.

Karena saya tahu teknologi-teknologi itu dengan baik, pada dasarnya tidak akan ada waktu untuk tugas itu.

Namun, saya agak khawatir bahwa melakukan semua ini untuk tugas yang relatif sederhana akan terlihat buruk. Walaupun itu tidak akan menambah lebih banyak waktu bagi saya, saya tidak ingin mereka berpikir saya menghabiskan terlalu banyak waktu untuk hal-hal yang seharusnya sederhana.

Sebagai pewawancara saya akan senang melihat pengetahuan tentang proses pengembangan perangkat lunak yang ditunjukkan oleh pendekatan ini; sebagai lawan dari hanya penulisan kode.

Secara khusus, memiliki test suite bahkan untuk masalah yang sangat sederhana akan menjadi pertanda baik (bahkan level FizzBuzz). Saya telah melihat kandidat mengajukan solusi yang bahkan tidak menyelesaikan masalah dan serangkaian tes sederhana akan menunjukkan kepada mereka hal ini. Juga, memiliki sejarah komit memungkinkan saya untuk mendapatkan ide dari proses pemikiran yang telah digunakan kandidat untuk mendapatkan solusi.

Di sisi lain, saya tahu orang-orang ditolak oleh beberapa perusahaan pada tahap awal proses over-engineering. Namun, dalam banyak kasus, hal ini disebabkan oleh rekayasa yang berlebihan dari solusi yang belum tentu proses yang digunakan.

Memiliki sebagai orang yang diwawancarai seseorang yang memahami hal-hal seperti kontrol versi, CI, pengujian unit dan sejenisnya akan menjadi langkah maju pada apa yang biasanya saya lihat.

Meskipun, bagi saya, hal yang paling penting adalah bahwa masalahnya diselesaikan, dan dipecahkan dengan baik, mengetahui bahwa kandidat memahami cara-cara untuk meningkatkan kualitas pengiriman mereka pasti akan menarik perhatian saya.

Apa yang biasanya saya lihat adalah orang-orang yang tidak hanya tidak memahami masalah, tetapi juga tidak mengerti bagaimana cara menyelesaikan masalah - dan mereka akan diabaikan tidak peduli berapa banyak alat tambahan yang mereka gunakan dalam proses.

Ingatlah bahwa ada batasan waktu untuk itu. Pewawancara mengetahui hal ini, jadi ini berarti (jika saya adalah pewawancara) dia akan melihat Anda tidak hanya menyelesaikan masalah dalam waktu yang ditentukan, tetapi melakukannya dengan cepat sehingga Anda memiliki waktu tersisa untuk pelapisan emas, yang merupakan pertanda baik dari Anda kemampuan memecahkan masalah serta penghargaan Anda atas ketelitian dan ketekunan.

Over-engineering adalah kata yang buruk ketika Anda membuat AbstractFactoryManagerAdaptors yang terhubung untuk membagikan BuzzManager dan FizzManager hanya untuk menyelesaikan FizzBuzz.

Apa yang Anda lakukan adalah ketekunan yang berlebihan, yang bahkan bukan hal apa-apa (meskipun pasti kurang rajin).

Yang mengatakan, jika Anda berakhir dari waktu ke waktu atau dengan solusi setengah diretas karena Anda menggunakan waktu Anda pada ekstra yang Anda klaim "tidak ada waktu sama sekali", ini akan terlihat seolah-olah Anda memiliki pemahaman yang sangat buruk tentang seberapa besar tampak kecil tugas bisa. Ini bisa menjadi atribut berbahaya pada seorang insinyur dan terlalu umum di kalangan junior. Prioritaskan secara tepat dan lakukan hal-hal ekstra-kredit hanya setelah menyelesaikan solusi yang diperlukan .

Pandangan lain untuk dipertimbangkan adalah bahwa pendekatan Anda tidak baik atau buruk. Saya bisa membayangkan pewawancara yang akan mempertimbangkannya terlalu banyak dan saya bisa membayangkan pewawancara yang akan lebih menyukai teknik.

Jangan terlalu khawatir. Alih-alih, selesaikan masalah dengan cara yang Anda anggap terbaik dan Anda kemungkinan akan menerima tawaran pekerjaan dari orang-orang yang setuju dengan Anda. Itu langkah awal yang bagus menuju lingkungan kerja yang produktif. Ingat, wawancara memiliki dua cara. Tanggapan pewawancara untuk solusi Anda akan memberi tahu Anda banyak tentang mereka juga. Apakah Anda benar-benar ingin bekerja dengan orang-orang yang percaya insting dan filosofi pengembangan Anda salah?

Pada kenyataannya, tidak ada yang peduli jika kandidat dapat menyiapkan git repo atau membuat makefile dengan tergesa-gesa, karena itu hanya mengingat apa yang dia pelajari dengan menghafal. Ini adalah keterampilan sekunder untuk pemecahan masalah dan aspek desain aktual dari pertanyaan wawancara.

Jadi ya, intuisi Anda tepat sehingga berpotensi terlihat buruk, karena mungkin tampak seolah kandidat percaya bahwa seseorang yang dapat memuntahkan beberapa perintah dan pola yang dihafal untuk membuat kerangka proyek memiliki keterampilan perangkat lunak yang mengesankan.

Namun, aspek test suite dari solusinya bagus. Memberikan jawaban dengan suite uji regresi mungkin akan mendapatkan poin Anda. Terlebih lagi jika suite tes Anda menggunakan kasus-kasus penting dalam kode. Test suite tidak harus memiliki banyak ornamen formal dan bergantung pada alat; hanya fakta bahwa Anda entah bagaimana memilikinya di sana cukup baik untuk wawancara. Lebih atau kurang jelas bahwa jika Anda dapat mengumpulkan beberapa tes unit ad hoc dalam kuis wawancara, Anda dapat melakukannya dengan alat pada proyek nyata.

Baru-baru ini saya melakukan wawancara telepon dengan perusahaan. Setelah wawancara telepon itu, saya diberitahu untuk menyelesaikan tugas pemrograman pendek (program kecil; tidak boleh lebih dari tiga jam).

Saya akan melanjutkan dengan hati-hati. Mengevaluasi relevansi tantangan dengan pekerjaan, dan pastikan penggantian di masa depan dari majikan akan membuat 3 jam waktu Anda berharga.

Saya mempertanyakan nilai dalam jenis tes ini, dan lebih suka menilai seseorang atas prestasi mereka di masa lalu. Tugas singkat yang sudah ditentukan sebelumnya tidak dapat memberi tahu majikan apa pun tentang apa yang dapat Anda lakukan. Hanya apa yang tidak dapat Anda lakukan, dan itu dapat dengan cepat ditentukan dengan beberapa pertanyaan melalui telepon.

Pengujian memang memiliki tempatnya. Tanyakan kepada diri Anda pertanyaan-pertanyaan berikut tentang tes ini, dan berikan respons yang sesuai.

1. Apakah tes ini adil mengingat tingkat karier Anda saat ini?
2. Apakah tes memiliki jawaban yang benar dan jelas?
3. Apakah pewawancara memiliki minat pada potensi Anda sebagai seseorang atau mereka lebih tertarik pada hasil tes (yaitu agen perekrutan sangat buruk untuk ini).
4. Apakah tes tersebut mewakili jenis pekerjaan yang akan Anda sukai atau apakah itu verifikasi keterampilan yang ambigu (yaitu tes jika Anda tahu sintaks Java).

Saya hanya diinstruksikan secara langsung untuk menyelesaikan tugas dan menyerahkan kode.

Anda baru saja menjawab pertanyaan Anda sendiri.

Segera saya berencana untuk melemparkannya ke Github, menulis test suite untuknya, menggunakan Travis-CI (integrasi berkesinambungan gratis untuk repositori Github publik) untuk menjalankan suite tes, dan menggunakan CMake untuk membangun file Linux untuk Travis-CI.

Tidak, bukan itu yang mereka minta Anda lakukan.

Dengan begitu, saya tidak hanya dapat menunjukkan bahwa saya memahami cara menggunakan Git, CMake, Travis-CI, dan cara menulis tes, tetapi saya juga dapat dengan mudah menautkan ke halaman Travis-CI sehingga mereka dapat melihat output dari tes tersebut. Saya pikir itu akan membuatnya sedikit lebih nyaman bagi pewawancara.

Saya akan menunjukkan keterampilan terlalu dini atau terlambat dalam proses wawancara. Jika Anda merasa tidak berhasil dengan baik dalam wawancara, dan sekarang mencoba untuk memberikan kompensasi maka itu tidak akan berhasil. Di sisi lain, melakukan terlalu banyak saat tidak diminta juga menunjukkan keinginan yang berlebihan. Ini bisa mengakibatkan majikan membalas dengan tawaran upah yang lebih rendah dari yang Anda harapkan.

Namun, saya agak khawatir bahwa melakukan semua ini untuk tugas yang relatif sederhana akan terlihat buruk.

Ya itu terlihat buruk. Menyelesaikan tantangan mereka dengan satu baris kode akan jauh lebih mengesankan daripada proyek penuh flushed out.

Dari pengalaman saya, ini bukan bagaimana Anda memenangkan wawancara pekerjaan, tapi itu salah satu cara untuk kehilangan pekerjaan. Tes kode adalah masalah kontrol kualitas. Setiap perusahaan yang menggunakan tes kode ketika merekrut orang melakukannya, karena sebelumnya mereka tidak menggunakan tes kode. Mereka memiliki pengalaman buruk seseorang tergelincir melalui celah-celah proses wawancara yang seharusnya tidak.

Mereka akan mengambil kode sumber Anda dan menyebarkannya di kantor. Orang-orang akan berkomentar tentang hal itu, dan apa yang Anda tidak ingin mereka katakan adalah "Dia membuat kesalahan ini? Tetapi menghabiskan waktu menggunakan Git, CMake dan Travis-CI. Betapa bodohnya melewatkan kesalahan ini."

Itu dia. Anda tersesat.

Mereka ingin tahu Anda bisa kode, karena mereka tidak bisa mengajari Anda itu. Git, CMake dan Travis-CI dapat dengan mudah diajarkan.

Saya berpikir bahwa pendekatan Anda tidak baik atau buruk per se . Saya akan bertanya kepada pewawancara apakah boleh menggunakan Github dan alat-alat lainnya. Seperti @Izkata tunjukkan dalam komentar, Anda membuat solusi Anda publik.

Sebagai pewawancara, saya tahu bahwa biasanya tidak ada salahnya kandidat mencoba mengklarifikasi beberapa hal. Juga, mengajukan satu atau dua pertanyaan bisa menjadi pertanda baik, karena Anda tidak terburu-buru melakukan hal-hal yang tidak Anda pahami.

Ingat, bagaimanapun, bahwa hal yang paling penting adalah bahwa masalahnya diselesaikan, dan diselesaikan dengan baik. Dalam hal itu, semua orang setuju bahwa test suite membantu. Tetapi, untuk itu, mungkin Anda hanya perlu mengirim beberapa kelas ujian bersama dengan proyek / solusi Anda.