Спасибо за развёрнутый ответ!

Все идеи практичны, будем пробовать поэтапно внедрять их.

Спасибо за развёрнутый ответ! Отвечу на тезисы по порядку.

Про прозрачность: мы вряд ли сможем избежать «креатива» от HR, ведь ничего не мешает им после нашего сервиса выйти на контакт с кандидатом и продолжить бесконечные этапы найма. Вижу решение в том, чтобы предоставить наш сервис как полноценный инструмент найма, т. е. без надобности в каких-либо еще действиях, а это достигается качеством инструмента.

Про реальный стек: это, к сожалению, ответственность нанимающих, так как, как бы мы ни хотели, мы не можем заставить их изучать собственный стек для правильного заполнения. Постараемся придумать здесь механизмы для помощи в составлении правильного стека и системы поощрений/наказаний, но большее, к сожалению, не вытянуть.

Про вилку и фидбэк: примерно такая же история, как и со стеком. Пока мы не настолько большие игроки, чтобы диктовать условия для честного найма, который в то же время может быть невыгоден для компании. Возможно, встав на рельсы, постараемся исправить эту оплошность.

Про JobPath: обязательно изучим, попробуем извлечь лучшие практики.

Чёткое разделение довольно сложно передать, т.к. большинство сфер смежные. И выявить алгоритмически у кандидата его сильные черты довольно сложно, можно доверять самим пользователям, но это быстро кончится накруткой, какой-то AI анализ не особо будет пользоваться доверием, какой вы тут механизм видите?

Понимаете, в чем проблема - в разработке наступила специализация, а многие руководители этого не понимают. Программировать UX/ UI и программировать микроконтроллеры - не одно и то же и даже не смежные занятия. То же самое можно сказать о программировании на С и C++ - это очень разная работа. К сожалению, мало кто это понимает. А какие механизмы - больше вовлеченности реальных людей и меньше AI. AI - это скорее костыль, чем "серебряная пуля".

Спасибо за развёрнутый ответ, специфику проблемы услышал, будем пробовать искать решение на это

С первым пунктом полностью согласен. Единственный минус — приняли решение этот функционал отложить в post-MVP вариант, но постараемся приоритизировать его, если проект "встанет на рельсы".

Во втором пункте: в создании таких инструментов есть большой подводный камень — отсутствие детерминизма. То есть можно, конечно, сделать для кандидатов обязательным параметром описание своих архитектурных решений, но их в большинстве случаев будет оценивать «первым эшелоном» рекрутер, то есть не техспециалист. И здесь это может пойти только во вред, ведь главная идея — подлатать частую техническую пропасть между рекрутером и кандидатом. А это реализуемо только в тех вещах, где присутствует автоматизируемый детерминизм.

Третий пункт очень интересный, обязательно забрейнштормим его.

P. S. Спасибо за развёрнутый ответ!

Пока ориентир на компании, если смотреть в сторону фриланса, то если описание тз сделать обязательным, то захочет ли бизнес идти на такие сложности? Как его привлечь настолько, чтобы он остался на платформе и прилагал усилия к обязательному тз?

В обязательном порядке?

Иначе это всё просто разработка для ничего.

Я не думаю, что бизнес сильно заботится о ненанятых кандидатах, конечно, можно заручиться поддержкой разработчиков и устроить бойкот😁

Если без шуток, то бизнес сложно завлечь продуктом, который будет выставлять такие обязательства, по итогу продукт будет отталкивающим, есть отдельные идеи на этот счёт, учту, что вопрос насущный

Тогда ваш продукт будет просто невостребованным клоном.

Думаю, скорее продукт будет дешевым невостребованным клоном

Их много.