---

Вступ до проблеми підбору кадрів без зберігання даних

Нещодавно в Slack розгорілася дискусія про те, як краще співвідносити вакансії та резюме, не створюючи зайвих баз даних. Один із розробників підняв питання: як ми можемо зберігати тільки необхідні дані і при цьому забезпечувати якісне відповідність. Це стало для нас викликом, оскільки від цього залежала ефективність нашого сервісу підбору кадрів.

Контекст завдання

Проблема, з якою ми зіткнулися, виникла внаслідок розширення нашої платформи. Рекрутери та кандидати почали помічати, що результати пошуку вакансій та резюме не завжди збігалися. Ми розуміли, що від цього залежить наше репутаційне становище на ринку. Якщо ми не зможемо надати якісні результати, ми ризикуємо втратити довіру наших користувачів, тим більше в умовах високої конкуренції.

Конкретні труднощі

Одним із прикладів, які ми вивчали, було співвідношення резюме, де ключові слова не завжди збігалися між вакансіями та кандидатами. Наприклад, резюме кандидата могло містити термін «розробка ПЗ», у той час як вакансія вимагала «програмування». Це різниця впливала на результати пошуку і, як наслідок, на задоволеність користувачів. Ми розуміли, що потрібно знайти більш гнучкий і розумний підхід до обробки даних.

Перші спроби рішення

Першим рішенням, яке ми спробували, було використання простих алгоритмів за ключовими словами. Ми створили систему, яка співвідносила вакансії та резюме на основі частоти входження слів. Однак це рішення виявилося неефективним. Під час тестування ми помітили, що багато відповідних кандидатів не знаходили вакансії через невідповідність термінології. Це стало для нас сигналом про необхідність більш глибокого аналізу.

Технічний підхід до рішення

Врешті-решт, ми вирішили використовувати більш складний алгоритм машинного навчання, який враховував контекст слів і їх семантику. Ми впровадили модель, навчена на наборі даних, що містить різні вакансії та резюме. Приклад коду, що ілюструє ключові моменти реалізації:

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity

vectorizer = TfidfVectorizer()
vacancy_matrix = vectorizer.fit_transform(vacancies)
candidate_matrix = vectorizer.transform(candidates)

similarity = cosine_similarity(vacancy_matrix, candidate_matrix)

Цей підхід дозволив нам більш точно співвідносити вакансії та резюме, мінімізуючи обсяг даних, які нам потрібно було зберігати. Ми змогли зберігати тільки «сжаті» представлення вакансій та резюме, що значно знизило навантаження на нашу базу даних.

Зміни в продукті

Після впровадження нового алгоритму ми помітили значне покращення в якості результатів пошуку. Кандидати стали отримувати більше релевантних пропозицій, а рекрутери відзначали підвищення якості підбору. Це позитивно вплинуло на користувацький досвід, що, в свою чергу, відобразилося на показниках у розділі /jobs та /for-companies. Ми впевнені, що ці зміни допоможуть нам зміцнити позиції на ринку.

Уроки, які ми витягли

• Використання простих алгоритмів може призвести до недостатньої ефективності.
• Контекстна семантика важливіша, ніж частота входження слів.
• Стиснення даних дозволяє знизити витрати на зберігання.
• Зворотний зв'язок користувачів — важливий фактор для покращення продукту.
• Не бійтеся пробувати різні підходи: іноді найкраще рішення може бути несподіваним.

Значення для кандидатів

Кандидати тепер можуть розраховувати на більш точні та релевантні пропозиції. Завдяки покращеному алгоритму, їх шанси бути поміченими рекрутерами зростають, що робить процес пошуку роботи більш ефективним і приємним.

Значення для рекрутерів

Рекрутери отримують доступ до більш якісних кандидатів, що мінімізує час, витрачений на пошук. Покращена система співвідношення дозволяє їм швидше знаходити підходящі резюме, що підвищує загальну продуктивність роботи.

Наступні кроки

Незважаючи на досягнутий прогрес, ми продовжуємо стежити за результатами роботи нового алгоритму. Ми плануємо проводити додаткові експерименти, щоб зрозуміти, як ще можна покращити якість співвідношення без збільшення обсягу збережених даних. Якби нам довелося почати знову, ми б приділили більше уваги зворотному зв'язку на ранніх стадіях розробки, щоб уникнути деяких попередніх помилок. ---