Gerçek bir mühendis olmayan “Not a real engineer” (2019)

• Kısa düzyazı şiir, “You are not a real engineer” ilanıyla başlayarak mülakatta elenme bildirimi ile mitolojik canavar imgesini aynı bağlamda üst üste bindiriyor
• Öznesi, insan boyunda, aslan başlı, on altı kanatlı, yüzlerce gözlü ve yılan biçiminde bir kemere sahip aşkın bir varlık olarak tasvir ediliyor
• Fırtına bulutları gibi nefesi, rüzgarın kükreyişini andıran sesi ve otları solduran adımları, öznenin ezici gücünü sürekli büyütüyor
• Sonunda “şu anda bu rolü önermeyeceğiz” diyen işe alım reddi ifadesi ile “daha teknik birini arıyoruz” gerekçesi peş peşe geliyor
• Yıkıcı bir varlık bile daha teknik biri olmadığı gerekçesiyle reddedilince, “gerçek mühendis” ölçütünün saçmalığı ortaya çıkıyor

---

Mitolojik bir varlığa doğru genişleyen tasvir

• Açılış cümlesi “You are not a real engineer”; bu da özneye gerçek bir mühendis olmadığını doğrudan ilan ediyor
• Ardından özne, insan yapılı ama aslan başlı bir varlığa dönüşerek, on altı beyaz kanadı ve yüzlerce meşale benzeri gözü olan bir figür olarak çiziliyor
• Belindeki kuşak bir yılandır; nefesi fırtına bulutlarının toplanışı, sesi ise rüzgarın uğultusuna yakındır
• Adımlarının önünde otlar solar; derin uçurum kadar kara dili ise dokunduğu her şeye son getirir

İşe alım reddi ifadesinin yarattığı ters köşe

• Final, ezici tasvirden işe alım sürecindeki kibar ret ifadesine aniden geçiyor
• “Şu anda bu rolü önermeyeceğiz” sözünün ardından “daha teknik birini arıyoruz” gerekçesi geliyor
• Önceki mitolojik imgeler ile sondaki sıradan işe alım reddi cümlesi çarpışınca, “gerçek mühendis” sözünün ne kadar temelsiz olduğunu ortaya koyuyor

[GN⁺]

Hacker News yorumları

• Son zamanlarda, çalışma saatlerinin %80’i CRUD uygulamaları geliştirmek olan pozisyonlara dâhi seviyesinde mühendis alma fikrinden vazgeçtim.
  Bu hem para israfı hem de yetenek havuzunun israfı; aday için de iyi değil, şirket için de uzun vadeli risk oluşturuyor. Böyle insanlar eninde sonunda sıkılıp kafalarını çalıştırmak için aşırı tasarım yapmaya başlama eğiliminde oluyor.
  Çoğu mühendis için veritabanı ve API seviyesinde oluşturma, güncelleme, silme ve okuma işlemlerini düzgün yazmak; frontend’de API’yi çağırmak; uygun hata yönetimi ve fena olmayan bir hata ayıklama yaklaşımına sahip olmak yeterli.

  • Birkaç ekipte işe alım yöneticiliği yaptım ama iş o kadar basit değildi. John Carmack düzeyinde olmayan teknik görevler için John Carmack’e ihtiyaç olmadığı doğru.
    Ama “idare eder” programcıların “şöyle böyle” sonuçlar çıkardığını da gördüm; daha iyi programcıların 5 kat daha uzun çalışmadan 5 kat hızlı çalıştığını, neredeyse kendi kendini yönettiğini, kapatılan ticket’ın gerçekten bitip bitmediğini anlamak için QA’in sürekli peşinde koşmasına gerek bırakmadığını ve bir sorun çıktığında Git deposunu onların yerine çözmek zorunda kalmadan yaratıcı biçimde çözdüğünü de gördüm.
    Zihni dağınık bir dâhiye kadar gerek yok, ama iyi/çok iyi programcılar teknik olarak sıradan görünen projelerde bile büyük fark yaratıyor.
  • Bugünün SPA ve mikroservis dünyasında, az önce tarif edilen kişi aslında dâhi seviyesinde bir mühendisi anlatmaya oldukça yakın.

• Son zamanlarda Steve Howe’a sardım; tüm zamanların en iyi gitaristlerinden biri sayılan onun, gitaristlerin icracı olmaya odaklanmasını istediğine benzer bir şey söylediğini okudum. Kod yazan kişi ile mühendis arasındaki fark da buna benziyor.
  Benden teknik olarak daha yetenekli çok programcı gördüm, ama onlar daha iyi mühendis değildi. Benim kurucu olmam ve belli ölçüde pazarlama geçmişimin bulunması bunda büyük rol oynuyor.
  Pek çok şirket, insanı gerçekten mühendis yapan kod dışı becerileri hafife alıyor. Şef yerine kasap tutup sonra yemeğin neden lezzetsiz olduğunu merak etmek gibi.

  • Bir ölçüde doğru, ama genel olarak mühendisliğe giren standart karakter eğilimiyle biraz ters düşüyor.
    Teknik bir alanda lisans derecesi alıp Ingersoll Rand ya da Boeing gibi bir yerde mühendis #52354 olarak çalışmak ve karmaşık ama sınırlı bir alanın uzmanı olarak 30 yıl sonra emekli olmak da harika bir kariyer. Bu da “mühendis” için geçerli bir tanım; böyle insanlar sıkıcı görünebilir ama kişisel olarak tatmin edici hayatlar yaşama ihtimalleri yüksek.
    Son zamanlarda bu konuyu çok düşündüm; yönetimler standart mühendisi kolayca maliyet merkezi olarak görebiliyor, oysa metindeki kişi gibi olanların değeri mühendisliğin ötesine, doğrudan gelir üreten başka departmanlara kadar uzandığı için bu eleştiriden sıyrılabiliyor.
    Ben de benzer tipte bir mühendis gibiyim, ama bu klişeye duyduğum küçümsemeyi daha işbirlikçi bir tavra dönüştürmeye çalışıyorum.
  • Ama piyasa bu. İşverenlerin %99’u mühendis istemiyor, ucuz, güncel framework kodcusu istiyor.
    Gerçek piyasa, donanımla uğraşan C++ mühendisinden çok Spring Java kodcusuna değer veriyor.
  • Kod dışı becerilerin insanı daha iyi mühendis yaptığına dair ne tür örnekler var?
  • Küçük bir ekleme: Howe harikadır ve en iyilerden biridir, doğru; ama Paco De Lucia çok daha yukarıdadır.

• İki tarafı da yaşadım. İş arama sürecinin anlaşılmaz kaprislerini ve hafif hakaretlerini yaşadığım da oldu; lafı kulağa hoş gelen ama herhangi bir dilde FizzBuzz düzeyi bir problemi kodlayıp gösteremeyen deneyimli adaylarla mülakat yapıp elediğim de oldu.
  Bu, “teknik mülakatlar berbat” ile “iş piyasasında niteliksiz aday çok” seçeneklerinden yalnızca birini seçme meselesi değil. İkisi de doğru olabilir; hatta bence limon piyasası gibi birbirine bağlılar.

  • Mülakatların, daha geniş anlamıyla iş aramanın, nesnel ve adil bir süreç olmadığını; sonuçlarının da kesin ya da tekrar üretilebilir olmadığını anlamanın önemli olduğunu öğrendim.
    Nesnel olarak daha iyi biri varken işe alınabilirsiniz; ideal aday olsanız bile telefon taramasında hemen elenebilirsiniz. Sonuçta bu daha çok şansa benziyor; aksini söyleyenlerde ise hayatta kalan yanlılığı ile sürecin kendisinin kusurlu olduğunu kabul etmek istememe hali karışık.
    Deneyimli bir adayın FizzBuzz seviyesini bile çözemediği türünden yargıların da işe alımı rahatsız eden kargo kültü tarzı düşünceyi yansıttığını düşünüyorum. Gerçek yazılım mühendisliğine benzemeyen coding golf, algoritma ve veri yapıları quiz’lerine haftalarca çalışmadan ilk mülakatı geçemeyen FANG mühendisleri de biliyorum.
    Hatta bu sorunların teknik değerlendirmeden çok merdiveni arkadan çekmeye benzediğini düşünüyorum. Bir zamanlar masaüstü uygulama geliştiren bir C++ pozisyonunda placement new bilmediğim için otomatik elenmiştim; backend pozisyonuna başvuran bir tanıdığım ise sıfırdan Spring servisi yazıp tüm entegrasyon testlerini geçmesine rağmen controller’da yorum satırı olmadığı için elenmişti. PR’da tek satırlık yorumla düzeltilebilecek bir şeyi büyük bir teknik görev gibi ele alıp aday eleyen mülakatçılar var.

• İşe alan insanlar da hata yapıyor. Başarılı şekilde birini işe almak gerçekten zor.
  Bazen zaten sevmeyeceğiniz insanlarla çalışacağınız bir yerden sizi kurtarmış da olabiliyorlar. Neden işe almadıklarına dair makul bir bahane uydurmakta da pek iyi değiller; işin önemli bir kısmı şans.
  Örneğin “Trump destekçisi değil gibi” izlenimi edinip sizinle rahatça takılamayacaklarını hissetmiş olabilirler. Gerçekten onların tipinden değilseniz, orada çalışmak istemeniz için neden olsun ki?
  İş aramak beni her zaman depresyona sokuyor; belirli bir işe fazla umut bağlamamak dışında bir cevap bilmiyorum. Aynı zamanda pek de muhteşem görünmeyen fırsatları da fazla kolay göz ardı etmemek gerek.
  Şu anki işimdeki ilk patronum berbattı ve iyi insan da pek yoktu, ama onlar şirketten ayrıldı, ben terfi ettim. Böyle bir şeyi nasıl öngörebilirsiniz ki? İşe alımcı da sizi öngöremez; tüm süreç epey rastgele ve rahatsız edici.
  Mülakat yapan tarafta olduğumda önceliklerim var. Birincisi, yöneticim kısa bir tavsiye vermişti: “İyi insanları işe almaya çalış.” Her zaman kendi dediği olsun isteyen ve ultra üretken bir dâhi olduğu için tüm yetkinin kendisine verilmesi gerektiğine inanan biri yerine; nazik, birbirine yardım eden ve iyi geçinilebilen iyi bir geliştiriciyle çalışmak isterim.
  İkincisi, adayın yazılıma ya da en azından bir şeye ilgi duyup duymadığına bakarım. Yazılım, teknoloji, işle ilgili herhangi bir şeye az da olsa tutkunuz yoksa CV’nizde yazmayan gerekli şeyleri nasıl öğreneceksiniz? İnsanlar “bitmiş ürün” olarak gelmez; öğrenmeleri beklenmelidir.

  • Gerçekten onların tipinden değilseniz neden orada çalışmak isteyesiniz? Kirayı ödeyebilmek için. Arada bir lüks yapıp yemek de yemek istiyorum.

• İyi bir mülakat sürecinin bile, gerçekte işi çok iyi yapabilecek bazı adayları kesinlikle eleyeceğini düşünüyorum.
  Birinin o işe uygun olup olmadığını gerçekten anlamak için hem işverenin hem adayın mülakat sürecine ayırması gereken zaman çok büyük olur. İşveren açısından da kötü kaynak tahsisi, aday açısından da kabul edilmesi zor.
  İdeal olarak adayın ofise gelip bir gün boyunca tek başına küçük bir kodlama projesini tamamlaması güzel olurdu, ama gerçekçi olarak pratik değil.