Ağ Mühendisi CV Şablonu: Topoloji Mantığından Otomasyona, Tasarım Düşüncesini Özgeçmişte Mühendislik Anlatısına Dönüştürme Rehberi

Ağ mühendisliği özgeçmişleri, çoğu zaman birbirinin kopyası gibi görünür: belirli üreticilerin cihazlarının madde işaretli listesi. Pratikte, kısaltmalardan oluşan bir protokol envanteri, "firewall deneyimi", "VPN kurulumu" gibi kalıplar. Ne var ki ağ ekipleriyle yıllardır çalışan herhangi birinin fark edeceği üzere. Bu tür CV'ler aslında adayın ne yaptığını değil, hangi kısaltmalara aşina olduğunu anlatır. Halbuki bir ağ mühendisinin gerçek değeri, komut ezberlemekten çok topolojiyi tasarlayabilmesi. Ölçeklenebilir kararlar alabilmesi ve karmaşık problemleri kök neden seviyesinde çözebilmesinde yatar. Bu rehber, ağ mühendisliği içinCv şablonuOluştururken bu ayrım üzerinden yeniden kurmayı hedefliyor: cihaz listesi değil, tasarım anlatısı; protokol bilgisi değil, mühendislik kararı.

Operatör ile Mühendis Aynı Kâğıda Sığmaz: Ağ Mühendisi CV'sinin Ayrıştırıcı Çizgisi

Önce ufak bir ayrım. Ağ yöneticisi (network administrator) ve ağ mühendisi (network engineer) kavramları özgeçmişlerde sıklıkla birbirinin yerine kullanılır. Ama sorumluluk alanları farklıdır. Yönetici rolü daha çok mevcut altyapının ayakta kalmasını, değişiklik taleplerinin uygulanmasını ve olay müdahalesini kapsar. Mühendis rolü ise topolojinin gelecekteki hâlini tasarlamak. Kapasite artışı kararlarını vermek, güncel bir segmentasyon stratejisini uygulamak ve çoğu zaman bu tasarımı otomasyonla desteklemekle ilgilenir. Bu fark, CV'ye yansımadığında, aday mühendislik pozisyonuna başvurduğunda "operasyon tecrübesi" etiketiyle değerlendirilir; bu da ya mülakata çağrılmamak ya da uygun seviyede pozisyona yerleştirilmemek anlamına gelebilir.

Dolayısıyla ağ mühendisi için CvŞablonu hazırlarken tek bir soru rehber olmalı: "Ben bu satırlarda bir topoloji tasarlayabilen kişiyi mi anlatıyorum. Yoksa sadece komut çalıştırabilen bir operatörü mü?" Yanıt birincisi ise, anlatı da ona göre kurulmalı.

Mühendislik Anlatısının Anatomisi: Bir Ağ Mühendisi CV'sinde Hangi Katmanlar Olmalı?

Klasik bir özgeçmişin isim-iletişim, özet, iş deneyimi, eğitim ve sertifikalar bölümleri ağ mühendisi için de geçerlidir. Ancak her birinin içeriği, mühendislik odağıyla yeniden yazılmalıdır.

Özet bölümü: "Ne yapıyorum" yerine "Hangi problemi çözüyorum"

Çoğu özgeçmişin açılış paragrafı şöyle başlar: "X yıldır ağ mühendisi olarak çalışan. BGP/OSPF bilgisine sahip, CCNP sertifikalı bir profesyonelim." Bu cümlenin teknik olarak isabetli olması, onu ayrım edilir kılmaz. Kısaca, işe alım uzmanının ya da teknik müdürün ilk on saniyede aradığı şey. Adayın hangi ölçekte ve hangi türde problemlerle uğraştığıdır. Özet bölümünde bunu şu şekilde ifade etmek daha etkilidir:

• Çalışılan ölçek: "12 lokasyonlu, 400'den fazla cihazdan oluşan kampüs ve veri merkezi ağı" gibi somut bir tanım.
• Bir noktada, çözülen problem türü: "Segmentasyon stratejisi yeniden tasarımı", "çoklu üretici ortamda MPLS geçişi", "SD-WAN dönüşümü" gibi.
• Mühendislik katkısı: "Tasarım kararlarının alınması, PoC süreçlerinin yürütülmesi, otomasyon altyapısının kurulması."

Bu üç unsur bir araya geldiğinde. Özet bölümü artık bir özellik listesi değil, bir konumlandırma cümlesi işlevi görür.

Yetkinlik bloğu: tasarım, uygulama, operasyon üçlüsü

Ağ mühendisinin yetkinlikleri tek bir "Skills" başlığı altında toplanmak yerine, üç ayrı kümede gruplanırsa daha okunabilir olur:

• Çoğu durumda, tasarım: Ağ topolojisi modelleme, segmentasyon stratejisi, IP planlama, kapasite modellemesi, çoklu üretici değerlendirmesi.
• Uygulama: BGP/OSPF/EIGRP/MPLS konfigürasyonları, VXLAN/EVPN fabric kurulumu, SD-WAN geçişleri, kablosuz denetleyici (WLC) yapılandırması, dokümantasyon.
• Operasyon ve otomasyon: Python/Netmiko/NAPALM, Ansible, Jinja2 şablonları, NETCONF/RESTCONF, NetBox/Git tabanlı değişiklik yönetimi, gözlemlenebilirlik.

Bu üçlü yapı, adayın hangi katmanda derinleştiğini net biçimde ortaya koyar.

Proje deneyimi: topolojiden karar gerekçesine

Proje anlatımında en sık yapılan hata, "Cisco ASR 9000 cihazlarını yapılandırdım" gibi bir cümle yazmaktır. Bu cümle, cihazı yapılandırılabilen herkes için geçerlidir. Mühendislik anlatısı ise karar gerekçesini içerir:

• Neden bu topoloji seçildi?
• Hangi alternatifler değerlendirildi, neden elendi?
• Ölçek, gecikme, yedeklilik kriterleri nasıl belirlendi?
• Ağın hangi metrikleri değişti?

Söz gelimi: "Üç veri merkezinden oluşan bir VXLAN/EVPN fabric tasarımı yürüttüm; segmentasyon ihtiyacı. Uç nokta sayısı ve operasyonel ekiplerin yetkinliği değerlendirilerek spine-leaf topolojisi tercih edildi. Şöyle ki, tasarım, PoC aşamasından üretime geçişe kadar üç fazda uygulandı." Bu cümle, mühendislik kararının izini sürer.

Sertifikalar ve sürekli öğrenme

Ağ mühendisliğinde sertifikalar tek başına yeterli değildir, fakat doğru kombinasyonla değer kazanır. Genelde, cCNA/CCNP/CCIE, JNCIA/JNCIS/JNCIE, Aruba, Fortinet, AWS Advanced Networking gibi sertifikalar, hangi üretici ekosistemiyle çalışıldığını kanıtlar. Kayda değer olan, sertifikalarınCv şablonuÇoğu durumda, içinde sadece madde işareti olarak sıralanmaması, hangi projede bu bilginin uygulandığının bir veya iki cümleyle belirtilmesidir.

Topoloji tasarımını cV'de anlatmak: cihaz listesinin ötesine geçmek

Ağ mühendisi CV'lerinin bir bölümü şöyle görünür: "Cisco Catalyst 9300. Cisco ASR 9000, Juniper MX, Arista 7280..." Bu liste, donanım bilgisini gösterir, ama mühendislik katkısını anlatmaz. Topoloji tasarımı deneyimini aktarmanın yolu, cihazları bir topoloji anlatısının parçası hâline getirmektir.

Mesela, "Beş şubeli kurumsal ağda, merkez-şube yedekliliği için çift ISP ve BGP multi-homing tasarımı uyguladım" cümlesi. Cihazlardan çok kararı ve amacı anlatır. Eğer bu tasarım sırasında tercih edilen yönlendirme protokolü. IP planlama yaklaşımı veya QoS politikası gibi detaylar eklenirse, mühendislik katkısı daha belirgin olur. Şöyle ki, yine, "bu topoloji hangi problemi çözdü, hangi riski azalttı" soruları bir cümleyle yanıtlanmalıdır.

Genelde, bGP, OSPF ve segmentasyon: routing kararlarını yetkinlik değil karar hikâyesi olarak yazmak

Routing bilgisi ağ mühendisliğinin temel taşıdır, ama özgeçmişlerde nasıl anlatıldığı ciddi ayrım yaratır. "BGP, OSPF, EIGRP bilgisi" ifadesi neredeyse hiçbir şey söylemez. Daha anlamlı bir anlatım, bu protokollerin hangi senaryolarda ve neden tercih edildiğini içerir:

• Çoklu ASN ortamında BGP route filtering ve prefix-list politikalarının uygulanması.
• OSPF area tasarımı ile broadcast domain kontrolü ve summarization stratejisi.
• VXLAN/EVPN fabric kurulumunda spine ve leaf katmanlarındaki karar mantığı.
• Çoklu lokasyon arasında MPLS VPN veya SD-WAN üzerinden segment izolasyonu sağlanması.

Bu cümleler, "bilgi" değil "uygulama ve karar" anlatır. Bir mühendisin portföyünde ne tür bir segmentasyon tasarımı yaptığı. Hangi ölçekte çalıştığı ve karar sürecinde hangi kriterleri kullandığı, protokol adlarından çok daha belirleyicidir.

İşin aslı, çoklu üretici ortamları (Cisco, juniper, arista, nokia) cV'de nasıl konumlanır?

Pek çok kurumsal ortam, tek üreticiyle sınırlı değildir. Kampüs tarafında bir üretici, veri merkezi tarafında başka bir üretici. WAN tarafında bir başkası, güvenlik katmanında ise değişik bir üretici çalışıyor olabilir. Bu durum, mühendisin hem teknik hem de entegrasyon açısından geniş bir yelpazeye hakim olduğunu gösterir. İşin aslı, cV'de bu çeşitliliği aktarmanın yolu, her üreticiyi ayrı ayrı listelemek yerine. "üreticiler arası tasarım kararlarını alabilen ve PoC süreçlerini yönetebilen" bir profil çizmektir.

Pratikte bu şöyle ifade edilebilir: "Cisco Catalyst ve Arista tabanlı hibrit kampüs/veri merkezi topolojisinde EVPN-VXLAN geçişini yönettim; üretici seçiminde yetkinlik. Pratikte, lisanslama modeli ve operasyonel ekiplerin kapasitesi belirleyici oldu." Bu cümle. Çoklu üretici ortamını, bir yetkinlik olarak değil, bir mühendislik kararı olarak sunar.

Ağ otomasyonu: python, ansible, nETCONF/RESTCONF becerisini stratejik yansıtmak

Bir noktada, ağ otomasyonu, son yıllarda ağ mühendisinin portföyünde en çok aranan yetenek alanlarından biri hâline geldi. Ne var ki özgeçmişlerde bu yetenek çoğu kez "Python bilgisi" veya "Ansible kullanımı" gibi tek satırlık ifadelerle geçiştiriliyor. Şöyle ki, mühendislik anlatısı, otomasyonun hangi amaca hizmet ettiğini açıkça ortaya koyar:

• Manuel konfigürasyon hatalarının azaltılması.
• Değişiklik yönetimi sürecinin Git tabanlı bir pipeline'a taşınması.
• Audit ve uyumluluk gereksinimlerinin otomatik doğrulanması.
• Yeni bir VLAN veya VRF talebinin self-servis bir süreçle sağlanması.

Bu türden somut kullanım senaryoları, otomasyon becerisini "Python biliyor" ifadesinden çok daha üst bir noktaya taşır. Bir cümleyle bile ifade edilebilir: "GitOps yaklaşımıyla ağ konfigürasyonlarını yönetilen bir CI/CD sürecine taşıdım; değişiklik süresi ve insan kaynaklı hata oranı belirgin biçimde düştü." Buradaki somutluk. Proje ölçeği ve sonuç yönüdür; uydurma rakam vermeden, sürecin varlığını anlatmak kâfidir.

İşin aslı, kablosuz ağ mühendisliği: WLC, RF planlaması ve site survey deneyimini yazmak

Kablosuz ağ tasarımı, kendi başına uzmanlık gerektiren bir alan. Pek çok kurumsal ortamda kampüs veya üretim alanlarında yüksek yoğunluklu Wi-Fi. Misafir ağı izolasyonu veya 802.1X tabanlı kimlik doğrulama çözümleri uygulanır. CV'de bu deneyim, yalnızca "Cisco WLC yapılandırdım" demek yerine, tasarım kararları üzerinden anlatılabilir:

• RF planlaması için kullanılan araçlar ve yaklaşım.
• İşin aslı, site survey sırasında dikkate alınan yoğunluk, bina yapısı ve kullanıcı profili.
• SSID segmentasyonu ve 802.1X ile entegre edilen kimlik doğrulama mimarisi.
• Roaming ve kapasite artışı kararlarının nasıl verildiği.

Sahada, bu detaylar, kablosuz tarafının "yan beceri" olarak değil, mühendislik disiplini olarak sunulmasını olanak tanır.

Kapasite planlaması ve trafik mühendisliği: somutluktan tasarım anlatısına

Kapasite planlaması, ağ mühendisinin önündeki en görünmez ama en kritik sorumluluklardan biridir. Bir noktada, bant genişliği, paket kaybı, gecikme ve jitter gibi metrikler, kullanıcı deneyimini doğrudan etkiler. CV'de bu alanın anlatımı genellikle "trafik artışı yönetimi" gibi muğlak ifadelere dayanır.

Daha etkili bir anlatım, aşağıdaki unsurları içerebilir:

• Mevcut ve gelecekteki kapasite ihtiyacının nasıl modellendiği.
• Trafik ölçümlerinin hangi araçlarla (sFlow, NetFlow, SNMP tabanlı izleme) toplandığı.
• Bant genişliği artışı veya QoS politikası değişikliği kararlarının hangi kriterlere göre alındığı.
• Planlama döngüsünün operasyonel ekiple nasıl entegre edildiği.

Burada başlıca olan, uydurma yüzde değerleri vermek değil, planlama sürecinin varlığını ve mühendislik bakış açısını göstermektir. Yönü ve kapsamı yazmak, sayısal iddia kadar etkili olabilir.

Gerçekte, bulut ağları (AWS VPC, azure vNet) ve hibrit bağlantılar

Açıkçası, modern ağ mühendisliği, artık yalnızca fiziksel topolojiyle sınırlı değil. AWS, Azure veya Google Cloud üzerindeki sanal ağ yapıları. Açıkçası, direct Connect veya ExpressRoute gibi özel bağlantı seçenekleri ve bulut-ağ arası trafik mühendisliği. Çok sayıda mühendisin günlük işinin parçası. CV'de bu alan şu şekilde konumlandırılabilir:

• İşin aslı, çoklu hesap veya abonelik yapısında ağ topolojisinin tasarlanması.
• Transit Gateway veya hub-and-spoke mimarisi kararlarının gerekçeleri.
• Kurum içi veri merkezi ile bulut arasında hibrit bağlantı stratejisinin uygulanması.
• Pratikte, bulut ağında segmentasyon ve güvenlik politikalarının kod tabanlı tanımlanması (Terraform gibi IaC araçlarıyla).

Bu deneyimler, adayın "sadece fiziksel ağ" değil, "uygulamanın çalıştığı her yerde ağ" düşüncesine sahip olduğunu gösterir.

Dokümantasyon kültürü: netBox, visio, çizim disiplini

Ağ mühendisliğinde dokümantasyon sıklıkla ya çok az ya da geçici çözümler şeklinde bulunur. Fakat ciddi ölçekteki ağlarda, NetBox gibi kaynak olarak tek gerçeklik (source of truth) sistemleri ve Visio/Lucidchart gibi görselleştirme araçları olmadan tasarım kararlarının izlenmesi neredeyse imkânsızlaşır. CV'de bu beceri, "NetBox kullanıyorum" demekten çok, dokümantasyon kültürünün kurulması veya sürdürülmesindeki rol olarak yazılabilir:

İşin aslı, "NetBox'u kaynak gerçeklik olarak kurarak tüm IP, VLAN ve cihaz envanterini tek bir noktadan yönettim. Topoloji çizimlerini düzenli olarak güncellenen bir mimari deposuna taşıdım."

Bu tür cümleler, mühendisin sadece bugünü değil, gelecekteki operasyonu da düşündüğünü gösterir.

ATS Uyumu: Ağ Mühendisi CV'sinde Anahtar Kelime Yoğunluğu ve Biçim

İster hazır bir Cv şablonuİndirilsin ister sıfırdan yazılsın. Hatırı sayılır şirketler ve İK ekipleri artık Aday Takip Sistemleri (ATS) üzerinden ön eleme yapıyor. Bu sistemler, belirli anahtar kelimeleri ve yapısal kalıpları arar. Pratikte, ağ mühendisi CV'sinin ATS uyumlu olması için şu noktalar gerekir:

• Genelde, iş unvanı bölümü, pozisyonun resmi adıyla uyumlu olmalı. "Network Engineer", "Network Architect", "Senior Network Engineer" gibi net ifadeler tercih edilmeli.
• Yetkinlik bölümünde, başvurulan pozisyonun ilanında geçen anahtar kelimeler doğal biçimde yer almalı: "BGP". "OSPF", "MPLS", "SD-WAN", "Cisco", "Juniper", "Python", "Ansible", "NetBox" gibi.
• Tablo, grafik, ikon veya çok karmaşık görsel düzen ATS tarafından okunamaz; bu nedenle düz metin veya basit başlık yapısı tercih edilmeli.
• Gerçekte, dosya formatı olarak PDF önerilir; ancak ATS'in bazı sürümleri PDF'te zorlanıyorsa. Düz metin içeren bir.docx alternatifi oluşturmak akıllıca olabilir.

Anahtar kelime, yapıyı boğacak düzeyde tekrarlanmamalı; ancak yetkinlik bölümünde doğal biçimde birkaç kez geçmesi yeterli olacaktır. Yapay bir "keyword stuffing" hem ATS hem de insan gözünde güven kaybettirir.

Sık yapılan hatalar ve son kontrol listesi

Bu rehberi kapatmadan önce, ağ mühendisi CV'lerinde sık karşılaşılan hataları mek faydalı olabilir:

• Cihaz modeli listesi ile doldurulmuş, karar anlatısı olmayan deneyim bölümleri.
• Net konuşmak gerekirse, "Routing bilgisi", "switching bilgisi" gibi her şeyi kapsayan ama hiçbir şey anlatmayan ifadeler.
• Otomasyon becerisinin tek bir kelimeyle (Python) geçiştirilmesi, hangi probleme uygulandığının yazılmaması.
• Somut olarak, sertifikaların madde işareti olarak sıralanması, hangi projeyle ilişkilendirildiğinin belirtilmemesi.
• Aslına bakılırsa, ölçek bilgisinin hiç verilmemesi (lokasyon sayısı, cihaz sayısı, kullanıcı sayısı gibi bağlam).
• Çok uzun, iki sayfayı aşan özgeçmişler; bu durumda mühendislik katkısı çok dağınık anlatılır.
• Görsel olarak aşırı süslü CvÇoğu durumda, tasarımları; ATS uyumunu bozabilir ve mühendislik mesleğinin ciddiyetine uygun düşmeyebilir.

Şöyle ki, ideal bir ağ mühendisi CV'si, bir cihaz envanteri değil, bir tasarım portföyüdür. Hangi ölçekte, hangi sorunları çözdüğünüzü, hangi kararları aldığınızı ve bu kararların sonuçlarını yazabiliyorsanız. Şöyle ki, özgeçmişiniz sizi tanımlayan bir doküman olmaktan çıkıp sizi savunan bir doküman hâline gelir. Teknik derinliğiniz sürekli bir hamle önde olabilir. Şöyle ki, ama o derinliği başkalarının görebileceği bir dile çevirmek de mühendisliğin kendisi kadar fark yaratır.