Resume yang sama bisa dapat skor 90, 74, 88, lalu 83 dari sistem AI yang sama. Kalau angka itu cuma buat eksperimen, mungkin lucu. Tapi kalau angka itu menentukan siapa yang lanjut interview dan siapa yang langsung ditolak, ini bukan sekadar bug kecil.
Artikel ini membahas kenapa AI hiring bisa berubah jadi luck filter kalau sistem scoring-nya tidak stabil. Intinya: skor AI yang terlihat rapi belum tentu objektif, apalagi kalau output bisa berubah antar-run tanpa alasan yang jelas. Buat developer dan builder produk AI, pelajarannya sederhana: kalau AI dipakai untuk keputusan manusia, testing, audit, dan human review harus jauh lebih serius daripada sekadar “modelnya pintar”.
Apa itu AI hiring dan kenapa scoring resume rawan disalahpahami?
AI hiring adalah penggunaan sistem AI untuk membantu proses rekrutmen: membaca resume, mencocokkan kandidat dengan job description, memberi skor, merangkum pengalaman, atau merekomendasikan kandidat. Di atas kertas, ini terdengar masuk akal. Recruiter punya banyak dokumen, waktu terbatas, dan butuh bantuan buat memilah kandidat.
Masalahnya muncul ketika output AI diperlakukan seperti angka objektif. Skor 88/100 terlihat presisi, padahal bisa saja dia cuma hasil dari prompt, model, konteks, dan run tertentu. Kalau sistem yang sama memberi skor berbeda untuk input yang sama, berarti angka itu bukan “kebenaran”; dia sinyal yang perlu diaudit.
Dan di hiring, efeknya nggak kecil. Buat kandidat, satu angka bisa berarti lanjut interview atau hilang kesempatan. Buat perusahaan, false reject bisa bikin kandidat bagus tidak pernah masuk pipeline.
Kasus HackerRank open-source ATS: resume sama, skor beda
Pemicunya adalah tulisan Dan Kinsky tentang open-source ATS dari HackerRank/InterviewStreet. Dia mencoba sistem hiring-agent yang diposisikan sebagai AI agent untuk mengevaluasi dan memberi skor resume. Hasil yang dia laporkan cukup mengganggu: resume yang sama bisa dapat skor 90/100, lalu 74/100, lalu 88/100, lalu 83/100.
Gua nggak mau menjadikan satu eksperimen ini sebagai vonis final bahwa semua ATS berbasis AI pasti buruk. Konfigurasi model, prompt, temperature, input parsing, dan cara menjalankan tool bisa memengaruhi hasil. Tapi justru di situ poinnya: kalau sistem dipakai untuk keputusan serius, ketidakstabilan seperti ini harus dianggap risiko produk, bukan detail teknis yang bisa diabaikan.
Repo interviewstreet/hiring-agent sendiri tersedia publik dan menjelaskan dirinya sebagai AI agent untuk mengevaluasi dan memberi skor resume. Transparansi seperti ini bagus karena publik bisa mengaudit, belajar, dan mengkritik. Tapi transparansi source code tidak otomatis membuat keputusan AI jadi adil, stabil, atau layak dipakai tanpa guardrail.
Kenapa skor AI bisa terlihat objektif padahal belum tentu stabil?
Ada beberapa alasan kenapa sistem scoring berbasis AI bisa berubah-ubah:
- Model generatif tidak selalu deterministik. Kalau sampling tidak dikunci, output bisa berubah walau inputnya sama.
- Prompt bisa memberi ruang interpretasi terlalu besar. Kata seperti “strong candidate” atau “relevant experience” bisa dibaca beda antar-run.
- Parsing resume bisa rapuh. Format PDF, bullet, tabel, layout dua kolom, atau teks yang kepotong bisa mengubah konteks yang masuk ke model.
- Rubric scoring sering kurang eksplisit. Kalau bobot pengalaman, skill, domain, dan seniority tidak jelas, model akan mengisi celah dengan asumsi.
- Angka presisi memberi ilusi kepastian. Skor 83/100 terasa ilmiah, padahal mungkin tidak dikalibrasi terhadap performa kerja nyata.
Ini bukan cuma masalah hiring. Pola yang sama berlaku buat semua AI decision system: credit scoring, moderation, ranking kandidat, review bug report, prioritas support ticket, sampai evaluasi performa karyawan. Begitu output AI memengaruhi nasib orang, standar engineering-nya harus naik.
Checklist buat builder sebelum pakai AI untuk menilai manusia
Kalau lu bikin atau memakai sistem AI buat hiring, jangan berhenti di “demo-nya jalan”. Minimal, cek beberapa hal ini:
- Stability test: input yang sama harus diuji berkali-kali. Kalau skor berubah banyak, sistem belum siap jadi filter otomatis.
- Rubric eksplisit: tulis bobot penilaian dengan jelas. Jangan biarkan model mengarang prioritas sendiri.
- Audit log: simpan versi prompt, model, input, output, dan alasan keputusan. Tanpa audit log, komplain kandidat sulit ditelusuri.
- Human review: AI boleh membantu ranking, tapi jangan jadi palu akhir untuk menolak kandidat tanpa konteks.
- Regression test: punya set resume contoh. Setiap perubahan prompt/model harus diuji ulang, bukan langsung dipakai produksi.
- Bias review: cek apakah sistem menghukum format resume, gap karier, kampus non-populer, atau pengalaman non-linear secara tidak proporsional.
- Calibration: pastikan skor punya arti. Bedanya 74 dan 88 harus bisa dijelaskan, bukan cuma angka yang keluar dari model.
Checklist ini terdengar membosankan. Tapi ini bedanya prototype AI dengan software production. Prototype boleh membuat orang kagum. Software production harus bisa dipertanggungjawabkan.
Pelajaran buat developer yang lagi cari kerja
Buat lu yang sedang melamar kerja, ada sisi praktis juga. Kalau proses hiring makin banyak memakai AI, resume harus makin mudah dibaca mesin dan manusia.
Beberapa langkah yang bisa lu lakukan:
- Pakai struktur resume yang bersih: role, company/project, periode, impact, tech stack.
- Hindari layout yang terlalu kreatif kalau versi ATS-friendly tidak tersedia.
- Tulis impact konkret, misalnya “mengurangi waktu build 35%” atau “migrasi payment webhook dengan idempotency”.
- Siapkan portfolio publik: GitHub, blog, case study, demo, atau catatan build in public.
- Jangan cuma optimasi keyword. Bukti kerja nyata tetap lebih kuat daripada resume yang penuh buzzword.
Menurut gua, ini nyambung banget dengan personal branding developer. Ketika resume bisa dipoles AI, bukti kerja nyata jadi makin mahal: artikel teknis, project yang bisa dicoba, kontribusi open-source, dan penjelasan proses berpikir.
Pelajaran buat perusahaan: automasi hiring bukan alasan menghapus judgment
Perusahaan sering tergoda memakai AI karena proses hiring memang mahal. Banyak resume masuk, waktu recruiter terbatas, dan hiring manager tidak selalu punya bandwidth. Tapi kalau AI filter dipakai terlalu agresif, perusahaan bisa menghemat waktu sambil membuang kandidat bagus.
AI seharusnya membantu manusia melihat pola, bukan mengganti judgment sepenuhnya. Misalnya: merangkum resume, menandai skill yang perlu diverifikasi, mencari inkonsistensi, atau membantu menyusun pertanyaan interview. Itu beda dengan “skor di bawah 80 otomatis reject”.
Kalau lu membangun produk AI untuk HR, jangan jual narasi “AI bisa memilih kandidat terbaik” terlalu gampang. Janji yang lebih sehat: AI membantu proses screening jadi lebih rapi, konsisten, dan bisa diaudit, dengan manusia tetap memegang keputusan akhir.
Takeaway singkat
- Skor AI yang terlihat objektif belum tentu stabil.
- Resume yang sama seharusnya tidak mendapat hasil yang liar antar-run.
- AI hiring butuh stability test, audit log, rubric eksplisit, dan human review.
- Buat developer, bukti kerja nyata makin penting karena resume makin mudah dipoles AI.
- Buat builder, sistem AI yang menilai manusia harus diuji lebih ketat daripada chatbot biasa.
FAQ singkat
Apakah AI tidak boleh dipakai untuk hiring?
Boleh, tapi posisinya sebaiknya sebagai alat bantu, bukan pengambil keputusan final. AI bisa merangkum dan membantu screening awal, tapi keputusan penting tetap perlu manusia, audit, dan mekanisme banding.
Apakah skor resume dari AI selalu salah?
Tidak selalu. Masalahnya bukan “AI selalu salah”, tapi skor yang tidak stabil dan tidak terkalibrasi bisa menyesatkan. Angka rapi tetap harus punya dasar yang bisa dijelaskan.
Apa yang harus dicek sebelum perusahaan memakai AI hiring tool?
Cek stabilitas output, dokumentasi rubric, audit log, bias testing, regression test, dan apakah ada human review. Kalau vendor tidak bisa menjelaskan itu, lu patut hati-hati.
Developer harus ngapain menghadapi ATS berbasis AI?
Bikin resume yang jelas dan ATS-friendly, tapi jangan berhenti di situ. Bangun bukti kerja nyata: portfolio, blog, project, kontribusi, atau case study yang bisa diverifikasi.
