IT Şirketleri İçin Uzaktan Çalışan İşe Alım Kontrol Listesi (2026) [+ Ücretsiz Şablon]

Çoğu uzaktan işe alım kontrol listesi, genel insan kaynakları uzmanları için yazılır. Ekipman gönderimi, hoş geldin e-postaları ve yan haklara kayıt gibi konuları kapsar, orada biter. Geliştirme ortamının kurulumu, doğru repo erişiminin verilmesi veya yeni bir mühendisin beşinci güne kadar ilk PR'ına ulaşması hakkında tek bir kelime yoktur.

Bu uzaktan çalışan işe alım kontrol listesi farklıdır. Özellikle IT şirketleri için hazırlandı: yazılım evleri, ürün ekipleri ve uzaktan çalışan mühendisleri işe alan, dağıtık mühendislik organizasyonları. İşe alımın gerçekten işlemesi gereken yerler için. Fazlı bir kontrol listesi (işe başlamadan önceki hazırlıktan ilk aya kadar), rol bazlı sorumluluk tablosu, yazılım mühendisliği yöneticilerinin yaptığı yaygın hatalar ve takip etmeye değer metrikler bulacaksınız. Sonunda ücretsiz bir PDF ve Notion şablonu da var. Pratikte işleyen bir süreç arıyorsanız, doğru yerdesiniz.

Şu anda uzaktan geliştirici işe alıyorsanız, uzaktan geliştirici işe alımını otomatikleştirme rehberi belge otomasyonu kısmını daha detaylı ele alıyor — bu makale ise insan sürecine odaklanıyor.

40 kişilik bir yazılım şirketinde uzaktan işe alım, bir perakende zincirindeki uzaktan işe alımla aynı değildir. Farklar önemlidir.

Erişim sağlama bir güvenlik olayıdır. Yeni bir geliştirici, ilk günden önce GitHub veya GitLab erişimi, AWS veya GCP kimlik bilgileri, VPN yapılandırması, SSO kurulumu ve bir parola yöneticisi daveti gerekir. Bunu yanlış yapmak, mühendisin 48 saat boyunca boşta oturması anlamına gelir; IT destek talepleri birikirken veya daha da kötüsü, henüz dokunmaması gereken üretim ortamlarına aşırı yetkilendirilmiş erişim alır.

Evrak paketi farklıdır. Genel işe alım, istihdam sözleşmeleri ve vergi formlarına odaklanır. IT şirketleri genellikle bir yazılım şirketleri için taşeron NDA, bir geliştiriciler için fikri mülkiyet devri anlaşması ve bazen ayrı bir yazılım geliştirme anlaşması gerektirir, özellikle taşeronlar için. Bu belgeler kodunuzun ve fikri varlıklarınızın güvenliğini ilk günden sağlar.

Kültür öncelikli olarak asenkron. GitLab Remote Playbook'a göre, yüksek performanslı uzaktan mühendislik ekipleri yazılı iletişime, aşırı dokümantasyona ve yapılandırılmış asenkron ritüellere varsayılan olarak başvurur. Asenkron normlarınızı anlamayan yeni bir mühendis, ya insanları fazla Slack'ler ya da sessizleşir — ikisi de kötüdür.

İlk üretken katkı ölçülebilir. İlk commite kadar geçen süre ve ilk PR'a kadar geçen süre, genel HR işe alım rehberlerinin hiç bahsetmediği somut metriklerdir. Bunlar, "çalışan ilk günün ardından nasıl hissetti" değil, birincil başarı göstergeleriniz olmalıdır.

Dürüst olalım: çoğu genel amaçlı kontrol listesi, IT işe alımını yeni bir muhasebe ödemeleri koordinatörü karşılıyormuş gibi ele alır. Geliştiriciye özgü boşluklar, bu makalenin var olma nedenidir.

Kontrol listesi dört aşamada düzenlenmiştir. Her aşamanın net bir sahibi vardır (IK, IT veya işe alım yöneticisi). Tecrübe gösteriyor ki, ön hazırlığı atlayan ekipler ilk hafta pişman oluyor. Sırayla ilerleyin. Ön hazırlık görevlerini atlayarak "zaman kazanmaya" çalışmak, neredeyse her zaman ilk hafta sorun yaratır.

İşe Başlamadan Önce (Ön Hazırlık)

Bu aşama, teklifin kabul edildiği anda başlar, ilk gün değil.

Evrak paketi (IK sorumlusu, teklif kabulünden sonra 48 saat içinde tamamlanmalı):

• İstihdam sözleşmesi veya taşeron sözleşmesi imzalanmış ve karşı imzalanmış
• IT şirketleri için belge yönetimi üzerinden NDA imzalandı. Blockchain ile doğrulanmış denetim izi, belgenin doğruluğunu kanıtlar
• Fikri mülkiyet devri anlaşması imzalandı; bu sayede kodunuzun mülkiyeti ilk günden netleşir
• Vergi belgeleri tamamlandı (ABD taşeronları için W-9, yargı alanınıza uygun formlar)
• Geçmiş kontrolü veya referans doğrulaması tamamlandı
• Yan hak kayıt materyalleri gönderildi (tam zamanlı çalışan ise)

Bir sözleşme ile basit bir anlaşma arasındaki farktan emin değil misiniz? Sözleşme vs anlaşma rehberi, her birinin ne zaman uygun olduğunu açıklar.

IT erişim sağlama (IT sorumlusu, işe başlamadan 2–3 iş günü önce tamamlanmalı):

• Kurumsal e-posta ve SSO hesabı oluşturuldu
• Parola yöneticisi daveti gönderildi (1Password, Bitwarden veya eşdeğeri)
• VPN kimlik bilgileri yapılandırıldı — NIST SP 800-46, tüm uzaktan erişimde MFA önerir
• GitHub veya GitLab hesabı, en düşük ayrıcalıkla sağlandı (yalnızca belirli repolar, organizasyon geneli değil)
• Bulut kimlik bilgileri, doğru IAM rolüyle kuruldu (ilk gün üretim erişimi yok)
• Donanım gönderildi ve teslimat onaylandı (dizüstü bilgisayar, monitör, çevre birimleri)
• İletişim araçları kuruldu: Slack veya Teams, Zoom, Loom
• Proje yönetimi aracı erişimi: Jira, Linear veya eşdeğeri

Yönetici tarafından önceden okunacaklar (işe başlamadan 3–5 gün önce):

• Mimari genel bakış dokümanı veya README paylaşıldı
• Mühendislik wiki'si veya Confluence alanı erişimi verildi
• Ekip çalışma normları belgesi (asenkron saatler, PR inceleme beklentileri, toplantı sıklığı)
• 30-60-90 günlük plan dokümanı önceden paylaşıldı, böylece yeni çalışan ilk gün önce okuyabilir
• Arkadaş (buddy) atandı ve tanışma e-postası gönderildi

1. Gün — İlk İzlenim Önemlidir

İlk gün, yoğun bilgi yüklemesi yapmak için değil, güven inşa etmek içindir.

• Hoş geldin görüntülü görüşmesi: yönetici + yakın ekip (30 dakikanın altında tutun — insanlar gergin olur)
• Yönetici 1:1'i: 30-60-90 planı açıkça gözden geçirildi. Okuduğunu varsaymayın.
• IT kontrolü: tüm hesaplar çalışıyor, VPN bağlanıyor, geliştirme araçları kurulu
• Geliştirme ortamı kurulum seansı: yeni çalışanı, ortam kurulumu için kıdemli bir mühendisle eşleştirin (Docker, yerel geliştirme, IDE yapılandırması). Doküman gönderip ummak yetmez.
• İlk görev atandı: 1–2 günde tamamlanabilecek, küçük ve net kapsamlı bir sorun seçin, "iyi bir ilk sorun" veya eşdeğeri olarak etiketlenmiş.
• Kod inceleme süreci açıklandı: dal stratejisi, commit mesajı kuralları, PR şablonu
• Güvenlik eğitimi tamamlandı: kimlik avı farkındalığı, veri işleme politikası, kabul edilebilir kullanım politikası

1. Hafta — Hızlanma

• Teknoloji yığını derinlemesine inceleme: gün 1–2 iletişim araçlarına odaklanın, gün 3–4 ana kod tabanı oryantasyonuna
• İlk kod incelemesi: yeni çalışan, kendi kodunu yazmadan önce mevcut bir PR'ı inceler — bu, işe alım aracı olarak yeterince kullanılmayan bir yöntemdir
• Çiftli programlama seansı: ilk görev üzerinde kıdemli bir mühendisle en az 2 saat
• Teknik liderle 1:1: mimari kararlar, teknik yol haritası, mevcut sprint öncelikleri
• Sosyal temas noktaları: 2–3 ekip üyesiyle gayri resmi kahve sohbeti (bunları planlayın — uzaktan ekiplerde doğal olarak gerçekleşmezler)
• Hafta sonu yönetici kontrolü: ne belirsiz, ne engellenmiş, ne iyi gidiyor

İlk Ay — İşe Alımdan Üretkenliğe

• İlk PR, ilk 5–7 iş günü içinde birleştirildi. Bu bir görev değil, bir dönüm noktasıdır.
• 30 günlük yönetici değerlendirmesi: plana göre performans, erişim ihtiyaçları ayarlandı, kültür soruları yanıtlandı
• Erişim denetimi: kurulum sırasında verilen geçici veya aşırı yetkilendirilmiş erişimler kaldırıldı
• Dokümantasyon katkısı: yeni çalışan, kendi başına çözmek zorunda kaldığı bir şeyi dokümante eder (yinelenen bir işe alım borcu ödeme alışkanlığı)
• Kültür kontrolü: asenkron iletişim doğal mı hissediliyor? Doğru yinelenen toplantılara katılıyorlar mı?
• Gelişim planı başlatıldı: 2–3. aylarda geliştirilecek yetkinlikler, mentorluk yapısı onaylandı

IT Çalışanları İçin 30-60-90 Günlük Plan

30-60-90 günlük plan, yeni çalışanlara belirsiz adapte olma beklentileri yerine net hedefler sunar. Somut tutun.

Gün 1–30 (Öğren): Kod tabanını anla, 2–3 küçük görevi tamamla, güvenlik eğitimini bitir, ekibin asenkron normlarını öğren. Başarı = ilk PR birleştirildi ve erişim denetimi temiz.

Gün 31–60 (Katkı): Orta karmaşıklıkta bir özelliği baştan sona sahiplen, kod incelemelerine aktif katıl, süreç iyileştirmesi için bir alan belirle. Başarı = özellik hazırlık ortamına (staging) gönderildi.

Gün 61–90 (Liderlik): Küçük bir proje veya sprint yönet, bir süreç veya araç iyileştirmesi öner, kıdemli ise mentorluk yapmaya başla. Başarı = sprint hızına ölçülebilir katkı.

En yaygın işe alım başarısızlığı, eksik bir kontrol listesi öğesi değil, herkesin bir başkasının üstlendiğini varsaymasıdır. Bu tablo, sahipliği açık hale getirir. Bir şeyin iki sahibi varsa, aslında hiçbirinin değildir.

Bu hatalar, bunun dışında iyi işleyen mühendislik ekiplerinde tekrar tekrar ortaya çıkar. Bunu yaşayan bilir. Çoğu, tek bir süreç değişikliğiyle düzeltilebilir.

1. Erişim sağlamayı ilk güne ertelemek. Hesapları mühendisin ilk sabahına kadar oluşturmayı beklemek, ilk günün yarısının IT destek taleplerini izlemekle geçmesi anlamına gelir. VPN, GitHub ve SSO, işe başlama tarihinden 48 saat önce hazır olmalıdır. Bunu yapmak, en yüksek getiri sağlayan şeydir.

2. "Yardımcı olmak için" aşırı yetkilendirme. Yeni bir mühendise GitHub'ta tam organizasyon erişimi veya AWS'de yönetici hakları vermek, iyi niyetli bir hatadır. Güvenlik açığı yaratır ve ironik bir şekilde, doğru şeyleri bulmalarını zorlaştırır. Belgelendirilmiş bir yükseltme yoluyla en düşük ayrıcalık erişimi, herkes için daha iyidir. NIST SP 800-63, ilk günden itibaren rol tabanlı erişim kontrolü önerir.

3. Çalışma başlamadan evrak paketini atlamak. Fikri mülkiyet devri anlaşması imzalanmadan önce bir geliştiricinin kod yazmasını istemezsiniz. Bu paranoya değil — gerçek bir fikri mülkiyet sahipliği riskidir. Evrak paketini (NDA, fikri mülkiyet devri, istihdam veya taşeron sözleşmesi), ilk commit'ten önce halledin, sonra değil. Tümünü IT ekipleri için geliştirilmiş e-imza ve sözleşme yönetimi ile dijital olarak işleyebilirsiniz.

4. Oturum olmadan dokümantasyon göndermek. "İşte 80 sayfalık wiki'miz" işe alım değildir. Yeni bir mühendise 45 dakika boyunca mimariyi anlattıktan sonra onları dokümanlara yönlendirmek işe yarar. Asenkron dokümantasyon referans içindir — senkron oryantasyonun yerini tutamaz.

5. İlk PR dönüm noktası yok. Birleştirilen ilk PR, uzaktan işe alımda psikolojik bir dönüm noktasıdır. Yedinci güne kadar hiçbir şey teslim etmemiş mühendisler, kendilerini ekip üyesi yerine misafir gibi hisseder. Planın içine açıkça yerleştirin: iyi kapsamlı bir görev, bir çiftli programlama seansı, zamanında bir kod incelemesi.

6. 30. günde erişim denetimini atlamak. Geçici erişim izinleri birikir. Yeni mühendis, belirli bir görev için geçici yönetici hakları alır ve kimse bunu kaldırmaz. 30. günde ve tekrar 90. günde resmi bir erişim denetimi yapın. 20 dakika sürer ve gerçek bir güvenlik boşluğunu kapatır.

SHRM araştırmasına göre, yapılandırılmış işe alım programlarına sahip organizasyonlar, yeni çalışanların tutundurulmasında %50 daha fazla başarı sağlar. IT sektöründe bu tutundurma boşluğu daha da pahalıdır — orta seviye bir mühendisi değiştirmek, yıllık maaşının %50-200'üne mal olur.

Çoğu şirket, işe alım başarısını 30 günlük memnuniyet anketiyle ölçer. Bu hiç yoktan iyidir ama yeterli değildir. Rakamlar acımasızdır ama dürüsttür. İşe alımın gerçekten işe yarayıp yaramadığını söyleyen metrikler şunlardır.

İlk commite kadar geçen süre. İşe başlama tarihinden ilk kod commite kadar kaç takvim günü geçer? Deneyimli mühendisler için bu, 2–3 gün olmalıdır. Daha uzunsa, geliştirme ortamı kurulum süreciniz bozuktur.

İlk PR'a kadar geçen süre. İlk pull request'in gönderilip birleştirilmesi ne kadar sürer? Hedef: 5–7 iş günü. Onuncu güne kadar hiçbir şey teslim etmemiş mühendisler, genellikle kendilerini kopuk ve verimsiz hissettiklerini bildirir.

30 günlük tutundurma oranı. Yeni çalışanların yüzde kaçı 30. günde hala şirkette? Erken ayrılma oranı, teknoloji sektöründe genellikle bir işe alım başarısızlığıdır, işe alım başarısızlığı değil. Bunu kohort bazında takip edin.

Erişim denetimi temizlik oranı. 30 günlük erişim denetiminde, hesapların yüzde kaçında aşırı yetkilendirilmiş izin yoktur? Bu hem bir güvenlik metriği hem de işe alım kalite metriğidir — aşırı yetkilendirme, sağlamanın dikkatli yapılmadığı anlamına gelir.

Eğitim tamamlama oranı. Yeni çalışan, ikinci hafta sonuna kadar güvenlik farkındalığı eğitimini, kod inceleme süreci eğitimini ve gerekli uyumluluk eğitimlerini tamamladı mı? Tamamlanmamış eğitim risk yaratır ve bir süreç boşluğuna işaret eder.

Yönetici tarafından bildirilen üretkenlik. 30 günlük değerlendirmede yapılandırılmış bir soru: "1–5 ölçeğinde, bu kişi beklentilere göre ne kadar üretken?" Bunu tüm işe alımlar arasında toplayarak sistemik işe alım sorunlarını tespit edin.

Buffer Uzaktan Çalışma Raporu, ekipten kopuk hissetmenin uzaktan çalışanlar için en büyük zorluk olduğunu tutarlı bir şekilde gösteriyor. Bu metrikler, bunun istifa haline gelmeden önce erken yakalamanıza yardımcı olur.

Özel bir işe alım ürününe ihtiyacınız yok. Çoğu IT şirketinin zaten ihtiyacı olan her şeyi var. Boşluk genellikle süreçtedir, araçlarda değil. Yine de, yığının şunları kapsaması gerekir.

Kimlik ve erişim yönetimi. SSO için Okta, JumpCloud veya Google Workspace. SSO kullanmayan kimlik bilgileri için parola yöneticisi (1Password Teams, Bitwarden Business). Her şeyde MFA — yönetici hesapları için donanım token'ları, standart erişim için doğrulayıcı uygulamalar.

İletişim. Asenkron mesajlaşma için Slack veya Microsoft Teams. Senkron görüntülü görüşme için Zoom veya Google Meet. Asenkron görüntülü turlar için Loom (mimari oryantasyonları için kullanışlıdır — bir kez kaydedin, her yeni çalışan için yeniden kullanın).

Proje yönetimi ve dokümantasyon. Sprint çalışmaları için Jira veya Linear, dokümantasyon için Confluence veya Notion. Mühendislik wiki'si, muhtemelen çoğu ekibin işe alımda en az yatırım yaptığı varlıktır.

Geliştirme ortamı. Tekrarlanabilir yerel ortamlar için Docker. Gerçekten çalışan belgelenmiş bir kurulum betiği (üç ayda bir temiz bir makinede test edin). Sürüm kontrolü için GitHub veya GitLab, yeni çalışanın ilk PR'ından önce dal koruması kuralları ayarlanmış.

Belge imzalama ve sözleşmeler. Burası, birçok IT şirketinin hâlâ e-postaya eklenmiş PDF'leri kullanıp en iyisini umduğu yerdir. NDA imzalama, fikri mülkiyet devri anlaşmaları ve istihdam sözleşmeleri için, IT ekipleri için geliştirilmiş e-imza ve sözleşme yönetimi isteyin. Zaman damgalı kayıtlar ve değiştirilemez denetim izleri ve tam bir evrak paketini üç ayrı e-posta zinciri yerine tek bir iş akışında gönderme yeteneği ile.

Amaç araç eklemek değil. Yığınızdaki her aracın net bir sahibi olduğundan ve yeni çalışanın ilk gününden önce kurulduğundan emin olmaktır.