Adayları iş ilanlarına eşleştiren bir işe alım web uygulaması nasıl kurulur öğrenin. Temel özellikler, veri modeli, eşleştirme mantığı, UX, entegrasyonlar ve lansman ele alınıyor.
Ekran taslağı çizmeye veya teknoloji seçmeye başlamadan önce, işe alım web uygulamanızın hangi problemi kimin için çözdüğünü netleştirin. “Aday iş eşleştirme” basit bir anahtar kelime filtresinden, işe alımcının bir pozisyonu alım aşamasından yerleştirmeye taşımasına yardımcı olan rehberli bir iş akışına kadar her şey anlamına gelebilir.
Her gün giriş yapacak insanlardan başlayın. Ajanslar için bir uygulamada bunlar genellikle:
Yararlı bir egzersiz her kullanıcı için 2–3 “en önemli görev” yazmaktır. Bir görev bunları desteklemiyorsa, muhtemelen MVP dışıdır.
“Daha iyi eşleşmeler” gibi belirsiz hedeflerden kaçının. İş sonuçlarını ve manuel işi azaltan metrikleri seçin:
Bu metrikler daha sonra işe alım analizlerinizi bilgilendirir ve eşleştirme algoritmanızın sonuçları iyileştirip iyileştirmediğini doğrulamaya yardımcı olur.
İşe alım iş akışı eşleştirmenin ötesindedir. Aşamaları ve her adımda hangi verinin oluşturulduğunu belgeleyin:
Sourcing → Screening → Submitting → Interviewing → Offer → Placement
Her aşama için hangi “nesnelerin” (aday, iş, gönderim, mülakat) yer aldığını, temel eylemleri (arama kaydı, e-posta gönderme, mülakat planlama) ve karar noktalarını (reddet, ilerlet, beklet) not edin. ATS ve CRM özellikleri burada sıkça örtüşür—izleyeceğiniz şeyi kasıtlı seçin.
MVP'niz kullanılabilir bir döngü sunmalı: iş ilanı oluştur → aday ekle (manuel veya temel özgeçmiş ayrıştırma) → eşleştir → gözden geçir → gönder.
Yaygın v1 dahil olanlar:
Daha sonra eklenebilecek yaygın özellikler (ilk etapta iyi-to-have):
Kullanıcıları, metrikleri, iş akışını ve kapsamı önceden tanımlayarak projeyi “her şeyi yapan bir ATS” haline gelmekten korur ve yapıyı daha odaklı tutarsınız; bu da daha hızlı, daha güvenli kısa listeler üretir.
Bir işe alım web uygulaması veri modeline bağlıdır. Adaylar, işler ve etkileşimleri temiz yapılandırılmamışsa eşleştirme gürültülü olur, raporlama güvenilmez hale gelir ve ekip aracı kullanmak yerine onunla mücadele eder.
Başlangıç olarak hem doküman saklayan hem de aranabilir alanları destekleyen bir Aday varlığı oluşturun. Orijinal özgeçmişi/dosyayı saklayın (dosya + çıkarılan metin) ama ayrıca aday iş eşleştirmede ihtiyaç duyacağınız anahtar öznitelikleri normalize edin:
İpucu: "ham" verileri (pars edilmiş metin) ile işe alımcıların düzenleyebileceği "kürate" alanları ayırın. Bu, ayrıştırma hatalarının profilleri sessizce bozmasını önler.
Bir İş (requisition) varlığı oluşturun; tutarlı alanlar: başlık, kıdem seviyesi, zorunlu vs tercih edilen beceriler, konum/uzaktan politika, maaş aralığı, durum (taslak/açık/askıda/kapatıldı) ve işe alım sorumlusu bilgileri. Gereksinimleri puanlama yapacak kadar yapılandırılmış, ancak gerçek iş ilanları için yeterince esnek tutun.
Çoğu aktivite adaylar ile işler arasındadır, bu yüzden ilişkileri açıkça modelleyin:
Erken tanımlayın: ajans-geneli vs takım-özel adaylar, müşteri-spesifik görünürlük ve rol bazlı düzenleme hakları (recruiter, manager, admin). İzinleri her okuma/yazma yoluyla ilişkilendirerek gizli adayların veya gizli iş ilanlarının arama veya eşleştirme sonuçlarından sızmasını önleyin.
İşe alımcılar hızlı hareket eder: tarar, filtreler, karşılaştırır ve takip eder—çoğunlukla aralarındaki çağrılar arasında. UX'iniz bu “sonraki tıklamaları” belirgin ve ucuz hale getirmeli.
Dört ana sayfa artı bir eşleştirme görünümü ile başlayın:
İşe alımcılar arama çubuğunun bir komut çubuğu gibi davranmasını bekler. Global arama artı beceriler, konum, deneyim yılı, maaş, durum ve uygunluk için filtreler sağlayın. Çoklu seçim ve kaydedilmiş filtrelere izin verin (örn. “Londra Java 5+ yıl 80k altında”). Filtreleri görünür tutun ve hangi filtrelerin aktif olduğunu açıkça gösteren etiketler (chip) sağlayın.
Uzun listelerle çalışırken toplu işlemler saatler kazandırır. Aday listesi veya eşleştirme görünümünden şunları destekleyin: etiketleme, durum değiştirme, iş kısa listesine ekleme ve e-posta dışa aktarımı. Bir “geri al” toast'ı dahil edin ve onaylamadan önce kaç kaydın değişeceğini gösterin.
UI'yi klavye dostu yapın (odak durumları, mantıklı sekme sırası) ve okunabilirliği yüksek tutun (iyi kontrast, büyük dokunma hedefleri). Mobilde liste → detay akışını önceliklendirin, filtreleri slide-over panelde tutun ve kısa liste, e-posta, durum gibi ana eylemlerin baş parmakla ulaşılabilir olmasını sağlayın.
Eşleştirme, bir işe alım web uygulamasının motorudur: kimlerin önce görüneceğini, kimlerin gizleneceğini ve işe alımcıların neye güveneceğini belirler. İyi bir MVP basit başlar—önce net kurallar, sonra puanlama—ve gerçek işe alım sonuçlarından öğrendikçe nüans ekler.
Değerlendirmeye alınmadan önce doğru olması gereken zorunluluklarla başlayın. Bu kurallar sonuçları ilgili tutar ve “yüksek puanlı ama imkansız” eşleşmeleri önler.
Tipik geçitler arasında zorunlu beceriler/sertifikalar, konum veya çalışma izni kısıtlamaları ve maaş örtüşmesi bulunur (örn. aday beklentileri iş bütçesiyle kesişmeli).
Bir aday geçitleri geçtiğinde, eşleşmeleri sıralamak için bir skor hesaplayın. İlk sürümü şeffaf ve ayarlanabilir tutun.
Pratik bir puanlama karışımı:
Bunları zamanla ayarlanacak ağırlıklarla ifade edebilirsiniz:
score = 0.45*skill_match + 0.20*recency + 0.20*seniority_fit + 0.15*keyword_similarity
İş gereksinimlerini iki kovada modelleyin:
Bu, tercihlerin güçlü adayları dışlamasını önlerken daha iyi uyumları ödüllendirir.
İşe alımcılar bir adayın neden eşleştiğini—ve neden eşleşmediğini—bilmelidir. Eşleştirme kartında kısa bir döküm gösterin:
İyi açıklanabilirlik eşleştirmeyi kara kutudan bir araca dönüştürür; işe alımcılar bunu güvenle kullanıp işe alım yöneticilerine savunabilir.
Aday veri kalitesi “eşleştirme” ile “tahmin” arasındaki farktır. Profiller tutarsız formatlarda gelirse en iyi eşleştirme algoritması bile gürültülü sonuç üretir. Önce işe alımcılar ve adaylar için kolay giriş yolları tasarlayın, sonra ayrıştırma ve normalizasyonu kademeli iyileştirin.
Takımların tıkanmaması için birden fazla yol sunun:
Alanlarda bir “güven” göstergesi (örn. “parsed”, “user-entered”, “recruiter-verified”) tutun ki işe alımcılar hangi alanlara güveneceğini bilsin.
MVP'de mükemmel yapı yerine güvenilirliği önceliklendirin:
Her zaman işe alımcıların ayrıştırılmış alanları düzenlemesine izin verin ve yapılan değişikliklerin denetim izini tutun.
“JS”, “JavaScript” ve “Javascript”in aynı beceri olarak eşlenmesi eşleştirmeyi iyileştirir. Bir kontrollü sözlük kullanın:
Normalizasyonu kaydetme zamanında uygulayın (ve sözlük güncellendiğinde yeniden çalıştırın) ki arama ve eşleştirme tutarlı kalsın.
Yinelenen kayıtlar pipeline metriklerinizi gizlice zehirler. Potansiyel çoğaltmaları e-posta ve telefon (artı isteğe bağlı bulanık isim + şirket kontrolleri) ile tespit edin. Bir çakışma göründüğünde rehberli bir merge ekranı gösterin:
Bu, veri kaybı riski olmadan veritabanını temiz tutar.
Eşleştirme uygulaması içindeki işler ne kadar iyi yapılandırılmışsa o kadar iyi sonuç verir. Requisitionlar tutarsız, eksik veya güncellenmesi zor ise işe alımcılar sonuçlara güvenmeyi bırakır. Amacınız iş girişi hızlı, yapılandırılmış ve tekrarlanabilir yapmak—uzun formlara zorlamadan.
Recruiterlar genellikle işleri üç şekilde başlatır:
UI'de “İşi kopyala”yı iş listesinde birinci sınıf bir eylem olarak sunun, gizli bir seçenek olarak değil.
Serbest metin iş tanımları insanlar için kullanışlıdır, ancak eşleştirme yapı ister. Gereksinimleri tutarlı alanlarda yakalayın:
Bunu hafif tutun: bir işe alımcının becerileri saniyeler içinde ekleyebilmesi, sonra gerekirse detaylandırabilmesi gerekir. Bir ayrıştırma adımınız varsa, sadece alanları önermek için kullanın—otomatik kaydetmeyin.
Hiring pipeline'ı açık ve işe özel yapın. Basit bir varsayılan iyi çalışır:
New → Shortlisted → Submitted → Interview → Offer → Placed
Her aday-iş ilişkisi mevcut aşamayı, aşama geçmişini, sahibi ve notları saklamalı. Bu, işe alımcılar için ortak bir doğruluk kaynağı sağlar ve analitiklerinizi anlamlı kılar.
Şablonlar ajansların yaygın rolleri standartlaştırmasına yardımcı olur (örn. “Sales Development Rep” veya “Depo İşçisi”). Bir şablon aşamaları, eleme sorularını ve tipik must-have becerileri önyüklemeli—aynı zamanda müşteri bazında hızlı düzenlemelere izin vermeli.
Tutarlı bir akış istiyorsanız, iş oluşturmayı doğrudan eşleştirme ve kısa listelemeye yönlendirin; bu adımları farklı ekranlara yaymayın.
Güvenliği ilk sürüme entegre etmek en kolay yoldur. Bir işe alım web uygulaması için hedef basit: sadece doğru kişiler aday verilerine erişebilmeli ve her önemli değişiklik izlenebilir olmalı.
E-posta + şifre kimlik doğrulamasıyla başlayın; şifre sıfırlama ve e-posta doğrulama ekleyin. MVP için bile bazı pratik önlemler ekleyin:
Daha büyük ajanslar için Google Workspace veya Microsoft Entra ID gibi SSO (SAML/OIDC) yoluna gelecekte geçiş planlayın. SSO'yu ilk günde kurmak zorunda değilsiniz, ama eklemeyi zorlaştıracak seçimlerden kaçının.
En azından iki rol tanımlayın:
Eğer ürününüz opsiyonel bir müşteri/işe alım yöneticisi portalı içeriyorsa, bunu ayrı bir izin kümesi olarak ele alın. Müşteriler genellikle sınırlı erişime ihtiyaç duyar (örn. sadece kendilerine gönderilen adaylar, gizli kişisel detaylar sınırlı olacak şekilde).
İyi bir kural: varsayılan olarak en az erişimi verin ve izinleri kasıtlı ekleyin (örn. “adayları dışa aktarabilir”, “ücret alanlarını görebilir”, “kayıtları silebilir”).
İşe alım çok sayıda el değiştirme içerir; hafif bir denetim izi kafa karışıklığını önler ve iç güven oluşturur. Şu tür önemli eylemleri kaydedin:
Bu günlükleri uygulama içinde aranabilir tutun ve düzenlenemez hale getirin.
Özgeçmişler son derece hassastır. Bunları genel erişimli URL'ler yerine özel obje depolamada (S3 uyumlu) saklayın, imzalı/sona eren indirme bağlantıları gerektirin ve yüklemelere zararlı yazılım taraması uygulayın. Erişimi role göre kısıtlayın ve ekleri e-posta ile göndermek yerine güvenli uygulama içi bağlantılar kullanın.
Son olarak, verileri iletimde (HTTPS) ve mümkünse dinamik olarak şifreleyin ve yeni çalışma alanları için güvenli varsayılanları zorunlu kılın.
İşe alım uygulamaları son derece hassas verilerle çalışır—CV'ler, iletişim bilgileri, ücret bilgileri, mülakat notları. Adaylar verilerin nasıl saklandığına güvenmezse etkileşime girmez ve ajanslar gereksiz hukuki risk alır. Gizlilik ve uyumluluğu ek özellik değil, temel ürün özelliği olarak ele alın.
Farklı ajanslar ve bölgeler farklı hukuki gerekçelere dayanır (rıza, meşru menfaat, sözleşme). Her aday kaydında yapılandırılabilir bir takip alanı oluşturun:
Paylaşım işlemlerinin (profil gönderme, dışa aktarma, kampanyaya ekleme) bu ayarları kontrol ettiğinden emin olun.
Ajans düzeyinde saklama ayarları ekleyin: inaktif adayları, reddedilen başvuruları ve mülakat notlarını ne kadar süreyle saklayacakları. Sonra net akışlar uygulayın:
Bu eylemleri denetlenebilir ve gerektiğinde geri alınamaz şekilde yönetin.
Erişim taleplerini destekleyin: aday kaydının yapılandırılmış JSON dışa aktarımı ve insan tarafından okunabilir PDF/HTML özeti çoğu ihtiyacı karşılar.
İletim ve dinamik depolamada şifreleme, ayrı ortamlar ve güçlü oturum yönetimi kullanın. Varsayılan rolleri en az ayrıcalıkla ayarlayın: recruiterlar otomatik olarak ücret, özel notlar veya tüm müşteri gönderimlerini görmemeli.
Aday verilerini görüntüleme/dışa aktarma/paylaşma için bir görüntüleme denetim kaydı ekleyin ve politika detaylarını /privacy üzerinden ajansların adaylara açıklayabilmesi için erişilebilir hale getirin.
Entegrasyonlar uygulamanızın işe alımcının gününe doğal uyum sağlayıp sağlamayacağını belirler—veya “bir başka sekme daha” olur. Önce yüksek etkili bağlantılar için küçük bir set hedefleyin ve diğer her şeyi temiz bir API katmanının arkasına koyun ki daha sonra yeniden yazmadan ekleyebilesiniz.
E-posta ile başlayın; çünkü bu doğrudan iletişimi destekler ve değerli aktivite geçmişi oluşturur.
Gmail ve Microsoft 365 ile bağlanarak:\n
Basit tutun: mesaj meta verilerini (konu, zaman, katılımcılar) ve arama için güvenli bir gövde kopyası saklayın. Loglamayı açık tutun ki işe alımcılar hangi konuların sisteme ait olacağını seçebilsin.
Takvim zaman çizelgesini tehlikeye sokmuyorsa bekleyebilir, ama güçlü bir yükseltmedir. Google Calendar / Outlook Calendar ile mülakat etkinlikleri oluşturabilir, zaman önerileri gönderebilir ve sonuçları kaydedebilirsiniz.
Erken sürümlerde odaklanılması gereken: etkinlik oluşturma + katılımcı ekleme + mülakat detayını aday pipeline aşamasına yazma.
Birçok ajans zaten bir ATS/CRM kullanıyor. Kilit olaylar için webhook'lar sağlayın (aday oluşturuldu/güncellendi, aşama değişti, mülakat planlandı) ve REST uç noktalarınızı açıkça belgeleyin ki ortaklar hızlıca bağlansın. /docs/api gibi basit bir dokümantasyon sayfası ve hafif bir “entegrasyon ayarları” ekranı düşünün.
İş panosu yayınlama ve gelen başvurular güçlüdür, ama karmaşıklık getirir (ilan politikaları, yinelenen başvurular, kaynak takibi). Bunları 2. aşama olarak ele alın:\n
Veri modelinizi şimdi tasarlayın ki “kaynak” ve “başvuru kanalı” alanları ileride birinci sınıf alanlar olsun.
Teknoloji yığını MVP'yi hızlı göndermeye odaklanmalı, ancak daha sonra daha iyi arama ve entegrasyonlara yer bırakmalı. İşe alım uygulamalarının iki farklı ihtiyacı vardır: işlemsel iş akışları (pipeline'lar, izinler, denetim günlükleri) ve hızlı arama/sıralama (adayları işlemlere göre eşleme).
Modern bir JavaScript yığını için React + Node.js (NestJS/Express) yaygın bir seçimdir: ön yüz ve arka uçta tek dil, çok sayıda kütüphane ve basit entegrasyon.\n Daha hızlı CRUD ve güçlü konvansiyon isterseniz, Rails veya Django core ATS/CRM iş akışlarını daha az kararla kurmak için mükemmeldir. Bunları hafif bir ön yüzle (Rails view'ları, Django template'leri) veya daha zengin bir UI gerekiyorsa React ile eşleştirin.\n Eğer prototipleme hızınız darboğazsa (özellikle iç araçlar veya erken doğrulama için), Koder.ai gibi bir vibe-coding platformu uçtan uca MVP oluşturmanıza yardımcı olabilir: temel ekranlar, iş akışları ve bir başlangıç veri modeli ile. Takımlar bunu hızlı yineleme için kullanıp, hazır olduğunda kaynak kodunu dışa aktarır. Anlık görüntüler ve geri alma, sıralama değişikliklerini teste sokarken uygulamayı bozmadan denemeyi kolaylaştırır.
Kaynak veri için bir ilişkisel veritabanı (genellikle PostgreSQL) kullanın. İşe alım verisi işlem ağırlıklıdır: adaylar, işler, aşamalar, notlar, görevler, e-postalar ve izinlerin tümü transaction ve kısıtlamalardan faydalanır.
“Dokümanları” (özgeçmişler, ekler) S3-benzeri bir depolamada tutun ve Postgres'te meta verilerini saklayın.
Anahtar kelime sorguları ve filtreler için Postgres full-text search ile başlayın. MVP için sıklıkla yeterlidir ve başka bir sistemi çalıştırmaktan kaçınır.
Eşleştirme ve arama darboğaz olduğunda (karmaşık sıralama, eşanlamlılar, bulanık sorgular, yüksek hacim), asenkron olarak Postgres'ten beslenecek Elasticsearch/OpenSearch gibi bir indeks ekleyin.
Test edebilmek için ayrı staging ve production ortamları tutun.\n Otomatik yedeklemeler, temel izleme (hatalar, gecikme, kuyruk derinliği) ve maliyet kontrolü (log saklama, doğru boyutlu instance'lar) kurun. Bu, daha fazla işe alımcı ve veri geldikçe sistemi öngörülebilir tutar.
Eşleştirme, sonuçları ölçtüğünüzde daha iyi olur ve işe alımcı kararlarının “neden”ini yakaladığınızda gelişir. Hedef gösteriş metrikleri değil—her kısa liste, mülakat ve yerleştirme önerilerinizi daha doğru hale getiren sıkı bir döngüdür.
Küçük bir KPI setiyle başlayın ki ajans performansına doğrudan bağlansın:\n
KPI'ları müşteri, rol türü, kıdem ve recruiter bazında filtrelenebilir yapın ki sayılar ortalama ve muğlâk değil, eyleme geçirilebilir olsun.
Karar verilen yerde hafif geri bildirim ekleyin (eşleştirme listesi ve aday profili üzerinde): beğen/beğenme, artı isteğe bağlı nedenler (örn. “maaş uyuşmazlığı”, “eksik sertifika”, “konum/vize”, “düşük yanıt oranı”).
Geri bildirimi şu sonuçlarla ilişkilendirin:\n
Bu, puanlamanızı gerçekle karşılaştırmanıza ve ağırlıkları veya kuralları kanıt ile ayarlamanıza imkan verir.
Birkaç varsayılan rapor oluşturun:\n
Panolar “bu hafta ne değişti?” sorusunu bir ekranda cevaplamalı, sonra detaylandırmaya izin vermeli. Her tablo CSV/PDF dışa aktarılabilir olmalı ki müşteri güncellemeleri ve iç incelemeler için kullanılabilsin; tanımlar görünür olsun (tooltip veya /help) ki herkes aynı metrikleri aynı şekilde okusun.
Bir işe alım uygulaması gerçek roller, gerçek adaylar ve gerçek zaman çizelgeleriyle güvenilir çalıştığında başarılı olur. Lansmanı öğrenmenin başlangıcı olarak görün—bitiş değil.
İlk kullanıcıları davet etmeden önce, temel özelliklerin sadece inşa edilmiş değil, uçtan uca kullanılabilir olduğundan emin olun:
Büyük bir test paketine ihtiyacınız yok ama doğru testlere ihtiyacınız var:\n
Pilotu haftalık geri bildirim verecek 1–3 ajans ile başlatın. Başarı metriklerini önceden tanımlayın: ilk kısa liste süresi, azalan e-posta trafiği, işe alımcıların eşleşme açıklamalarına güveni gibi.
İki haftalık bir tempo yürütün: sorunları toplayın, en önemli engelleri düzeltin ve iyileştirmeleri gönderin. Değişiklikleri hafif bir changelog ile yayınlayın (ör. /blog).
Core iş akışı stabil hale geldikten sonra önceliklendirin:\n
Katmanlar (portal erişimi, entegrasyonlar, gelişmiş analizler) eklerken /pricing üzerinde paketlemeyi net tutun.
Bir işe alım eşleştirme web uygulaması için kapalı döngü bir iş akışıyla başlayın:
Bir özellik bu döngüyü doğrudan desteklemiyorsa (ör. iş panosu yayınlama, karmaşık otomasyon, işe alım yöneticisi portalı), bunu 2. aşamaya erteleyin.
Her ana kullanıcı için 2–3 “en önemli görev” seçin ve tasarımı bunların etrafında yapın.
Eğer işe alım yöneticilerini v1'e dahil ediyorsanız, izin modeli ve bildirim kurallarını önceden planlayın.
“Daha iyi eşleşmeler” gibi belirsiz hedefler yerine ölçülebilir, iş akışıyla bağlantılı metrikler kullanın. İyi başlangıçlar:
Bu metrikler ayrıca sıralama değişikliklerinin sonuçları iyileştirip iyileştirmediğini doğrulamak için kullanılır.
Temel varlıkları basit tutun ve iş akışını ilişkilerle modelleyin:
Bu yapı, eşleştirme, raporlama ve denetim kayıtlarının özellikler büyüdükçe tutarlı kalmasını sağlar.
Ne depoladığınızla neyi aradığınız arasında net bir ayrım yapın.
Bu, ayrıştırma hatalarının işe alımcı onaylı verilerin üzerine sessizce yazmasını önler ve zaman içinde eşleştirme kalitesini artırır.
Şeffaf kurallarla başlayın, sonra puanlama ekleyin.
Ağırlıkları ayarlanabilir tutun ve her sonucun yanında “eşleşme nedeni” gösterin. Açıklanabilirlik, işe alımcıların sistemi güvenle kullanmasını ve düzeltmesini sağlar.
Gereksinimleri iki kovada modelleyin:
Bu, tercihlerin güçlü adayları filtrelemesini önlerken daha iyi uyumları ödüllendirir.
Her okuma/yazma yoluna izinleri entegre edin (arama ve eşleştirme dahil):
Öntanımı en az ayrıcalık olarak ayarlayın ve yetenekleri kasıtlı şekilde ekleyin (ör. “adayları dışa aktarabilir”).
Uyumluluğu ürün davranışı olarak ele alın, belge olarak değil.
Politika detaylarını /privacy gibi bir sayfadan bağlayın ve hassas işlemleri denetlenebilir kılın.
Güvenilirlik ve öğrenme odaklı bir yayın yapın:
Küçük değişiklikleri sıkça yayınlayın ve basit bir changelog tutun (ör. /blog).