HackerRank açık kaynak ATS'sinde aynı özgeçmişin puanı 90, 74 ve 88 arasında dalgalandı
(danunparsed.com)- Aynı özgeçmiş ve aynı komutla HackerRank’in açık kaynak ATS işe alım ajanı tekrar tekrar çalıştırıldığında puanların 66 ile 99 arasında dalgalandığı, 85 puanlık eşikte ise başvuruların %65’inin elendiği görüldü
- Bu araç, PDF özgeçmişi ayrıştırıp LLM’i 6 kez çağırarak temel bilgiler, deneyim, eğitim, beceriler, projeler ve ödülleri yapılandırıyor; ardından GitHub bilgisini de ekleyip 100 puan + 20 bonus puan üzerinden değerlendiriyor
- Teknik beceriler 100 denemenin 98’inde 8/10 ile neredeyse sabit kalırken, proje değerlendirmesi “mimari karmaşıklık yetersiz” ile “gerçek dağıtımı gösteriyor” arasında gidip gelerek yüksek oynaklık gösterdi
- Varsayılan model gemma3:4b’de temperature 0.1 kullanılmasına rağmen, temperature 0’da bile belirlenimsizlik sürdü; Gemini’ye geçildiğinde de 60 puan eşiğinde %28 elenme oranı ortaya çıktı
- Deneyim bölümünde yalnızca tek bir staj bulunan eski bir özgeçmişin bile 25/25 alması, LLM tabanlı puanlamanın aday kalitesini ayırmaktan çok şansa dayalı bir filtrelemeye dönüşebileceğini gösteriyor
Aynı özgeçmiş her seferinde farklı puan alıyor
- HackerRank’in açık kaynak ATS’si hiring-agent, LinkedIn ve Reddit’te dikkat çekmesinin ardından teste tabi tutuldu
- İlk çalıştırmada puan 90/100 oldu; hata ayıklama için eklenen çıktı satırları kaldırıldıktan sonra aynı özgeçmiş ve aynı komutla yeniden çalıştırıldığında sonuç 74/100 çıktı
DEVELOPMENT_MODEdevre dışı bırakılıp 100 kez tekrar çalıştırıldığında puan aralığının 66’dan 99’a kadar açıldığı görüldü- Şirketin geçme barajı 85 puansa, aynı özgeçmişin bile %65 olasılıkla elenmesi söz konusu
Değerlendirme hattı ve puanlama yapısı
- Araç, PDF özgeçmişi metne dönüştürdükten sonra aday bilgisini yapılandırmak için LLM’i birkaç kez çağırıyor
- Temel bilgiler
- Deneyim
- Eğitim
- Beceriler
- Projeler
- Ödüller
- GitHub profili ve öne çıkan depolar taranıyor, ardından bu bilgi ek bağlam olarak eklenip tüm veri tek seferde LLM değerlendirmesine veriliyor
- Varsayılan model, yerelde çalışan gemma3:4b ve temperature değeri 0.1 olarak ayarlı
- Puanlama 100 tam puan üzerinden yapılıyor ve en fazla 20 bonus puan eklenebiliyor
- Açık kaynak katkıları: 35 puan
- Kişisel projeler: 30 puan
- İş deneyimi: 25 puan
- Teknik beceriler: 10 puan
- Startup deneyimi, portföy sitesi, teknik blog vb.: en fazla 20 bonus puan
Tutarlı kalan kalemler ve dalgalanan kalemler
- Teknik beceriler, 100 çalıştırmanın 98’inde 8/10 alarak neredeyse tamamen tutarlıydı
- React gibi teknolojilere sahip olup olmamak bir kontrol listesine daha yakın olduğundan, LLM’in öznel yorumu için daha az alan bırakıyor
- Buna karşılık projeler kalemi, her çalıştırmada büyük ölçüde farklı değerlendirildi
- Bazı çalıştırmalarda projeler “mimari karmaşıklık yetersiz” diye değerlendirildi
- Diğerlerinde ise “gerçek dağıtımı gösteriyor” olarak puanlandı
- Temperature 0.1 düşük bir ayar olsa da, değer 0’a indirilince bile sorun ortadan kalkmadı
- Ekim 2025’te açılan GitHub issue içinde de temperature 0 ile 6 ardışık puanın 27, 34, 32, 34, 34, 30 olduğu görüldü
Model değişse de süren istikrarsızlık
- gemma3:4b’nin yerel bir model olması nedeniyle model etkisi ayrıca kontrol edildi
- Gemini kullanıldığında puan dağılımı 48 ile 64 arasında daha dar oldu
- Ancak eşik 60 puansa, aday özgeçmiş içeriğinden bağımsız olarak %28 olasılıkla eleniyor
- Açık kaynak puanları daha tutarlı hale gelse de, proje puanları hâlâ ciddi biçimde dalgalandı
Deneyim puanındaki ters sorun: tutarlı ama işe yaramaz
- Deneyim kalemi tüm çalıştırmalarda 25/25 aldı
- Yalnızca tek bir staj içeren eski bir özgeçmiş bile 25/25 alabildi
- Değerlendirme istemindeki Production bölümü yalnızca iki satırdan oluşuyor
workvevolunteerbölümlerinden gerçek iş, staj ve production deneyimini analiz et- Kurucu, kurucu ortak ve erken aşama startup mühendisi rolleri için ek değerlendirme yap
- 15 puanla 25 puanı ayıran bir ölçüt, örnek ya da referans noktası yok
- Sonuç olarak junior bir mühendisin stajı, 10 yıllık dağıtık sistem deneyimine sahip bir principal engineer ve testte kullanılan özgeçmişin tamamı 25/25 alabiliyor
Özgeçmiş elemesindeki pratik riskler
- LLM ile özgeçmişi yapılandırılmış veriye dönüştürmek ya da Python bilgisi olup olmadığını kontrol etmek nispeten daha uygun kullanım alanlarına yakın
- Aday deneyiminin 18 mi yoksa 24 puan mı olduğuna karar vermek ise vibe-check benzeri sonuçlar üretiyor
- Açık kaynak ve projelerin birlikte toplam puanın %65’ini oluşturması da işe alım kararlarını çarpıtabiliyor
- 30 yıllık deneyimiyle S3’ü inşa eden bir mühendisten, iki stajı ve açık kaynak projeleri olan bir adaya daha yüksek puan verilebilir
- GitHub’da izi kalmayan önemli işler yapmış mühendisler puanlarının yarısından fazlasını kaybedebilir
- Özgeçmiş elemesinde yapay zeka araçlarını devreye alma yetkisine sahip mühendislerin, kaliteyi ayırt edemeyen bir aracın sadece aday eleme mekanizmasına dönüşebileceğine dikkat etmesi gerekiyor
Düzeltme notu
- resume_evaluation_criteria.jinja şablonunun ilk satırında “Software Intern” ifadesi yer alıyor
- Bu ifade belgelenmiş değil ve deponun başka bir yerinde de referans verilmiyor
- Aynı şablon ilerleyen kısımda kurucu, kurucu ortak ve erken aşama startup mühendisi rollerine bonus veriyor
- Açıkça Senior SWE istemi eklenip yeniden çalıştırıldığında da sonuç değişmedi; puan boyutları görev seviyesiyle ilişkisiz şekilde çalışıyor
1 yorum
Hacker News yorumları
LLM'lerin tamamen olasılıksal bir süreç olarak çalıştığını bilmeyen bu kadar çok insan olması şaşırtıcı; bu yüzden böyle derinlemesine yazıları görmek sevindirici
İş arıyorum ve bugünlerde geri dönüş almanın bu kadar zor olmasının nedeni belki de budur. Özgeçmiş sanki bir LLM kara deliğine atılıyor ve gerçekte nasıl çalıştığını kimse bilmiyor gibi
Yazıdaki “temperature 0.1 — düşük bir değer olduğu için modeli deterministik çıktıya yönlendirdiği düşünülür” açıklaması doğru değil. Temperature bir determinizm anahtarı değil, örnekleme dağılımını etkileyen bir değerdir; yalnızca daha sivri bir dağılım oluşur, ama hâlâ bir dağılımdır
Daha kesin söylemek gerekirse temperature 0 diye bir şey aslında yoktur. Matematiksel olarak temperature 0'a yaklaştıkça dağılım giderek sivrileşir; en olası örneğin ağırlığı neredeyse sonsuza yaklaşırken diğerleri neredeyse 0'a yaklaşır
Gerçek uygulamalarda
temperature=0, 0 olmayan değerlerde kullanılan formülü kullanmak yerine, sıfıra bölmeyi önlemek için ayrı birifdalında en yaygın örneği seçme şeklinde uygulanırAncak batch işleme veya uygulamaya bağlı kayan nokta hataları nedeniyle olasılık dağılımının kendisi çoğu zaman çalıştırmadan çalıştırmaya değişir; bunun sonucunda örnek de değişir
Aynı özgeçmişe bakan iki kişi aynı sonuca varabilir; aynı semptomlara ve klinik tabloya sahip iki hasta farklı hastalıklara sahip olabilir
Eski yapay zekanın esas olarak bilgi tabanını sürdürme maliyeti yüzünden öldüğü açıklaması bana pek ikna edici gelmiyor; bence asıl mesele belirsizliği ele alan genel bir çıkarım sisteminin yokluğuydu
Spock'ın sürekli “Kaptan, bu görevde hayatta kalma olasılığımız %21” gibi şeyler söylemesi bana kişisel olarak tekrar eden bir espri gibi geliyor. Bayesçi açıdan olasılık dağılımlarının da olasılık dağılımları vardır; bu yüzden “bu görevde hayatta kalma ihtimalimiz β(5,1)” demek daha doğru bir ifadeye yakın
Bu anlamda özgeçmişi o makineye 100 kez verip puanların olasılık dağılımına bakmak da o kadar tuhaf bir şey değil
[1] Yine de ben yatakta uzanıp tabletle görüntü ayıklarken görsel sistemim bozulana kadar devam eden türden bir deliyim
Ancak MoE ise yinelenen girdinin tüm batch içinde de aynı olması gerekir. Batch komşuları uzman seçimini etkileyebilir
Kernel deterministik olmalı ve akıl yürütme modellerinde küme genelindeki yük gibi şeylere tepki veren sistem düzeyinde bir efor seviyesi anahtarı bulunmamalı
Sonuç olarak mevcut bulut altyapısında temperature 0 muhtemelen deterministik değildir, ama edge inference'ta oldukça istikrarlı biçimde deterministik olabilir
0.1'in daha deterministik olduğu ifadesine gelince, bunu gayet makul bir özet olarak görüyorum. Temperature 0.9'a kıyasla 0.1'de “temperature 0'ın cevabı” yönünde çok daha sık örnekleme yapmıyor muyuz?
“Tutarlı sonuçlar almak istiyorsan temperature'ı 0 olarak ayarla” sözünü sayısız kez duydum
Bunun böyle olmayabileceği birkaç neden var, ancak yazarın yaptığı gibi yerel model çalıştırıldığı durumlarda bu nedenlerin geçerli olmadığını düşünüyorum
Yapay zekanın yapay zeka tarafından yazılmış kodu “tercih etme” eğilimi ve diğer önyargılar da eklendiğinde, bu yöntemin AB’de ayrımcılık karşıtı yasaları çeşitli şekillerde ihlal ederek büyük olasılıkla çok yasa dışı olması muhtemel
Özgeçmiş sayısının çok fazla olması gerekçesiyle rastgele eleme yapmak genel olarak kabul edilebilir gibi görünüyor. Ama bunun gerçekten rastgele olması ve özgeçmiş içeriğinden bağımsız olması gerekir
Yapay zekada rastgelelik, gerçek özgeçmiş değerlendirmesinden bağımsız olmadığı için bu kapsama girmez
Genel olarak yapay zekanın sistematik önyargı uygulamadığı garanti edilemez; hatta uygulama ihtimalinin yüksek olduğuna dair güçlü işaretler de var
İnsanlara önyargıları görmezden gelmeleri için eğitim ve talimat verilebilir. Elbette bu da güvenilir biçimde işlemez, ama en azından yasa dışı önyargının sorumluluğunun talimata uymayan işe alım görevlisine devredildiği bir yapı oluşur
Buna karşılık yapay zeka kullanımında, ne talimat verilmiş olursa olsun kullanıcı sorumludur. Belirli bir bağlamda belirli bir yapay zekanın güçlü biçimde önyargılı olduğu teknik olarak “gösterilebilir veya kanıtlanabilir”. İnsan çalışanlar için de teknik olarak mümkündür ama pratikte neredeyse zor değildir
Sonuçta hukuki risk “bireysel ve büyük ölçüde inkâr edilebilir” seviyeden sistematik olarak kanıtlanabilir önyargı alanına kayar. Başka bir deyişle işe alımda yapay zeka kullanıldığını öğrenirlerse insanlar bunu hukuken sistematik şekilde hedef alabilir
Yani yalnızca matematiksel açıdan bakıldığında bile bunun ABD’de ırk, cinsiyet ve diğer korunan gruplarla bir şekilde korele olma ihtimali yüksektir
Bu yüzden ABD’de de iyi bir dava ile yasa dışı hale gelebilir. Mutlaka davayı kazanmak da gerekmez; mahkemede yeterince dayanması bile diğer şirketleri bunu kullanmaktan korkutabilir
Kendi yapay zeka eleme aracımın tüm işe alım mevzuatına tamamen uyduğunu kanıtlamak zorunda olan davalı konumunda olmak istemezdim. Kâbus gibi olurdu
[1]: https://gwern.net/everything
Yığından dördüncü özgeçmişi alıp o kişiye iş teklif etmek aptalca ama tamamen adil bir işe alım kararı yöntemidir
Ancak yapay zeka önyargı yakalama konusunda çok iyi olduğundan, özgeçmişleri elemesi istendiğinde adayın adı gibi kesinlikle ölçüt alınmaması gereken unsurları ölçüt almasına şaşırmamak gerekir
Büyük bir açık kaynak projede yazım hatası düzelttiğini belirten tüm özgeçmişler geçerken, yalnızca kendi projesini yazan özgeçmişlerin %60 olasılıkla elenmesi gibi bir durum olabilir. O zaman kötü adaylardan çok iyi adayları kaybedersiniz
Mantıksız bir kumar makinesi gibi çalıştığı için istenmeyen dolaylı ayrımcılık etkileri doğurabileceğine katılıyorum. Ama “din veya inanç, engellilik, yaş, cinsel yönelim” nedeniyle ayrımcılık yaptığı izlenimini vermek muhtemelen kolay olmayacaktır. Mümkün, ama avukatların mahkemede bunu kanıtlaması için çok çalışması gerekir
Daha ilginç kısım EU AI Act. Bu bölüm 2 Aralık 2027’ye kadar henüz yürürlüğe girmeyecek olsa da, işe alım veya gerçek kişilerin seçimi için kullanılan yapay zeka sistemleri, özellikle hedefli işe alım ilanlarının yerleştirilmesi, başvuruların analizi ve filtrelenmesi, adayların değerlendirilmesi için kullanılan sistemler açıkça yüksek riskli yapay zeka sistemleridir
Bu yasaklandığı anlamına gelmez, ancak ileride LLM’ler yüksek riskli yapay zeka kullanım senaryolarının dışında tutulabilir. Çünkü istisnasız Article 6 kapsamına girebilirler
Standartlar henüz yayımlanmamışken, bu tür işler için LLM kullanıldığında Article 10’un aşağıdaki kısımlarına uyumun nasıl sağlanacağını hiç bilmiyorum
“(f) İnsanların sağlık ve güvenliğini etkileyen, temel haklar üzerinde olumsuz etki yaratabilecek ya da AB hukuku kapsamında yasaklanan ayrımcılığa yol açabilecek önyargıların incelenmesi. Özellikle veri çıktısının gelecekteki işlemlerin girdisini etkilediği durumlarda
(g) (f) uyarınca tespit edilen olası önyargıları saptamak, önlemek ve azaltmak için uygun önlemler”
Şu an için model sağlayıcısı tamamen işbirliği yapsa bile genel amaçlı LLM’lerle bunun teknik olarak mümkün olmadığını düşünüyorum. Küçük modellerde anlamlı bir denetim mümkün olabilir
EU AI Act sonunda Annex III’teki yüksek riskli kullanım senaryolarında “LLM kullanıyoruz ama neden kullandığımızı pek bilmiyoruz” tarzı vibe coding yaklaşımını tamamen dışarıda bırakabilir; bu da makul görünüyor
https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
“Veri sahibi, profilleme de dahil olmak üzere yalnızca otomatik işlemeye dayanan ve kendisi hakkında hukuki sonuç doğuran ya da benzer şekilde kendisini önemli ölçüde etkileyen bir karara tabi olmama hakkına sahiptir”
22(2)’deki istisnaların uygulanması zordur. Gerçekten gerekli olduğunu savunmak zordur ve istihdam bağlamında rıza da neredeyse geçerli sayılmaz. AB veya üye devletin belirli bir yasası izin veriyorsa mümkün olabilir, ancak ayrı bir hukuki dayanak gerekir
Bu noktada “şanssız insanları işe almak istemediğim için özgeçmişlerin yarısını gözüm kapalı atıyorum” şakasını doğrudan benimsemek de mümkün
Bu yöntem, o dönemde giderek karmaşıklaşan manuel özgeçmiş değerlendirme ölçütlerini hedefleyecek imkânı olan öğrencilerden ziyade, daha az varlıklı geçmişe sahip nitelikli öğrencilere avantaj sağlıyordu
“Geleceğin doktorlarını kumarla mı seçeceksiniz?” tarzı örgütlü bir kampanya yürütüldü ve sonunda kura yöntemi sessizce kaldırıldı
Geriye kalan adayların yarısı bu seçimde şanslarının bir kısmını zaten harcadığı için, ortalamada atılan yarıdan daha az şanslı olacaktır
Son birkaç on yılda eğitim ve öğretim büyük ölçüde genişledi; iş arayanların sayısı sürekli arttı, ancak iş yaratımı bu hıza yetişemedi
Tek bir açık pozisyon için onlarca aday başvurduğunda, işveren özgeçmişleri kötü şekilde eleseler veya yarısını çöpe atsalar bile yine de nitelikli birini işe alabilir
“%65 olasılıkla eleniyorum. Tamamen aynı özgeçmiş, farklı şans” sonucu, son birkaç yılda teknik pozisyonlar için işe alım pipeline’ı işletmiş biri açısından aslında harika bir sayı
Bunu söylemekten nesnel olarak hoşlanmıyorum ama gerçek bu
Hiç çaba harcamadan teknik yetenekleri bir sonraki aşamaya taşıma olasılığı %35 mi? Alana özel eleme soruları eklediğimizde bile saatte 100’den fazla adaya baktığımı gördüm. Bu da saatte 35 “elenmiş/seçilmiş” aday demek
Geçerli adaylar elenmiş oluyor mu? Evet. Yine de ihtiyacınız olandan 35 kat daha büyük bir aday havuzuna mı sahip oluyorsunuz? Ne yazık ki yine evet
Aday sayısı o kadar fazla ki yapay zeka devreye girmediğinde bir sonraki aşamaya geçme olasılığı aslında çok daha düşük oluyor. Hemen başvurmadıysanız, üstelik bunu bir yapay zeka botuyla yapmadıysanız, önünüzde 50’den fazla kişi var demektir ve yorgun bir teknik liderin bir gün sizin özgeçmişinize kadar gelmesi gerekir
Referans bonusunun var olmasının bir nedeni var
En yeni teknolojiyle en iyi* başvuruların yalnızca %1’ini geçiriyor
*Kendi tescilli, kapalı ve deterministik olmayan metriklerimize göre;
Math.randomolabilir de olmayabilir deÖzgeçmiş akışını azaltan bir kapı, ancak bu azalmanın kaliteyle korelasyonu varsa faydalıdır. Aksi halde işe alım sürecini uzatır ya da sonunda işe alım standartlarını gereksiz yere düşürtür
“John Schmidt”, “John J. Schmidt”, “John J. J. Schmidt”, “John Jacob J. Schmidt”, “J. J. Jingleheimer Schmidt” gibi
İlk başvuran 50 kişinin tamamı botsa, özgeçmişleri neden başvuru sırasına göre okuyorsunuz?
Daha endişe verici olan, başka sistemler de bu ATS gibi çalışıyorsa, oldukça makul ya da iyi adayları topluca eleyecek unsurlara göre karar veriyor gibi görünmeleri
Örneğin kişisel projeler ile açık kaynak katkılarının birleşimine 65 puan verilmiş. Teknoloji tek ilgi alanınızsa ve aileniz, bakmakla yükümlü olduğunuz kişiler ya da ikinci/üçüncü bir işiniz yoksa bu iyi olabilir
Ama bunlardan biri bile varsa ihtimallerin inanılmaz derecede aleyhinize döndüğü görünüyor
Bu sistemlerin ne kadarının, üniversiteye gitmek ya da istedikleri sektörde tek bir işte çalışmak dışında kaygısı olmayan ve teknolojiye neredeyse özel ilgi düzeyinde takıntıyla odaklanabilen varlıklı insanlar lehine tasarlandığını merak ediyorum
Kendimden örnek verirsem, şirket dışında neredeyse hiç kişisel proje yapmıyorum. Gerçek programlama deneyimimin tamamı çalışma saatlerinde işverenlerim için yaptıklarımdan ibaret
Hobilerim 3D baskı, donanım/Arduino, fotoğrafçılık gibi teknolojiye yakın alanlar; ama GitHub’a yığınla proje koyan biri değilim
Potansiyel işverenlere göstermek için sahte CRUD ya da SaaS uygulamaları da kesinlikle yapmayacağım. Zaman kaybı
Bilerek böyle bir çevrim içi varlık hiç oluşturmadım. GitHub’ımda herkese açık depo yok, blog da yazmıyorum
Bu eğilim çalıştığım operasyon/sistem yönetimi tarafına da yayıldı; orada durum daha da kötü. Elbette GitHub’ıma ortama özel bir sürü script koymadım, neden koyayım ki? Şu anki şirketimdeki departmanımda çalışmayan biri için hiçbir anlamı yok
Determinizm kelimesinin, dokunduğu çevrim içi yazıları çarpıtan sihirli bir etkisi var
O kelime duyulduğunda neredeyse kesin olarak yanlış yöne gidileceğini garanti edebilirsiniz. Yine de bu sefer aynı girdiyle aynı çıktı anlamındaki gerçek determinizmden söz ediliyor; alakasız başka şeylerden değil
Determinizm tekrarlanabilirlik için önemlidir, ama bu durumda gerçekten çıktının tekrarlanmasını istiyor musunuz? LLM çıktısını deterministik yapmak nispeten önemsizdir. Batch kullanıyorsanız batch’e invariant kernel kullanır, temperature’ı 0’a ayarlarsınız — ya da bunu yapmazsınız, çünkü rastgele örneklemenin bir nedeni vardır — daha iyisi seed’i sabitlersiniz. Bazı sistemlerde bu zaten mümkün
Ama bu sonucu daha kullanışlı yapmaz. Sadece ajan’ın aslında emin olmadığı gerçeğini gizler. Puan aralığına bakın. Hâlâ hiçbir şeyi öngöremez, yalnızca her seferinde aynı puanı verir. Gerçekten istediğiniz bu mu?
Burada olan şey, çok az bilgi sağlanması ve neredeyse gürültü düzeyinde tek bir özgeçmiş verip çok geniş sonuçları olan bir cevap beklenmesi
LLM kullanılıp kullanılmamasından bağımsız olarak temel bir tasarım hatası. Tüm anketler, sınavlar, yasalar ve oylama sistemleri çok az bilgiyle çalıştıkları için çerçevelemeye aşırı duyarlıdır. Sadece onlar, bu şeyin aksine, vakum içinde var olmaz
Las Vegas algoritmaları deterministik değildir ama %100 doğrudur. Bunun karşılığında doğru cevaba ulaşma süresinin çok değişebilmesi ödünleşimi vardır
Buradaki hata deterministik olmayan bir sistem kullanmak değil. Bir anlamda hata, onu fazla az kullanmak bile olabilir. Aynı özgeçmişi 5 kez yeniden değerlendirip puan varyansının yüksek olduğunu görmek, tek kez değerlendirmekten daha faydalı bir sinyaldir
Öğle yemeğinden hemen önceki bir saatte daha ağır cezalar çıktığı hikâyesini herkes duymuştur
İnsanların filtreleme sürecine göre optimizasyon yapmasını engellemek istiyorsanız, onu bir ölçüde deterministik olmayan hale getirmeniz gerekir
Örneğin ilk 100’de bıçak gibi kesmek yerine, daha iyi adayların filtreden geçme olasılığını üstel biçimde artırmak gibi
Böylece filtreleme sürecini Goodhart tarzı sömürmeye çalışmanın değeri azalır. Çünkü olasılık neredeyse hiç artmaz ve zamanı kullanacak çok daha iyi yerler vardır
Varsayılan model
gemma3:4bise bu çok küçük bir modeldirHiçbir LLM kusursuz ve tekrarlanabilir bir hakem olmayabilir ama böyle bir sisteme 4B model takmak, rastgele sayı üreteci bağlamaya benzer
Tüm deney, sanki biri açık kaynak bir ATS projesi yapmak istediği için vibe coding ile bir ATS yapmış, sonra da yalnızca testler geçecek kadar ayarlamış gibi hissettiriyor
Bu modelle de iyi çalışacak bir özgeçmiş analiz yöntemi muhtemelen vardır. Ama bu yöntem “hey hurda yığını, bu kişi hangi projeleri yapmış?” gibi bir yaklaşım değildir
Çıkarma, düzenleme, muhtemelen OCR üzerinden karşılaştırma ve ek düzenleme, sinyal başına birden çok LLM analizi, karar vericiler vb. gerekir
Bunların hiçbirinin büyük model olması şart değil. Büyük model kullanmak biraz daha iyi yapabilir ama bağlam çok az olduğu için doğru kullanılırsa bu tür modeller de iyi çalışabilir
ATS’yi kendim çalıştırdım ve benzer şekilde tuhaf bir deneyim yaşadım
GitHub profilimi bulamadığı için 70’lerde puan verdi, ardından yaptığım bazı ünlü Ruby kütüphanelerini beğenmedi
Birkaç kez çalıştırdıktan sonra düzgün tanımaya başladı ama resmî eğitim geçmişimde her zaman puan kırdı
Bu tür şeyler mide bulandırıcı
Sertifikaları veya ödülleri de yakalayamadı. İnsanların iyileştirme önerdiği birkaç PR’ı uygulamayı denedim (https://github.com/Zem-0/hiring-agent); faydası oldu ama genel olarak bu ATS, büyük ölçekli GitHub açık kaynak katkıları olan kişilere ciddi şekilde yanlı
İyi mühendis bulmak zor olduğu için teknoloji şirketlerinin 300 bin doların üzerinde ödeme yapmasına rağmen, işe alım uzmanlarının destek olmadan çalışması ve “iyi aday” ölçütlerinin tamamen farklı olması bana hep şaşırtıcı gelmiştir
ATS, berbat filtreleme sezgiselleri yüzünden özgeçmişlerin %50’den fazlasını kara deliğe gönderiyor; işe alım ekipleri ise Google Gmail entegrasyonu gibi nedenlerle ATS seçiyor ve o ATS’nin filtreleme teknolojisi mühendislik ya da veri ekiplerinden kimse tarafından incelenmiyor
Kendi özgeçmişimle denediğimde somehow GSoC bonus puanı aldım
BONUS POINTS: 5.0------------------------------Google Summer of Code (GSoC) participation: +5Oysa GSoC’ye hiç katılmadım ve özgeçmişimde de katıldığımı yazmadım
Bilinen bir halüsinasyon https://github.com/interviewstreet/hiring-agent/issues/240