Bukan Insinyur Sungguhan, ‘Not a real engineer’ (2019)

• Prosa puisi singkat ini berangkat dari deklarasi “You are not a real engineer”, lalu menumpuk pemberitahuan gagal wawancara dan citra monster mitologis dalam satu konteks
• Sosok yang dituju digambarkan sebagai makhluk transenden dengan tinggi seperti manusia, kepala singa, enam belas sayap, ratusan mata, dan sabuk berbentuk ular
• Napas seperti awan badai, suara seperti auman angin, dan langkah kaki yang membuat rumput layu terus memperbesar kesan kekuatan sosok itu
• Pada bagian akhir, muncul frasa penolakan rekrutmen “saat ini kami tidak akan menawarkan peran ini” yang disusul alasan “kami mencari seseorang yang lebih teknis”
• Bahkan sosok yang destruktif pun ditolak karena bukan orang yang lebih teknis, sehingga terlihat absurditas standar tentang “insinyur sungguhan”

---

Deskripsi yang meluas menjadi makhluk mitologis

• Kalimat pembuka adalah “You are not a real engineer”, yang secara langsung menyatakan bahwa sosok tersebut bukan insinyur sungguhan
• Setelah itu, sosok tersebut membesar menjadi makhluk bertubuh manusia dan berkepala singa, dengan enam belas sayap putih dan ratusan mata seperti obor
• Sabuk di pinggangnya adalah ular, napasnya merupakan kumpulan awan badai, dan suaranya mendekati auman angin
• Di hadapan langkahnya, rumput menjadi layu, dan lidah hitam gelap seperti jurang dalam membawa kiamat pada segala sesuatu yang disentuhnya

Pembalikan yang diciptakan oleh frasa penolakan rekrutmen

• Penutupnya tiba-tiba beralih dari deskripsi yang sangat menggetarkan ke frasa penolakan sopan dalam proses rekrutmen
• Setelah kalimat “saat ini kami tidak akan menawarkan peran ini”, muncul alasan “kami mencari seseorang yang lebih teknis”
• Benturan antara citra mitologis sebelumnya dan kalimat penolakan rekrutmen yang biasa di bagian akhir mengungkap rapuhnya makna ungkapan “insinyur sungguhan”

[GN⁺]

Opini Hacker News

• Belakangan ini saya sudah berhenti berpikir untuk merekrut engineer level jenius untuk posisi yang 80% jam kerjanya adalah membangun aplikasi CRUD.
  Itu pemborosan uang dan talent pool, tidak baik bagi kandidat, dan menjadi risiko jangka panjang bagi perusahaan. Orang seperti itu pada akhirnya kemungkinan besar akan bosan lalu mulai melakukan over-engineering agar otaknya tetap terpakai.
  Bagi sebagian besar engineer, sudah cukup jika mereka bisa menulis operasi create, update, delete, read dengan benar di level database dan API, memanggil API dari frontend, serta memiliki penanganan error yang layak dan pendekatan debugging yang cukup baik.

  • Saya pernah menjadi hiring manager di beberapa tim, tetapi tidak sesederhana itu. Memang benar, tugas teknis yang bukan level John Carmack tidak membutuhkan John Carmack.
    Namun saya juga melihat programmer yang “cukup oke” menghasilkan pekerjaan yang “lumayan”, dan programmer yang lebih baik bekerja 5 kali lebih cepat tanpa bekerja 5 kali lebih lama, nyaris bisa mengelola dirinya sendiri, tidak perlu terus ditempeli QA untuk memastikan tiket yang ditandai selesai benar-benar selesai, dan saat ada masalah bisa menyelesaikannya secara kreatif tanpa perlu orang lain membongkar Git repository untuk mereka.
    Kita tidak perlu otak yang terlalu liar, tetapi programmer yang baik/hebat membuat perbedaan besar bahkan dalam proyek yang secara teknis tampak biasa-biasa saja.
  • Di dunia SPA dan microservices sekarang, orang yang baru saja Anda gambarkan itu pada dasarnya sudah mendekati deskripsi engineer level jenius.

• Baru-baru ini saya sedang tertarik pada Steve Howe, dan saya pernah membaca bahwa dia, yang dianggap salah satu gitaris terbaik sepanjang masa, mengatakan semacam harapan agar para gitaris fokus menjadi musisi. Perbedaan antara coder dan engineer juga mirip.
  Saya sudah melihat banyak programmer yang secara teknis lebih piawai daripada saya, tetapi mereka bukan engineer yang lebih baik. Fakta bahwa saya seorang founder dan juga punya latar belakang marketing cukup berpengaruh besar.
  Banyak perusahaan meremehkan kemampuan non-coding yang sebenarnya membentuk seorang engineer. Itu seperti mempekerjakan tukang jagal alih-alih chef lalu heran mengapa makanannya tidak enak.

  • Sampai batas tertentu benar, tetapi itu agak melenceng dari kecenderungan standar orang yang masuk ke engineering secara umum.
    Mendapat gelar sarjana di bidang teknis, bekerja sebagai engineer #52354 di tempat seperti Ingersoll Rand atau Boeing, lalu pensiun 30 tahun kemudian sebagai ahli di domain yang kompleks tetapi terbatas, juga merupakan karier yang bagus. Itu juga definisi “engineer” yang valid, dan meski orang-orang seperti itu mungkin tampak membosankan, mereka sangat mungkin menjalani hidup yang memuaskan secara pribadi.
    Belakangan saya banyak memikirkan masalah ini; manajemen cenderung melihat engineer standar sebagai pusat biaya, sementara orang seperti yang dibahas dalam tulisan ini nilainya melampaui engineering hingga ke departemen lain yang langsung menghasilkan pendapatan, sehingga bisa lolos dari kritik semacam itu.
    Saya rasa saya juga engineer tipe serupa, tetapi saya berusaha mengubah rasa meremehkan stereotip itu menjadi sikap yang lebih kolaboratif.
  • Tapi begitulah pasarnya. 99% pemberi kerja tidak menginginkan engineer, mereka menginginkan coder framework terbaru yang murah.
    Pasar nyata menilai coder Spring Java lebih tinggi daripada engineer C++ yang menangani hardware.
  • Apa saja contoh kemampuan non-coding yang membuat seseorang menjadi engineer yang lebih baik?
  • Tambahan kecil, Howe memang hebat dan termasuk salah satu yang terbaik, tetapi Paco De Lucia jauh berada di atasnya.

• Saya sudah mengalami kedua sisinya. Saya pernah menghadapi perubahan tak terduga dan penghinaan ringan dalam proses mencari kerja, dan saya juga pernah mewawancarai lalu menolak kandidat berpengalaman yang omongannya meyakinkan tetapi tidak bisa menunjukkan kemampuan coding untuk soal setingkat FizzBuzz dalam bahasa apa pun.
  Ini bukan soal memilih salah satu antara “wawancara teknis itu berantakan” dan “di pasar kerja ada banyak kandidat yang tidak memenuhi syarat”. Keduanya bisa benar, dan menurut saya dalam praktiknya saling terkait seperti market for lemons.

  • Saya belajar bahwa penting untuk memahami bahwa wawancara, atau lebih luas lagi proses mencari kerja, bukanlah proses yang objektif dan adil, dan hasilnya juga tidak pasti atau bisa direproduksi.
    Seseorang yang secara objektif lebih baik bisa saja direkrut, dan kandidat ideal pun bisa langsung tersingkir di phone screening. Pada akhirnya ini mendekati faktor keberuntungan, dan orang-orang yang mengatakan sebaliknya bercampur antara survivorship bias dan keengganan mengakui bahwa prosesnya sendiri cacat.
    Penilaian seperti kandidat berpengalaman tidak bisa mengerjakan soal setingkat FizzBuzz juga menurut saya mencerminkan pola pikir cargo cult yang merusak rekrutmen. Saya tahu engineer FANG yang harus berlatih coding golf serta kuis algoritma dan struktur data selama berminggu-minggu, yang tidak mirip dengan software engineering nyata, hanya untuk lolos wawancara tahap pertama.
    Saya bahkan berpikir masalah-masalah semacam ini lebih mirip menendang tangga daripada evaluasi teknis. Dulu saya pernah otomatis gugur untuk posisi C++ yang membuat aplikasi desktop karena tidak tahu placement new, dan seorang kenalan yang melamar posisi backend membuat service Spring dari nol dan semua integration test lulus, tetapi ditolak karena tidak ada komentar di controller. Ada pewawancara yang memperlakukan hal yang bisa diperbaiki dengan satu baris komentar di PR seolah-olah itu masalah teknis besar lalu menggugurkan kandidat.

• Orang yang merekrut juga melakukan kesalahan. Merekrut orang dengan sukses itu benar-benar sulit.
  Kadang-kadang mereka justru menyelamatkan Anda dari tempat kerja berisi orang-orang yang pada akhirnya memang tidak akan Anda sukai. Mereka juga tidak terlalu pandai membuat alasan yang terdengar masuk akal soal mengapa Anda tidak direkrut, dan sebagian besar adalah keberuntungan.
  Misalnya, mereka mungkin mendapat kesan “sepertinya bukan pendukung Trump” lalu merasa tidak bisa bergaul nyaman dengan Anda. Kalau Anda memang bukan bagian dari kelompok mereka, apakah ada alasan untuk ingin bekerja di sana?
  Mencari kerja selalu membuat saya murung, dan saya tidak tahu jawabannya selain jangan menaruh harapan terlalu besar pada satu pekerjaan tertentu. Pada saat yang sama, jangan terlalu mudah mengabaikan peluang yang tampaknya tidak terlalu istimewa.
  Atasan pertama saya di pekerjaan sekarang buruk sekali dan tidak banyak orang baik di sana, tetapi mereka pergi dari perusahaan dan saya dipromosikan. Bagaimana mungkin hal seperti itu bisa diprediksi? Perekrut juga tidak bisa memprediksi Anda, dan keseluruhan prosesnya cukup acak dan tidak nyaman.
  Saat saya berada di posisi pewawancara, saya punya prioritas. Pertama, atasan saya memberi nasihat singkat: “usahakan merekrut orang baik”. Saya lebih ingin bekerja dengan developer yang baik, ramah, saling membantu, dan mudah diajak bekerja sama daripada orang yang selalu harus mengikuti kemauannya sendiri dan percaya bahwa ia jenius superproduktif sehingga harus diberi wewenang penuh.
  Kedua, saya melihat apakah kandidat tertarik pada software atau setidaknya pada sesuatu. Jika tidak ada sedikit pun antusiasme terhadap software, teknologi, atau sesuatu yang berkaitan dengan pekerjaan, bagaimana mereka akan mempelajari hal-hal yang dibutuhkan tetapi tidak ada di CV? Orang tidak datang sebagai “produk jadi”; kita harus mengharapkan mereka belajar.

  • Kenapa ingin bekerja di sana kalau memang bukan bagian dari kelompok mereka? Karena harus bisa membayar sewa. Sesekali juga ingin makan sebagai kemewahan.

• Menurut saya bahkan proses wawancara yang baik pun jelas bisa menolak sebagian kandidat yang sebenarnya akan bekerja dengan sangat baik.
  Untuk benar-benar memahami apakah seseorang cocok untuk pekerjaan itu, waktu yang harus dihabiskan baik oleh pemberi kerja maupun kandidat dalam proses wawancara akan terlalu besar. Dari sisi pemberi kerja itu alokasi sumber daya yang buruk, dan bagi kandidat juga sulit diterima.
  Idealnya, kandidat datang ke kantor dan menyelesaikan proyek coding kecil sendirian selama satu hari, tetapi secara realistis itu tidak praktis.