Added score algorithm

[ealight]

Привіт, не претендую на вакансію, але можливо ви розглянете цей алгоритм, як один із варіантів імплементації.

Також, чомусь Лум вирішив зробити мене шипілявим - дуже сильно вибачаюсь за цей звук)

Loom

[RusinovAnton]

Здається тут помилка, не бачу щоб була евалюація чи підходить англійська кандидата по вакансії

[ealight]

Справді повинно бути candidate.english_level замість job.english_level.

Також можна зробити це так: якщо ми справді хочемо щоб під вакансію з рівнем англійської Intermediate найкраще підпадав кандидат з рівнем Intermediate, і т.д тоді варто зробити це ось так:
scoring.add(SimpleRule(score=lower_distance(ENGLISH_WEIGTH.get(candidate.english_level), ENGLISH_WEIGTH.get(job.english_level)), description="Considering English level"))

Я зроблю зараз коміт з другий варіантом.

[RusinovAnton]

Важливо щоби рівень кандидата був не менший за вказаний у вакансії

[ealight]

Важливо щоби рівень кандидата був не менший за вказаний у вакансії

Хм, тоді краще навіть так:

scoring.add(LogicalRule(score=ENGLISH_WEIGTH.get(candidate.english_level), when=ENGLISH_WEIGTH.get(candidate.english_level) >= ENGLISH_WEIGTH.get(job.english_level), otherwise=0, description="Add score if candidate English level greater than job required level"))

і трішки відкорегувати значення англійської в розрахунках:

ENGLISH_WEIGTH = { EnglishLevel.NONE: 0, EnglishLevel.BASIC: 0.5, EnglishLevel.PRE: 1, EnglishLevel.INTERMEDIATE: 1.5, EnglishLevel.UPPER: 2, EnglishLevel.FLUENT: 2.5 }

[RusinovAnton]

Дякую за участь!
Мені дуже подобається рішення, виділяється поміж інших. Особливо гнучкість правил, можна додати правило яке перевіряє чи рекрутер відповідала кандидату.

[ealight]

Дякую за участь! Мені дуже подобається рішення, виділяється поміж інших. Особливо гнучкість правил, можна додати правило яке перевіряє чи рекрутер відповідала кандидату.

Дуже дякую за відгук! Справді гнучкість цього рішення получилась дуже крутою, як з додаванням правил, так і з легкою реалізацію інших правил, які можна придумати, крім SimpleRule, IterableRule і LogicalRule

Також, якщо візьмете цей алгоритм в продакшин в мене є наступні ідеї для його покращення:

1. Додати до таблиці threads два поля: score і score_algorithm_version
2. Версію алгоритму зберігати в конфізі або score_algorithm.py файлі.
3. Зробити дістпатчер на @post_save для треда і в цьому діспатчері вираховувати score треда.
4. Імплементувати батч-скрипт який би обновляв скор всіх тредів в базі даних, якщо версія алгоритму за яким обчислявся скор є іншою ніж на час запуску батч-скрипту.
5. При оновленні правил, оновляти версію алгоритму.
6. Запускати батч-скрипт в ночі, щоб не положити базу.

Таке рішення дуже сильно вплине на швидкість загрузки інбоксу, тому що можна буде відмовитись від цього коду:
sorted({score_thread(thread) for thread in threads}, key=lambda thread: thread.score, reverse=True), а сортувати зразу за допомогою django і order_by.

[RusinovAnton]

якщо візьмете цей алгоритм в продакшин

Ми не будемо брати рішення учасників для нашого продакшну. Мета цього тестового - відбір кандидатів на посаду девелопера в команду.

[ealight]

якщо візьмете цей алгоритм в продакшин

Ми не будемо брати рішення учасників для нашого продакшну. Мета цього тестового - відбір кандидатів на посаду девелопера в команду.

Зрозуміло, тоді дякую за відгук!