Gerçekten Okunan Bir Mühendis Özgeçmişi Hazırlamak İçin 5 İpucu
İşe alım evreninde hafif trajik bir olgu var: Parlak mühendislerin PDF belgeleri tarafından hayaletlenmesi.
Dağıtık sistem tasarlayamadıkları, yarış durumlarıyla boğuşamadıkları ya da kayan noktalı aritmetiğin bazen neden ele geçirilmiş gibi davrandığını açıklayamadıkları için değil—özgeçmişleri bir sinyal yerine bir RAM dökümü gibi göründüğü için.
İşe alım yöneticileri, zaman baskısı altında desen eşleştiren makinelerdir. Özgeçmişiniz bir hayat hikâyesinden çok, çok sabırsız bir kullanıcı için dikkatle inşa edilmiş bir arayüzdür. Bir API gibi ele alın: öngörülebilir, okunabilir, yan etkileri minimum.
Aşağıdaki beş ipucu, özgeçmişleri “hmm” yığınından “hadi konuşalım” yığınına taşımada düzenli olarak işe yarar.
1. Sorumluluk Odaklı Değil, Sonuç Odaklı Yazın
Birçok mühendis özgeçmişi, birinin yapması gerekeni anlatır; gerçekte dünyada neyi değiştirdiğini değil.
Şu:
Ödeme sistemi için backend servislerinin bakımından sorumluydu.
İş tanımınızın bir İK portalından kopyala-yapıştır yapıldığı izlenimini verir.
Onun yerine, orada olmanız sayesinde ne olduğuna odaklanın:
Async iş kuyrukları ekleyip veritabanı indeksleme stratejisini optimize ederek ödeme işleme gecikmesini %37 azalttı.
Artık nedensellik var. Etki var. Evrende ölçülebilir bir şey değişmiş.
Mühendislik, iş problemleri için uygulamalı fiziktir. Hiçbir metrik oynamadıysa—gecikme, erişilebilirlik, maliyet, throughput, hata oranı—işe alım açısından sistem durumu aynı kalmıştır.
Recruiter’lar çabayı işe almaz. Farkı (delta) işe alırlar.
2. Tech Stack’inizi Kişilik Özelliği Değil, Araç Olarak Gösterin
Şunu yazan bir özgeçmiş:
JavaScript, Python, Docker, Kubernetes, Redis, AWS, Terraform, Kafka
Bağlam olmadan, temelde bir Pokémon koleksiyonu gibidir.
Araçlar, kararlarla ilişkilendirildiğinde anlam kazanır:
Ödeme yetkilendirmesini dolandırıcılık tespitinden ayırmak için Kafka ile event-driven bir mimari tasarladı; sistem bağımlılığını azaltıp deploy sıklığını haftalıktan günlük seviyeye çıkardı.
Şimdi stack’iniz mimariyi ve trade-off’ları anlatan bir hikâyeye dönüşüyor.
Temel fikir şu: teknolojiler, aslında gizli fiillerdir. Sistemde neden var olduklarını açıklayan cümlelerin içinde kullanın.
3. Karmaşıklığı Gösterin, Ama Sıkıştırın
Gerçek mühendislik işi dağınıktır. Legacy kısıtlar, deadline baskısı, belgelenmemiş ve kadim deniz canavarları gibi davranan sistemler.
Özgeçmişiniz karmaşıklığı kabul etmeli—ama onu yönetebildiğinizi gösterecek şekilde sıkıştırılmış bir biçimde.
Şunun yerine:
Microservices geçişi üzerinde çalıştı.
Şunu deneyin:
Monolitik sipariş sisteminin 12 mikroservise taşınmasına liderlik etti; yoğun trafikte (Black Friday) retry fırtınalarını yönetmek için circuit breaker’lar ve idempotent API’ler uyguladı; sistem erişilebilirliğini %99,1’den %99,95’e çıkardı.
Tek bir maddeyle şunları göstermiş oldunuz:
- mimari sahiplik
- dağıtık sistem farkındalığı
- güvenilirlik odağı
- gerçek dünya trafik kısıtları
Hepsi tek bullet point’te. Deneyim için kayıpsız sıkıştırma gibi.
4. Hızlı Okunabilirlik İçin Optimize Edin (Çünkü İnsanlar Üşengeç Memeliler)
Bir özgeçmiş, ilk bakışta genellikle 10 saniyeden kısa sürede taranır.
Bu şu anlama gelir:
- Madde işaretleri > paragraflar
- Sayılar > sıfatlar
- Boşluk > yoğun metin
- Etken fiiller > edilgen ifadeler
Karşılaştırın:
Sistem performansını önemli ölçüde iyileştirmeye dahil oldu.
Buna karşılık:
Sorgu cache’i ve connection pooling ekleyerek API yanıt süresini 420ms’den 110ms’ye düşürdü.
Biri bir “hissiyat”. Diğeri veri.
Yorgun bir beynin anlamlı sinyallere tutunmasını kolaylaştırın.
5. Özgeçmişinizi İşin Mühendislik Problemleriyle Hizalayın
Farklı şirketler farklı hata türlerine karşı optimize olur.
Bir fintech startup’ı tutarlılığa ve denetlenebilirliğe (auditability) çok önem verebilir.
Bir streaming platformu throughput ve gecikmeye odaklanabilir.
Bir SaaS ürünü multi-tenant ölçeklenebilirliğe önem verebilir.
Özgeçmişiniz statik olmamalı. Etkileşime gireceği sisteme—bir PID kontrolörü gibi—ayarlanmış olmalı.
Rol şunları vurguluyorsa:
- dağıtık sistemler → fault tolerance çalışmalarınızı öne çıkarın
- bulut maliyet optimizasyonu → altyapı verimliliğini öne çıkarın
- veri pipeline’ları → ETL, streaming, batch job’ları öne çıkarın
- geliştirici deneyimi → tooling veya CI/CD iyileştirmelerini öne çıkarın
Sadece yetkinliği değil, alakayı (relevance) da göstermiş olursunuz.
Ve mülakatı dönüştüren şey alakadır.
Son Düşünce
Bir mühendisin özgeçmişi tuhaf bir belgedir. Yılların debug’ını, tasarım trade-off’larını, production incident’larını ve zor kazanılmış sezgiyi bir-iki sayfaya sıkıştırmaya çalışır.
Kötü yapılırsa, bir listedir.
İyi yapılırsa, daha önce çözmüş olduğunuz problemlerinin bir haritasıdır—ve sıradakileri de çözebileceğinize dair sessiz bir vaattir.
Gürültüyle dolu bir evrende işiniz, sinyali görmezden gelinmesi imkânsız hâle getirmektir.
Burada bilgi teorisiyle eğlenceli bir paralellik var: En iyi özgeçmişler, anlamı kaybetmeden sinyal-gürültü oranını maksimize eder.