Aslan, Cadı ve Recruiter’ın Yüzsüzlüğü
(hauleth.dev)- İş arayan kişi, iki şirketin işe alım sürecinden geçerken rol uyumsuzluğunun ve geri bildirim asimetrisinin adayların zamanını nasıl tükettiğini eleştiriyor
- Hop.NS, “Senior Elixir Developer” pozisyonu için 1 haftalık trial contract yürüttü; ancak gerçek görev TypeScript tarayıcı eklentisi bakımı ve UI özelliği eklemekti
- trial week’in başlarında Slack, GitHub ve tasarım şablonu erişimi almak zaman aldı; yaklaşık 10–12 saat geçtikten sonra eklenti yerelde çalıştırılabildi
- PerhapsMaybe, 5 saatten uzun teknik mülakat yaptıktan sonra bireysel geri bildirim vermeyi reddetti; ancak bir hafta sonra aday deneyimi anketi göndererek yalnızca adaydan geri bildirim istedi
- Şirketler uzun zaman ve emek talep ediyorsa, rol tanımında doğruluk, kişiselleştirilmiş ret gerekçesi ve adaya saygı da sunmalı
Hop.NS: Elixir pozisyonundan tarayıcı eklentisi görevine dönen trial week
- İş arayan kişi, LinkedIn’de eski bir çalışma arkadaşının çalıştığı Hop.NS’in iş ilanını görüp başvurdu
- Şirket adı ve bazı ayrıntılar hukuki sorunlardan kaçınmak için değiştirilmiş adlardır
- Geçmişte 1 haftalık take-home project isteyen ve bu süre için ödeme yapan bir şirketti
- İlan Senior Elixir Developer içindi; CTO ile yapılan görüşmede de Elixir geliştirici rolü, ekip ve süreçler konuşuldu
- CTO, 1 haftalık trial contract boyunca “işe alınırsa yapacağı işi” yapacağını söyledi
- Sözleşme belgeleri sorunsuz ilerledi ve trial week pazartesi 09:00’da başladı
1. Gün: Erişim sorunları ve gerçek görevin açıklanması
- İlk gün geçici şirket e-posta kimlik bilgileri alındı; ancak Slack workspace’e girilemiyordu ve yalnızca yöneticiyle iletişime geçilmesini söyleyen bir mesaj çıkıyordu
- İletişim kanalı olmadığı için LinkedIn üzerinden şirket içindeki tanıdığına mesaj atıp erişim izni istemesini rica etti
- 40 saatlik sözleşmenin 2–3 saati Slack erişim sorunuyla harcandı
- Ardından GitHub erişimi de ek talepler ve beklemenin sonunda alınabildi; repository clone edilebilir hale geldi
- Gözetmen Güney Amerika’da olduğu için görev açıklama görüşmesi 18:00’e ayarlandı; o zamana kadar Elixir codebase’ine bakıp küçük bir düzeltme PR’ı açtı
- Akşam görüşmesinde trial week görevinin TypeScript tarayıcı eklentisi bakımı ve yeni özellik ile UI tasarımı eklemek olduğu ortaya çıktı
- İş arayan kişi bu alanda deneyiminin az olduğunu teyit etti; ancak sorumlu kişi görevin bu olduğunu söyledi
- Sorumlu kişi “backend işleri zaten tamamen bitti, endişelenmeye gerek yok” dedi
- İş arayan kişi, istediği backend/Elixir işinin zaten bittiğini ve istemediği frontend ağırlıklı bir işi yapmak zorunda kaldığını düşündü
2. Gün: Çalıştırma ortamını kurma ve rol uyumsuzluğunu doğrulama
- İkinci gün tarayıcı eklentisini çalıştırıp anlamak için Google Chrome kurmak gerekiyordu
- İş arayan kişi normalde Safari ve Firefox’u tercih ediyor, Chrome kullanmaktan kaçınıyordu
- Yerel build ve çalıştırma yöntemini anlamak birkaç saat sürdü; ek kimlik bilgileri ve erişimler almak için başkalarıyla sürekli iletişim kurması gerekti
- Kendisine referans olan tanıdığıyla yaptığı konuşmada, trial week görevinin adayın uzmanlık alanından tamamen farklı olup olamayacağını sordu
- Tanıdığı, adayların comfort zone dışına çıkarıldığı durumlar olabildiğini; ancak bir backend geliştiriciye tamamen frontend işi verilirse bir sorun olduğu anlamına geldiğini söyledi
- Aynı durumda kendisi olsa hemen bırakacağını da ekledi
- İş arayan kişi, kendisini tavsiye eden iki kişiye duyduğu saygı nedeniyle sürece devam etmeye karar verdi
- İşe alıma özel Slack kanalında “işe alınırsa bu projeye devam edip etmeyeceğini, yoksa başka işler mi yapacağını” sordu; yanıt “her zaman böyle olmuyor” oldu
- Tasarım şablonunu almak için yine sorumlu kişinin peşine düşmek zorunda kaldı ve trial week’in 40 saatinden 10–12 saati geçtikten sonra tarayıcı eklentisini yerelde çalıştırabildi
3. Gün: Görev kapsamının genişlemesi ve trial’ın sonlandırılması
- Üçüncü gün çalışma biçimini ve yapılması gerekenleri bir ölçüde anlamıştı; ancak tarayıcı eklentisi debug bilgisi hâlâ yetersizdi
- trial week’in ortasında, üçüncü gün öğle saatlerinde şirket görev kapsamını ayrıca genişletti
- İş arayan kişi, görevin işe alım sürecinde anlatılanlarla hiç uyuşmadığını uzun bir mesajla dile getirerek itiraz etti
- İş tanımında TypeScript ve tarayıcı eklentisiyle ilgili hiçbir şey yoktu
- Kendisi birçok kez “backend-and-ops” eğilimli bir mühendis olduğunu vurgulamıştı
- Bu görevin hem kendi zamanını hem şirketin zamanını boşa harcadığını düşünüyordu
- Hemen bırakmamasının tek nedeninin, kendisini tavsiye eden tanıdıklarına duyduğu saygı olduğunu belirtti
- CTO, “kültüre uygun olup olmadığını” görmek istediklerini söyledi; şirketin yanlış bir şey yaptığını düşünmediğini belirterek yazıyı yayımlamamasını rica etti
- Hop.NS, acı verici geçen yaklaşık 20 saatlik çalışma için ödeme yaptı
- 3–4 hafta sonra CTO, LinkedIn üzerinden Staff Software Engineer pozisyonuyla ilgilenip ilgilenmediğini sordu; iş arayan kişi hâlâ bait-and-switch taktiği kullanıp kullanmadıklarını sordu
PerhapsMaybe: Uzun mülakattan sonra geri bildirim yok, ama anket isteniyor
- PerhapsMaybe’de Software Engineer with Elixir pozisyonu açıktı ve şirkette tanıdığı kişiler olduğu için başvurdu
- Bir tanıdığı başvurusunu, bu pozisyonun hiring manager’ı gibi görünen VP of Infrastructure’ın önüne taşıdı; ancak süreç hızlı ilerlemedi
- Başvuru bilgileri 27 Mayıs 2026 tarihinde gönderildi
- İşe alım ekibinden ilk temas 11 Haziran 2026 tarihinde, iki haftadan uzun süre sonra geldi
- LinkedIn’de VP’ye davet gönderdikten sonra recruiter iletişime geçti
- VP ile yapılan 1 saatlik görüşme iyi geçti ve role ilgisi daha da arttı
- Ardından teknik mülakat takvimi ayarlandı; tüm mülakat 5 saat 30 dakika sürecek şekilde planlandı
PerhapsMaybe mülakat yapısı ve ret bildirimi
- Mülakat bir günde yapıldı; oturumlar arasında 30 dakika ve 2 saatlik aralar vardı
- Üç bölümden oluşuyordu
- Systems Design 1 saat: Senkron ödeme geçidi kullanan asenkron ödeme sistemi tasarımı
- Coding Interview 1 saat: cross product ve tuş takımı üzerinde satranç taşı hareketi gibi LeetCode benzeri görevler
- Technical Deep Dive 1 saat: Geçmiş projesi olan Ultravisor’ın teknik ayrıntılarını açıklama
- İş arayan kişi, coding interview’ün ikinci görevinde big-O karmaşıklık analizinde hata yaptı; ancak genel olarak çözümünün iyi olduğunu düşündü
- Technical Deep Dive’da kendisi iyi geçtiğini düşündü; ancak karşı tarafın etkilenmediği ya da başka bir şey beklediği hissine kapıldı
- Mülakattan sonraki ikinci günün sonuna doğru recruiter’dan güncelleme istedi ve ret bildirimi aldı
- Ret e-postasında “başvuru sayısı yüksek olduğu için bireysel geri bildirim sağlamıyoruz” cümlesi yer alıyordu
Aday deneyimi anketinin yarattığı geri bildirim asimetrisi
- Retten bir hafta sonra PerhapsMaybe Hiring Team Candidate Experience Survey e-postası gönderdi
- E-posta, işe alım sürecinin verimli olup olmadığını ve aday deneyiminin iyi geçip geçmediğini kontrol etmek istediklerini söylüyor; son mülakat deneyimi hakkında dürüst geri bildirim ve iyileştirme noktaları istiyordu
- İş arayan kişi, şirketin yaklaşık 5 saatlik kayıt ve otomatik toplantı notlarına sahip olma ihtimalinin olduğunu düşündü
- Kendisine toplantı notları için AI kullanmasının yasaklandığını belirtti
- Şirketin 3–4 cümlelik kişiselleştirilmiş ret gerekçesi sunmazken, adaydan süreç iyileştirme geri bildirimi istemesini eleştirdi
- İş arayan kişi, aday değil de işe alım sürecini değerlendiren bir contractor gibi muamele gördüğünü düşündü ve contractor ücretiyle fatura göndermek için billing details istedi
İşe alım piyasasına eleştiri ve istisnai olumlu örnek
- İş arayan kişi, mevcut işe alım piyasasının bozuk olduğunu ifade ediyor
- Bazı recruiter’ların başvuru sürecinde LLM kullanımını eleştirdiğini belirtiyor
- Başvuru formlarında “Neden XYZ’de çalışmak istiyorsunuz?”, “XYZ’de çalışmanın en heyecan verici yanı nedir?” gibi soruların sıkça yer aldığını eleştiriyor
- İş arayan kişi, şirketin ürününü şirkete yeniden satıyormuş gibi anlatmanın kendi işi olmadığını düşünüyor
- İlgi duyduğu işi yapmak ve bunun karşılığında para almak istediğini belirtiyor
- Şirket ürününe gerçekten heyecan duyabilecek kişilerin yalnızca kurucular olduğunu; IPO sonrasında hissedarların da yalnızca değer artışı istediğini ifade ediyor
- İstisna olarak Fresha başvuru sürecinde Christine Wong olumlu bir örnekti
- Ret nedeni “coding agents deneyimi eksikliği” idi
- Christine Wong, kişiselleştirilmiş geri bildirimi doğrudan iletmek için bir görüşme ayarlamayı istedi
- İş arayan kişi, adaylara saygı gösteren gerçek bir insan görmenin iyi geldiğini ve bu deneyim için minnettar olduğunu belirtiyor
1 yorum
Lobste.rs yorumları
Adayı güvenli alanının dışına itmekten bahsetmeleri, istedikleri kişiyi seçmek için bir bahane yaratıp diğer unsurları görmezden gelecekleri anlamına geliyor gibi geliyor.
Bir backend geliştiricisine tamamen frontend işi verip sonra “kültür uyumuna” bakacaklarını söylemek, balığı ağaca tırmanamıyor diye suçlamak gibi.
Çalışanlar, en azından kendi ekipleri için, ekibe kimin alınacağını ve kimin çıkarılacağını kontrol etmedikçe bu tür oyunlar devam edecek gibi görünüyor.
Bu yazının yazarına pek katılamadım.
Kurumsal bir ortamda erişim yetkisi almak ya da farklı saat dilimindeki biriyle konuşmak için bir gün beklemek o kadar da şaşırtıcı değil; kişinin böyle durumlara nasıl tepki verdiği de kültür uyumu için iyi bir sinyal olabilir.
En acil işin önceden tanımlanmış rol kapsamının dışında olması da şaşırtıcı değil; kendi alanının dışına çıkıp çalışabilen bir aday, şirket için yalnızca belirli bir kapsamda kalan birinden daha değerlidir.
Elbette uzmanlık alanının dışındaki bir işi verince ilerleme yavaş, sonuç da daha kötü olur; ama şirketin bunu doğrudan reddetmeye tercih etmesi olası.
İşe alım görevlisinin mülakatı ayarlamasının haftalar sürmesi ya da LinkedIn’den başkan yardımcısına yazınca sürecin hızlanması da kurumsal ortamda tuhaf değil. Ne zaman başkan yardımcısına ulaşmak gerektiğini bilmek de işin bir parçası.
Adaya geri bildirim verilmezken işe alım görevlisi geri bildirim istediyse, akılda en çok bunun kaldığını söylemek başlı başına iyi bir geri bildirim olabilir.
Beni en çok rahatsız eden şey, en üstte üstü çizilmiş “bitch” ifadesiydi. Bir iş arkadaşına ya da potansiyel iş arkadaşına böyle hitap etmek kesinlikle kabul edilebilir değil. Fikir ayrılığı olabilir, ama cinsiyeti hedef alan kişisel saldırı olmaz.
İş ilanı tamamen backend işini anlatıyordu ve ben de neredeyse yalnızca backend ve sistem operasyonları yaptığımı söylemiştim.
Buna rağmen tamamen backend işi teklif edip birdenbire hiç bilmediğim bir görev veriyor, en fazla 32 saat içinde “sistemin geri kalanıyla uyumlu tasarıma” sahip çalışan bir çözüm bekliyorlarsa, bunu deneyimime ve bilgime saygısızlık dışında yorumlayamam.
10 yıldan uzun süredir backend geliştiricisiyim; bunun yaklaşık 7 yılında gözlemlenebilirlik ve performansla uğraştım. Frontend’i görece fazla yaptığım tek dönem ise 8 yıl önce mevcut bir Vua uygulamasına özellik eklediğim zamandı.
Deneyimimi ve bilgimi böyle bir görevle değerlendirmeye çalışıyorlarsa, beni istemedikleri sonucuna varmaktan başka çarem yok. Bunu kibarca söylemek yerine anlamsız bir işi dayatıp beni uğraştırmaları neredeyse hakaret gibi.
İşe alım takviminin haftalar sürmesi de bana şaşırtıcı geldi. Çünkü o şirketten kıdemli/principal/staff seviyesinde bir mühendisin iki hafta önce ilgili başkan yardımcısına benim için referans olduğunu ve o başkan yardımcısının da bunu doğruladığını biliyordum.
Geri bildirim verdim; ayrıca işe alım görevlisinden işe alım süreci danışmanlığı ücreti kesebilmem için fatura bilgilerini de istedim.
Neyse ki geri bildirim almanın başka yolları da var. AB’de olduğum için GDPR sayesinde işe alım sürecimle ilgili tüm notları ve ayrıntıları talep edebilirim.
Kurumsal dil, hayatın tüm büyük meselelerinde taban tabana zıt düşünen iki kişinin bile şirket hedefleri doğrultusunda birlikte iyi şekilde ilerleyebilmesi için vardır.
Ben de benzer okudum. Bunun arkadaşlar arasında iç dökme yazısı olduğunu anlıyorum, ama mülakat aşamasında bu tavrın en ufak bir izi görünseydi muhtemelen mülakatı reddederdim.
Kendi uzmanlık alanının dışında çalışmaya istekli olmak yalnızca işveren için değerli değildir; kişinin kendi alanında kalmakta ısrar etseydi göremeyeceği kariyer ve öğrenme fırsatlarını da açabilir.
Önemli olan, bu sınırın nerede olduğunu iletişimle netleştirip beklentileri ve takvimi doğru ayarlamaktır; bunu yapabilmek de mülakatta güçlü bir sinyaldir.
Yine de denge gerekir. Kariyer yönünüz zaten çok netse ve istenen proje sizi o yöne götürmüyorsa, zamanınızı başka yerde kullanmak daha iyi olabilir.
Ama benim hedeflerimle işverenin hedefleri çatışıyor diye bunu kişisel bir hakaret olarak algılamaz ya da köprüleri yakma riskini almazdım.
Sadece bu yazıya bakarak işe almazdım; çocukça ve profesyonellikten uzak hissettiriyor.
Yakınlarda oldukça ilginç bir şey yaşadım. Bir şirketin işe alım görevlisi bana ulaşıp konuşmak isteyip istemediğimi sordu; şirketin ürününü her gün kullandığım için kabul ettim.
Görüşme başlayınca işe alım görevlisi “Peki ne arıyorsunuz?” diye sordu; oysa ben hiçbir şey aramıyordum. Bana onlar yaklaştığı için benim şirketi ikna etmem değil, şirketin beni ikna etmeye çalışması gerektiğini düşünmüştüm.
Yine de bunun sıradan bir laf olduğunu düşündüm ve şirketin ne yaptığı gibi konuları yaklaşık bir saat konuştuk. Sonunda, teklif aşamasına gidebilecek üç teknik mülakattan oluşan sürece devam etmek isteyip istemediğimi sordu; istikrarlı bir işi olan görece avantajlı bir konumda olduğum için ilginç olabilir diye kabul ettim.
İşe alım görevlisi görüşmeden sonra e-posta göndereceğini söyledi ve vedalaştık.
Ama neredeyse bir hafta boyunca e-posta gelmedi. Sonunda ben, acaba unuttunuz mu diye e-posta attım; birkaç gün sonra bu kez sürece devam etmemeye karar verdiklerini söylediler.
Başvuru bile yapmamışken ret bildirimi almış gibi oldum; tuhaf bir şekilde incitti.
Ama iş burada bitmedi. Birkaç hafta sonra büyük bir programlama konferansına katılmıştım; aynı işe alım görevlisi, kendilerinin de orada olduğunu, akşam yemeğine çıkmak ve mülakat sürecini yeniden başlatmayı düşünüp düşünmediğimi sormak için e-posta attı.
Masrafları onlar karşılayacağı için yemeğe gittim ve şirketten birkaç mühendisle keyifli bir sohbet ettim. Ama süreci durduran ben değilken yeniden başlatmanın neden bir seçenek olduğu, bunun neden benim sorumluluğummuş gibi sunulduğu tuhaftı.
Bu tür etkileşimlere hazırlıklı olmak için yaygın okunan bir kurumsal BT ortamı rehberi gibi bir sayfaya ihtiyaç olduğunu düşünüyorum.
Orada olanları savunmaya çalışmıyorum, ama birçok kişi gerçeği pek bilmiyor.
İçeride de dışarıda da gecikmeler olur. Erişim yetkisi alma sürecinde bir gün kaybetmek normal ve beklenebilir bir şeydir.
Süreçler yavaşlar; kişi, bireysel başarı ve başarısızlıklara değil genel metriklere bakan bir mekanizmadaki küçük bir dişliye dönüşür.
Birçok yerde toplu olarak geri bildirim vermeme politikası vardır. Çünkü olası kayıp dava riskidir, olası kazanç ise yoktur.
İletişim çoğu zaman kötüdür; iş testlerinin değişmesi ya da atlanması da olur.
Böyle bir rehber beklentileri hizalar ve bu gündelik gerçeklerle uğraşmak istemeyen kişileri elemek için de işe yarayabilir.
O süre içinde bitirebilmek için süreç dışındaki insanlarla ve üçüncü taraf iletişim kanallarıyla erişim yetkisi almam gerekiyordu.
Normal işte bekleyebileceğiniz için gecikme normal olabilir; ama işe alım süreci benim gündelik işimi etkilememeli. Bu büyük bir fark.
Geri bildirim vermeme politikası da, AB’de olduğum ve GDPR kapsamına girdiğim için tüm ayrıntılarımı ve iç notları talep edebilirim.
Sonuçta onların elde ettiği tek şey, profesyonel görünmemek ve tüm bu sürecin meşru bir işe alımdan çok işe alım süreci danışmanlığı gibi hissettirmesi.
Beklentileri hizalamak ve insanları elemek sorun olmayabilir, ama ben daha fazla zamana ihtiyacım olduğunu söylersem aynı standardın onlara da uygulanacağından ciddi şekilde şüpheliyim. Bu yüzden haksız bir avantaj doğuyor.
Geriye dönüp bakınca belki de hiçbir şey yapmamalı, erişim yetkisi için bastırmamalı, hafta sonuna kadar makinelerinin çalışmasını bekleyip sadece ücretimi almalıydım. Öyle olsaydı daha az kafaya takardım.