Saya sudah mewawancarai banyak engineer selama dua tahun terakhir, dan tes syntax di whiteboard diam-diam sudah jadi bagian paling tidak berguna dari proses ini. Merekrut engineer di era AI berarti menguji skill set yang berbeda, karena hal yang dulu membedakan engineer bagus dari yang biasa saja, yaitu kemampuan menulis kode yang benar secara cepat dari ingatan, bukan lagi bottleneck-nya. AI sekarang yang menulis kode itu. Yang tidak bisa dilakukan AI secara konsisten adalah memutuskan apakah kode yang ditulisnya itu benar-benar tepat, atau apakah ia menyelesaikan masalah yang tepat sejak awal.

Ini bukan pergeseran teoretis bagi saya. Di tim Fleet dan Collecta kami, engineer menggunakan AI-assisted coding setiap hari. Yang benar-benar produktif bukan yang mengetik paling cepat. Mereka adalah yang bisa merumuskan masalah secara presisi, menangkap saran AI yang salah secara halus saat code review, dan bernalar soal bagaimana sebuah perubahan merambat ke seluruh sistem. Itu semua skill yang bisa dipelajari, tapi bukan yang diuji oleh kebanyakan proses interview.

Kalau pipeline rekrutmen Anda masih berpusat pada teka-teki algoritma dan hafalan syntax, Anda sedang mengoptimalkan skill yang nilainya cepat menyusut, sambil mengabaikan skill yang sekarang benar-benar memisahkan engineer kuat dari yang lemah.

Apa yang berubah dan kenapa ini penting untuk rekrutmen engineer di era AI

Tiga tahun lalu, engineer yang bisa menulis binary search yang benar dari ingatan di bawah tekanan sedang menunjukkan sesuatu yang nyata: kefasihan, presisi, disiplin. Sekarang, AI assistant menghasilkan binary search yang sama dalam dua detik, benar, hampir selalu. Skill langka itu bergeser satu lapis ke atas dalam stack.

Yang sekarang langka:

  • Spesifikasi masalah. Mengubah permintaan bisnis yang samar menjadi spesifikasi yang presisi dan bisa diuji, yang bisa dieksekusi oleh AI (atau junior engineer) tanpa menghasilkan sesuatu yang salah dengan percaya diri.
  • Review kritis. Membaca kode hasil AI dan tahu 10% mana yang salah secara halus, karena kode itu selalu terlihat masuk akal walau sebenarnya rusak.
  • System thinking. Memahami bagaimana perubahan di satu service memengaruhi tiga service lain, sesuatu yang tidak bisa dinalar oleh alat autocomplete mana pun.
  • Debugging dalam kondisi ambigu. Ketika kode hasil AI gagal di production, kegagalannya seringkali bukan error syntax, melainkan asumsi yang salah dan tertanam tiga lapis lebih dalam.

Tidak satu pun dari ini muncul dalam interview "balikkan linked list ini dalam 20 menit".

Bagaimana interview harus berubah

Saya sudah merestrukturisasi cara kami menyaring kandidat engineering di Syntax menjadi tiga jenis latihan, sepenuhnya menggantikan babak algoritma tradisional.

1. Latihan code review, bukan latihan menulis kode

Berikan kandidat sebuah pull request, baik nyata maupun sintetis, yang terlihat benar di permukaan tapi punya bug halus: off-by-one di query pagination, race condition di payment callback, null check yang hilang pada field opsional dari API eksternal. Amati bagaimana mereka menemukannya dan bagaimana mereka menjelaskan perbaikannya. Ini menguji persis otot yang akan mereka pakai setiap hari saat mereview output AI.

2. Tugas kolaborasi dengan AI

Dudukkan kandidat dengan AI coding assistant dan sebuah tiket nyata yang cukup ambigu. Jangan uji apakah mereka bisa memakai alatnya, uji apakah mereka berani mengoreksi alatnya. Apakah mereka menerima saran pertama begitu saja, atau mereka menangkap bahwa AI melewatkan edge case yang tersirat tapi tidak disebutkan secara eksplisit di tiket tersebut? Ini adalah prediktor terbaik yang pernah saya temukan untuk performa kerja di tim yang menggunakan AI-assisted coding.

3. Menulis spesifikasi

Minta kandidat mengubah permintaan fitur yang berantakan, dua paragraf (tulis dengan gaya yang benar-benar mirip cara stakeholder non-teknis menulisnya) menjadi spesifikasi lengkap dengan input, output, edge case, dan acceptance criteria yang jelas. Engineer yang tidak bisa melakukan ini akan menghasilkan kode berbantuan AI yang menyelesaikan masalah yang salah dengan cepat, dan itu lebih buruk daripada menyelesaikannya dengan lambat tapi benar.

Apa yang harus secara eksplisit berhenti diuji

Sinyal lama Kenapa jadi lebih lemah sekarang
Hafalan implementasi algoritma AI menghasilkannya secara instan dan benar
Kefasihan syntax di bahasa tertentu AI menerjemahkan antar bahasa dengan trivial
Kecepatan mengetik kode yang benar Bottleneck kecepatan bergeser ke review dan judgment
"Apakah mereka pernah pakai framework X" Waktu ramp-up dengan bantuan AI turun drastis

Saya tidak bilang fundamental jadi tidak penting, engineer yang sama sekali tidak bisa bernalar soal kompleksitas atau struktur data tetap akan kesulitan menangkap kesalahan AI di area itu. Tapi menguji kemampuan menghafalnya di bawah tekanan interview adalah menguji hal yang salah.

Membangun tim di sekitar ini, bukan cuma interview-nya

Pergeseran ini juga mengubah seperti apa rasio tim yang sehat. Saya sudah melihat kenapa estimasi software selalu meleset menjadi lebih parah, bukan lebih baik, pada tim berbantuan AI yang direkrut dengan skill set lama, karena kecepatan menulis kode naik sementara kecepatan mereview dan menyusun spesifikasi tetap datar, menciptakan bottleneck yang tidak direncanakan siapa pun. Kalau Anda merekrut lima pengetik cepat dan tidak ada satu pun reviewer yang kuat, Anda akan mengirim bug lebih cepat, bukan fitur.

Aturan praktis yang saya pakai: untuk setiap dua engineer yang direkrut terutama demi kecepatan membangun, rekrut satu orang khusus untuk kekuatan review dan system design, meskipun output koding mentahnya terlihat lebih lambat di atas kertas.

Kesimpulan praktisnya

Berhenti menguji hal yang sudah dikuasai AI dengan baik. Rancang ulang alur interview Anda di sekitar code review, latihan kolaborasi dengan AI, dan penulisan spesifikasi, karena itulah skill yang sekarang menentukan apakah tim Anda mengirim software yang benar atau dengan percaya diri mengirim software yang rusak lebih cepat dari sebelumnya. Engineer yang layak direkrut di era ini bukan yang bisa mengalahkan AI dalam menulis kode. Mereka adalah yang bisa menangkap AI saat AI salah.