Gerçek Dışı Kodlama Challenge’larının Durdurulması Çağrısı

• Bazı teknik mülakatlardaki gerçek dışı kodlama görevleri, gerçek işle uyuşmayan baskı koşulları yaratıyor ve geliştiricinin pratik iş yetkinliğini doğru biçimde ölçemiyor
• Tek başına ve yüksek baskı altında verilen görevler, iş hayatındaki iş birliği ve destek ortamını yansıtmıyor; belge ya da ekip desteği olmadan eski bir kod tabanını debug etme türü işlere dönüşebiliyor
• Şirketlerin “4 saatlik görev” diye sunduğu şeyler de şirket araştırması, rol gerekliliklerini inceleme ve çıktıyı parlatma eklendiğinde 8-10 saatten fazlaya uzayabiliyor
• Rolle ilgisiz teknoloji yığını görevleri uyum sağlama becerisini ölçme gerekçesiyle sunulsa da, bir Ruby geliştiricisinden PHP debug etmesini istemek gerçek uygunlukla çelişebiliyor
• İşe alım, rastgele yüksek baskılı görevler yerine ilgili teknikler, problem çözme, iş birliği ve gelişim potansiyeline odaklanmalı; aşırı görevler iyi adayları yorup süreçten uzaklaştırabiliyor

---

Gerçek işle uyuşmayan mülakat görevleri

• Bazı teknik mülakatlarda geliştiricilerden birkaç saat içinde legacy PHP debug etme ya da mini uygulama geliştirme gibi görevler isteniyor
• Bu tür tek kişilik görevler, gerçek iş yapış biçimiyle farklılık gösteriyor
  • İşte genellikle ekiple birlikte çalışılır ve gerekli destek alınabilir
  • Belge veya ekip yardımı olmadan eski bir kod tabanını tek başına hızla debug etme durumu, tipik geliştirme ortamıyla örtüşmüyor
• Şirketler bunu “problem çözme becerisi” değerlendirmesi olarak görse de, görev rolün gerçek gereksinimleriyle bağlantılı değilse adayın işe pratik uygunluğunu anlamak zorlaşıyor

Gizli zaman maliyeti ve aday yükü

• Kodlama görevleri için verilen önerilen süre, adayın gerçekte harcadığı zamanı yeterince yansıtmıyor
  • Görevden önce şirketi araştırmak ve rol gerekliliklerini incelemek gerekiyor
  • Teslimi iyi bir duruma getirmek için projeyi düzenlemeye de zaman ayırmak gerekiyor
  • “4 saatlik” bir görev 8 saate, 10 saate veya daha fazlasına çıkabiliyor
• İş ve yaşamı birlikte yürüten geliştiriciler için bu, henüz kazanılmamış bir iş uğruna ücretsiz çalışmak gibi hissettirebiliyor

Uyum sağlama becerisi değerlendirmesinin şaştığı nokta

• İlgisiz teknoloji yığını görevleri bazen “uyum sağlama becerisi” değerlendirmesi diye meşrulaştırılıyor
  • Bir Ruby geliştiricisinden PHP debug etmesini istemek, uyum sağlama becerisinin önemi ayrı olsa da, adayın değerini ölçmek için uygun bir ölçüt olmayabiliyor
  • Belirsiz ve alakasız görevleri hızlıca tamamlama becerisi tek başına kişinin gerçek role uygun olup olmadığını göstermiyor
• Bazı görevler, aday uygunluğunu ölçmekten çok şirketin “elit” standardını sergileme yöntemi gibi hissedilebiliyor
  • Her işe alımda “üst %1” tarzı engeller konduğunda, gerçekte işi iyi yapabilecek deneyimli adaylar bile yapay ve yüksek baskılı koşullar yüzünden süreçten çekilebiliyor

İşe alım görevleri neyi değerlendirmeli

• İşe alım süreci, rol için gerekli somut teknikler etrafında tasarlanmalı
  • Gerçek iş gereklilikleriyle ilgisiz, coding bootcamp tarzı görevlerden kaçınılmalı
  • Problem çözme, iş birliği ve ilgili alanlarda gelişim potansiyeline odaklanılmalı
  • Uyum sağlama becerisi, rastgele görevleri ne kadar hızlı yaptığıyla değil, uzun vadede öğrenebilme kapasitesiyle değerlendirilmeli

[GN⁺]

Hacker News yorumları

• En son ne zaman belgesi de ekip desteği de olmayan eski bir kod tabanında debug yaptın? Her zaman. 300-400 bin satır C++ idi; legacy olması hiç test olmadığı anlamına geliyordu, neredeyse hiç dokümantasyon yoktu ve küçük bir şirkette tek geliştirici olarak on binlerce kullanıcıya hizmeti sürdürürken hataları düzeltiyor, özellik ekliyordum.
  Yakın tarihli bir örnek: Bir yıldan uzun süredir bekleyen çekirdek bir özellik yaması vardı; asıl yazarı artık yoktu ve kodu baştan yazmak ya da yamayı master'a uyacak şekilde yeniden canlandırmak gerekiyordu.
  Bir projeye atlayıp insanları hedefe götürebilme yeteneği kıdemli geliştirici için kesinlikle gerekli bir beceri; problem çözme yeteneğinin test edilmesi gerektiği sonucuna katılıyorum. Ancak teknik mülakatın içeriği role göre değişmeli; junior web geliştiricisine whiteboard'da graf algoritması sormaya gerek yok, ama bir sosyal ağ ürününde kıdemli geliştirici ya da mimarsa bunu derinlemesine anlamalı.

  • "Her zaman" kısmına katılıyorum. Bugün de sistemin çekirdek bir bölümünde debug yaptım; sistemin geri kalanından farklı olarak Python ile yazılmış, 2020'den beri neredeyse hiç güncellenmemiş, yorum da dokümantasyon da yok ve dağıtım sistemi her düşündüğümde ağlamak isteyeceğim kadar bozuk.
    Geçen hafta da aynı şekilde yorum ve dokümantasyon içermeyen, 2020'den kalma Go kodunda debug yaptım; bu da sistemin çekirdek bir parçasıydı ve deliler yazmış gibiydi. Acı verici.
  • 6 ay önce bir aptalın, yani benim yazdığım kodda da debug yapmak zorundayım; nasıl debug edeceğimi hiç hatırlamadığım için fiilen başkasının yazdığı koddan farkı yok.
  • Gerçekten öyle. Bu sorunun olmadığını düşünen mühendisler, bağımlılıkları ve stack'in alt katmanlarını dokunulamaz, katı kara kutular olarak görenlerdir. Gerektiğinde içine girip düzeltebileceğin, hatta özellik ekleyebileceğin şeyler olarak görmek gerekir.
    Sorunu doğru katmanda çözmek için aşağıya inmeye istekli olmak, bence kıdemli mühendisleri ayıran büyük soft skill'lerden biridir. Alt katmandaki bir bug'ı ya da eksik özelliği kendi kodunda sonradan yamayla dolaşmak yerine doğru katmanda düzeltirsen, tüm sistem stack'in yukarısı ve aşağısındaki değişikliklere ve beklenmedik gelecekteki kullanım senaryolarına karşı daha sağlam olur.
    Tersine, bu yaklaşım benimsenmezse kıdemli mühendisler ayrıldıktan ya da junior'larla değiştirildikten sonra kod tabanı çürümeye başlar. Örneğin her giriş ayrıştırma sınır durumu için korkutucu ve opak bir parser'ın önüne bir tane daha saf doğrulama regex'i eklersen ve parser gramerinin kendisini düzeltmezsen, kod tabanı bir çamur yığınına dönüşüyor demektir.
    Elbette doğru katmanda düzeltirsen, çoğu zaman şirketin stack'te kullandığı ekosistem yazılımının küçük, kapalı, uzun ömürlü hotfix branch'lerini koruman gerekir. Upstream genelde o sorunu sorun olarak görmediği için yamayı kabul etmez; bu yüzden onu tek başına elinde tutman gerekir.
    Şaka yollu söylersek, GitHub profilinde doğrulayıp bu tür uzun ömürlü kapalı hotfix branch'leri kaç kez oluşturduğunu ya da sürdürdüğünü saysak, bir mühendisin kıdemini kod testinden çok daha basit ölçebiliriz.
  • Bilmediğin bir kod tabanına, bazen de bağlı olunan kütüphanelere dalıp hızla inceleme, debug yapma ve kök nedeni bulma becerisi deneyimlerime göre çok değerli.
    Gerçek hayatta işe yaramazmış gibi davranmanın faydası yok. Gerçeklik dağınıktır; dokümantasyon çoğu zaman yoktur ya da güvenilir değildir, asıl kodu yazan kişi veya ekip de çoktan gitmiş olabilir.
  • Küçük bir şirkette tek geliştirici on binlerce kullanıcıya hizmet veriyorsa, daha fazla geliştirici almaya değer gibi geliyor. Testlere ya da geliştirici deneyimini iyileştirmeye bütçe ayırıp daha az stresle çalışabilmeleri gerekirdi; üzücü.

• Küçük bir anekdot var. Bir arkadaşımın eşi bu yılın başında işinden ayrıldıktan sonra Big Tech şirketlerinin her biri için mülakata 4-6 hafta hazırlandı. Meta için 4-6 hafta, Stripe için 4-6 hafta gibi hazırlandı; aralarda rastgele mülakatlara da girerek pratik yaptı ve kas hafızası oluşturdu, her şirkette çıkabilecek türden soruları araştırdıktan sonra günde birkaç saat LeetCode çözdü.
  Sonuçta işler yolunda gitti ve MAANG’den L6/staff teklifini kabul etti. Ama bu hafta konuştuğumuzda, yeni rolüne daha başlamamış olmasına rağmen çalıştığı ayrıntıların çoğunu çoktan unuttuğunu söyledi. Sistem tasarımı deneyimi olmadığı için sistem tasarımı hazırlığının en zoru olduğunu söyledi, ama artık MAANG’de staff eng oldu. Birlikte küçük bir projede çalıştığım gerçek hâli iyiydi, ama olağanüstü parlak bir mühendis değildi.
  Gerçekten tuhaf ve işe alımdaki yükseliş-düşüş döngülerini epey açıklıyor gibi. Sistem tasarımı mülakatı hazırlık videolarına bakınca neredeyse senaryo gibi görünüyor. Mülakata girip senaryoyu takip etmeniz yeterli; gerçekten benzer ya da daha karmaşık sistemler tasarlayıp tasarlamadığınız önemli değilmiş gibi duruyor. Sistem tasarımı mülakatının amacı en nihayetinde “senaryoyu biliyor musun” gibi.
  Bu iki videoyu art arda 2x hızda izleyince ne kadar senaryo gibi icra edildiklerine şaşırıyorsunuz: https://www.youtube.com/watch?v=4_qu1F9BXow, https://www.youtube.com/watch?v=_K-eupuDVEc

  • Eskiden işe alım yaptığımda, adayı yönlendirerek ilerletebileceğim bir problem hazırlardım; o anda neyi keşfettiğine ve farkında olmadan bildiği şeyleri nasıl ortaya çıkardığına bakardım. Benim öğrendiğim whiteboard problemi buydu; bugünkü LeetCode tarzı değildi.
    Annem ve babam 1980-90’larda Santa Cruz teknoloji sektöründeydi; o zamanlar yetenek havuzu büyük olmadığı için, geliştirici olarak yetiştirilebilecek insanları bulmaya yarayan kapsayıcı bir araçtı. Bugün sektör bu pratiği aldı ama tam tersine dışlayıcı hâle getirdi.
    İşe aldığım kişilerden biri fizikçiydi; teknik jargonu hiç bilmiyordu ve ilk whiteboard problemini gördüğünde dehşete kapılmıştı. Onu rahat ettiği noktaya kadar yönlendirince, fizik çalışmalarına yardımcı olmak için yaptığı araçlardan söz etmeye başladı; yazılım bilgisi olmadan yaptığı o araçların yazılım olduğunu söyleyince şaşırdı. Bu sadece gerçek yazılım olmakla kalmıyordu, aynı zamanda son derece etkileyiciydi; whiteboard problemi potansiyeli ortaya çıkaran bir araçtı.
    Büyük şirketlerin insan yerine doğrudan takıp çalıştırabilecekleri birer widget istediğini anlıyorum, ama aslında tam tersi amaç için geliştirilmiş bir şeyi kullanmaları komik. Böyle kod challenge’ları yapan havalı şirketlere girme umudum kalmayacak kadar yaşlanmış olduğum için bir bakıma şanslı olduğumu da düşünüyorum.
  • Bu şirketlerin işe alımcılarıyla konuşunca, bu yöntemin bilerek nispeten liyakatçi olacak şekilde tasarlandığını görüyorsunuz.
    Hangi üniversiteden mezun olduğunuzdan, hangi dersleri aldığınızdan, ne gibi avantaj ya da dezavantajlarınız olduğundan bağımsız olarak, rolde gereken niteliklere sahipseniz bunların birkaç ay içinde öğrenilebilecek şeyler olduğu mantığına dayanıyor. Teknikler çok standartlaştığı için süreç de oldukça nesnel biçimde farklılaşıyor.
    Gerçek işte o spesifik tekniği kullanmanız beklenmiyor. Bunun yerine, o tür teknikleri öğrenebildiğinizi ve yüksek stresli bir mülakat ortamında yüksek seviyede performans gösterebildiğinizi kanıtlıyorsunuz. Mantık şu: Bu, daha sonra atanacağınız proje için gereken teknikleri öğrenip büyük teslim tarihi baskısı altında performans gösterebileceğinize dair iyi bir sinyal.
    Bu sistemi savunmuyorum, ama arkasında belirgin bir mantık var.
  • O eğitim sürecinden geçtikten sonra onunla çalışıp çalışmadığını merak ediyorum. Veri yapıları ve algoritmalar kodlama problemi pratiği ile sistem tasarımı çalışmak bir mühendisi değiştirebilir. Sandığınızdan çok daha iyi hâle gelmiş olabilir.
    Kendisi unuttuğunu söylüyor, ama o pozisyonu aldıysa muhtemelen orta zorlukta LeetCode problemleri çözebilmiştir. Her şeyi unuttuğunu düşünmek zor; çoğu insanın anında çözemediği kolay problemleri hâlâ çözebiliyor olma ihtimali yüksek. Arama, sıralama, diziler ve hash lookup, ağaç ve grafik traversal gibi temel backend işlerinin karmaşıklığını da hâlâ biliyor olmalı.
  • Daha karmaşık sistemler tasarladığını yalnızca kişinin kendisi bilir. Mülakat yapan kişinin bunun doğru olup olmadığını, yoksa “karmaşık sistemler tasarladım” diyen bir oyunculuk senaryosunu takip eden bir aktör mü olduğunu bilmesinin yolu yok.
    Üstelik oyunculuk yeteneği, genel nüfusta programlama yeteneğinden daha yaygın olabilir.
  • O zaman sistem tam da amaçlandığı gibi çalışmış gibi geliyor. Akıllı görünen biri iyi bir iş bulmuş; bu hikâyedeki sorunun tam olarak ne olduğunu anlamıyorum.

• Yakın zamanda küçük bir startup’ta nispeten kıdemli bir mühendis rolü için mülakat sürecini yürüttüm. Herkes için daha uygun olan mülakat yönteminin farklı olduğuna inandığım için herkese seçenek sundum

  1. Yaklaşık 4 saati hedefleyen ama gerçek bir zaman sınırı olmayan ev ödevi tipi test. Bir algoritma sorusu değil, geçen ay gerçekten yaptığım bir işi küçülttüğüm bir projeydi
  2. 2 saatlik yerinde eşli çalışma alıştırması. 1 numaranın bir varyantıydı ama daha çok “2 saat içinde nereye kadar gidebiliyoruz, bakalım” gibiydi
  3. Mevcut çalışmalardan kod örneği gönderme
     Ev ödevi tipi testlere yönelik çok öfke gördüğüm için üç seçeneğe eşit dağılacaklarını sanıyordum; şaşırtıcı biçimde adayların yaklaşık %90–95’i ev ödevi tipi testi seçti. Ben de aday olsam tercih edeceğim yöntem bu olurdu, bu yüzden ilginç bir veriydi; çoğunluğun bunu tercih etmesi ise çok şaşırtıcıydı
  • Ev ödevi tipini biraz daha fazla tercih ediyorum; esas olarak daha az kaotik olduğu için. Ancak karşı tarafın buna zaman ayıracağının garantisi olmaması gibi bir sorun var
    Yüz yüze mülakatta şirket de ciddi bir maliyete katlandığı için zamanımın boşa gitme olasılığının düşük olduğu düşünülebilir. İş arama sürecindeki asimetriklik zaten büyüyor; ev ödevi tipi testler de bunu daha da hızlandıran bir akım
    Eskiden bir ödevi tamamlamadığım için teknik olmayan bir arkadaşım hâlâ bana kızıyor; temel gereksinimler açıkça önemsizdi ama talimatlar yeterince belirsizdi, bu yüzden teslim etmeye yetecek kadar iyi olup olmadığına karar etmeye çalışırken saatler harcanabilirdi. Üstelik dar bir teknoloji seti bekleniyordu; zor değildi ama “teknik yetenek bulamıyoruz” diyen bir şirkete belki yardımcı olma fırsatı için bunu öğrenmek istemedim
  • Neden ev ödevi tipini seçtiklerini sorup sormadığını merak ediyorum
    Ben 1 ve 2’yi 3’e tercih ederdim. Çözdüğüm problemi mülakatçının anlaması, yaklaşımımı daha iyi değerlendirmesini sağlar
    Evde yapıp sonradan teslim edersem, mülakatçı çözümümü kendi çözümüyle ya da başka çözümlerle karşılaştırarak aynı ödev üzerinden kodlama tarzımı daha iyi anlayabilir
    Eşli çalışmada birlikte çalışırsak düşünme sürecimi görebilir ve belirli deyimleri neden seçtiğimi daha iyi açıklayabilirim
    Geçmiş kodda neredeyse hiç bağlam yoktur. Sadece başka bir proje için yazılmış koddur. İlk aşamada özgeçmişle birlikte gönderilip gerçekten kod yazabildiğini doğrulamak için faydalıdır; ama sonraki aşamalarda, çalışan bir uygulama olduğunda ve belirli bir özelliğin kodunu gösterebildiğinde etkileyici olur. Fakat kaç kişinin elinde öylece çalışan yazılım var? Genelde birkaç hileyle bir şekilde çalışan kod vardır
    Ben 2 yerine 1’i tercih ederim. Hata yapma olasılığını azalttığı için. Yerinde 2 saat boyunca baskı ve Murphy Kanunları yüzünden batırma riskini almak yerine, evde 2 saat daha harcayıp bilmediklerimi özgürce araştırma zamanı bulmak elbette daha iyi geliyor
  • Ortalama beceri düzeyine sahip içe dönük bir mühendisim ama 10 yılı aşkın süredir problem çözen biri olarak 2 numarayı seçerdim. Yüz yüze olunca düşüncelerimi çok daha kolay açıklayabilirim, yapılacak iş de çok daha az olur ve mülakatçıyı etkilemenin daha fazla yolu olur gibi geliyor
    Ev ödevi tipi testleri değerlendiren tarafta da bulundum; bunlarla birini derinden etkilemenin ne kadar zor olduğunu biliyorum
  • “3. Kod örneği gönderme” seçeneğinin ezici biçimde kazanacağını sanıyordum. Zaten bitmiş bir iş olduğu için doğal görünüyor; gerçekten bunu seçen biri olup olmadığını merak ediyorum
  • Seçenek sunma fikri ilginç ama işe alım yöneticisi açısından sorun daha zorlaşıyor. Farklı seçeneklerin sonuçlarını nasıl adil biçimde karşılaştırabilirsiniz? Aynı mülakata girseler bile adayları adil karşılaştırmanın epey zor olduğunu düşünüyorum
    Son gerçek kodlama mülakatımda herhangi bir programlama dilini seçebiliyordum ve çözeceğim soruyu da 3 sorudan seçebiliyordum. Epey hoşuma gitti ve teklif de aldım. Zaman sınırlı bir mülakatta C++ yerine Python seçebilmek neredeyse hile gibi hissettirdi

• İnternette kodlama mülakatlarıyla ilgili şikâyetler arttıkça, yazılım geliştirme pozisyonu adaylarını elemek için kodlama mülakatının açık ara en iyi yöntem olduğuna inancım güçleniyor. Sektör genelinde iyi konuşanlar, sahtekârlar, toplantı ayarlayanlar çok fazla; kolları sıvayıp koda dalarak işi gerçekten bitirenler ise az
  Seviye yükseldikçe bu sorun daha da kötüleşiyor. İstediğiniz kadar şikâyet edebilirsiniz ama rahat bir FAANG’da yıllık 500 bin dolar maaşlı iş size doğal olarak sunulacak değil. Temel programlamayı tekrar gözden geçirmeye ve birkaç for döngüsü yazmaya niyetiniz yoksa şirket bunu yapacak kişiye geçer

  • Ben bu tür mülakatları iyi geçiyorum, FAANG’dayım ve bu ay başka bir FAANG’a geçmeyi planlıyorum. Yine de bu mülakatlar işe yaramaz ve problem çözme ile öğrenme becerisi hakkında yanlış sinyal verir
    Mülakat gerçekten kolları sıvayıp koda dalma becerisini test ediyorsa, yeni giren biri olarak neden uzun süredir orada olanlara yazılım mühendisliği ve hata ayıklama pratiklerini bu kadar çok anlatmak zorunda kaldığımı bilmiyorum
    Büyük bir şirkette gerçekten çalıştıysanız, gerçek işin %90’ını insanların %5’inden azının yaptığını bilirsiniz. Mülakatlar düzgün çalışsaydı bu oran çok daha iyi olmalıydı
  • Kodlama challenge’larından hoşlanmıyorum ama bunun nedeni zor olmaları değil. Kodlama challenge’ı yapmaya zamanı olan kişilere avantaj sağlamaları. Yine de sektörde ne kadar çok sahte kişi olduğu doğru; onları elemek için kodlama testleri muhtemelen şu an için en iyi seçenek olabilir
  • Geçmişte öyle olmuş olabilir ama artık bu sistemi istismar etmeye yardımcı olan koca bir sektör oluştu
    Cracking the Coding Interview, Elements of Programming Interviews in Java/Python/diğer diller, LeetCode ve ücretli premium abonelik siteleri, deneme mülakatı bootcamp’leri bile var. Artık mesele yetenekten çok sistemi oyunlaştırmaya yakın
  • “Kodlama mülakatı, yazılım geliştirme pozisyonu adaylarını elemenin açık ara en iyi yoludur” derken aynı anda “sektörde iş yapamayan çok fazla insan var” diyorsun
    Kodlama mülakatının standart işe alım yöntemi olduğu varsayımı ile sonucun bu kadar kötü olduğu gerçeği arasında hiç bilişsel çelişki olmaması şaşırtıcı
  • LeetCode’un genel olarak iyi kabul edildiğini varsaysak bile, giderek daha baskın hâle gelen bir varyant olan ML/AI mühendisi için durum ne olacak?
    Problem LLM tokenizasyonu gibi bir şeyse, “ML-LeetCode” sorularında LLM kullanımını nasıl yasaklayabilirsiniz?
    Aday Cursor ve Claude’u ustalıkla kullanarak kodlayan bir uzmansa; 3 prompt ve kolayca bulduğu 2 hata düzeltmesiyle 10 dakikada çözüyor, üstüne NeurIPS düzeyinde makaleleri ve açık kaynak kodu da varsa, ben sahte bir dolandırıcıyı mı elemiş olurum yoksa en üst düzey bir adayı mı?
    LLM’lerle ilgili iş yapan biri için LeetCode tarzı soruların anlamlı olduğunu düşünmüyorum. Beğenin ya da beğenmeyin, gelecekte rahat FAANG+ yıllık 500 bin dolarlık işlerin giderek daha büyük kısmı LLM ile ilgili olacak

• Bir Ruby geliştiricisine esneklik testi olarak PHP debug ettirmek kulağa fena bir test gibi gelmiyor. İyi, özellikle de kıdemli bir geliştiriciyseniz bunu yapabilmeniz gerekir. Kendinizi yalnızca “Ruby geliştiricisi” diye sınıflandırmak bir kariyer tuzağıdır

  • Üstelik epey para kazandıran bir tuzak da olabilir
  • Kimin nasıl yürüttüğüne bağlı olarak eğlenceli bir alıştırma da olabilir, berbat bir alıştırma da. Ama rol Ruby rolü diye sunulmuşsa ve adayın yeterince seçeneği varsa, rol açıklamasının yalan olduğunu düşünüp gitmesine yol açabilir
  • Katılıyorum. Gerçek işte bu yeterince sık yaşandığı için tamamen uydurma bir örnek değil. Genelde tüm şirkette bunu yapabilen ve yapmak isteyen sadece iki üç kişi olur
    Eski, tedarikçiye özgü bir DSL’i ya da framework’ler ve standartlar o kadar eski olduğu için neredeyse başka bir dile dönüşmüş kodu debug etmek zorunda kalabilirsiniz
    Backport edilmiş özellik desteği eklemek veya eski istemcilerle legacy stack’teki güvenlik açıklarını yamamak da buna dahil. Büyük bir şirkette, çok daha küçük bir iş ortağının escrow kodunun sorumluluğu bize kalmıştı
    Düzgün debug edebilmek için ortamı kurmak çoğu zaman asıl düzeltmeden daha büyük iş olur. Yine de kıdemli ve üzeri için iyi bir testtir
  • Tek satır JavaScript yazmışlığım olmadan bir JavaScript testini geçip işe alınmıştım. Görev neredeyse etkileşimliydi
    Mülakatçı “Bu diziyi ters çevirin” dediğinde, “Python olsaydı array.reverse() ya da reversed(array) kullanırdım; JS’te de bunlardan biri vardır, muhtemelen .reverse metodudur” diye yanıtladım. Mülakatçı “İyi tahmin” dedi
    Gerçekten eğlenmiş, birkaç şey öğrenmiş hissiyle çıktım; karşı taraf da yeni bir problemi nasıl akıl yürüttüğümü görebildi
  • Kariyeri ruh sağlığının önüne koymak da bir hayat tuzağıdır

• Dokümantasyonu da ekip desteği de olmayan eski codebase’leri defalarca debug ettim. Onu yazan hiç kimsenin kalmadığı, dokümantasyonun olmadığı ya da bulunamadığı sistemler gerçekten var. Bu yüzden bu örnek pek iyi değil. Bir programı debug edebilmek, istek akışını takip edip neler olduğunu görebilmek iyi bir beceridir
  Ancak bu örneğin gerçekten kötü olduğu nokta, geliştiricileri belirli bir teknolojiye güvercin yuvasına koyar gibi hapsetmesi. Legacy bir PHP uygulamanız varsa Java, Python, Ruby, Go geliştiricileri arasından böyle debug becerisi olan ama PHP bilmediği için yavaş kalacak kişileri elemiş olursunuz. Oysa birkaç ay PHP ile doğrudan uğraşsa daha güçlü bir geliştirici bile olabilir
  “4 saatlik görev”in iyi bir çıktı üretmek için kolayca 8, 10 saat ya da daha fazlasına uzayabildiğine katılıyorum. Verilen süre kolayca oyuna getirilebilir; daha fazla zamanı olan kişi daha iyi aday gibi görünebilir

  • Stripe’ta mülakata girdiğimde, birkaç dilde “bunu debug et” tarzı sorular hazırlamışlardı. Sanırım Ruby, Java, Python, JavaScript, Go ve bir iki tane daha vardı. Oldukça iyiydi ama emek yoğun da görünüyordu

• Dokümantasyonu da ekip desteği de olmayan eski bir codebase’i en son ne zaman debug ettim mi? Bu hafta her gün yaptım
  Dokümantasyon diyorsanız, kod en son haziranda güncellenmiş, dokümantasyon ise en son Ocak 2022’de güncellenmiş
  Ekip diyorsanız, iki yıl önce işten çıkarılmayan yarısı daha iyi yerlere gitmiş. Elbette bu projenin sahibi bir ekip var ama aynı zamanda üç başka projeye de sahipler ve son bir yılda buraya katkıları on küsur satır; onun da 11 satırı dependency update’ti

  • İşte bunu yapmak sorun değil, ama mülakatta yapmak bence sorun. Yabancı bir ortamda, yabancı insanların önünde herkes rahat olamayabilir. Lütfen take-home test verin ve ben whiteboard’un önünde dururken kendi aranızda sohbet etmeyin

• “Ruby geliştiricisine PHP debug ettirmek gibi”, “Pozisyon belirli bir teknoloji gerektiriyorsa o teknolojiyi test edin” sözleri, coding challenge’da elenmiş birinin lafları gibi geliyor
  Ciddi konuşursak, şirketlerin işe alım pratiklerini sırf eğlencesine devreye aldığı nadirdir. Genellikle o kolektif aklın bulabildiği en iyi yöntemdir. Çözmeye çalıştıkları problemin ne olduğunu anlamaya çalışmadan ve alternatif de sunmadan kaldırın demek üretken değil
  Yazılım geliştirmede, başka mesleklerin pratiklerini ödünç almak yerine tekerleği çok sık yeniden icat ettiğimizi düşünüyorum. İnşaat mühendislerinin yazılım geliştiricilerin yarı maaşını almak için nasıl bir işe alım sürecinden geçtiğine bakalım ve bunu kendi pratiklerimize entegre edelim. O zaman hepimiz mutlu askerler oluruz

  • Şirketlerin işe alım pratiklerini sırf eğlencesine oluşturmadığı ve bunun kolektif aklın en iyisi olduğu iddiası pek olası değil. Genelde en kıdemli kişinin geçmişte okuduğu ya da yaşadığı bir şeyi getirmesidir
    Gerçekte neyi başarmaya çalıştıklarını düşündükleri ihtimali bence çok düşük. Sadece başkaları yaptığı için takip ettiler ve birilerinin bir yerlerde bunu niyetli biçimde tasarladığına inanıyorlar
    Teknik işe alım o kadar yolunu kaybetmiş durumda ki, en iyi ihtimalle bir yerel maksimum gibi görünen noktaya yerleşmiş gibiyiz
  • Yine de belki daha iyi yazılım üretebiliriz

• Hiç kodlama testi yapmayan bir şirkette çok kötü bir deneyim yaşadım. Toplamda 2-3 mülakat vardı
  Sorun, veri mühendisliği ekibinde birlikte çalışmaya başlayınca ortaya çıktı. Stack’in çoğu Hadoop, Kubernetes, Ruby, Python ve çeşitli teknolojilere dayanıyordu; bulut bilişim konusunda temel bir anlayış gerekiyordu
  Ama iş deneyimi ve arka planlar o kadar dağınıktı ki, işe alındığım işi yapmak yerine çoğu zaman başkalarının açıklarını kapatıyordum. Bazı ekip arkadaşları Docker ile Python CLI paketleme ya da Hadoop job’larını kontrol etme gibi temel işleri bile yapamıyordu; bu yüzden bunları telafi eden çok fazla yapıştırıcı iş yapmak zorunda kaldım
  Sonunda ayrıldım. Kendimi özel sandığım için değil, aynı seviyede ya da daha yüksek seviyede işe alınmış insanlara destek vermeye zamanımın %80’ini harcamaktan bıktığım için. O şirketin işe alım pratiklerinin çok kötü olduğunu kabul ediyorum ama bir şekilde temel teknik test şart

  • “Temel işleri bile yapamıyorlardı” derken, kendilerine verilen işi tamamen yerine getiremediklerini mi kastediyorsunuz, yoksa basit işlerde takılsalar da genel olarak bağımsız ve yetkin olduklarını mı?
    Bir diğer önemli soru da aynı kişiye aynı şeyi tekrar tekrar anlatmak zorunda kalıp kalmadığınızdır. Bilmemek kabul edilebilir, ama öğrenmeye çalışmamak kabul edilmesi zor bir şey

• Ödev tipi testlerin ilginç yanı, “sadece X saat ayırın” denilse bile daha fazla zaman harcamaya yönelten bir ahlaki tehlike barındırması. Şirket sorarsa, gerçekten harcanan süre hakkında yalan söyleme teşviki de doğuyor
  Önerilen süreye uymayı vurgulayarak problemi makul şekilde çözüp ödevi teslim ettiğim birkaç kez oldu; sonraki mülakatta “Neden X’i uygulamadınız?” diye azarlandığım da oldu
  Bununla bağlantılı olarak, aşırı ucu açık ödev tipi testler kötü ödevlerdir. Çünkü daha fazla boş zamanı olup işi daha titiz yapabilenlere avantaj sağlar. Nihai çıktı olarak PowerPoint sunum dosyası isteyen veri bilimi ödev tipi testlerine selam olsun

  • Aynen bu. Sonra şirkette oturan, benimle hiç tanışmamış ya da konuşmamış biri yorumların çok fazla olduğundan, sevdikleri kod formatter’ını kullanmadığımdan ya da isteğe bağlı tip denetimi yapmadığımdan şikâyet ediyor. Düzgün bir proje kurulum rehberi istiyorsanız bunun bedelini ödemelisiniz