Web Yazılımcı ve Web Geliştirici Seçerken Teknik Mülakat ve Kod İnceleme Rehberi

Bir web yazılımcı veya web geliştirici seçerken yalnızca bildiği programlama dillerine, kullandığı framework’lere ya da portföyünün görünümüne bakmak yanıltıcı olabilir. Kurumsal web sitesi, müşteri veya bayi portalı, e-ticaret sistemi ya da ERP bağlantılı bir platform; kod yazmanın yanında iş kurallarını anlama, doğru veri modelini kurma, kullanıcı yetkilerini sınırlama, entegrasyon hatalarını yönetme ve sistemi işletilebilir biçimde teslim etme becerisi gerektirir.

Bu nedenle teknik değerlendirme, adayın ezber bilgisini ölçen bir soru-cevap oturumu olmamalıdır. Amaç; şirket içi geliştirici, freelancer veya yazılım ajansının gerçek bir ihtiyacı nasıl analiz ettiğini, kararlarını nasıl gerekçelendirdiğini ve ürettiği kodun sürdürülebilirliğini kanıtlarla görmektir. Aşağıdaki yaklaşım, insan kaynakları, BT, ürün, dijital dönüşüm ve satın alma ekiplerinin ortak bir değerlendirme zemini kurmasına yardımcı olur.

Teknik değerlendirmeden önce proje bağlamını netleştirin

İyi bir mülakat, doğru hazırlanmış kapsamla başlar. “React biliyor musunuz?” veya “Kaç yıldır PHP kullanıyorsunuz?” gibi sorular tek başına projenin başarısını öngörmez. Önce geliştirilecek ürünün kullanıcılarını, kritik işlemlerini, veri kaynaklarını, entegrasyonlarını ve işletim koşullarını tanımlayın. Örneğin bir bayi portalında bayi yöneticisi, satış temsilcisi ve finans kullanıcısı aynı veriyi farklı yetkilerle görebilir. ERP’den stok alınırken siparişin hangi sisteme ve hangi hata kurallarıyla yazılacağı da belirleyicidir.

Değerlendirmeye girecek herkese aynı kısa proje özeti verilmelidir. Özette hedef, kapsam, varsayımlar, bilinen sınırlar ve beklenen çıktı yer almalıdır. Henüz bu bilgiler yoksa önce bir web yazılım ihtiyaç dokümanı hazırlamak, adayları eşit koşullarda karşılaştırmayı kolaylaştırır. Kapsam belirsiz bırakıldığında en çok varsayım yapan aday değil, belirsizliği fark edip doğru soruları soran aday değerli sinyal üretir.

Web geliştirici seçimi için beş aşamalı değerlendirme süreci

Tek görüşmede hem iletişimi hem mimari düşünceyi hem de kod kalitesini ölçmeye çalışmak tutarsız sonuç doğurur. Bunun yerine her aşaması farklı bir kanıt üreten, adayın rolüne ve kıdemine göre derinliği ayarlanabilen bir süreç kullanın.

1. İş senaryosunu ve başarı ölçütünü paylaşın

Adaya gerçek projeyi bütünüyle açmak yerine anonimleştirilmiş, sınırlı bir senaryo verin. Örneğin “Kurumsal müşteriler ürün seçip teklif isteyecek; fiyatlar ERP’den gelecek; satış yöneticisi talepleri onaylayacak” ifadesi yeterli bir başlangıçtır. Beklenen çıktı bir çalışan ürün değil; sorular, temel akış, riskler ve çözüm yaklaşımı olabilir. Böylece adayın doğrudan teknoloji önermek yerine problemi çözümleyip çözümlemediği görülür.

2. Keşif sorularını değerlendirin

Güçlü aday; kullanıcı rolleri, veri sahipliği, işlem hacmi, kişisel veriler, hata durumları, mevcut altyapı ve yayın sorumluluğu hakkında sorular sorar. “Stok bilgisi ne kadar güncel olmalı?”, “ERP erişilemezse sipariş bekletilecek mi?” veya “Onay yetkisi tutara göre değişiyor mu?” gibi sorular, gerçek iş akışının düşünüldüğünü gösterir. Yalnızca kullanılacak framework’e odaklanmak ise kapsamın operasyonel tarafının gözden kaçabileceğine işaret eder.

3. Mimari yaklaşımı sözlü olarak sınayın

Adaydan kullanıcı arayüzü, uygulama katmanı, veri tabanı, entegrasyonlar ve dış servisler arasındaki ilişkiyi basitçe çizmesini isteyin. Ardından bir kararını değiştirecek koşulu sorun: İşlem hacmi on kat artarsa, ERP gecikirse veya yeni bir kullanıcı rolü eklenirse ne olur? Amaç belirli bir mimariyi ezberden duymak değil; adayın ödünleşimleri açıklayıp daha basit çözümle gereksiz karmaşıklığı ayırabilmesidir.

4. Sınırlı uygulamalı görev ve kod incelemesi yapın

Görev, işin küçük fakat temsili bir parçasını içermelidir. Bir rol bazlı erişim kontrolü, dış servisten veri alma, hata durumunu kaydetme ve birkaç test yazma; algoritma bulmacasından daha anlamlı olabilir. Kapsam iki ila dört saat içinde tamamlanabilecek kadar küçük tutulmalı, süre ve teslim beklentisi baştan açıklanmalıdır. Ücretsiz şekilde gerçek üretim işi yaptırılmamalıdır. Daha büyük çalışma gerekiyorsa ücretli pilot proje tercih edilmelidir.

5. Bulguları kanıtla puanlayıp referansla doğrulayın

Her değerlendirici görüşmeden önce tanımlanmış ölçütlere ayrı puan vermeli ve gözlemini yazmalıdır. “Kıdemli görünüyor” yerine “ERP kesintisi için kuyruk, tekrar deneme ve mutabakat yaklaşımını açıkladı” gibi kanıt kaydedin. Son aşamada referans görüşmesinde teslim disiplini, inceleme geri bildirimlerine yaklaşım, canlı sorunlara müdahale ve teknik devir sorulmalıdır. Böylece görüşme performansı geçmiş çalışma davranışıyla karşılaştırılır.

Teknik mülakatta hangi yetkinlikler ölçülmeli?

Soru havuzu, işin risklerine göre kurulmalıdır. Kurumsal bir tanıtım sitesi için içerik yönetimi, performans ve erişilebilirlik öne çıkarken; müşteri portalında yetkilendirme, işlem kayıtları ve entegrasyon dayanıklılığı daha ağır basar. Aşağıdaki başlıklar ortak bir çekirdek oluşturur.

İş gereksinimini teknik modele dönüştürme

Adaydan bir isteği kullanıcı hikâyesine, veri alanlarına, durumlara ve kabul ölçütlerine dönüştürmesini isteyin. “Bayi sipariş verebilsin” talebinde ürün uygunluğu, bayi fiyatı, kredi limiti, onay, iptal ve ERP aktarımı nasıl ele alınacak? İyi cevap kesin olmayan noktaları işaretler; iş kuralıyla teknik tercihi birbirinden ayırır ve ilk sürüm için makul sınır önerir.

Mimari ve veri tasarımı

Veri modelinin neden o şekilde kurulduğunu, modüllerin nasıl ayrıldığını ve bağımlılıkların nasıl yönetildiğini sorgulayın. Aday yalnızca ideal koşulu değil; veri taşıma, geriye uyumluluk ve büyüme senaryolarını da konuşabilmelidir. Projeye özel bir sistem değerlendiriyorsanız web yazılım geliştirme kapsamı; roller, veri akışları, entegrasyonlar, test ve işletim sorumluluklarıyla birlikte düşünülmelidir.

Güvenlik ve kişisel veri yaklaşımı

Kimlik doğrulama ile yetkilendirme arasındaki farkı, erişim kontrollerinin nerede uygulanacağını, gizli anahtarların nasıl saklanacağını ve girdilerin nasıl doğrulanacağını sorun. Adayın yalnızca araç adı vermesi yeterli değildir; örneğin bir bayinin başka bayiye ait siparişi URL’deki kimliği değiştirerek görmesini nasıl engelleyeceğini açıklaması gerekir. NIST Güvenli Yazılım Geliştirme Çerçevesi, güvenli geliştirme pratiklerinin yazılım yaşam döngüsüne ve tedarik süreçlerine dahil edilmesi için ortak bir çerçeve sunar.

Entegrasyon ve hata yönetimi

ERP, CRM, ödeme veya kargo servislerinde yalnızca başarılı akışı değil; zaman aşımı, yinelenen istek, kısmi başarı ve veri uyuşmazlığı durumlarını sorun. İyi bir yaklaşım idempotency, tekrar deneme sınırı, kuyruk, kayıt, alarm ve manuel düzeltme yolunu ihtiyaca göre ele alır. ERP bağlantılı projelerde kurumsal kaynak planlaması yalnızca API bağlantısı değil, sistemler arasındaki veri sahipliği ve mutabakat düzenidir.

Test, yayın ve işletim

Aday hangi davranışların birim, entegrasyon veya uçtan uca testlerle doğrulanacağını açıklayabilmelidir. Ayrıca yapılandırma yönetimi, test ortamı, veri tabanı geçişi, geri alma, loglama, izleme ve yedekleme konularını sorun. Kodun çalışması teslim için yeterli değildir; başka bir ekip tarafından yayınlanabilir, gözlemlenebilir ve bakım yapılabilir olması gerekir.

Uygulamalı teknik görev nasıl hazırlanmalı?

Görev gerçek rolü temsil etmeli, fakat adayın vaktini orantısız tüketmemelidir. Aynı rol için adaylara aynı brief, süre, başlangıç verisi ve değerlendirme ölçütleri verilmelidir. Kullanılacak kaynaklara izin verilip verilmediği ve yapay zekâ destekli araçların nasıl beyan edileceği açıkça belirtilmelidir. Araç kullanımını tamamen yasaklamak yerine adayın üretilen kodu açıklaması, doğrulaması ve sorumluluğunu üstlenmesi ölçülebilir.

Örnek görev; iki kullanıcı rolüne sahip küçük bir teklif talebi servisi olabilir. Adaydan veri modelini, iki API uç noktasını, yetki kontrolünü, doğrulama hatalarını ve kritik davranışlara ait testleri hazırlaması istenebilir. README dosyasında çalıştırma adımları, varsayımlar ve üretime çıkmadan önce yapılacaklar bulunmalıdır. Ön yüz geliştiricisi için aynı senaryoya erişilebilir form, yüklenme durumu, hata mesajı ve mobil davranış eklenebilir.

Değerlendirme; işlev doğruluğu, okunabilirlik, güvenlik, test yaklaşımı, hata yönetimi ve karar açıklığı üzerinden yapılmalıdır. Piksel ayrıntıları veya kişisel kod stili, rolün temel gereksinimi değilse sonucu belirlememelidir. Eksik kalan kısmı gizlemek yerine önceliklendirip açıklayan aday, kapsam ve zaman yönetimi açısından olumlu sinyal verebilir.

Kod incelemesinde aranacak kanıtlar

Kod inceleme, “kod güzel mi?” sorusuna indirgenmemelidir. Önce değişikliğin kullanıcı ihtiyacını doğru karşılayıp karşılamadığına, ardından tasarım, veri, güvenlik, test ve işletim etkilerine bakılmalıdır. Google’ın kod inceleme rehberi; tasarım, işlev, karmaşıklık, testler, adlandırma, yorumlar ve dokümantasyon gibi alanların birlikte değerlendirilmesini önerir.

Okunabilirlik ve sorumluluk sınırları

Fonksiyon ve sınıf adları amacı anlatıyor mu? İş kuralları denetleyici, arayüz veya veri erişim koduna dağılmış mı? Aynı mantık tekrar ediyor mu? Kod, gereksiz soyutlamalarla gelecekte oluşacağı varsayılan ihtiyaçlara göre karmaşıklaştırılmış mı? Adaydan belirli bir bölümü neden o şekilde tasarladığını anlatmasını ve bir alternatifin artı-eksilerini karşılaştırmasını isteyin.

Güvenlik kontrolleri

Girdi doğrulama, sunucu taraflı yetkilendirme, hassas verilerin loglanmaması, güvenli hata mesajları, bağımlılık kullanımı ve sır yönetimi incelenmelidir. Otomatik taramalar yararlı olsa da iş mantığı açığı veya yanlış yetki sınırı gibi bağlamsal sorunları tek başına yakalayamaz. OWASP Secure Code Review Cheat Sheet, manuel incelemenin veri akışı, yetkilendirme, iş mantığı ve güven sınırları üzerindeki rolünü açıklar.

Testlerin niteliği

Yalnızca test sayısına veya kapsama yüzdesine bakmayın. Test bozuk davranışta gerçekten başarısız oluyor mu, kritik iş kuralını doğruluyor mu ve dış servise gereksiz şekilde bağımlı mı? Başarılı akışın yanında yetkisiz erişim, geçersiz veri, zaman aşımı ve yinelenen istek gibi riskli durumların ele alınıp alınmadığını kontrol edin.

İşletilebilirlik ve teknik devir

Yapılandırmalar koddan ayrılmış mı, anlamlı loglar ve hata kimlikleri var mı, veri tabanı değişiklikleri geri alınabilir mi? Kurulum açıklaması, ortam gereksinimleri ve bilinen sınırlamalar belgelenmiş mi? Ajans veya freelancer seçiminde kaynak kod deposu, alan adı, sunucu, üçüncü taraf hesapları, lisanslar ve yayın yetkilerinin sahipliği de sözleşme öncesinde netleştirilmelidir.

Adayları ortak puan kartıyla karşılaştırın

Puan kartındaki ağırlıklar projeye göre değişmelidir. ERP entegrasyonlu bir portalda gereksinim analizi, veri güvenliği ve entegrasyon dayanıklılığına; içerik ağırlıklı kurumsal sitede erişilebilirlik, performans ve yönetilebilirliğe daha yüksek ağırlık verilebilir. Her ölçüt için 1–5 arası davranış tanımı oluşturun: Bir puan riski fark etmemeyi, üç puan uygulanabilir temel yaklaşımı, beş puan ise ödünleşimleri kanıtla açıklayıp işletim etkisini düşünmeyi temsil edebilir.

Kırmızı bayraklar da önceden tanımlanmalıdır: Sorunu anlamadan teknoloji dayatmak, yetkilendirmeyi yalnızca arayüzde yapmak, test ihtiyacını reddetmek, tüm erişimleri tek kişide toplamak, üretim verisini kontrolsüz kullanmak veya devir belgelerini gereksiz görmek bunlar arasındadır. Bununla birlikte tek bir sözdizimi hatası ya da farklı stil tercihi otomatik eleme sebebi olmamalıdır.

Şirket içi geliştirici, freelancer ve ajans aynı şekilde mi değerlendirilir?

Çekirdek teknik kalite ölçütleri aynı olsa da sorumluluğun kapsamı değişir. Şirket içi geliştiricide mevcut ekiple çalışma, kod tabanını uzun süre sahiplenme ve kurum bilgisini geliştirme önemlidir. Freelancer seçiminde erişilebilirlik, kapasite, yedekleme düzeni ve işi başka bir uzmana devredebilme koşulları ayrıca değerlendirilmelidir.

Yazılım ajansında ise görüşmeye katılan satış ekibiyle projeyi yürütecek gerçek ekibin aynı olup olmadığı sorulmalıdır. Analiz, UX, yazılım, test, DevOps ve proje yönetimi sorumluluklarının kimde olduğu; personel değişikliğinde sürekliliğin nasıl sağlanacağı açıklanmalıdır. Tek bir örnek kod kadar ajansın kod inceleme standardı, yayın süreci, güvenlik yaklaşımı ve teknik devir sistemi de incelenmelidir.

Seçim kararını sürdürülebilir teslimata bağlayın

En iyi web geliştirici, her soruya en hızlı cevap veren kişi değildir. İş problemini doğru sorularla açan, riskleri görünür kılan, yeterince basit bir çözüm kuran, güvenlik ve test sorumluluğunu geliştirme sürecine dahil eden aday daha güçlü bir seçim olabilir. Kararı teknoloji listesi, portföy estetiği veya düşük fiyat yerine; aynı senaryo, aynı ölçüt ve kayıtlı kanıt üzerinden verin.

Web projenizin iş akışlarını, kullanıcı rollerini, veri ve entegrasyon ihtiyaçlarını Kumsal Ajans ile değerlendirin. Kapsamı ve teknik beklentileri birlikte netleştirerek; kurumsal web sitesi, e-ticaret, müşteri veya bayi portalı ya da ERP bağlantılı platformunuz için sürdürülebilir bir geliştirme yol haritası oluşturun.