Kagi Search’ün ödev tipi mülakatında elenme deneyimi

 (bloggeroo.dev)
4 puan yazan GN⁺ 2025-05-16 | 1 yorum | WhatsApp'ta paylaş
  • Yazılım geliştirici mülakatlarında verilen "take-home assignment"ların verimsizliği ve adayların zamanını boşa harcaması sorununu vurguluyor
  • Kagi Search başvuru sürecinde aşırı geniş ve muğlak ödev gereksinimleri ile karşılaştığını anlatıyor
  • Önerdiği somut uygulama planı için yöneticiden net geri bildirim alamadığını ve iletişimin verimsiz olduğunu aktarıyor
  • Büyük emek vererek geliştirdiği projeyi teslim ettikten sonra, açık bir gerekçe olmadan elenmesini ve ölçütlerin değişmesini haksız bulduğunu söylüyor
  • Daha iyi işe alım süreçleri için alternatifler (ör. gerçek zamanlı kod incelemesi) öneriyor ve ödev tipi mülakatların aşırı taleplerine dikkat çekiyor

Giriş

  • Take-home assignment, yazılım geliştirici mülakatlarında adaya bir problem verilip bunu kodla uygulayarak teslim etmesinin istendiği bir değerlendirme yöntemidir
  • Bu yazı, itibarlı bir şirket olduğunu düşündüğü Kagi Search’e başvururken aldığı gerçek ödev ve yaşadığı deneyim üzerinden, bu yöntemin mantıksızlığını ve adayların zamanını boşa harcama sorununu eleştirmeyi amaçlıyor

Kagi Search’e iş başvurusu

  • Kagi Search’ün backend geliştirici pozisyonuna özgeçmişini gönderdiğini belirtiyor
  • Rolün beklentileri şunlardı
    • Backend sistemleri kurma deneyimi
    • Go dili kullanabilme
    • Büyük ölçekli backend sistemlerini ölçeklendirme ve bakım deneyimi
    • SRE gibi ekip üyeleriyle iş birliği becerisi
    • Docker gibi konteyner teknolojilerini anlama

Mülakat ödevi bilgilendirmesi ve gereksinimler

  • Ön elemeden geçtikten sonra take-home assignment hakkında bir e-posta aldığını söylüyor
  • Ödev konusu: "minimum düzeyde terminal esintili bir e-posta istemcisi uygulamak"
    • Terminal ya da web uygulaması biçimlerinden biri seçilebiliyor
    • Temel e-posta görüntüleme/gönderme işlevleri
    • Sahte ya da gerçek bir e-posta backend’i (IMAP/POP vb.) serbestçe seçilebiliyor
    • Yalnızca plaintext mesaj desteği zorunlu, rich text gerekmiyor
    • Proje teslimi: GitHub deposu, dağıtılmış sürüm ve kurulum dokümantasyonu dahil
  • Net yönlendirme eksikliği olduğunu ve projenin kapsamının oldukça büyük olduğunu düşünüyor
  • Yine de şirketin itibarı nedeniyle ödevi yapmaya karar verdiğini anlatıyor

Yöneticiyle iletişim

  • Ödevin net kapsamı ve ek özellikler hakkında soru sorduğunda, yalnızca “neyi ekleyeceğine aday karar verir” şeklinde muğlak bir yanıt aldığını söylüyor
  • Ödeve zaman ve emek harcamadan önce, somut bir uygulama planını (proposal) paylaşıp buna yanıt istemesine rağmen özel bir geri bildirim almadan sürece devam ettiğini belirtiyor

Ödev önerisi ve plan

  • Uygulama planı:
    • Go tabanlı bir web uygulaması
    • AWS ECS Fargate üzerinden dağıtım ve SSL uygulanması
    • E-posta gönderici servisi (Postmark) entegrasyonu
    • Giriş/kimlik doğrulama özelliği eklenmesi
    • E-posta alma-gönderme ve arayüzde gösterim
  • Teknoloji seçiminin gerekçesi:
    • Backend rolüyle ilişkili çeşitli teknolojileri kullanmak
    • Infra-as-Code araçlarıyla pratikte gerçek bir sistem kurmak
    • Basit bir API entegrasyonunun ötesine geçip gerçek bir servise daha yakın özellikler geliştirmek
  • Başlıca uygulama unsurları:
    • Pocketbase (backend/DB), TEMPL (şablon), Pulumi (IaC), Postmark (e-posta servisi)
    • Sayfalama, giriş gibi özelliklerin uygulanması
    • Stretch Goal: veri yedekleme ve kurtarma gibi dayanıklılık özellikleri
  • Sonuç: Önceden yeterli açıklama ve gerekçe sunduğunu, buna karşılık net bir değerlendirme ve yanıt beklediğini ifade ediyor

Yöneticinin yanıtı ve iletişim sorunu

  • Somut bir değerlendirme olmadan yalnızca “ilginç bir öneri” şeklinde kısa bir yanıt aldığını söylüyor
  • Önerinin uygunluğu ya da iyileştirme ihtiyacı konusunda hiçbir geri bildirim verilmediğini belirtiyor
  • Aday açısından bunun, harcadığı zaman ve emeğe saygı gösterilmemesi gibi hissettirdiğini aktarıyor

Proje ödevinin gerçekleştirilmesi

  • Verilen gereksinimlerin ve önerdiği unsurların tamamını uyguladığını ve buna bir haftalık tam zamanlı emek harcadığını söylüyor
  • Proje demo videosu, GitHub deposu ve ayrıntılı dokümantasyonu da teslim ettiğini belirtiyor

Elenme bildirimi ve buna verilen geri bildirim

  • Otomatik bir red e-postası aldıktan sonra geri bildirim istediğinde şu yanıtı aldığını söylüyor:
    • “Daha güçlü aday teslimleri vardı”, “işe alım rekabeti çok yoğundu”
  • Sorunlar
    1. Basit çözümler tercih ediliyorsa, bu en baştan belirtilebilirdi
    2. Öneri yetersiz görüldüyse, o aşamada geri bildirim verilebilirdi
    3. Elendikten sonra bile ilanın hâlâ yayında olması, bunun yalnızca rekabet değil aşırı zaman tüketen talepler olduğunu düşündürüyor
    4. Proje teslim edildikten sonra gereksinimlerin daha da ağırlaşması, sanki teslim edilen çözümün çıtayı yükseltmiş olması anlamına geliyor

Sonuç ve problem tespiti

  • Bu tür bir yaklaşımın birçok iş arayan için haksız olduğunu ve hatta geçim açısından gerçek baskılar yarattığını savunuyor
  • Aşırı ücretsiz ödev taleplerinin reddedilmesi ya da bunlara itiraz edilmesi gerektiğini vurguluyor
  • Proje tabanlı ödevlerin yerine gerçek zamanlı kod incelemesi gibi daha iyi işe alım süreçlerinin mümkün olduğunu söylüyor
    • Gerçek geliştirme problemi çözme becerilerinin asenkron/senkron kod incelemeleriyle görülebileceğini belirtiyor
    • Leetcode tarzı problem çözümü ile gerçek iş gereklilikleri arasındaki kopukluğa dikkat çekiyor
  • Aday tükenmişliği ve adaletsiz değerlendirme kültürünün iyileştirilmesi çağrısında bulunuyor

Daha iyi işe alım süreci için öneriler

  • Gerçek zamanlı kod incelemesi gibi, geliştirici yetkinliğini daha anlamlı biçimde değerlendiren alternatifler öneriyor
  • Zamanlayıcıya dayalı algoritma bulmacaları çözmeye odaklanmak yerine, gerçek yetkinlik ve problem çözme becerilerini merkeze alan bir değişimin gerekli olduğunu savunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-16
Hacker News görüşleri
  • Dürüst olmak gerekirse, işe alım yapan biri olarak fikrimi bırakıyorum. Kişisel olarak take-home ödevlerinden hoşlanmıyorum. Bu tür ödevler herkesin zamanını boşa harcıyor. İşe alımın son aşamasıysa anlaşılabilir, ama aday elemek için kullanmak verimsiz.
    1. Çok fazla soru sorulmuş. Belirsizlik içinde muhakeme kullanıp çözmek zaten ödevin bir parçası. Verilen koşullara göre bir-iki gün ayırıp basit bir yerel proje düzeyinde yapmak yeterli olurdu.
    2. Teklif dokümanı yazımı ve paylaşımı fazlasıyla abartılmış. Aday titizliğini göstermek istemiş gibi görünüyor ama şirket açısından bu verimsiz ve zaman kaybı olarak görülebilir.
    3. Ortaya çıkan sonuç işlevseldi ama altyapı ve cilaya gereğinden fazla emek harcanmış. Elenince sonuçta bu zaman boşa gitmiş oldu.
    4. Sanki terminal esintili bir e-posta istemcisi gibi bir gereksinim vardı, ama çıkan işte o yönü göremedim.
      Adayın yeteneğini ve işe duyduğu tutkuyu takdir ediyorum. Sadece biraz farklı bir açıdan görüş vermek istedim.
    • Blog yazarının tavrı biraz rahatsız edici geliyor. Yazıdan bile birlikte çalışmanın zor olacağı, kendi başına karar vermekte zorlanan ve net yönergeler gerektiren biri izlenimi çıkıyor. Büyük şirkete uygun olabilir ama startup'a uygun değil.
      İlk aşamadaki bir startup mühendisi için "terminal esintili bir e-posta istemcisi geliştirip müşterilerle alfa testine çıkmak" gayet makul bir taleptir. Daha fazla şart olsa bile pek çok nokta mühendisin muhakemesine bağlıdır. Aday fazla kesinlik istiyor.
      Kagi'nin ödev tamamlandıktan sonra ne tür geri bildirim vereceğini önceden merak etmesi iyi bir işaret değil. Kesin bir yanıt verilebilecek bir durum değil. Muhtemelen yüzlerce, binlerce başvuruyu değerlendiriyorlardır.
    • Yazar işi iyi yapmış ama örtük olarak var olan "fazla uğraşma" şartında başarısız olmuş.
      Eğer gereksinimleri netleştirmeye gerek yoksa, o zaman insanlara doğrudan "1 ile 10 arasında sayıyı tahmin et" deyip yanlış seçenleri elemekten farkı kalmıyor.
      Ödeve emek verip iyi bir bitiriş yaptığı için eleme yapılmasına katılmıyorum.
      Böyle muğlak ödevler aslında sadece "kültür uyumu" seçmenin başka bir yolu.
    • Bence adayın kendi fikrini doğrulama yaklaşımı günümüz mühendislik tarzına benziyor. Sağlıklı bir ekip, özellik tasarım dokümanını İngilizce anlatarak onay alır ve sonra ilerler.
      "Önce kod, geri bildirim sonra" kültürü kariyerimde yaşadığım en zararlı deneyimdi. Bu aday modern yazılım pratiklerini izlemiş. (Ben 1000'den fazla mühendisi olan bir şirkette işe alım yapıyorum.)
    • İşe alım yapan biri olarak sevdiğim take-home ödevleri; 30 dakika içinde tamamlanabilen, değerlendirme ölçütü net olan, farklı yaklaşımlar ve trade-off düşünmeyi içeren türden olur.
      Ben de son iş arayışımda kapsamlı bir take-home ödevinde hangi kısmın değerlendirme ölçütü olduğunu bilemeyip elenmiştim. Bu deneyimden sonra bu tür ödevlere karşı ciddi bir iticilik geliştirdim.
    • Bence elenme nedeni teklif dokümanının fazla büyümesiydi. Yönergelerde teklif dokümanı istenmiyordu ve çok ayrıntılı teslim etmek tersine "bağımsız inisiyatif eksikliği" olarak yorumlanabilir. Böyle olunca kod kalitesinin artık bir anlamı kalmıyor.
      Şirketin, adayın daha fazla zaman harcamasına izin vermek yerine o noktada ödevi bitirmesi daha iyi olurdu.
    • Bugünün sektöründe gereksinim anlama becerisi yetersiz olduğu için geliştiricileri zihin okuma becerisine göre eleme gerçeği üzücü.
    • Adayın teslim tarihini kaçırmış olması da sorun. Özel bir durum açıklanmayan gecikme zaten elenme sebebi. Ödevin amacı, süre içinde uygun bir çözüm tasarlamaktı.
    • 4 numaradaki terminalle ilgili ifadeye dair, yazarın paylaştığı tam sürümde o kısmın açıklaması var.
    • Sonuca bakıp böyle tartışmalar yapmak her zaman kolaydır. Ters strateji izlenseydi de (gereksinimleri sormamak, sadece minimumu karşılamak) aynı sonuç çıkabilirdi. Böyle durumlarda her zaman "daha proaktif biçimde gereksinim netleştirilmeliymiş" görüşü tam tersi yönde de söylenebilir.
  • Koda baktığımda ve demo videosunu izlediğimde, bir haftada iki sayfalık bir web uygulaması için epey zaman harcanmış gibi geldi.
    En temel e-posta işlevleri (örneğin mail açma) bile yok ve backend mühendisi rolüne başvurmasına rağmen pratikte postmark ve turso gibi dış ürünler kullanılmış; düz metin biçimlendirme, görüntüleme, klasörler gibi temel özellikler eksik.
    Yönetici paneli, giriş gibi ek özellikler var ama posta başlığı haritası gibi asgari veri yapıları bile yoktu.
    İyi bir mühendis olabilir ama o pozisyon için uygun olmadığı sonucuna vardım.
    Take-home teklif dokümanı da fazla sıra dışı geldi.
    İlk ilanı yeniden okuyunca "asgari düzeyde terminal esintili e-posta istemcisi" ve aerc, mutt, himalaya gibi referansların açıkça yazıldığını gördüm. Bu, gereksinimlerin açık biçimde yanlış yorumlanması.
    • "Gereksinimleri yanlış yorumlama" denince tam olarak hangi gereksinimin karşılanmadığını merak ediyorum.
      Terminal ya da web uygulaması biçiminde bir e-posta istemcisi ve temel işlevlerin uygulanması isteniyordu; bunun karşılandığını düşünüyorum.
      Terminal tabanlı araçlardan esinlenme kısmı öznel. Backend pozisyonu için UI'a çok odaklanmak verimsiz de olabilir.
    • Adayın ciddi zaman harcayıp sadece bir ret maili alması üzücü.
      En azından geri bildirim alabilse gelişimine katkı sağlar ama bunun bile pratikte çoğu zaman zor olduğu görülüyor.
      Bu yüzden take-home ödevlerine karşı şüphe duyuyorum. Hem adayların hem işe alım yapanların birbirinin zamanına saygı göstermesi gerek.
    • Şöyle bir ifade var: "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Take-home değerlendirmeleri anlamlı olabilir ama mutlaka bir zaman sınırı olmalı.
    2-3 saat aday değerlendirmek için fazlasıyla yeterli. Zaman sınırı olsaydı aday da buna uygun bir çözüm önerebilir, şirketin ne istediği de daha net olurdu.
    Ayrıca şirketin "hangi cevap olursa olsun olur" mu dediği, yoksa "en iyi cevabı" mı beklediği açıkça belirtilmeli.
    Take-home'un amacı testi geçmek mi, görevi karşılama oranı mı, kod kalitesi mi; türüne göre değiştiği için adayın kafası karışabiliyor.
    • İşe alımcı bakış açısından Kagi'nin ödevi fazla kapsamlı ve adayın zamanına karşı saygısız görünüyor.
      Hatta zamanı olmayan, meşgul kişileri eleme riski taşıyor.
      Bizim şirkette sadece basit bir ETL problemi veriyoruz ve 4 saat sınırı koyuyoruz.
      Tamamlanamasa da sorun olmayacak şekilde tasarlıyoruz; sonrasında kod incelemesi ve soru zamanı içeren bir follow-up yapıyoruz.
      Gerçek yetkinlik aslında bu takip görüşmesinde anlaşılabiliyor.
    • Adayların fiilen harcadıkları sürenin açıklanandan çok daha fazla olması mümkün; işe alımcının bunu nasıl bilebileceğini merak ediyorum.
      Eşit zaman biriminin korunduğu canlı ödevlerin aksine, take-home'da herkesin farklı zaman ayırması nedeniyle dezavantaj oluşabiliyor.
      Bu durumda 1 saatlik canlı kodlama daha iyi. Aday ve görüşmeci aynı zamanı yatırdığında birbirlerinin zamanının değerine daha çok saygı gösterilmiş olur.
    • Bence canlı inceleme, canlı kodlamadan çok daha iyi. Eğer canlı kodlama yapılacaksa, benim laptop'umda 45 dakika uzaktan çalışıp sonra dönüp birlikte incelemek daha iyi olur.
  • Şirketin yanıtı soğuk ve faydasızdı, bu doğru; ama gereksinimlerde 'terminal esintili' olduğu açıkça yazıyordu.
    Demo videosunda ise sıradan bir web uygulaması görülüyor. Açıkça aerc, mutt, himalaya gibi mevcut terminal e-posta istemcilerinden esinlenilmesi istenmişti.
    Acaba benim kaçırdığım bir şey mi var diye merak ediyorum.
    • Ret mailinde neden daha net açıklansaydı daha iyi olurdu ama en başta ödev tasarımında terminal istemcisi referansları doğrudan istenmişti.
      Terminal istemcilerine özgü UX hâlâ "doğru cevap"ı olmayan bir alan olduğu için, tam da bu noktanın değerlendirme ölçütü yapılmış olması muhtemel.
    • Go diline odaklı olduğu düşünülürse, bir CLI yapmak 20 satır bile sürmezken neden özellikle web GUI geliştirmeye yoğunlaşıldığı soru işareti.
    • Şöyle bir yönlendirme vardı: "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Yakın zamanda mülakatta benzer bir deneyim yaşadım. Ödev projesini çok iyi teslim ettim ama proje üzerine hiçbir konuşma yapılmadan doğrudan elendiğim bildirildi.
    Bir ödev istendiyse mutlaka bir follow-up görüşmesi olması gerektiğine inanıyorum.
    Zaten Kagi'yi ücretli kullanıyordum ama bu olaydan sonra hesabımı kapatmayı düşünüyorum.
    Adayla konuşacak vakitleri bile yoksa baştan böyle bir ödev istememeliler.
    • Take-home ödevleri sadece aday için değil, değerlendiren görüşmeci için de ciddi emek gerektirir.
      İnceleme de yapıldıktan sonra geri bildirim alma hakkı olduğunu düşünüyorum.
      Ama pratikte onlarca güçlü aday arasından yalnızca biri seçildiğinde, elenmek doğrudan "yeterince iyi değildi" anlamına gelmez.
      Hukuken de "neden A seçildi de B elendi?" sorusuna verilecek resmî yanıt çoğu zaman kusur aramaya indirgeniyor.
    • Şirket nasıl değerlendireceğine dair ölçütleri açıkça yayınlasaydı ya da geri bildirim verseydi daha iyi olurdu. Başarısızlık geri bildirimi olmadan zaman kaybı kabul edilemez.
      Pek çok şirket bunu daha iyi yönetiyor.
    • Bunun gerçekten "güçlü bir çözüm" olup olmadığı şüpheli. Asgari terminal esintili bir e-posta istemcisi talebini ve ilgili referansları tamamen görmezden gelmiş gibi duruyor.
      Gereksinimlerdeki bu kadar büyük bir yanlış anlamada tartışmanın hiç yapılmaması da mümkün.
  • Bu vaka, ödev metnindeki örtük niyetin yanlış okunmasının tipik bir örneği.
    Şirket kendi kendine hareket edebilen ve hedeflerini kendisi koyabilen birini istiyordu.
    Belirsizlik, adayın cevapları farklı açılardan araştırıp çözebilme becerisini görmek içindi.
    • O ödev, mümkün olduğunca basit, zekice ve çalışan bir çözüm çıkarabilecek kişi içindi.
      Prototip odaklı şirketler herkese uymaz; bazı adaylar 10 dakika düşünüp 60 dakika içinde mümkün olan en iyi sonucu çıkarabilirdi.
    • R&D projesi ve sadece "minimal olsun" vurgusu varsa, bunun prototip mi olduğu, kullanıcıya mı sunulacağı, UX'in önemsenip önemsenmeyeceği gibi gereksinimler belirsiz kalır; sonuçta bu, değerlendiricinin neye önem verdiğini tahmin etme oyununa dönüşür.
    • Böyle "kendin yorumla" türü ödevlerde gereksinim netleştirme ya da ek soru sorma yapmayan kişi elenebilir.
      Ama geliştirici için bu tür soru sorma becerisi çok önemli bir niteliktir. Bu yüzden işe alım yaklaşımından daha fazlasını bekleyip hayal kırıklığına uğramak kaçınılmaz oluyor.
    • Bence "misreading the subtext" denilen şey aslında talebin içinde zaten yazıyordu.
    • Eğitimde, "anlamıyor" diye sadece öğrenciyi suçlamak fazla kolay bir sonuç.
      Asıl sorun çoğu zaman muğlak açıklamadır.
      İyi bir öğretmen mümkün olduğunca çok kişinin anlamasını sağlar. Çok sayıda öğrenci kafası karışıyorsa sorun soru hazırlayandadır.
      Üniversite öğrencileri Zen keşişleri gibi koan çözmek zorunda olmamalı.
  • Yazıyı doğrudan yazar paylaştığı için, Kagi'de çalışmış biri olarak biraz bağlam vermek istiyorum.
    Eskiden adayları doğrudan Vlad değerlendirirdi ve ödevler de bu şekildeydi.
    Şirket büyüdükçe artık değerlendirmeyi başkaları yapıyor gibi görünüyor.
    Vlad'ın HN tarzı bir mizacı var ve "cool" bulduğu adaylarla çalışmak istiyor.
    Örneğin uzun bir tasarım dokümanı yazıp "Galactor kullanacağım ve proje flop-ready" derseniz bu tamamen ters etki yaratır.
    "Terminal esintili" talebinde, tüm klavye kısayolları gibi terminal uygulamasına özgü detayların gerçekten hayata geçirilmesini bekleme eğilimi var.
    Bunun iyi bir filtre olup olmadığı tartışmalı, ama o bağlamı anlayıp geçecek yetkinliğiniz varsa ödev size kolay gelecektir.
    Keşke Kagi bu bağlamı daha iyi anlatsaydı. Zamanın boşa gitmesi üzücü ama umarım size daha uygun bir şirket bulursunuz.
    • Pek çok şirket, kendisine benzeyen düşünme biçimini arıyor.
      Çeşitliliği olmayan ekiplerde herkes aynı duvara çarpıp tıkanabiliyor.
      Bu olgu özellikle startup'larda yaygın ve bence 10 girişimden 9'unun başarısız olma nedenleriyle de bağlantılı.
    • Sorun, Vlad'ın "cool insanlar" bulmak için fazla çok kişinin zamanını boşa harcıyor olması gibi geliyor.
      Net ölçütler olmadan puanlanan ödevlerin adil olmadığını düşünüyorum.
      Sonuçta bu, "kafamdaki cevabı bul" türü örtük bir görevden farksız.
      İnsana karşı özen eksikliği izlenimi veriyor.
    • "Bunu gerçekten önceden bilmem mi gerekiyordu?" diye düşünmeden edemiyorum.
      Bu tarz bir kültürde herkesin gizli araştırma yapar gibi önceden öğrenmesi mi bekleniyordu, belli değil.
      Benim gibi yeterince 'cool' olmayan adaylar da net sinyal alıp hızla başka şirketlere yönelebilse daha iyi olurdu.
  • Kodu bizzat incelediğimde, ilk dosyadan itibaren amaçsızca örnek kod kopyalanmış gibi duran yorumlar, tutarsız açıklamalar ve dikkat eksikliği izlenimi veren ifadeler gördüm.
    Bu tür ayrıntı eksiklikleri yüzünden incelemeyi bırakırdım.
    • Uygulamayı kendi alan adımda dağıttım ve performans sorunu yaşamadım. Kimlik doğrulama ve altyapı gibi backend yönlerini de iyi uyguladım. Ama kod yorumlarına daha fazla dikkat etmem gerektiği eleştirisine katılmıyorum.
    • Bu vakadaki asıl sorun, elenmenin kendisi değil; net bir rehberlik ve en ufak bir geri bildirim olmadan yürütülen işe alım sürecinin adayın zamanına hiç saygı göstermemesiydi.
  • DuckDuckGo'da da benzer bir deneyim yaşadım ama tüm başvuru aşamalarında küçük de olsa ücretliydim.
    Basit bir tasarım teklifinden implementasyon ödevine kadar, net zaman sınırlarıyla ilerlediler.
    Sonuçta kabul edilmedim ve net bir gerekçe de verilmedi.
    Muhtemelen aday çok fazlaydı ama bu deneyim duygusal olarak uzun süre üzerimde kaldı. OP'nin hislerini anlıyorum.
  • Bir mühendislik mülakatçısı olarak konuşuyorum: leetcode da take-home da çok zaman alıyor ve az bilgi sağlıyor.
    Ama işe alımcı ben olsaydım ben de yazarı elerdim.
    Startup'lar hızlı ve pratik çalışan insanları ister.
    Geçmişte çevreden görüş toplayıp sonra günlerce tek başına derin çalışmaya giren, bu sırada gereksinimleri çoktan değişmiş olan çalışma arkadaşlarım oldu ve bu hiç kimse için iyi olmadı.