- Bir geliştirici, Kagi Search’ün backend işe alım sürecinde terminal hissi veren bir e-posta istemcisini yaklaşık bir hafta tam zamanlı çalışarak geliştirdi; ancak teslimden sonra takip mülakatı yapılmadan elendi
- Görev; TUI veya web uygulaması, temel e-posta görüntüleme ve gönderme, sahte backend ya da IMAP/POP/JMAP seçeneği gibi konularda açık bırakılmıştı; bu yüzden uygulama kapsamını ve değerlendirme ölçütlerini adayın kendisinin yorumlaması gerekiyordu
- Aday; Go web uygulaması, AWS ECS Fargate, SSL, Postmark, oturum açma, Pulumi, Pocketbase, TEMPL gibi unsurları içeren ayrıntılı bir planı önceden gönderdi; ancak Kagi tarafı somut kabul ölçütleri paylaşmadı
- Elendikten sonra istediği geri bildirimde yalnızca “daha basit ve daha güçlü teslimler” olduğu yanıtı geldi; bu aşamada genellikle bireysel geri bildirim verilmediği belirtildi
- Bu deneyim, ücretsiz görev bazlı mülakatların ve süre sınırlı kodlama bulmacalarının, gerçek mühendislik yetkinliğinden çok adayın zamanını ve yaşam koşullarını sınayabileceğini gösteriyor
Başvuru ve görevin alınması
- Aday, Kagi Search’ün backend rolü için özgeçmişini gönderdi; rol özetinde şu yetkinlikler yer alıyordu
- Backend sistemleri kurma deneyimi
- Go yetkinliği
- Backend sistemlerini ölçeklendirme ve bakımını yapma konusunda anlayış
- SRE ve ekip üyeleriyle iş birliği yapabilme
- Docker gibi konteynerleştirme teknolojilerini anlama
- Daha sonra Kagi’den, bir sonraki adım olarak Kagi Developer Assessment’ı tamamlamasını isteyen bir e-posta aldı
- Görev URL’si HackMD üzerinden iletildi
- Tamamladıktan sonra iletişime geçerse inceleyecekleri; geçerse takip mülakatında yaklaşımını ve çözümünü tartışacakları belirtiliyordu
Görev gereksinimleri ve açık değerlendirme ölçütleri
- Görevin amacı “asgari düzeyde terminal hissi veren bir e-posta istemcisi” yapmaktı
- Uygulama koşulları nispeten geniş bırakılmıştı
- E-posta istemcisi terminal TUI ya da web uygulaması olarak geliştirilebilirdi
- Temel e-posta görüntüleme ve gönderme işlevleri gerekiyordu
- Sahte backend (DB, bellek içi vb.) ya da gerçek IMAP/POP/JMAP backend kullanılabilirdi
- Zengin metin mesajları hariç tutulup yalnızca düz metin işlenmesi yeterliydi
- Değerlendirmenin yalnızca kodlama becerisini değil, Kagi Labs gibi Ar-Ge projeleri için gereken belirsizlik ve açık uçlu problemleri ele alma becerisini de kapsadığı belirtiliyordu
- Çıktı koşulları şöyleydi
- Geliştirici olarak yetkinliği gösterecek şekilde uygulanması
- Tamamlanan projenin bir GitHub deposuna yüklenmesi ve kolayca test edilebilmesi için bir yerde dağıtıma alınması
- README’de kurulum yönteminin yazılması
İşe alım sorumlusuyla iletişim
- Aday, gereksinimlerin çok geniş olduğunu düşünerek işe alım sorumlusuna sorular gönderdi
- Sorumlu, çok sayıda aday olduğunu; bazı adayların yalnızca temeli uyguladığını, bazılarının ise ek özellikler, iyi dokümantasyon, kararların açıklaması, demo dağıtımı ve gelecek planları sunduğunu söyledi
- Hangi ek özelliklerin yüksek değerlendirildiğini sorunca sorumlu, “bunun kendisinin değerlendirmenin bir parçası” olduğunu ve adayın aklına gelen ek özellikleri görmek istediklerini belirtti
- Aday, gerçek kodlamaya başlamadan önce tüm çıktının uygulama planını ayrıntılı şekilde yazıp göndermeye karar verdi
- Önerisi kabul edilirse telefon mülakatına ya da iş teklifine yaklaşabileceğini umdu
- Sonuçları gördükten sonra, koşulları önceden netleştirmeye çalışma çabasının işe alım sorumlusu için pek anlam taşımadığına kanaat getirdi
Adayın önerdiği uygulama
- Önerinin merkezinde Go web uygulaması tabanlı bir e-posta istemcisi vardı
- AWS’ye dağıtım
- ECS Fargate kullanımı
- SSL/HTTPS uygulanması
- E-posta gönderim sağlayıcısıyla entegrasyon
- Oturum açma ekranı üzerinden kimlik doğrulama
- Form tabanlı e-posta gönderimi
- Gelen e-postaların arayüzde gösterilmesi
- Öneride teslim tarihi olarak 30 Mart Pazar EOD belirlenmişti; bunun ilk e-postadan sonraki 2 haftalık noktadan iş günü bazında iki gün daha geç olduğu yazıyordu
- Teknoloji seçimleri şöyleydi
- Go backend: Pocketbase ve TEMPL kullanımı
- Altyapı kodu: Pulumi kullanımı, TypeScript SDK seçimi
- E-posta servis sağlayıcısı: Postmark kullanımı
- UI: gönderilen ve alınan e-postalar için sayfalama, oturum açma ekranı, demo için 2 hesap sağlanması
- Seçim gerekçeleri, rolü ve değerlendirme kapsamını geniş biçimde göstermeye daha yakındı
- Rol backend olsa da web frontend eklemek, web teknolojileri yelpazesini gösterebilirdi
- Veritabanı backend rolüyle ilgiliydi
- AWS ve altyapı koduyla dağıtım; IaC, Docker, ağ ve dayanıklılık tartışmalarıyla bağlantılıydı
- Postmark gibi bir e-posta servisi, IMAP/POP entegrasyon karmaşıklığını azaltırken işlevselliği koruyordu
- Aday, “bunu tamamladığımda Kagi’den nasıl bir tepki bekleyebilirim” diye sordu; ancak yanıt “çok ilginç, tesliminizi bekliyoruz” düzeyinde kaldı
Teslim ve elenme
- Aday, önerdiği her şeyi uyguladığını ve tüm işin bir hafta tam zamanlı sürdüğünü belirtti
- Web uygulaması demosunu YouTube’a yükledi, kodu da dokümantasyonla birlikte GitHub’da yayımladı
- Otomatik ret e-postasını aldıktan sonra geri bildirim isteyince Kagi tarafı şu şekilde yanıtladı
- Bu aşamada genellikle geri bildirim verilmez
- Daha basit ve daha güçlü teslimler vardı; bu adaylarla sürece devam etmeye karar verildi
- Her pozisyona yüksek ilgi ve çok sayıda başvuru olduğu için seçim süreci çok rekabetçidir
- Gelecekteki pozisyonları takip edip yeniden başvurması istenir
Elenme sonrası kalan sorular
- Aday, “daha basit bir çözüm” isteniyorsa bunun 18 Mart’ta öneriyi gönderdiğinde söylenebileceğini düşünüyor
- Çözüm role uygun değilse, benzer şekilde bunun 18 Mart’taki öneri aşamasında değerlendirilebileceğini düşünüyor
- 13 Mayıs itibarıyla, elenmesinin üzerinden bir buçuk ay geçmiş olmasına rağmen iş ilanının hâlâ yayında olduğunu yazıyor
- Şirketin aynı ilanla birden fazla rolü doldurabileceğini kabul ediyor
- Ancak bunun “kazananın yeri zaten dolmuş bir yarış” gibi görünmesinin zor olduğu kanaatinde
- Orijinal görev yönergelerinde demo dağıtımının iyi olacağı ama zorunlu olmadığı belirtilmişken, teslimden sonra yönergelerin dağıtımı katı bir gereklilik hâline getirecek şekilde değiştiğini yazıyor
Daha iyi bir seçim yöntemi için öneri
- Aday, ücretsiz görevlerin iş arayanlar, özellikle de işsizken birikimleri azalan kişiler için büyük bir yük olduğunu eleştiriyor
- LeetCode tarzı mülakatlara da olumsuz bakıyor
- Yakın zamanda Clojure tabanlı bir rolde “coin change” problemi çözdüğünü; 50 dakika içinde testlerin yaklaşık yarısını geçirdiğini, ancak backtracking kısmını uygulamaya zamanının yetmediğini yazıyor
- Alternatif olarak canlı kod incelemesi öneriyor
- Bunun hem asenkron hem de senkron şekilde mümkün olduğunu düşünüyor
- Gerçek yazılım projelerindeki sorunlar ve konular sözlü olarak ele alınabilir
- Deneyimli bir yazılım mühendisinin bilgisini daha iyi ortaya koyabilir
- Canlı kodlamaya tamamen karşı değil; ancak 50 dakika içinde knapsack çözme becerisinin günlük mühendislik işiyle uzak olduğunu düşünüyor
- Çok çaresiz bir durumda değilseniz, bu tür ücretsiz çalışma isteyen rolleri reddetmeyi öneriyor
1 yorum
Hacker News yorumları
İşveren açısından bakınca, ödev tipi elemeyi şu nedenlerle sevmiyorum. Herkesin zamanını boşa harcıyor; işe alımdan hemen önceki son aşama olarak fena değil ama filtre olarak kullanmaya uygun değil
Yine de yetkinliği ve samimiyeti açıkça belli; ben sadece başka bir açıdan şeytanın avukatlığını yapıyorum
“Birkaç müşteriye alfa testi yaptırabileceğimiz terminal tarzı bir e-posta istemcisi yap” demek, erken aşama bir startup mühendisi için makul bir istek; ayrıntılar da kaçınılmaz olarak mühendise bırakılmak zorunda
Özellikle “tamamına kadar ilerlersem Kagi’den nasıl bir tepki bekleyebilirim, bilmek istiyorum” talebi iyi değildi. Yüzlerce, binlerce teslimi incelemek gereken bir durumda kesin bir cevap vermenin yolu yok
Gereksinimleri netleştirmeye çalışmak istenmeyen bir davranışsa, bu 1 ile 10 arasında bir sayı seçtirip yanlış seçeni elemekten farklı değil
Ödev tipi testler yeteneği göstermek içindir; somut yönlendirme yoksa ne kadarını göstermek gerektiğini nasıl tutturacaksın?
Son rötuşlar ancak teslimi engellediğinde kötüdür; “fazla cilaladığı” için elemek, işi fazla iyi yaptığı için elemek gibi hissettiriyor
Bu tür belirsiz testler nihayetinde kültür uyumu olmadığı gerekçesiyle insan elemenin başka bir yoluna benziyor
“Önce yap, sonra incelet” ortamları kariyerimdeki en toksik yerlerdi; günler harcayıp bir özellik yaptıktan sonra bunun istenmeyen bir özellik olduğunu öğrenmek en kötüsü
Bu yüzden özelliği yazıyla açıklayıp onay alma yöntemi, proje yayınlamada sektör standardına oldukça yakın; bu aday da sağlıklı organizasyonların izlediği yazılım pratiklerini uygulamış
1.000’den fazla mühendisi olan bir şirkette işe alım yöneticisi olarak ben de böyle görüyorum
Elbette bu, sonucu kabul/ret kararını etkileyecek yalnızca bazı adaylara verilmeli
Son iş arayışımda böyle geniş kapsamlı bir ödev aldım; fazlasıyla nitelikli olduğum bir iş olmasına rağmen, hangi kısmın puanlanacağını kestiremediğim için elendim
Gelecekte referans dışında bir yöntemle iş bulma ihtimalim düşük görünüyor ama bu tür ödevleri almak da vermek de beni ciddi biçimde soğuttu
Bu ödev, birkaç soru sorma, varsayımları yazma ve belirsiz bir işe özgüvenle dalıp bir şeyler yapma becerisini ölçüyordu
Muhtemelen o e-postadan sonra kodun önemi kalmamıştı; şirket de adayın ödevi uygulamaya zaman harcamasını önlemek için o noktada süreci bitirmeliydi
Koda ve demo videosuna baktığımda ilk düşüncem şuydu: “İki sayfalık bir web uygulaması yapmak bir hafta sürmüş ve mesaj açma gibi en temel e-posta işlevi bile eksik.”
Gereksinimlere bakınca bu kişi “Email Backend Engineer” pozisyonuna başvurmuş ama gerçek e-posta backend’i için Postmark ve Turso gibi üçüncü taraf ürünler kullanmış
Düz metin e-posta formatı, görüntüleme, klasörler, en azından gelen kutusu ve gönderilenler gibi temel öğeler eksik; buna karşılık giriş ekranı, yönetici sayfası, backend framework’ü gibi opsiyonel özellikler var
Backend veritabanında e-posta başlıkları için bir map bile yok
Harika bir mühendis olabilir ama bu özel pozisyona uygun görünmüyor; ben de olsam reddederdim
Orijinal ilana bakınca başlık “The project is to build a minimal, terminal-inspired email client” idi ve aerc, mutt, himalaya gibi mevcut terminal e-posta araçlarından ilham alınması açıkça belirtilmişti
Bu, gereksinimleri doğru okuyamama düzeyinde; bu yüzden işe alınamaz görünüyor
İkisini de yeterince karşıladığı görünüyor
Mevcut araçlardan ilham almak öznel bir şey; backend pozisyonunun ödevinde kullanıcı arayüzüne zaman harcamanın yeteneğini göstermenin en iyi yolu olduğunu düşünmemiş olabilir
Popüler bir pozisyonda işe alım görevlisi yüzlerce kişiyi değerlendiriyorsa bunun her zaman gerçekçi olmadığını anlıyorum ama ödev tipi elemenin kötü olmasının nedeni de bu
Aday hayatının birkaç saatini hiçbir şey kazanmadan boşa harcayabilir; bu yüzden iki taraf da birbirinin zamanına saygı göstermeli
Yanıtın çok kısa ve yardımcı olmadığını anlıyorum, ancak gereksinimlerde açıkça terminal-inspired bir e-posta istemcisi yapılması isteniyor.
Paylaşılan videoya https://www.youtube.com/watch?v=yY1sVXMkP_o bakınca, özellikle terminalden esinlenmiş bir yanı olmayan sıradan bir e-posta web uygulaması gibi görünüyor.
Asıl istenen gerçek bir TUI ya da web uygulamasından biri idiyse, web uygulamasının da terminal havasında olması büyük olasılıktı.
Tüm gereksinimlerdeki “Inspiration” bölümünde “aerc, mutt, himalaya gibi mevcut terminal e-posta araçlarından ilham alın” diye açıkça belirtilmiş.
Yine de prompt, diğer terminal istemcilerini ilham kaynağı olarak açıkça belirtmişti.
Ayrıca terminal istemcisi gereksinimi, değerlendirilecek şeyi büyük ölçüde değiştiriyor. E-posta web arayüzü uzun zamandır bilinen bir alan; ancak terminal istemcilerinin kullanıcı deneyimi henüz tamamen “çözülmüş” bir alan değil.
Değerlendirme tablosunda, adayın tesliminde hiç ele alınmayan terminal istemcisi tasarım kararlarının büyük ağırlığı olmuş olabilir.
Ödev tipi değerlendirmeler mülakat sürecinde değerli olabilir, ama mutlaka zaman sınırı gerekir. 2-3 saat, gerekli bilgiyi almak için fazlasıyla yeterlidir; daha fazlası, bakmakla yükümlü olduğu kişiler, hobileri veya sorumlulukları olmayan yeni mezunları eleme yöntemine yaklaşır.
Sınır 3 saat olsaydı, en kötü durumda aday yalnızca 3 saat kaybederdi; daha olası durumda ise o süreye uygun bambaşka bir öneri ya da çözüm sunardı.
Adayın “herhangi bir yanıt mı istiyorlar, iyi bir yanıt mı istiyorlar” sorusunu da netleştirmesi gerekir.
Bazı ödevlerde yalnızca test paketinin geçip geçmediğine bakılır, yöntem önemsenmez; bazı ödevlerde ise gereksinimlerin yalnızca %80’i karşılansa bile daha iyi kod tercih edilir. Adayların iki tarafta da yanlış tahmin yaptığını gördüm.
Böyle ödevler, projeye çok zaman harcayabilecek kişileri süzer; asıl meşgul olan, yani muhtemelen istenen kişilerin ise vazgeçmesine yol açabilir.
Veri mühendisliği yetkinliği için işe alım yaparken basit bir ETL ödevi veriyorum. ZIP dosyasından veriyi çıkarıp dönüştürmelerini ve herhangi bir veritabanına koymalarını istiyorum.
Muğlak noktalar bırakıyor, veri kümesine beklenmeyen null değerler veya hatalı biçimlendirilmiş CSV gibi gizli unsurlar koyarak uygulama becerisine bakıyorum.
4 saatle sınırlıyorum ama zaman yetmezse ne yapacaklarına dair yönerge vermemiştim; bu iyi bir öneri.
Sonraki görüşmede kodu birlikte inceliyor, “veri kümesi belleğe sığmazsa?” gibi sorularla iyileştirme yönünü soruyorum; asıl teknik değerlendirme de orada oluyor.
Tüm adayların aynı süreyi harcadığının garantisi olmadığı için bu bir oyun teorisi problemine dönüşüyor ve aday genelde bir şekilde zarar görüyor.
Çoğu durumda doğru hamle, daha fazla zaman harcayıp çok cilalı ama aşırı da cilalı olmayan bir çözüm üretmek ve sonra zaman sınırına uyulmuş gibi davranmak oluyor.
3 saat bile, bir sonraki kişiyle konuşup konuşamayacağını bilmeyen bir aday için çok uzun bir süre.
1 saatlik mülakatta programlama ödevi yaptırarak adayın ek zaman harcamadığını garanti edebilirsiniz.
Aday isterse daha sonra iyileştirilmiş yanıt göndermesine izin verilebilir; genelde o noktada yetkinliğini zaten iyi gördüğünüz için “istersen yap, ama zaten geçtin” denebilir.
Adayla mülakatçının zaman yatırımını eşit tutarsanız, kendi zamanıma saygı duyduğum gibi adayın zamanına da saygı duymuş olurum.
Bir işe alım yöneticisi adayın zamanına saygı duymuyorsa, çalışanın zamanına da saygı duyma olasılığı düşük görünür.
Son dönemde birkaç yerde mülakata girdim ve bu deneyime çok benziyordu. Ödev için çok iyi bir çözüm sundum ama sonuç üzerine hiç tartışılmadan reddedildim.
Ödevli işe alım süreçlerini işveren tarafında birçok kez yürütmüş biri olarak, birinden evde ödev yapmasını istediyseniz kod hakkında mutlaka konuşmanız gerektiğine inanıyorum.
Ödev veriliyorsa, değerlendirme sonucu ne olursa olsun sonrasında bir görüşme olup olmayacağını mutlaka teyit etmeyi; buna razı değillerse “ev ödevi” yapmamayı güçlü şekilde öneririm.
Açıkçası birçok işe alım ekibinin seviyesi düşük olduğu için, iyi bir çözüm uygulamak tersine eksi puan bile olabilir. İşe alım ekibinin o seviyeye uygun olmaması gibi sinir bozucu bir nedenle elenebilirsiniz.
Kagi’nin erken kullanıcılarındandım, ama bu olay yüzünden hesabımı kapatmayı düşünüyorum. Adayla konuşacak zamanınız yoksa baştan iş yaptırmamalısınız.
Ödevli süreç, yalnızca aday için değil bunu yürüten kişi ve işe alım ekibi için de ciddi emek gerektirir; proje incelendiyse, talep edildiğinde geri bildirim ya da yanıt beklemek makuldür.
Ancak gerçeklik de var. Bir pozisyon için 20 harika aday varsa, yetenekli birçok kişi de reddedilir. Bu onların yetersiz olduğu ya da “başarısız olduğu” anlamına gelmez.
Hukuken neden A’yı seçip B’yi seçmediğinizi açıklamanız gerekiyorsa, “ikisi de harikaydı ama birini seçtik” demek zorlaşır; sonunda var olmayan kusurları bile bulmaya doğru kaymak kolaylaşır diye düşünüyorum.
Amerikan şirket kültüründe bu yaklaşımı sık gördüm ve Kagi Palo Alto merkezli.
Ödevde elenmek sorun değil; ama karşılığında hiçbir şey vermeden birinin zamanını boşa harcamak kabul edilmesi zor.
Popüler startup’lar dahil, bunu iyi yöneten çok sayıda şirket var.
Sonuç, “minimal terminal tarzı e-posta istemcisi”ne pek benzemiyor ve ilham alınması istenen araçları da tamamen görmezden gelmiş gibi duruyor.
Gereksinimleri bu kadar büyük ölçüde yanlış anladıysa, ben de tartışmaya zaman ayırmazdım.
Bu, gizli bağlamı yanlış okumanın tipik bir örneği. Şirket, bağımsız biçimde kendi işini ve hedeflerini oluşturabilen birini istiyordu.
Görevin muğlaklığı, bir sürü e-postayla didiklemek için değil; oldukça geniş bir görevi alıp problem alanını kendi başına keşfetme ve ortaya bir çıktı koyma biçimini göstermek için verilmiş boş bir tuvaldi.
Üniversitede çalışırken, ödevi anlamayan bir öğrencinin beklemediği bir not alıp şikâyet etmesine çok benziyor.
Mülakat gibi etkileyici görünmek istenen bir durumda “tembel” davranmaya cesaret edebilen insan pek yaygın değildir.
Hızlı deney yayımlama ve prototip odaklı yaklaşımı olan bir şirkette bazı kişiler gerçekten uygun olmayabilir; bu da herkes için kötüdür.
Muhtemelen bazı adaylar 60 dakika içinde ne yapabileceklerini 10 dakika düşünüp, HTTP kimlik doğrulaması ve formlardan yararlanarak küçük bir Go backend’i çalıştırıp kısa bir e-postayla göndermiştir. Böyle biri süreçte çok daha iyi görünmüş olabilir.
Bunun atılacak bir prototip mi, gerçek kullanıcıların göreceği bir şey mi, eksik kullanıcı deneyimi nedeniyle eleştirilecek mi, yoksa sadece bir şey görmek mi istedikleri belli değil.
Sonunda bu, değerlendiricinin zevkini tahmin etme alıştırmasına dönüşüyor.
Tersine, gereksinimleri sürekli zorlayıp netleştirmediği için elenen kişiler de olacaktır; oysa bu, bir mühendis için önemli bir erdemdir.
Hayat adil değil ama işe alım yöneticilerinden daha fazlasını bekliyoruz; bu yüzden de sürekli hayal kırıklığına uğruyoruz.
Öğrenci zihin okuyamadığı ve yönergeler berbat yazıldığı için yanlış anlamış da olabilir.
İyi öğretmen, mümkün olduğunca çok öğrencinin anlamasını sağlayandır; kötü öğretmen bunun tersidir.
En iyi öğretmenlerimde notlandırma ölçütleri baştan şeffaf olduğu için nottan şüphe etmeye gerek kalmazdı.
Kafası karışan öğrenci çoksa ortak payda öğretmen olabilir.
Budist bir keşişin koan denen çetin bilmeceleri çözerek öğrenmesi, harç ödeyen üniversite öğrencilerine de aynı yöntemin uygulanması gerektiği anlamına gelmez.
Yazıyı yazan kişi bunu doğrudan paylaşmış gibi göründüğüne göre, aldığı tepkinin bağlamını açıklayayım. Daha önce Kagi’de çalıştım ve benzer bir take-home testten geçtim.
O dönemde şirket çok küçüktü; Vlad adayları bizzat inceliyor ve bu tür proje bazlı görevler kullanıyordu. Şimdi şirket büyüdüğü için bizzat bakmıyor olabilir ama öz aynı görünüyor.
Vlad’la konuştuğunuzda, onun neredeyse Hacker News yorumcusunun tipik örneği olduğunu görürsünüz; mülakat da “makul biri gibi görünüyor mu” diye bakılan bir hava kontrolüne yakındır.
Ona uzun bir tasarım belgesinde “Galactor kullanacağım, florp-ready hale getireceğim ve fleem edeceğim” yazmak, havalı olmanın tam tersidir.
Görev “terminal tarzı e-posta istemcisi” ise, tam puana yakın proje muhtemelen tüm işlevlerde klavye kısayolları olan ve bir frame çizmenin 2 ms’yi aşmadığını tek paragrafta açıklayan bir şey olurdu.
Mülakatı yapan kişi, adayın Kagi’de çalışmak için fazla enterprise tarzı düşündüğünü görmüş olabilir.
Elbette bu seçme yönteminin iyi olup olmadığı ayrı konu. Vlad kendisi gibi düşünen insanları istiyor ve bu tür mülakatlarda uzun süredir tartışılan ve araştırılan birçok sorun var.
Yine de bunu anlayıp böyle bir süreci kaldıracak alanınız varsa, görev aslında anlamlı hale geliyor. Kagi bunu daha iyi aktarabilirdi.
Çok zaman kaybetmiş olmanız üzücü; umarım çalışma biçiminize daha uygun bir yer bulursunuz.
Bir probleme yeni içgörü katmak için düşünce çeşitliliği gerekir. Herkes aynı şekilde düşünürse, bir kişi tıkandığında herkesin tıkanma olasılığı yüksektir.
Bu, startup’larda yaygın bir sorun gibi görünüyor ve startup’ların 10’da 9’unun neden başarısız olduğunu gösteren bir işaret de olabilir.
Bu, yeteneği test etmekten farklı. Burada, size söylenmeyen bir metrikte yüksek puan almanız gerekiyor.
“İstediğin gibi kod yaz, muğlaklıkla iyi başa çıkabilmelisin” diye görev verip aslında aklımda olan şeyi tahmin et demekten pek farklı değil.
İnsanlara karşı çok düşüncesiz bir yöntem ve Vlad hakkında da iyi bir sinyal vermiyor.
Bunu anlamak için şirketteki insanların sosyal medyasını mı kurcalamalıyım?
Sonunda yeterince havalı olmadığımı açıkça göstermeme rağmen “devam et” deyip meraklarını gidermiş oldularsa, umarım onlar da başkalarına davrandıkları şekilde muamele görürler.
Açıklama için teşekkürler, kötü niyet beslemiyorum. Yalnız keşke böyle bir yazıyı daha erken görseydim.
Bundan sonra “take-home” içeren işleri havalı çocuklara yönelik işler diye sınıflandırmak iyi olur. Böylece sıkıcı ama deneyimli mühendisler, şirket gerçekten emeğimizi istiyorsa yöntemini değiştirmesi için baskı yapabilir.
Değiştirmeyen şirketler içinse o rolü “sunan” şirketin nasıl bir yer olduğu çıkarılabilir.
Bir değerlendirici olsam nasıl görürdüm diye koda baktım.
Açtığım ilk dosyada şuraya kadar bakıp dururdum: https://github.com/Sleepful/mymail/blob/main/app/router/page...
İlk yorum işle alakasız olduğu için çok tuhaf ve bir blog örneğinden kopyalanmış gibi görünüyor. Her hâlükârda olduğu gibi bırakılması dikkatsizlik.
İkinci satırdaki ifade, üçüncü satırla tutarlı değil.
İncelemeyi burada bırakırdım. Bu, ayrıntılara dikkat eksikliği ve net düşünebilme becerisini göstermiyor.
Buna karşılık gelen şey boş bir ret e-postasıydı.
O durumda kod yorumlarına daha fazla zaman harcamam gerektiği görüşüne katılmam zor.
Bir mühendislik mülakatçısı olarak söylemek istiyorum: LeetCode’u da proje ödevlerini de sevmiyorum. İkisi de çok zaman alıyor, verdiği sinyal ise az.
Yine de bu durumda yazarı büyük olasılıkla reddederdim. Kagi Search bir startup ve bu tür yerler genelde hızlı hareket eden pratik iyimserler ile derinlik ve genişlik arasında denge kurabilen insanları arar.
Eskiden girdileri toplayıp birkaç gün kapanarak bir çözüm üretip çıktığında, o arada gereksinimlerin değişmiş olduğunu gören bir iş arkadaşım vardı. Kimse için keyifli bir deneyim değildi.
Proje ödevli süreçlerden gerçekten nefret ediyorum.
“Bu proje yalnızca kod yazmayı değil, belirsizlikle ve açık uçlu problemlerle başa çıkma becerisini de test eder” ifadesi bana pratikte a) ödevin çok kötü tasarlandığı ve bir değerlendirme cetveli bile hazırlanmadığı ya da b) çalışma ortamının o kadar kaotik olduğu ki hiçbir spesifikasyon veya gereksinimin net tanımlanmadığı anlamına geliyormuş gibi geliyor.
Üstelik “tekniğini sergile” ile “pratik ve işlevsel bir çözüm üret” talimatları birbiriyle çelişiyor. İyi ve basit bir çözüm gösterişli olmaz.
HTTP isteği oluşturabilmek ve temel bir CRUD düzenleme ekranı yapabilmek neredeyse hiçbir şey anlatmaz. Yapay zeka araçları da bunları hızlıca ve oldukça iyi kalitede üretebiliyor.
Görmek istediğim şey, mühendisin garip iş mantığını nasıl uyguladığıdır.
Sonucun bir milyon iç içe
ifve “burada ejderhalar var” yorumları mı olacağını, yoksa uygun kalıplar bulup okunabilir ve akıl yürütülebilir kod mu yazacağını görmek isterim.Gerçek işte çok daha değerli olan şey bu; mülakat sinyali de daha güçlü, yapay zekanın doğru yapması daha zor ve daha az zaman alıyor.
İyi ve basit bir çözüm üretmek de yetkinliği göstermenin bir yolu olabilir.
Bence bu, kıdemli yazılım mühendisi rolünün büyük bir parçası.
Bu format bunu test etmenin en iyi yolu olmayabilir; ama “belirsizlikle başa çıkıp çıkamadığını göreceğiz” demek, her işin belirsiz olduğu anlamına gelmez.
Her işin “belirsiz gereksinimler”den “net spesifikasyon”a giden bir süreçten geçmesi gerektiği anlamına gelebilir.