CV Hazırlama

GitHub Profilini CV'nin Güçlü Bir Eki Haline Getirmek: Geliştiriciler İçin Profil README ve Pinned Repolardan ATS Uyumlu Bir Portföye Uzanan Rehber

CVANALIZ Editör Ekibi 9 dk okuma

Uzman incelemesi: Can Demir

CV'nin Sessiz Tanığı: GitHub Profili Ne Anlatır, Ne Anlatmaz?

Bir işe alım uzmanı elinize tutuşturulan CV'yi okurken gözleri otomatik olarak belirli satırlara kayar. İsim, e-posta, son pozisyon. Ama bir yazılımcı için bu satırların hemen altında. Çoğu zaman ayrı bir sekmede açılan başka bir sayfa vardır: GitHub profili. İşte o sayfa, CV'nin doğruluğunu sessizce sınayan. Yazılımcının yazdığını iddia ettiği kodla yazdığı kodu yüz yüze getiren sınırlı bir mahkeme salonudur.

Somut olarak, bu rehberde, GitHub profilinizi bir ek belge olmaktan çıkarıp CV'nin en güçlü yanını oluşturan bir portföye nasıl dönüştürebileceğinizi adım hamle ele alacağız. Burada yazılanların hiçbiri tek başına ATS'yi (Aday Takip Sistemleri) yenmenizi garanti etmez. Zira ATS, çoğunlukla GitHub profilinize girip kodunuzu okumaz. Ancak ATS'nin ötesine geçen, diğer bir ifadeyle CV'nizi fiilen okuyan. Pratikte, sizi bir aday olarak değerlendiren bir insan kaynakları uzmanı veya teknik mülakatçı için GitHub profili. CV'deki iddiaların somut karşılığıdır.

Cv hazırlama sürecinde pek çok geliştirici, GitHub profil URL'sini iletişim bilgilerinin arasına sıkıştırıp geçer. Bu, linki koymak anlamına gelir; ama linkin arkasındaki profili tasarlamak anlamına gelmez. Oysa mühendislik ekibi, profilinize girdiğinde:

  • Hangi dillerde aktif kod yazdığınızı
  • Commit sıklığınızla iddia ettiğiniz deneyimin tutarlı olup olmadığını
  • README yazma alışkanlığınız olup olmadığını
  • Açık kaynak projelere nasıl yaklaştığınızı
  • Forkladığınız depoların mı, sıfırdan kurduğunuz depoların mı ağırlıkta olduğunu

Birkaç saniyede okur. Şöyle ki, bu okuma, CV'nin kendisinden daha uzun sürer; zira CV'de nen bilgi, profilde genişletilir. Bir başka deyişle GitHub, CV'deki özetin devamını sunduğunuz yerdir.

Profil rEADME'si: kendinizi kodun içinden tanıttığınız mini CV

İşin aslı, gitHub'ın kullanıcıya özel profil README özelliği birkaç yıldır açık. Fakat hâlâ pek çok geliştirici bu alanı boş bırakıyor ya da birkaç emoji ile geçiştiriyor. Net konuşmak gerekirse, oysa profil README'si, sizinle ilgili ilk beş saniyelik izlenimi şekillendiren yerdir.

İyi hazırlanmış bir profil README'si şu katmanlardan oluşur:

  • Bir noktada, tek satırlık bir kimlik cümlesi: Ne iş yaptığınızı, hangi sektörde çalıştığınızı, neyle ilgilendiğinizi tek cümlede söyleyin. "Frontend geliştirici, erişilebilirlik ve performans konularına takıntılı" gibi.
  • Şu an ne yaptığınız: Üzerinde çalıştığınız bir proje, öğrendiğiniz bir teknoloji, katkıda bulunduğunuz bir açık kaynak çalışması.
  • Gerçekte, teknik yığınınız: Burada CV'nizdeki teknoloji yığınını kopyalamak yerine, o yığını nasıl kullandığınızı birkaç kelimeyle yin. "TypeScript ile tip güvenli API tasarımı, Postgres ile şema evrimi" gibi.
  • Sosyal kanallar: LinkedIn, blog, kişisel site, mail. Sadece ve düzenli.

Burada kayda değer olan nokta, README'nin bir CV kopyası olmaması gerektiğidir. Açıkçası, cv hazırlama ile GitHub profilini oluşturmak farklı metin türleridir. CV özet ve ölçülebilir; README kişisel ve somut olmalıdır. Gerçekte, birinde "Backend geliştirici, 4 yıl deneyim" yazarken, diğerinde "API sözleşmelerinin yaşam döngüsünü merak eden. Şu aralar distributed tracing öğrenen bir geliştirici" yazabilirsiniz.

README'de sıklıkla yapılan üç hata

  • Gerçekte, teknoloji rozeti seli: README'nin yarısını logosu olan renkli rozetler kaplıyorsa, gerçek bilgi kaybolur. Rozet bir süs değil, bilgi taşıyıcısıdır. Beş-altı rozet yeterlidir.
  • Bir noktada, son güncelleme tarihi olmayan bölümler: "Şu sıralar X öğreniyorum" yazıp iki yıldır güncellememişseniz. Bu sizi değil, ihmalinizi gösterir. Ya güncelleyin ya çıkarın.
  • Ölçülemez cümleler: "Çok sayıda projede görev aldım" gibi ifadeler CV'de zayıf, README'de daha da zayıftır. Bunun yerine projelerin somut çıktılarına yönlendirin.

Pinned repolar: vitrinin vitrini

Genelde, gitHub'da pinned olarak işaretlediğiniz altı depoya kadar alan, profilinize giren herkesin önce baktığı yerdir. Bu vitrin rastgele doldurulmaz. Buraya koyduğunuz her depo, "Bunları yaptım ve bunlarla gurur duyuyorum" anlamına gelir.

Pinned için hangi depolar seçilir?

Sahada, aşağıdaki üç kategoriden seçim yapın ve onları karışık yerleştirin:

  1. Pratikte, çalışan, canlı bir ürün: Sıfırdan kurduğunuz ve belirli bir kullanıcı kitlesine hitap eden bir uygulama. URL'si olan, açık kaynak olan veya en azından deploy edilmiş bir demo'su olan depolar burada güçlüdür.
  2. Teknik derinlik gösteren bir repo: Bir algoritma çalışması, bir tasarım deseni uygulaması, bir sistem tasarımı pratiği. Kodun kendisinin öğrettiği depolar.
  3. Sahada, cV'nin üzerine yazamadığı bir katkı: Açık kaynak bir projeye gönderdiğiniz anlamlı bir PR. Topluluk için hazırladığınız bir kaynak, boilerplate. Bu, ekip oyuncusu olduğunuzun somut kanıtıdır.

Başlıca olan, seçtiğiniz depoların CV'nizdeki projeler bölümüyle çelişmemesidir. Genelde, eğer CV'de en üst sırada "E-ticaret backend" varsa. GitHub'da pinned'lerde yalnızca kişisel oyun motoru varsa, bu uyumsuzluk cv analiz sürecinde not düşülmesine yol açar. Pinned'ler, CV'nin projeler bölümünün sayısal kanıtıdır; bu yüzden birbirini tamamlamalıdır.

Hangi depolar asla pinned olmamalı?

  • Yıllardır güncellenmemiş, "belki bir gün devam ederim" dediğiniz depolar
  • Fork'lar (kendi yazdığınız anlamlı bir PR yoksa)
  • README'siz, kullanım kılavuzu bulunmayan depolar
  • Genelde, sadece başlangıç şablonu olarak fork edilmiş bootcamp projeleri

Bunlar profilinizde bulunabilir ama öne çıkmamalıdır. Gerçekte, profilinizi bir portföy vitrini olarak düşünün: vitrinde yarım kalmış ürünler değil, satışa hazır ürünler yer alır.

Commit grafiği: sessiz ama konuşkan bir sinyal

Yeşil karelerle dolu bir katkı grafiği, geliştiricinin düzenli kod yazdığını gösterir. Ama bu sinyal tek başına değerlendirilmemelidir. Somut olarak, bir yazılımcının iş yerinde yoğun olduğu dönemler, kişisel katkılarını azaltabilir. Bu yüzden commit grafiği yorumlanırken bağlam önemlidir.

Boşlukları Yönetmek

Eğer uzun bir boşluk varsa ve bunun bir açıklaması varsa (askerlik. Çoğu durumda, eğitim, sağlık, iş değişimi), profil README'sinde veya bio alanında tek satırlık, kısa bir not düşebilirsiniz. Bu, işe alım uzmanının boşluğu yanlış yorumlamasını önler. İşin aslı, ancak her boşluğu açıklamak zorunda değilsiniz; sadece profilinizde hatalı bir hikâye anlatmamasını sağlayın.

Katkıyı Çeşitlendirmek

Sadece kişisel depolara değil, dış depolara katkı da grafiğe yansır. Eğer açık kaynak projelere PR gönderiyorsanız, bu bilgiyi profilinizde vurgulamak için GitHub'ın başarı rozetlerini kullanabilirsiniz. Pull Shark, Arctic Code Vault Contributors gibi sınırlı detaylar. Başta cv hazırlama aşamasında teknik görüşmeye çağrılma ihtimalinizi artıran ufak tetikleyicilerdir.

Depo İçi README ve Yapı: Her Repo Ufak Bir CV'dir

Profilinize giren biri, tek bir depoya tıkladığında o deponun README'si, klasör yapısı ve commit geçmişiyle karşılaşır. Sahada, bu küçük pencere, o geliştiricinin detaycılığını, iletişim becerisini ve mühendislik kültürünü okur.

İyi Bir Depo README'sinin Anatomisi

  • Projenin amacı: İlk iki cümlede ne olduğu, kimin için olduğu
  • Teknoloji yığını: Hangi dil, framework, veritabanı, deploy ortamı
  • Genelde, çalıştırma aşamaları: Klonlamadan ayağa kaldırmaya kadar olan net yol
  • Somut olarak, mimarinin kısa özeti: Klasör yapısının neden öyle olduğu, modüller arası sınırlar
  • Kısaca, varsa, öğrendiğiniz dersler: Bu kısmı pek çok kişi yazmaz; ama yazıldığında, geliştiricinin refleksif düşünme yeteneğini ortaya koyar

Depo yapısı da bir mesaj verir. Src/, tests/, docs/, scripts/ gibi standart klasörlemelere sahip bir proje, geliştiricinin klasör yapısını bilinçli kurduğunu ortaya koyar. Buna karşılık, ana dizine otuz dosya boşaltan bir repo. Genelde, "ben sadece kod yazıyorum, mimari düşünmüyorum" mesajını sessizce verir.

Commit mesajları: küçük ama belirleyici

"fix", "update", "wip" gibi mesajlarla dolu bir commit geçmişi. Kısa vadede işleri hızlandırır ama uzun vadede CV'nizin bir uzantısı olan GitHub profilinizi zayıflatır. Conventional commits kullanmasanız bile, "feat: kullanıcı oturum açma akışına rate limiting ekle" gibi mesajlar. Gerçekte, sizin hem yazılım pratiğinizi hem de iletişim kalitenizi yansıtır.

CV'de gitHub linki nereye, nasıl yerleştirilir?

GitHub URL'si, CV'nin üst kısmında iletişim bilgilerinin arasında yer alır. Ama linkin kendisi de bir tasarım kararıdır.

  • Genelde, kısa ve okunabilir URL: github.com/kullaniciadi formatını tercih edin. Yönlendirme servislerinden geçen linkler cv analiz sürecinde gereksiz gürültü yaratır.
  • Yanına sınırlı bir etiket: "GitHub: kod örnekleri" gibi bir açıklayıcı, linkin neden orada olduğunu belirtir.
  • Tek satır, tek link: GitHub dışında birden fazla portföy linki koymak (LinkedIn, kişisel site, Medium) CV'yi kalabalıklaştırır. Sadece en güçlü iki-üç link yeterlidir.

ATS bu linkleri çoğunlukla düz metin olarak okur. Bir noktada, diğer bir ifadeyle "buraya tıkla" tarzı buton görselleri, tıklanabilir ikonlar ATS için anlamsızdır. Düz metin URL, hem ATS hem de insan için en güvenli formattır.

GitHub profili ve CV analiz süreci: teknik mülakatçı ne görür?

Cv analiz süreci çoğunlukla iki aşamalıdır: ilk olarak insan kaynakları tarafından yapılan anahtar kelime eşleştirmesi. Ardından teknik mülakatçı tarafından yapılan derinlemesine değerlendirme. İkinci aşamada GitHub profili devreye girer.

Teknik mülakatçı, CV'nizdeki iddiaları GitHub'da arar. "React ile 3 yıl deneyim" yazıyorsanız, profilinizde React içeren depoların olup olmadığına. Bu depolardaki kodun kalitesine, hook kullanımına, performans pratiklerine bakılır. İşin aslı, "Takım liderliği" yazıyorsanız, açık kaynak projelere yaptığınız katkılar, PR'larınızın niteliği, issue'lara verdiğiniz yanıtlar incelenir.

Diğer bir ifadeyle GitHub profili, CV'deki her satırın altını doldurmanız gereken bir yerdir. İddia edemeyeceğiniz bir şeyi yazmanız, profilde hemen ortaya çıkar. Bir noktada, bu yüzden profili güzelleştirmekten çok, CV ile tutarlı bir hikâye anlatmasını sağlamak esastır.

Ücretsiz CV hazırlama araçlarıyla gitHub profilini birleştirmek

Pek çok geliştirici, cv hazırlama için ücretsiz şablonlar arar. Gerçekte, cv bedava olarak internette dolaşan çok sayıda ATS uyumlu CV şablonu vardır. Fakat hiçbir şablon, GitHub profilinizdeki boşlukları dolduramaz. Şablonu seçerken şu noktaya dikkat edin: şablon, GitHub ve LinkedIn gibi profillere açıkça yer versin. Zira şablon bu alanı yok sayıyorsa, siz de gözden kaçırırsınız.

GitHub profilinin cV'ye zarar verdiği durumlar

Her ne kadar çoğu yazı GitHub profilini parlatma üzerine olsa da. Profildeki bazı örüntüler CV'den daha hızlı elenmenize yol açar:

  • README'si olmayan depolar: "Kodunu anlatamayan geliştirici" izlenimi
  • Fork yoğunluğu: Fork'lar, kişisel çalışmanızın ağırlığını düşürür; her fork pinned edilmemeli
  • Boş depolarla dolu profil: "Başladım ama bitirmedim" mesajı
  • README'de elli rozet, sıfır bilgi: Tasarım bilinci var, içerik bilinci yok izlenimi
  • CV'de olmayan projeler: Profilde gözüken ama CV'de yer almayan depolar, tutarsızlık olarak değerlendirilir

Cv hazırlama sürecinde "neyi yazmalıyım" sorusu kadar "neyi yazmamalıyım" sorusu da fark yaratır. Açıkçası, gitHub profili için de aynı şey geçerlidir: yazmadığınız şey, yazdığınız şey kadar konuşur.

Net konuşmak gerekirse, sık yapılan beş pratik hata ve düzeltme önerileri

1. Profili bir kez kurup unutmak

GitHub profili, CV gibi yaşayan bir belgedir. Yeni öğrendiğiniz bir teknoloji, tamamladığınız bir proje, katkıda bulunduğunuz bir repo, profile yansıtılmalıdır. Bir noktada, yılda bir kez bile olsa gözden geçirmek yeterli olacaktır.

2. Pinned repoları alfabetik sıraya göre seçmek

Pratikte, alfabetik sıralama yerine, hikâye anlatacak bir sıralama tercih edin. En güçlü deponuz en başta olsun.

3. README'de kişisel bilgi paylaşmak

Pratikte, e-posta, telefon, fiziksel konum gibi bilgiler README'de yer almamalıdır. Bu bilgiler CV'de zaten vardır; profilde tekrar etmesi gereksizdir ve gizlilik riski taşır.

4. Profil fotoğrafını unutmak

GitHub, kullanıcı fotoğrafını zorunlu kılmaz. Ne var ki fotoğrafsız bir profil, CV'deki fotoğrafsızlıkla birleştiğinde kişiden ziyade "bir hesap" hissi verir. Tanınabilir, profesyonel bir profil fotoğrafı dahil edin.

5. Linkleri açıklama etiketleri olmadan sıralamak

"Site" yerine "Kişisel blog: dağıtık sistem notları" yazmak, linkin ne olduğunu önceden söyler ve tıklama ihtimalini güçlendirir.

Sonda Söylenecek: Profil, CV'nin Değil; CV, Profilin Kılavuzudur

GitHub profili ve CV arasındaki ilişki, tek yönlü değildir. CV, profili tanıtır; profil, CV'yi doğrular. Çoğu durumda, bu yüzden ikisini aynı hikâyeyi anlatacak şekilde inşa etmek gereklidir. Hikâyenin ne olduğu kayda değer değildir: backend uzmanı, frontend meraklısı, veri mühendisi, mobil geliştirici. Kayda değer olan, hikâyenin tutarlı olmasıdır.

Bir geliştiricinin CV'si, iddialarıyla dolu kısa bir metindir. Net konuşmak gerekirse, gitHub profili, o iddiaların kanıtlarının toplandığı bir portföydür. Bu iki belge birlikte okunduğunda. Mülakatçının zihninde "bu kişi iddia ettiklerini gerçekten yapıyor" cümlesi oluşuyorsa, iş o zaman kazanılır. Profilinizi tasarlarken her ekranı, her commit mesajını, her README satırını bu cümleyi kurmak için değerlendirin.

Yazılım kariyeri, çoğunlukla yazılı belgeler üzerinden şekillenir. Cv bedava araçlarla hazırlanmış, ATS uyumlu bir CV ile birlikte özenle inşa edilmiş bir GitHub profili. Sizi diğer adaylardan ayıran en sessiz ama en güçlü ikili olabilir. Üstelik bu ikiliyi kurmak için ciddi bütçelere ya da özel araçlara gerek yoktur: birkaç saatlik dikkatli bir düzenleme ve düzenli güncelleme yeterli olacaktır.

ATS uyumlu CV'ni dakikalar içinde hazırla.

Ücretsiz Başla
İçindekiler