ATS open source HackerRank goyah memberi skor 90, 74, dan 88 untuk resume yang sama
(danunparsed.com)- Menjalankan berulang agen rekrutmen ATS open source milik HackerRank dengan resume yang sama dan perintah yang sama menghasilkan skor yang berubah-ubah dari 66 hingga 99, dan dengan cutoff 85 poin, 65% hasilnya berakhir gagal lolos
- Alat ini mem-parsing resume PDF dan memanggil LLM 6 kali untuk menyusun informasi dasar, pengalaman, pendidikan, keterampilan, proyek, dan penghargaan, lalu menambahkan informasi GitHub untuk menilai dengan skema 100 poin + bonus 20 poin
- Skor keterampilan teknis hampir tetap, dengan 98 dari 100 percobaan menghasilkan 8/10, tetapi penilaian proyek menunjukkan volatilitas besar, bolak-balik antara “kurang kompleksitas arsitektur” dan “menunjukkan deployment nyata”
- Bukan hanya temperature 0.1 pada model dasar gemma3:4b, ketidakdeterministikan tetap ada bahkan pada temperature 0, dan saat diganti ke Gemini pun muncul tingkat kegagalan 28% pada cutoff 60 poin
- Pada kategori pengalaman, bahkan resume lama yang hanya berisi satu magang mendapat 25/25, sehingga penskoran oleh LLM bisa menjadi penyaringan berbasis keberuntungan alih-alih membedakan kualitas kandidat
Resume yang sama menerima skor berbeda setiap kali
- ATS open source HackerRank, hiring-agent, menjadi sasaran pengujian setelah mendapat perhatian di LinkedIn dan Reddit
- Skor pada eksekusi pertama adalah 90/100, lalu setelah menghapus output debug dan menjalankan lagi dengan resume serta perintah yang sama, hasilnya menjadi 74/100
- Setelah
DEVELOPMENT_MODEdinonaktifkan dan dilakukan 100 kali eksekusi berulang, rentang skor melebar menjadi 66~99 - Jika ambang kelulusan perusahaan adalah 85, resume yang sama akan gagal lolos dengan probabilitas 65%
Pipeline evaluasi dan struktur bobot skor
- Alat ini mem-parsing resume PDF menjadi teks, lalu memanggil LLM beberapa kali untuk menyusun informasi kandidat
- informasi dasar
- pengalaman
- pendidikan
- keterampilan
- proyek
- penghargaan
- Profil GitHub dan repositori teratas dipindai, lalu informasi ini ditambahkan sebagai konteks ekstra dan seluruh informasi dimasukkan sekaligus ke evaluasi LLM
- Model default adalah gemma3:4b yang dijalankan secara lokal, dengan temperature disetel ke 0.1
- Skor dasar adalah 100 poin, dengan bonus tambahan hingga 20 poin
- kontribusi open source: 35 poin
- proyek pribadi: 30 poin
- pengalaman kerja: 25 poin
- keterampilan teknis: 10 poin
- pengalaman startup, situs portofolio, blog teknis, dll.: bonus hingga 20 poin
Bagian yang konsisten dan bagian yang goyah
- Keterampilan teknis hampir konsisten, dengan 8/10 pada 98 dari 100 percobaan
- Keberadaan teknologi seperti React lebih mendekati checklist, sehingga ruang untuk penilaian subjektif LLM lebih kecil
- Sebaliknya, kategori proyek menunjukkan penilaian yang sangat berbeda di tiap eksekusi
- Pada beberapa eksekusi, proyek dinilai “kurang kompleksitas arsitektur”
- Pada eksekusi lain, proyek dinilai “menunjukkan deployment nyata”
- Temperature 0.1 memang rendah, tetapi bahkan saat diturunkan ke temperature 0 masalahnya tidak hilang
- Dalam GitHub issue yang dibuka pada Oktober 2025, skor pada temperature 0 juga berbeda selama 6 kali berturut-turut: 27, 34, 32, 34, 34, 30
Ketidakstabilan tetap ada meski model diganti
- Karena gemma3:4b adalah model lokal, pengaruh model juga ikut diperiksa
- Saat menggunakan Gemini, distribusi skor menyempit menjadi 48~64
- Namun jika cutoff adalah 60, kandidat tetap gagal lolos dengan probabilitas 28% terlepas dari isi resume mereka
- Skor open source berubah lebih konsisten, tetapi skor proyek tetap sangat berfluktuasi
Masalah kebalikan pada skor pengalaman: konsisten tetapi tidak berguna
- Kategori pengalaman menghasilkan 25/25 pada semua eksekusi
- Bahkan resume lama yang hanya memiliki satu magang pun mendapat 25/25
- Bagian Production dalam prompt evaluasi hanya terdiri dari dua baris
- menganalisis pekerjaan nyata, magang, dan pengalaman production dari bagian
workdanvolunteer - memberi pertimbangan tambahan untuk peran pendiri, co-founder, dan engineer awal di startup
- menganalisis pekerjaan nyata, magang, dan pengalaman production dari bagian
- Tidak ada kriteria, contoh, atau patokan yang membedakan 15 poin dan 25 poin
- Akibatnya, magang milik engineer junior, principal engineer dengan 10 tahun pengalaman sistem terdistribusi, dan resume yang dipakai dalam pengujian semuanya bisa sama-sama mendapat 25/25
Risiko praktis dalam penyaringan resume
- Menggunakan LLM untuk mem-parsing resume menjadi data terstruktur atau memeriksa apakah seseorang memiliki Python adalah penggunaan yang relatif lebih cocok
- Menentukan apakah pengalaman kandidat bernilai 18 atau 24 poin menghasilkan sesuatu yang lebih dekat ke vibe-check
- Struktur yang memberi bobot gabungan 65% pada open source dan proyek juga dapat mendistorsi keputusan rekrutmen
- Kandidat dengan 2 magang dan proyek open source bisa dinilai lebih tinggi daripada engineer dengan 30 tahun pengalaman yang membuat S3
- Engineer yang telah mengerjakan hal penting tetapi tidak meninggalkan jejak di GitHub bisa kehilangan lebih dari setengah nilainya
- Engineer yang memiliki kewenangan untuk menerapkan alat AI dalam penyaringan resume perlu berhati-hati bahwa alat yang tidak mampu membedakan kualitas bisa berubah menjadi sekadar perangkat untuk menyingkirkan pelamar
Koreksi
- Pada baris pertama template resume_evaluation_criteria.jinja, terdapat frasa “Software Intern”
- Frasa ini tidak didokumentasikan dan juga tidak dirujuk di bagian lain repositori
- Template yang sama di bagian belakang memberikan bonus untuk peran pendiri, co-founder, dan engineer startup tahap awal
- Bahkan setelah prompt Senior SWE dimasukkan secara eksplisit dan dijalankan ulang, hasilnya tetap sama, dan dimensi skor bekerja tanpa kaitan dengan level jabatan
1 komentar
Komentar Hacker News
Mengejutkan betapa banyak orang yang tidak tahu bahwa LLM bekerja sebagai proses probabilistik murni, jadi tulisan mendalam seperti ini menyenangkan untuk dibaca
Saya sedang mencari kerja, dan mungkin ini alasan mengapa sekarang begitu sulit mendapat callback. Rasanya resume kita cuma dilempar ke semacam black hole LLM, dan tidak ada yang benar-benar tahu cara kerjanya
Penjelasan dalam tulisan itu, “temperature 0.1 — nilai rendah sehingga dianggap mengarahkan model ke keluaran deterministik,” tidak akurat. Temperature bukan sakelar determinisme, melainkan nilai yang memengaruhi distribusi sampling; distribusinya hanya menjadi lebih tajam, tetapi tetap sebuah distribusi
Lebih tepatnya, temperature 0 itu sendiri tidak ada. Secara matematis, saat temperature mendekati 0, distribusinya makin tajam, sampel dengan probabilitas tertinggi mendekati tak hingga, sementara yang lain mendekati 0
Dalam implementasi nyata,
temperature=0bukan memakai rumus yang digunakan untuk nilai non-nol, melainkan memilih sampel yang paling umum lewat cabangifterpisah untuk menghindari pembagian dengan nolNamun karena pemrosesan batch atau galat floating-point yang berbeda menurut implementasi, distribusi probabilitas itu sendiri sering berubah di setiap eksekusi, dan akibatnya sampelnya juga berubah
Dua orang bisa melihat resume yang sama dan sampai pada kesimpulan yang sama, dan dua pasien dengan gejala serta gambaran klinis yang sama bisa memiliki penyakit yang berbeda
Penjelasan bahwa AI lama terutama mati karena biaya pemeliharaan knowledge base tidak terlalu meyakinkan bagi saya; saya melihat inti masalahnya justru ketiadaan sistem inferensi umum untuk menangani ketidakpastian
Secara pribadi, Spock yang selalu mengatakan hal seperti “Kapten, peluang bertahan hidup dalam misi ini adalah 21%” terasa seperti lelucon berulang. Dari sudut pandang Bayesian, distribusi probabilitas pun punya distribusi probabilitas, jadi ungkapan yang lebih tepat kira-kira “kemungkinan bertahan hidup dalam misi ini adalah β(5,1)”
Dalam arti itu, memasukkan resume ke mesin itu 100 kali dan melihat distribusi probabilitas skornya juga bukan hal yang terlalu aneh
[1] Meski begitu, saya memang jenis orang gila yang berbaring di tempat tidur sambil merapikan gambar di tablet sampai sistem visual saya rusak
Namun jika itu MoE, input duplikat juga harus sama dalam keseluruhan batch. Tetangga dalam batch bisa memengaruhi pemilihan expert
Kernel harus deterministik, dan pada model reasoning tidak boleh ada sakelar tingkat upaya di level sistem yang bereaksi terhadap hal seperti beban seluruh klaster
Kesimpulannya, pada infrastruktur cloud yang ada, temperature 0 mungkin juga tidak deterministik, tetapi pada inferensi edge bisa cukup stabil deterministik
Soal ungkapan bahwa 0.1 lebih deterministik, menurut saya itu ringkasan yang cukup masuk akal. Bukankah pada temperature 0.1 kita akan jauh lebih sering mengambil sampel yang mengarah ke “jawaban temperature 0” dibanding pada temperature 0.9?
Saya sudah tak terhitung seringnya mendengar kalimat “kalau ingin hasil yang konsisten, setel temperature ke 0”
Ada beberapa alasan mengapa itu bisa tidak terjadi, tetapi jika menjalankan model lokal seperti yang dilakukan penulis, saya rasa alasan-alasan itu tidak berlaku
Jika digabungkan dengan kecenderungan AI untuk “menyukai” kode yang dibuat AI dan bias-bias lain, pendekatan seperti ini kemungkinan besar sangat ilegal di UE karena melanggar undang-undang antidiskriminasi dalam berbagai cara
Menyaring secara acak karena ada terlalu banyak CV pada umumnya bisa dianggap diperbolehkan. Namun itu harus benar-benar acak, dan harus independen dari isi CV
Pada AI, keacakan tidak independen dari penilaian CV yang sebenarnya, jadi ini tidak berlaku
Secara umum, tidak bisa dijamin bahwa AI tidak menerapkan bias sistematis, dan ada banyak tanda bahwa kemungkinan besar memang begitu
Manusia bisa dilatih dan diinstruksikan untuk mengabaikan bias. Tentu itu juga tidak bekerja secara andal, tetapi setidaknya strukturnya membuat tanggung jawab atas bias ilegal dialihkan ke perekrut yang melanggar instruksi
Sebaliknya, dalam penggunaan AI, penggunalah yang bertanggung jawab apa pun instruksi yang diberikan. Dalam konteks tertentu, juga mungkin secara teknis “menunjukkan atau membuktikan” bahwa AI tertentu sangat bias. Secara teknis itu juga mungkin untuk karyawan manusia, tetapi dalam praktiknya hampir tidak mudah
Pada akhirnya, risiko hukum bergeser dari tingkat yang “individual dan umumnya dapat disangkal” ke wilayah bias yang dapat dibuktikan secara sistematis. Dengan kata lain, begitu diketahui bahwa AI digunakan dalam perekrutan, orang dapat menyerangnya secara sistematis secara hukum
Artinya, bahkan jika dilihat secara matematis saja, besar kemungkinan ini berkorelasi dalam suatu cara dengan ras, gender, dan kelompok terlindungi lainnya di AS
Jadi di AS pun, satu gugatan yang bagus bisa membuatnya menjadi ilegal. Bahkan tidak harus menang; cukup bertahan cukup lama di pengadilan saja sudah bisa membuat perusahaan lain takut menggunakannya
Saya tidak ingin berada di posisi tergugat yang harus membuktikan bahwa penyaring AI saya sepenuhnya mematuhi semua peraturan ketenagakerjaan. Itu akan seperti mimpi buruk
[1]: https://gwern.net/everything
Mengambil CV keempat dari tumpukan dan menawarkan pekerjaan kepada orang itu adalah cara mengambil keputusan perekrutan yang bodoh, tetapi sepenuhnya adil
Namun AI sangat pandai menangkap bias, jadi tidak mengherankan jika ketika diminta menyaring CV, ia akhirnya menggunakan faktor yang sama sekali tidak boleh dijadikan dasar, seperti nama kandidat
Bisa saja semua CV yang menulis pernah memperbaiki typo di proyek open source besar lolos, sementara CV yang hanya mencantumkan proyek pribadi gugur dengan probabilitas 60%. Kalau begitu, kandidat bagus yang hilang justru lebih banyak daripada kandidat buruk
Saya setuju bahwa karena ia bekerja seperti mesin judi yang tidak rasional, mungkin ada efek diskriminasi tidak langsung yang tidak diinginkan. Namun mungkin tidak mudah untuk menunjukkan bahwa ia mendiskriminasi atas dasar “agama atau kepercayaan, disabilitas, usia, orientasi seksual”. Bisa saja, tetapi pengacara perlu banyak pekerjaan untuk membuktikannya di pengadilan
Bagian yang lebih menarik adalah EU AI Act. Bagian ini memang belum berlaku hingga 2 Desember 2027, tetapi sistem AI yang digunakan untuk perekrutan atau seleksi orang perseorangan, khususnya sistem yang digunakan untuk penempatan iklan rekrutmen tertarget, analisis dan pemfilteran lamaran, serta evaluasi kandidat, jelas merupakan sistem AI berisiko tinggi
Itu bukan berarti dilarang, tetapi nantinya LLM bisa saja dikecualikan dari kasus penggunaan AI berisiko tinggi. Sebab tanpa pengecualian, ia bisa terkena Article 6
Dengan standar yang belum dipublikasikan saat ini, saya sama sekali tidak tahu bagaimana membuat penggunaan LLM untuk tugas seperti ini mematuhi bagian berikut dari Article 10
“(f) memeriksa bias yang dapat memengaruhi kesehatan dan keselamatan manusia, berdampak negatif pada hak-hak dasar, atau berpotensi mengarah pada diskriminasi yang dilarang berdasarkan hukum UE. Terutama jika keluaran data memengaruhi masukan untuk pekerjaan berikutnya
(g) langkah-langkah yang tepat untuk mendeteksi, mencegah, dan memitigasi kemungkinan bias yang diidentifikasi sesuai dengan (f)”
Untuk saat ini, saya rasa secara teknis ini mustahil dengan LLM umum, sekalipun penyedia model bekerja sama sepenuhnya. Model kecil mungkin bisa diaudit secara bermakna
EU AI Act pada akhirnya mungkin akan menyingkirkan semua pendekatan ala vibe coding “memang memakai LLM, tapi tidak benar-benar tahu untuk apa” dari kasus penggunaan berisiko tinggi di Annex III, dan itu tampak masuk akal
https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
“Subjek data berhak untuk tidak menjadi objek keputusan yang semata-mata didasarkan pada pemrosesan otomatis, termasuk profiling, yang menimbulkan akibat hukum baginya atau secara serupa berdampak signifikan terhadap dirinya”
Pengecualian dalam 22(2) sulit diterapkan. Sulit berargumen bahwa itu benar-benar diperlukan, dan dalam konteks ketenagakerjaan persetujuan juga hampir tidak berlaku. Jika ada hukum khusus UE atau negara anggota yang mengizinkannya, mungkin bisa, tetapi diperlukan dasar hukum tersendiri
Pada titik ini, mungkin cukup mengadopsi saja lelucon “saya tidak ingin merekrut orang yang bernasib sial, jadi saya membuang setengah CV dengan mata tertutup”
Cara ini menguntungkan siswa memenuhi syarat dari latar belakang yang kurang berada dibandingkan siswa yang punya keleluasaan untuk mengakali kriteria penilaian CV manual yang saat itu makin kompleks
Ada kampanye terorganisasi semacam “apakah kita akan memilih calon dokter lewat undian?”, dan akhirnya sistem undian itu diam-diam dihentikan
Separuh kandidat yang tersisa sudah memakai sebagian keberuntungannya dalam seleksi ini, jadi secara rata-rata mereka akan kurang beruntung dibandingkan separuh yang dibuang
Selama beberapa dekade terakhir, pelatihan dan pendidikan berkembang pesat sehingga jumlah pencari kerja terus bertambah, tetapi penciptaan lapangan kerja tidak mampu mengimbangi laju itu
Jika puluhan kandidat berebut satu lowongan, pemberi kerja tetap bisa merekrut orang yang memenuhi syarat meski menyaring CV dengan berantakan atau membuang separuhnya
Hasil seperti “Saya punya peluang 65% untuk tersingkir. Resume yang sepenuhnya sama, nasib berbeda” sebenarnya angka yang bagus, dari sudut pandang seseorang yang pernah mengoperasikan pipeline rekrutmen posisi teknis dalam beberapa tahun terakhir
Secara objektif saya tidak suka mengatakannya, tapi ini benar
Peluang 35% untuk menaikkan tenaga teknis ke tahap berikutnya tanpa usaha? Bahkan dengan pertanyaan penyaringan khusus domain, saya pernah melihat lebih dari 100 pelamar per jam. Itu berarti ada 35 pelamar “tersaring” per jam
Apakah kandidat yang valid ikut tersaring keluar? Benar. Tapi apakah kita tetap mendapatkan pool kandidat 35 kali lebih besar dari yang dibutuhkan? Sayangnya, juga benar
Karena jumlah pelamar terlalu banyak, peluang untuk maju ke tahap berikutnya justru jauh lebih rendah saat AI tidak ikut campur. Jika Anda tidak segera melamar, apalagi jika tidak melamar memakai bot AI, ada lebih dari 50 orang di depan Anda dan seorang technical lead yang kelelahan harus suatu hari nanti sampai ke resume Anda
Bonus referral ada karena suatu alasan
Dengan teknologi terbaru, hanya 1% lamaran terbaik* yang lolos
*berdasarkan metrik eksklusif, tertutup, dan nondeterministik kami, yang mungkin saja atau mungkin juga bukan
Math.randomGerbang yang mengurangi arus masuk resume hanya berguna jika pengurangan itu berkorelasi dengan kualitas. Kalau tidak, itu hanya akan menyeret proses rekrutmen berlarut-larut, atau pada akhirnya membuat standar perekrutan diturunkan secara tidak perlu
Misalnya “John Schmidt”, “John J. Schmidt”, “John J. J. Schmidt”, “John Jacob J. Schmidt”, “J. J. Jingleheimer Schmidt”
Jika 50 orang pertama yang melamar semuanya bot, kenapa membaca resume berdasarkan urutan lamaran?
Yang lebih mengkhawatirkan adalah, jika sistem lain juga bekerja seperti ATS ini, tampaknya mereka menilai berdasarkan faktor-faktor yang akan menggugurkan banyak kandidat yang cukup baik atau bahkan bagus
Misalnya, kombinasi proyek pribadi dan kontribusi open source diberi 65 poin. Itu mungkin bagus jika teknologi adalah satu-satunya minat Anda, dan Anda tidak punya keluarga, tanggungan, atau pekerjaan kedua atau ketiga
Tapi jika salah satu saja dari hal-hal itu ada, peluangnya tampak sangat tidak menguntungkan
Saya jadi bertanya-tanya berapa banyak sistem seperti ini dirancang untuk menguntungkan orang-orang kaya yang, selain kuliah atau bekerja di satu pekerjaan di industri yang mereka inginkan, tidak punya kekhawatiran lain dan bisa terobsesi pada teknologi hampir seperti minat khusus
Ambil saya sendiri sebagai contoh: di luar perusahaan, saya hampir tidak mengerjakan proyek pribadi. Seluruh pengalaman pemrograman nyata saya adalah pekerjaan yang saya lakukan untuk pemberi kerja pada jam kerja
Hobi saya memang berdekatan dengan teknologi, seperti 3D printing, hardware/Arduino, dan fotografi, tapi bukan jenis yang membuat banyak proyek lalu mengunggahnya ke GitHub
Saya juga sama sekali tidak akan membuat aplikasi CRUD atau SaaS palsu untuk ditunjukkan kepada calon pemberi kerja. Itu buang-buang waktu
Saya sengaja tidak membangun kehadiran online seperti itu sama sekali. GitHub saya tidak punya repositori publik, dan saya juga tidak blogging
Kecenderungan ini juga menyebar ke bidang operasi/administrasi sistem tempat saya bekerja, dan di sana malah lebih parah. Tentu saja saya tidak menaruh banyak skrip khusus lingkungan di GitHub saya; kenapa harus? Itu tidak ada artinya bagi orang yang tidak bekerja di departemen saya di perusahaan sekarang
Kata determinisme punya efek magis yang membengkokkan tulisan online apa pun yang disentuhnya
Begitu kata itu terdengar, hampir bisa dijamin arahnya akan keliru. Namun kali ini yang dibahas memang determinisme nyata, yaitu input yang sama menghasilkan output yang sama, bukan hal-hal lain yang tidak relevan
Determinisme penting untuk reproduksibilitas, tetapi dalam kasus ini apakah kita benar-benar ingin output-nya dapat direproduksi? Membuat output LLM menjadi deterministik relatif sepele. Jika memakai batching, gunakan kernel yang invariant terhadap batch, dan jangan sekadar mengatur temperature ke 0; sampling acak ada alasannya. Lebih baik lagi, tetapkan seed. Di beberapa sistem, ini sudah memungkinkan
Namun ini tidak membuat hasilnya lebih berguna. Itu hanya menutupi fakta bahwa agen tersebut sebenarnya tidak yakin. Lihat rentang skornya. Ia tetap tidak memprediksi apa pun, hanya saja skornya akan sama setiap kali. Apakah itu benar-benar yang kita inginkan?
Yang terjadi di sini adalah informasi yang diberikan terlalu sedikit, hanya satu resume yang hampir setara noise, lalu diharapkan jawaban dengan implikasi yang terlalu luas
Terlepas dari memakai LLM atau tidak, ini adalah kesalahan desain mendasar. Semua survei, ujian, hukum, dan sistem pemungutan suara bekerja dengan informasi yang terlalu sedikit, sehingga sangat sensitif terhadap framing. Hanya saja, tidak seperti benda ini, mereka tidak ada dalam ruang hampa
Algoritma Las Vegas bersifat nondeterministik tetapi 100% benar. Komprominya adalah waktu untuk mencapai jawaban yang benar bisa sangat bervariasi
Kesalahan di sini bukanlah memakai sistem nondeterministik. Dalam arti tertentu, kesalahannya mungkin justru memakainya terlalu sedikit. Menilai ulang resume yang sama 5 kali dan melihat bahwa varians skornya besar adalah sinyal yang lebih berguna daripada menilainya hanya sekali
Semua orang mungkin pernah mendengar cerita bahwa vonis yang lebih berat dijatuhkan pada satu jam tepat sebelum makan siang
Jika ingin mencegah orang mengoptimalkan diri sesuai proses penyaringan, proses itu perlu dibuat nondeterministik sampai batas tertentu
Misalnya, alih-alih memotong tepat di 100 teratas, buat peluang kandidat yang lebih baik lolos filter meningkat secara eksponensial
Dengan begitu, nilai untuk menyerang proses penyaringan ala Goodhart berkurang. Probabilitasnya nyaris tidak bertambah, dan ada jauh lebih banyak tempat lain untuk menggunakan waktu dengan lebih baik
Jika model dasarnya
gemma3:4b, itu model yang sangat kecilMungkin tidak ada LLM yang bisa menjadi juri yang sempurna dan dapat diulang, tetapi memasang model 4B ke sistem seperti ini mirip seperti menghubungkan generator angka acak
Seluruh eksperimen ini terasa seperti seseorang ingin membuat proyek ATS open source, lalu membuat ATS dengan vibe coding, dan hanya menyesuaikannya sampai tesnya lolos
Mungkin ada cara analisis CV yang bisa bekerja baik bahkan dengan model ini. Tapi bukan dengan cara seperti “hei rongsokan, proyek apa yang dikerjakan orang ini?”
Diperlukan ekstraksi, perapian, mungkin perbandingan lewat OCR dan perapian tambahan, beberapa putaran analisis LLM untuk tiap sinyal, penilai, dan sebagainya
Tak satu pun dari itu harus berupa model besar. Memakai model besar mungkin sedikit lebih baik, tetapi karena konteksnya sangat sedikit, model seperti ini pun bisa bekerja dengan baik jika digunakan dengan benar
Saya mencoba menjalankan ATS sendiri dan mengalami hal aneh yang mirip
Ia tidak bisa menemukan profil GitHub saya sehingga skor saya keluar di kisaran 70-an, lalu setelah itu ia tidak menyukai beberapa library Ruby terkenal yang saya buat
Setelah dijalankan beberapa kali, ia mulai mengenalinya dengan cukup baik, tetapi untuk pendidikan formal saya selalu kena pengurangan skor
Hal seperti ini menjijikkan
Ia juga tidak bisa menangkap sertifikasi atau penghargaan. Saya mencoba menerapkan beberapa PR yang diusulkan orang untuk perbaikan (https://github.com/Zem-0/hiring-agent), dan itu memang membantu, tetapi secara keseluruhan ATS ini sangat bias terhadap orang yang punya kontribusi open source GitHub berskala besar
Saya selalu heran perusahaan teknologi bersedia membayar lebih dari 300 ribu dolar dengan alasan engineer bagus sulit dicari, tetapi perekrutnya justru bekerja tanpa dukungan dan sama sekali punya kriteria berbeda tentang “kandidat bagus”
ATS mengirim lebih dari 50% CV ke lubang hitam karena heuristik penyaringan yang buruk, tim rekrutmen memilih ATS karena alasan seperti integrasi Google Gmail, dan teknologi penyaringan ATS itu tidak pernah ditinjau oleh siapa pun di tim engineering atau tim data
Saya mencobanya dengan CV saya dan entah bagaimana mendapat poin bonus GSoC
BONUS POINTS: 5.0------------------------------Google Summer of Code (GSoC) participation: +5Padahal saya tidak pernah ikut GSoC, dan saya juga tidak menuliskannya di CV
Ini halusinasi yang sudah diketahui https://github.com/interviewstreet/hiring-agent/issues/240