Cara Merekrut Developer Ketika Anda Tidak Paham Teknis

Saat Anda menyadari Anda kehilangan pegangan

Anda memasang lowongan, CV pun berdatangan, dan setiap satu darinya mencantumkan framework yang belum pernah Anda dengar. Ada yang mengklaim lima tahun pengalaman "full-stack development dengan arsitektur microservices yang scalable" dan Anda tidak tahu apakah itu benar-benar mengesankan atau hanya sesuatu yang dibaca dari situs tutorial sejam sebelum wawancara. Anda mengangguk-angguk saja selama panggilan. Anda tidak punya cara untuk membantahnya.

Ini wajar terjadi. Sebagian besar orang yang menjalankan perusahaan dengan 10–200 karyawan bukanlah developer, dan sebagian besar dari mereka tetap perlu merekrut satu. Kabar baiknya: Anda tidak perlu belajar coding untuk bisa merekrut dengan baik. Anda hanya perlu berhenti mencoba menilai kodenya dan mulai menilai bukti-bukti di sekitarnya.

Jangan berpura-pura paham teknis — itu bisa jadi bumerang

Kandidat bisa merasakan ketika Anda sedang menggertak. Menanyakan "jadi ceritakan pengalaman Anda dengan Kubernetes" lalu hanya menjawab "bagus, bagus" apa pun jawabannya akan mengajarkan kandidat yang cerdik bahwa wawancara ini tidak punya standar yang sebenarnya. Mereka yang pandai bicara tapi tidak bisa mengeksekusi akan lolos mulus. Sementara yang pendiam tapi kompeten, yang mengira Anda benar-benar memeriksa, justru akan meremehkan diri mereka sendiri.

Sebaiknya jujur saja soal ini. "Saya tidak paham teknis, jadi saya akan meminta Anda menjelaskan hal-hal dengan bahasa yang sederhana, dan saya akan melibatkan seseorang yang paham teknis untuk sebagian dari proses ini." Ini bukan kelemahan — ini sama seperti yang dilakukan manajer perekrutan yang kompeten ketika merekrut di bidang apa pun yang tidak ia tekuni sendiri.

Pinjam "mata teknis" orang lain — untuk satu jam, bukan seluruh proses

Anda tidak perlu co-founder teknis penuh waktu untuk bisa merekrut dengan baik. Anda hanya butuh satu jam waktu seorang developer, sebanyak dua kali: sekali untuk membantu menulis deskripsi pekerjaan dan pertanyaan penyaringan, dan sekali lagi untuk ikut dalam percakapan babak final atau meninjau contoh hasil kerja.

Siapa yang bisa membantu:

• Developer lepas (freelance) yang Anda bayar untuk konsultasi dua jam
• Teman atau penasihat yang pernah membangun software
• Kontraktor yang sudah Anda gunakan untuk hal lain

Yang Anda minta dari mereka harus spesifik: "Lihat jawaban kandidat ini untuk pertanyaan tertentu ini dan katakan apakah itu masuk akal." Bukan "tolong nilai orang ini untuk saya" — itu terlalu samar dan terlalu berat untuk sebuah bantuan.

Minta kandidat menjelaskan hasil kerja mereka sendiri, bukan skenario hipotetis

Developer yang benar-benar pernah membangun sesuatu bisa menjelaskannya dengan bahasa sederhana, sedetail apa pun yang Anda minta. Orang yang mengarang-ngarang CV biasanya tidak bisa menjelaskan lebih dari permukaannya.

Pertanyaan yang bagus, diurutkan berdasarkan seberapa banyak yang bisa diungkap:

1. "Ceritakan sesuatu yang pernah Anda bangun dan Anda banggakan. Apa fungsinya, dan apa peran Anda di dalamnya?"
2. "Apa masalah teknis tersulit dalam proyek itu, dan bagaimana Anda memecahkannya?"
3. "Jika saya bertanya pada engineer lain di tim itu bagaimana rasanya bekerja dengan Anda, apa yang akan mereka katakan — dan kenapa?"
4. "Ceritakan saat kode Anda pernah membuat sesuatu rusak di production. Apa yang terjadi dan apa yang Anda lakukan?"

Pertanyaan keempat paling banyak mengungkap. Hampir semua developer sungguhan pernah membuat sesuatu rusak. Orang yang bilang "itu tidak pernah terjadi pada saya" setelah mengklaim beberapa tahun pengalaman kemungkinan besar berbohong, atau memang belum pernah merilis sesuatu yang benar-benar penting.

Gunakan contoh kerja nyata yang kecil

Anda tidak perlu meminta kandidat membangun seluruh fitur secara gratis. Tugas singkat dan terbatas — yang memakan waktu 60–90 menit, mirip dengan pekerjaan sebenarnya yang akan mereka lakukan di posisi itu — memberi Anda informasi lebih banyak daripada satu jam percakapan.

Jaga agar tetap adil:

• Bayar untuk tugas itu, atau buat tugasnya benar-benar cukup kecil sehingga wajar jika tidak dibayar (kebanyakan kandidat akan memberi tahu Anda mana yang mana)
• Berikan tugas yang sama kepada semua orang di tahap tersebut
• Minta mereka menjelaskan solusi mereka sendiri setelahnya — di sinilah Anda bisa menangkap seseorang yang dibantu orang lain tanpa mengaku

Jika Anda tidak punya kemampuan teknis untuk menilai hasilnya sendiri, inilah saat yang tepat untuk menggunakan satu jam waktu teknis pinjaman Anda.

Jika Anda lebih memilih untuk tidak menyusun tugas dari nol, tes penyaringan teknis yang terkalibrasi bisa melakukan penyaringan awal sebelum Anda sampai ke tahap ini — AssessFit menjalankan tes adaptif di berbagai kemampuan teknis sehingga Anda tidak perlu mengirim setiap pelamar langsung ke satu-satunya peninjau teknis Anda.

Periksa apa yang sudah mereka hasilkan, bukan apa yang mereka klaim ketahui

CV yang penuh nama teknologi hanya menunjukkan apa yang pernah disentuh seseorang, bukan apa yang mereka kuasai dengan baik. Sebagai gantinya, minta bukti:

• Profil GitHub, portofolio, atau tautan ke sesuatu yang sudah live yang mereka bangun
• Nama perusahaan dan produknya, sehingga Anda bisa melihatnya sendiri
• Berapa persen dari sebuah proyek yang benar-benar hasil kerja mereka dibanding hasil kerja tim

Jangan terkesan hanya karena daftar tools yang panjang. Justru tertariklah pada satu atau dua hal yang bisa mereka jelaskan secara mendalam. Kedalaman adalah sinyal sesungguhnya; luasnya daftar istilah teknis justru sering menjadi kebalikannya.

Pengecekan referensi: tanyakan soal penyelesaian pekerjaan, bukan kemampuan

Anda tidak bisa bertanya pada referensi "apakah kodenya bagus?" dan berharap jawaban yang berguna, kecuali referensinya juga paham teknis — dan bahkan begitu, itu tetap pertanyaan yang lunak dan cenderung dijawab dengan murah hati tanpa dibantah.

Tanyakan ini sebagai gantinya:

• "Apakah mereka menyelesaikan apa yang mereka janjikan, sesuai jadwal yang mereka perkirakan?"
• "Ketika ada yang salah, apakah mereka memberi tahu Anda lebih awal atau Anda baru tahu belakangan?"
• "Apakah Anda akan mempercayakan sesuatu yang ambigu kepada mereka dan yakin mereka bisa mencari solusinya, atau semuanya harus dijelaskan secara rinci?"

Pertanyaan-pertanyaan ini juga tidak mengharuskan referensi paham kode. Yang dibutuhkan hanyalah referensi yang pernah bekerja bersama orang ini, dan itu jauh lebih mudah untuk mendapatkan jawaban yang jujur.

Batas kejujuran di sini

Tidak satu pun dari ini bisa menggantikan memiliki orang teknis yang Anda percaya, pada akhirnya. Jika perekrutan ini adalah engineer pertama Anda dan benar-benar tidak ada seorang pun di jaringan Anda yang bisa memeriksa kewajarannya, itu layak diakui secara terbuka sebagai risiko — kepada diri sendiri, dan mungkin kepada investor awal atau penasihat yang mungkin mengenal seseorang. Masa percobaan 90 hari dengan milestone penyelesaian yang jelas dan non-teknis (apakah produknya jadi dirilis, apakah berfungsi, apakah ada keluhan pengguna) adalah jaring pengaman Anda jika perekrutan ini ternyata lebih lemah dari yang terlihat saat wawancara.

Anda tidak sedang berusaha menjadi developer. Anda sedang berusaha membangun proses yang bisa membedakan antara orang yang benar-benar pernah membangun sesuatu dan orang yang hanya menghafal istilah-istilahnya.