LeetCode tarzı mülakatlardan bıkan insanlar
(nelson.cloud)- Robinhood'dan 2023 Kasımının sonlarında sağlık sorunları nedeniyle ayrıldıktan sonra çeşitli işe alım süreçlerinden geçerken, LeetCode tarzı değerlendirmelerin gerçek yazılım mühendisliği işiyle örtüşmediğini hissetti
- Birçok şirketin Google, Facebook/Meta, Amazon gibi büyük teknoloji şirketlerinin yöntemlerini takip ederek benzer mülakatları tekrarladığını düşünüyor
- Mühendislerin normalde aranabilir bilgiyi ezberlemeye gerek olmadığını söylediğini, ancak mülakatlarda akla hemen gelmesi zor olan aranabilir bilgilerin sınav sorusu gibi sorulduğunu eleştiriyor
- Bu tür mülakatlarda hem başarı hem başarısızlık yaşadığını, memnuniyetsizliğinin temelinin başarısızlık deneyiminden çok önceki pratik iş deneyimine dayandığını söylüyor
- AWS, Kubernetes, Ruby on Rails deneyimi olan bir mühendis arayan ve gereksiz bilgi yarışması tarzı sorular sormayan şirketler varsa kendisiyle iletişime geçebileceklerini ekliyor
LeetCode tarzı mülakatların gerçek işle örtüşmediği noktalar
- 2023 Kasımının sonlarında sağlık nedenleriyle Robinhood'dan ayrıldıktan sonra çeşitli şirketlerle mülakat yaptı
- İşe alım süreçleri çeşitli nedenlerle ilerlemedi, ancak özellikle tekrar eden LeetCode tarzı mülakatlardan yoruldu
- Bu tür mülakatların gerçek yazılım mühendisliği sorumluluklarını yeterince yansıtmadığını düşünüyor
- Birçok şirketin, Google, Facebook/Meta, Amazon gibi büyük şirketler kullandığı için aynı değerlendirme yöntemini benimsediği görülüyor
Bilgi yarışması tarzı değerlendirme ile pratik deneyimin çatışması
- Normalde Google'da kolayca bulunabilecek bilgileri ezberlemeye gerek olmadığını söyleyen mühendisler var
- Ancak mülakatlarda, aranınca bulunabilecek olsa da anında akla gelmesi zor olan şeyler sorulabiliyor; bunu çelişkili buluyor
- Bu soruna dair net bir çözüm yok, ancak sorunun kendisinin açık olduğunu düşünüyor
- Bu tür mülakatlarda hem başarılı hem başarısız oldu; bu görüşünün, başarısızlık oranından çok önceki profesyonel deneyiminden etkilendiğini söylüyor
- AWS, Kubernetes, Ruby on Rails deneyimi olan bir yazılım mühendisine ihtiyaç duyan ve bilgi yarışması tarzı mülakat yapmayan şirketler varsa kendisiyle iletişime geçebileceklerini belirtiyor
- Birlikte okunabilecek yazı olarak Re-imagining Technical Interviews: Valuing Experience Over Exam Skills bağlantısını paylaşıyor
1 yorum
Hacker News yorumları
Hayal kırıklığını anlıyorum ama sonuçta bu tür mülakatların da bir amacı olduğunu düşünüyorum. Çok iyi olmasalar bile yeterince işe yararlar ve genelde yanlış pozitiften çok yanlış negatif ürettikleri için şirket açısından mantıklıdır
Akıllı birinin elenmesinin maliyeti düşüktür; ama yanlış kişiyi işe alırsanız bunu anlamak, işten çıkarmak ve yeniden işe alım yapmak için aylar harcamanız gerekir, bu da pahalıdır. Ancak aday için son derece acı verici bir süreçtir; harika bir yazılım mühendisi bile gerilebilir, bir şeyi kaçırabilir ya da şanssız bir gününde olabilir ve birkaç kez elenebilir. Mülakat, hayattaki değerinizin nihai değerlendirmesi değil, sadece kaba bir araçtır; o yüzden geçip gitmesine izin vermek gerekir
“Tuzak” sorular aptalcadır ama adayın temelleri bilip bilmediğini görmek ve aynı zamanda şirketimizin nasıl bir yer olduğunu göstermek gerekir. Örneğin “Argümanları değiştirebilir miyim?” diye sormak ya da “strlen’in 0 baytını dahil edip etmediğini hatırlamıyorum, bu yüzden 1 ekleyeceğim; normalde bakardım” demek iyi bir işarettir. Sorular atoi ya da “bir deste kartı karıştırma” gibi temel ama fizzbuzz kadar tamamen önemsiz olmayan seviyedeydi. En iyi işe aldığımız kişilerden biri temel bir hata yapmıştı; amaçlandığı gibi çalışıp çalışmayacağını sorunca “Ben tam bir aptalmışım” dedi ve hemen düzeltti. Mülakatta böyle bir üslup uygun olmayabilir ama biz bunu güçlü bir olumlu sinyal olarak gördük. Buna karşılık, bir dizgeyi ayrıştırıp tamsayı döndürme sorusunun zaten kütüphane fonksiyonu olduğu için haksız olduğunu sonuna kadar savunan bir aday da vardı; oysa sistemimizin bir kısmı gerçekten kütüphanesiz gömülü bir ortamdaydı
Okul ve üniversitelerdeki berbat sınavlar gibi önce hafızayı test eden yaklaşımın taklit edilmemesini isterim. Gerektiğinde bir şeyi anında hatırlamakta çok zorlanıyorum; eminim yalnız değilim. Android geliştirici mülakatı yaparken soru sorup nasıl düşündüklerine baktım, tüm yanıtların doğru olmasını beklemedim. Android’e dair temel bir anlayışları olup olmadığına baktıktan sonra evde küçük bir uygulama yapmalarını istedim
Sonuçta pozisyonun doldurulması gereken işe alım süreçlerinde, yanlış negatifler arttıkça yanlış pozitif işe alma olasılığı da artar. Uç bir örnekle, dünyada o işe uygun yalnızca bir kişi varsa ve siz o kişiyi yanlış negatif olarak elerseniz, geriye kalan tek seçenek yanlış kişiyi işe almaktır
Sorun zeka eksikliği değil; algoritma problemlerini iyi çözse de kişinin yazılım mühendisi olmaması ya da pozisyonun gerektirdiği becerilerden yoksun olmasıdır. Bulmaca tarzı mülakatlarla çok kişinin alındığı bir ekipte çalışıyorum; herkes zeki ama yazılım mühendisi değiller ve bu fark büyük ölçüde ortaya çıkıyor
Birisi çözdüyse, gerçekten en iyi çözümü yeniden türetmiş olmasından çok, alıştırma çözerken aynı ya da benzer bir problemi görmüş olma ihtimali çok daha yüksektir
Bir keresinde oldukça hoşuma giden bir mülakata girmiştim; bir bankaydı. Aceleyle yazılmış, dağınık ama özellikle anlaşılmaz hale getirilmemiş bir kod verdiler ve olabildiğince iyi refactor etmemi istediler
Mülakatçı yanımda oturup tüm süreç boyunca konuştu; fiilen adayın yönlendirdiği pair programminge yakındı. LeetCode mülakatlarından sonra ferahlatıcıydı. Elbette o banka kullandığı teknolojiyi tam olarak biliyordu ve yeni teknoloji öğrenme becerisini ölçme ihtiyacı daha azdı; bu yüzden bu yöntem mümkündü. Onlar için sürdürülebilir kod yazıp yazamadığım, isimlendirmeyi doğru yapıp yapmadığım ve iş arkadaşlarıyla iletişim kurup kuramadığım daha önemliydi
İlginç olan, temel sorularda neredeyse başarısız olan birinin kod incelemede derin uzmanlığını gösterecek kadar iyi performans sergilediği durumların olması. Mülakat, bir insanın iş yapma becerisini göstermek için oldukça kötü bir araçtır; ama kişi problemi hem geniş hem dar açıdan görebiliyor ve kodlamayı da yeterince yapabiliyorsa, bunu genelde başarılı sayarım
LeetCode tarzı mülakatlar muhtemelen iki işe yarıyor. Birincisi, yazılım mühendislerinin ücretlerini ve iş değiştirebilirliğini baskılamanın bir aracı. İş değiştirmek için bir iki ay çalışmak gerekiyorsa kim kolayca geçer ki?
Şansınız yaver gitmez de çok hazırlanmış bir mülakatçı LeetCode hard seviyesinde bir bomba atarsa, o şirkete bir yıl boyunca yeniden başvurmanız bile zorlaşır. İkincisi, herkese benzer ve net bir hedef verildiğini iddia ederek sürecin önyargılarını perdelemenin bir yolu olur. Aynı okuldan, aynı cinsiyetten, aynı ırktan biriyseniz aynı soru verilse bile ipucu alabilir, sözdizimi hatalarınız görmezden gelinebilir ve en iyi yaklaşıma ulaşamasanız bile “iletişim” üzerinden güçlü bir işe alım kararı çıkabilir. Hoşlarına gitmeyen biriyseniz zor bir soru verip mülakat boyunca sessiz kalmaları yeterlidir. Şirket için kabul edilebilir bir gürültüdür ama birey için yüz binlerce dolarlık ücret fırsatını kaybetmek demektir. FAANG mülakatlarına girdim, mülakatçı da oldum; düşük standartlarla işe alınan insanları görürken aynı zamanda quadtree ya da sayı teorisi gibi saçma sorular yüzünden mükemmel mühendislerin fırsat kaçırdığını da gördüm
Adil bir mülakatçı varsayımıyla, bu yöntem özgeçmişinde ünlü isimler yazmayan adaylara da yeteneklerini gösterme fırsatı verir. Bilgisayar bilimi diplomam olmadan elde ettiğim bazı fırsatlar, whiteboard mülakatı olmasaydı asla olmazdı. Bir mülakatçının arkadaşını işe almak için prosedürü bilerek ters yüz etmesini engellemenin bir yolunu hayal etmek zor
Birçok şirketin adil ve bir ölçüde gerçek dünya problemleriyle ilgili tasarlanmış soru bankaları var. Mülakat yaptığım şirketler de genelde böyleydi; birebir gerçek LeetCode soruları olmasa da sonuçta izole kodlama problemleri olduğu için LeetCode tarzı sayıyorum. Bu yöntemi iyi işleten şirketlerin mülakatları oldukça iyiydi. İyi şirketler ve mülakatçılar yalnızca nihai koda değil daha fazlasına bakar; işe alım puanını da ölçekle vererek ikili değerlendirmeyi azaltır
Gerçekçi olmak gerekirse yalnızca fizzbuzz bile adayların %75’ini eliyordu. Baskı altındayken kod yazamayan çok kişi var; kopyala-yapıştırla zorla idare edenler de var. Bu insanlar hiçbir iş yapamaz değil; ama yavaştırlar, tuhaf soyutlamalar üretirler ve kullanılabilir bir sonuç almak için çok zaman harcatırlar. Üstelik onlar için de ortada yüz binlerce dolar olduğu için aynı şekilde itiraz ederler
Şirket açısından mantıklı. Çünkü dikkati dağılmayan ve fazla mesai yapabilecek çalışan ister
Günümüz teknoloji işe alım pratiklerine yönelik pek çok haklı eleştiri var; ama “ruhumu satmadan aşırı zengin olamıyorum” şikâyeti pek ikna edici değil
Yazılım mühendisi seçerken önemli olan bilgi değil, problem çözme becerisi ve probleme dair zihinsel model kurma yeteneğidir
Aday o problemi daha önce görmediyse ve mülakatçı neye bakması gerektiğini anlıyorsa, whiteboard mülakatı bu yeteneği değerlendirmek için iyi bir yöntemdir. Ama Goodhart yasasında olduğu gibi, ölçüt hedef haline geldiğinde artık iyi bir gösterge olmaktan çıkar. Problem çözme ya da modelleme becerisi zayıf olan insanlar da yüksek maaşlı yazılım işleri istediği için LeetCode’a abanır; zamanla bu kişiler mülakatçı olduğunda da kendilerine yapıldığı gibi mülakatı bir hafıza testi gibi yürütürler. Yine de şirketlerin kısıtları, adayların zamanını boşa harcamayı azaltma ihtiyacı ve İK’nın sevdiği tutarlı değerlendirme formlarını koruma koşulları altında daha iyi bir mülakat yöntemi önerildiğini henüz görmedim; bu yüzden bir süre daha kullanılmaya devam edecek
Yazılım üretme işine daha yakındır. LeetCode gerçek işten çok uzakta ve performansın gerçek uygunlukla korelasyonu da çok zayıf
Delik bir kova ama şirket mevcut durumdan memnun; geliştiriciler de LeetCode’a abanmaya devam ediyor. Yakında değişecek gibi görünmüyor; ama yeni iş ararken bu tür mülakatları reddedebilecek durumda olduğum için neyse ki şanslıyım
Bir arkadaşım teknik mülakat sırasında birden konuşmayı kesip kalkıp gitmişti. Şirkettekiler “Ne oldu, iyi gidiyorsunuz!” diye peşinden gitmişler ama o kadar morali bozulmuş ki artık ilgilenmediğini söylemiş
Çoğu kişi için eğlenceli bir meslek olmalıydı; üzücü
Ama mülakatın ortalarına doğru whiteboard çıktı, ekip arkadaşları içeri girip kalemle temel şeyleri implemente etmemi istedi; süreç ilerledikçe giderek daha düşmanca ve kaba hale geldi, ritüelleştirilmiş taciz gibi hissettirdi. Teknik açıdan önemsiz bir sonuç üretirken hakaret ve husumete dayanıp dayanamayacağımı test ediyor gibilerdi. Sonunda mülakatı durdurup “Nasıl çalıştığınızı gördüm, bu yüzden burada çalışmak istemediğime karar verdim. Fırsat için teşekkürler; birbirimizin zamanını boşa harcadığımız için üzgünüm” dedim ve çıktım. CEO otoparka kadar peşimden gelip bunun neden olduğunu sordu; adayın mülakat sırasında karar verebileceği gerçeği onu gerçekten şoke etmiş gibiydi. İnsanlar iş mülakatının iki yönlü olduğunu unutuyor. O günden sonra, çalışabileceğim bir şirketin her yönünü inceleme hakkım olduğunu ve süreçte olumsuz bir şey görürsem taviz vermek zorunda olmadığımı anladım. Ertesi gün rakip şirkette bugün hâlâ iyi arkadaşım ve meslektaşım olan insanlarla tanıştım; demek ki doğru kararmış. Bu meslek eğlenceli, ama o eğlence bir çiftlik gibi hasat edilip sömürülürse diğer köleleştirme biçimlerinden farkı kalmaz
“Sanırım bugün benim günüm değil ve mülakatı bırakmak istiyorum” dedim; ondan sonra kalan süre boyunca beni tutmak için epey uğraştılar. Aday gitmek istiyorsa bırakmak gerekir diye düşünüyorum
Aradan 5 yıl geçmiş olmasına rağmen hâlâ bu tür mülakatları reddediyorum ve o süreci bir daha yaşamak istemiyorum. İnsanlara bir saatlik tekmeleme oyunu gibi davranan kişiler tarafından taciz edildim ve alaya alındım; artık onlarla muhatap olmak istemiyorum.
Haber verilmeyen çok sayıda LeetCode mülakatı olduğu için LinkedIn [1] ve GitHub [2] profillerimde neyin kabul edilebilir olup olmadığını açıkça yazdım. “Mülakat sırasında her türlü canlı kodlamaya veya çevrim içi kodlama testine karşı kişisel bir politikam var; rekabetçi programlamadan hoşlanmıyor ve buna katılmıyorum. Bunun yerine makul hedefleri ve teslim tarihleri olan çevrim dışı kodlama ödevlerini, yazılım mimarisi ve tasarımı ile ilgili teknolojiler üzerine derin teknik tartışmaları memnuniyetle yaparım.”
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
Yine de ödev tipi mülakatlarda kopya/aldatma davranışının yaygın olduğuna dair söylentiler var; bu yüzden bunu kullanmak isteyen işveren sayısının hızla azalmasından endişeleniyorum
Şeytanın avukatlığını yaparsak, LeetCode ortalama bireysel katkı sağlayıcı işe alımında iki şeyden birini ya da ikisini birden elemek için kullanılıyor. Çalışkan mı; yani çok sayıda problem çalışıp çözümleri ezberleyerek tekrarlayan biri mi? Ya da zeki mi; yani LeetCode yapmasa bile temel bilgileri bilen ve geçmiş bilgisini sentezleyerek yeni sorulara cevap verebilen biri mi?
Hiçbir bilgi yoksa, LeetCode problemini geçemeyen birinin bu ikisinden de olmama ihtimalinin daha yüksek olduğunu düşünüyorum. Kodlama gerektiren bir rolse, adayın mülakatçının biraz yönlendirmesiyle bile olsa kolay-orta seviyede bir LeetCode problemini çözebilmesi gerektiğini düşünüyorum. Aslında şirketler, aday daha kıdemli oldukça veya daha özel rollere başvurdukça LeetCode becerisine verdikleri ağırlığı azaltıyor. Hata düzeltme, sistem tasarımı, davranışsal mülakatlar, ödevler, genel kültür tarzı sorular, arka plana özel sorular vb. de çok; giriş seviyesi üstü işe alımlarda LeetCode her şey değil. En iyi mühendisi sihirli şekilde seçen bir araç değil, işe alım komitesinin kullandığı sinyallerden yalnızca biri
Bütçe içinde işi sonuna kadar götürme mühendislik becerisini ölçmüyor. İyi ihtimalle kenarda kalan bir ayrıntı; kötü ihtimalle de 19 yaşına daha yakın kişileri tercih eden yaş ayrımcılığının dolaylı göstergesi. Belki de bu sektörün kaliteli yazılım çıkarmakta bu kadar zorlanmasının nedeni budur. Daha iyi bir yöntem, bozuk bir build veya çöken kod gibi başarısız bir durum verip bunu düzeltmesini istemek. Sistemi keşfedebiliyor, hatayı teşhis edebiliyor, nedeni bulabiliyor, bir yama önerebiliyor ve kodlama/yorum stiline uyabiliyorsa gerçekten ihtiyaç duyulan oyuncu odur. Bir branch ve issue tracker olabilir; hata tartışması zaten sürüyor olabilir; yorumlarda elle uygulanması gereken bir patch dosyası olabilir. Yamaya yeni bir hata eklenmiş olabilir ya da benzer ama alakasız bir soruna dokunan bir yem olabilir. Kapatılmış bir hatanın regresyonu olabilir ama birim testi olmayabilir; test olsa bile adayın onu bulması gerekebilir ya da testin kendisi eski ve hatalarla dolu olabilir. Gerçek iş budur. Sonunda “birim testi bozuktu” demekle “nasıl düzgün çalıştırılacağını anlamadığım için geçtim” demek arasında büyük bir tutum farkı vardır; takım oyuncusu olan ikincisidir
Bu yüzden tersine, mevcut rolünde çok iyi performans göstermeyen ama kalan enerjisini LeetCode’a gömen adaylar elde edebilirsiniz
Bir projede sadece birkaç hafta çalışınca bile zeki bir insan gerçekten gereken içgörüleri edinebilir. LeetCode’un ortaya attığı ani bulmacalar, eski dergilerdeki bulmacalara daha çok benzer
Bunu yapabilmenin tek nedeni, daha önce çalışmış olmaktır
2022 olsaydı LeetCode’un en iyi mühendisleri seçen bir araç olmadığına katılırdım; ama 2024’te, problemi doğru çözsen bile yeterince hızlı olmadığın veya ipucu olmadan çözemediğin için daha sık eleniyorsun. Ben bir LeetCode dehası değilim, çalışmam gereken çok fazla şey var ve mülakatlarda LeetCode’un payı yaklaşık %20; yine de bunun iki yıl öncesine göre o kadar kötüleştiğini hissetmiyorum. Sadece şirketlerin beklentileri göğe çıktı ve 15+ yıl deneyimli rolleri 5 yıllık maaşla satın almaya çalışır bir hava var
LeetCode tarzı mülakatlarda pek dile getirilmeyen ilginç bir nokta, bunun bir tür entelektüel kabul töreni olması
Giriş ritüeli ne kadar sert olursa, o gruba girenlerin bağlılığının o kadar arttığı defalarca kanıtlandı
Kapitalist bir şirket programcı işe alırken “doğru cevaba inanan zeki ve birbirine benzer insanlar” ile “rastgele karışmış yetenekli kişiler” arasında hangisi daha iyidir? Cevabınız ikincisiyse idealistsinizdir ve bu görüşün pratikte önemi yoktur. Doğa onu daha zeki ve gerçekçi biriyle değiştirecektir
Son birkaç mülakatta adaylara örnek kod gösterip inceletmiştik. Örnekte her satırda en az bir hata ya da sorun vardı.
Ardından genellikle beyaz tahtada yapılan bir modelleme görevi geliyordu. Junior birinin gerçekten junior rolünü yerine getirip getiremeyeceğini görmek için fizzbuzz tarzı basit bir alıştırma da vardı; ayrıca çalışma zamanı karmaşıklığı veya bellek yerleşimi gibi konularda sohbet başlatmak için dayanak olarak kullanıyorduk. Adayın performansına göre süreç çok etkileşimli ilerliyordu; amaç, bir şekilde elemeden geçmiş sahte adayları ayıklamak ve kültür uyumunu da bir ölçüde hissetmekti.
Saat dilimi ya da telefon numarası doğrulama gibi dağınık bir problem hazırlayıp, Wikipedia belgesini spesifikasyon olarak koyuyorum. Bitince çözümü soruyor ve kod incelemesi yapıyoruz. En iyi senior'lar doğrudan kütüphane kullanıyor. İyi adaylar kendileri yapıyor ama ödünleşimleri açıklayabiliyor. Junior'lar sadece testleri geçirip duruyor.
https://github.com/emilybache/GildedRose-Refactoring-Kata
Adayın sevdiği dille yapmasına izin verdim ve çok etkili bir filtreydi.
Teoriyi çok biliyor gibi görünen ama iş kod yazmaya gelince feci şekilde başarısız olan geliştirici adaylarıyla mülakat yaptığım oldu. fizzbuzz bile uygulayamıyorlardı; bir Senior Java geliştiricisi bakmadan HashMap'i import edememişti.
Matematiğe benziyor. 562 * 1041 için hesap makinesi kullanmak doğru olandır; ama 3 * 7'yi bulmak için hesap makinesi çıkarırsanız uzman olup olmadığınızdan şüphe ederim. Birçok şirket LeetCode mülakatlarını abartıyor, ama dizi manipülasyonu, akış kontrolü ve temel veri yapılarını kullanmayı gösteren canlı kodlama mülakatı, yalnızca deneyimden gelen kas hafızasının olup olmadığını gösterir. Geçmek için graf dolaşma algoritmaları çalışmanız gerekiyorsa, muhtemelen fazla LeetCodevari bir şeydir.
Ama bir programda böyle küçük öğelerden birkaç tane gerekir ve o dünya görüşünde hepsini ezbere bilmeniz beklenir. 562 * 1041 için hesaplama ilkesini, yani nasıl yapılacağını bilmeniz beklenir. Hesapta hata yapabilirsiniz ama uzun çarpma fikrinde hata yapmamalısınız. Bu bağlamda 3 * 7 gibi çarpım tablosundan bir öğeyi unutmuş olmanız sorun değildir. Programcı hesaplamayı organize eden kişidir, hesabı bizzat yapan kişi değil; onu bilgisayar yapar. Graf dolaşma algoritmaları için de çözümü nerede bulacağını bilmenin yeterli olduğuna, tüm çözümleri elinde tutmak gerekmediğine katılıyorum.
Bu insanların hangi durumda elle import etmesi gerekiyordu? IDE yok muydu?
Mülakatçı önyargılarını hicvetti mi, pek emin değilim.