Комментарии 11
Когда рассказываете про методы — оно по крайней мере интересно (я не особо специалист, возможно поэтому :). Но когда дело доходит до практики — начинаются вообще такие предположения, которые не основаны вообще ни на чем.
Самый простой пример — если я закоммитил в githib код на Java — это значит, что я закоммитил код на Java. Больше — ничего. Это вообще может быть не мой мопед.
А дальше начинается вообще чепуха — потому что владение Java может предполагать как владение языком как таковым (с учетом версий, но не сильным их влиянием, с определенного уровня знания кандидату почти все равно, что за версия), так и JavaEE, OSGI, Spring, и далее до бесконечности. Иными словами — число навыков, даже связанных непосредственно с одним из, стремится к бесконечности. Особенно если этот навык — фактически экосистема (вместо Java вполне можно написать скажем IOS — думаю, получится похоже).
А еще навыки имеют свойство устаревать…
Они разумеется связаны друг с другом, скажем, если я напишу, что владею karaf семейства 3.х, это будет означать, что я скорее всего работал с Java 7 (потому что это требование к karaf семейства 3.х), но вот ваш ML этого не узнает. А вот человек — тот да, тот может. Почему «скорее всего»? Да потому что в принципе, работа с karaf может вообще не предполагать Java разработки. Это все слабые связи.
>Всё ещё нет хорошего решения для оценки уровня владения навыками кандидатов.
Так его и не будет. Оценка уровня владения навыками кандидата — это задача, которую может решить технический специалист, владеющий этими же навыками. В идеале — лучше кандидата. По открытым публикациям чего-либо в интернете вы это не оцените никогда. Ну ок — пока не появится сильный ИИ, но не раньше.
Самый простой пример — если я закоммитил в githib код на Java — это значит, что я закоммитил код на Java. Больше — ничего. Это вообще может быть не мой мопед.
А дальше начинается вообще чепуха — потому что владение Java может предполагать как владение языком как таковым (с учетом версий, но не сильным их влиянием, с определенного уровня знания кандидату почти все равно, что за версия), так и JavaEE, OSGI, Spring, и далее до бесконечности. Иными словами — число навыков, даже связанных непосредственно с одним из, стремится к бесконечности. Особенно если этот навык — фактически экосистема (вместо Java вполне можно написать скажем IOS — думаю, получится похоже).
А еще навыки имеют свойство устаревать…
Они разумеется связаны друг с другом, скажем, если я напишу, что владею karaf семейства 3.х, это будет означать, что я скорее всего работал с Java 7 (потому что это требование к karaf семейства 3.х), но вот ваш ML этого не узнает. А вот человек — тот да, тот может. Почему «скорее всего»? Да потому что в принципе, работа с karaf может вообще не предполагать Java разработки. Это все слабые связи.
>Всё ещё нет хорошего решения для оценки уровня владения навыками кандидатов.
Так его и не будет. Оценка уровня владения навыками кандидата — это задача, которую может решить технический специалист, владеющий этими же навыками. В идеале — лучше кандидата. По открытым публикациям чего-либо в интернете вы это не оцените никогда. Ну ок — пока не появится сильный ИИ, но не раньше.
Возможно, я недостаточно подробно описал все шаги наших предположений и оснований, на которых мы строили систему. Тем не менее, мне кажется, вы верно поняли, что основное условие успешности подобной системы — это построить такое пространство или граф, если хотите, в котором связанные навыки будут находиться рядом (как если бы эксперты располагали их в этом пространстве).
То есть если через граф это описать то, такие примеры как kafar и Java7 будут иметь хоть и не очень сильную, возможно, но связь. В этом и есть задача. В некоторых кейсах (т. е. на некоторых данных), например, на оценках фильмов удается добиться вменяемых результатов относительно простыми моделями, вроде SVD, ALS. Для более сложных — нужны более сложные модели, например, тут можно посмотреть, как YouTube делает свои ± адекватные рекомендации.
Согласен, что будут такие пользователи, у которых в подписках будет не то, что они сами могли бы написать. Но все же большинство подписано на релевантные им репозитории и это позволяет рассчитывать на адекватно сконструированное пространство и, соответственно, адекватные рекомендации. Тем не менее нам не обойтись пока без рекрутеров, которые руками проверяют финальные рекомендации и отметают людей, чьи подписки не отражают их специальности.
Не согласен с вашим мнением по поводу того, что невозможно оценить уровень владения навыками. Во-первых, не очень понял, что вы имеете в виду под ИИ. Во-вторых, это действительно не простая задача. Но, например, хоть как-то понимать уровень специалиста можно через те же навыки. Сначала человек учит основы языка программирования, потом базовые библиотеки, потом более специализированные библиотеки, фреймворки и так углубляется в специальность. Поэтому у senior специалистов резюме обычно богаче, чем у junior, но бывают и исключения, конечно).
И нужны хорошие данные, на GitHub у нас пока не получилось оценивать уровень специалистов. Но с данными Stack Overflow это кажется уже более реалистично.
То есть если через граф это описать то, такие примеры как kafar и Java7 будут иметь хоть и не очень сильную, возможно, но связь. В этом и есть задача. В некоторых кейсах (т. е. на некоторых данных), например, на оценках фильмов удается добиться вменяемых результатов относительно простыми моделями, вроде SVD, ALS. Для более сложных — нужны более сложные модели, например, тут можно посмотреть, как YouTube делает свои ± адекватные рекомендации.
Согласен, что будут такие пользователи, у которых в подписках будет не то, что они сами могли бы написать. Но все же большинство подписано на релевантные им репозитории и это позволяет рассчитывать на адекватно сконструированное пространство и, соответственно, адекватные рекомендации. Тем не менее нам не обойтись пока без рекрутеров, которые руками проверяют финальные рекомендации и отметают людей, чьи подписки не отражают их специальности.
Не согласен с вашим мнением по поводу того, что невозможно оценить уровень владения навыками. Во-первых, не очень понял, что вы имеете в виду под ИИ. Во-вторых, это действительно не простая задача. Но, например, хоть как-то понимать уровень специалиста можно через те же навыки. Сначала человек учит основы языка программирования, потом базовые библиотеки, потом более специализированные библиотеки, фреймворки и так углубляется в специальность. Поэтому у senior специалистов резюме обычно богаче, чем у junior, но бывают и исключения, конечно).
И нужны хорошие данные, на GitHub у нас пока не получилось оценивать уровень специалистов. Но с данными Stack Overflow это кажется уже более реалистично.
>Не согласен с вашим мнением по поводу того, что невозможно оценить уровень владения навыками.
Ну, дело ваше конечно. Мой скромный опыт мне подсказывает, что формализуемого критерия для такой оценки не существует. Ну то есть, вы можете оценить, что человек коммитил код на каком-то языке (замечу — на том языке, который он сам написал, и не факт, что свой код), и подписан на какие-то репозитории на других языках. Это просто написано в метаданных проекта.
Но дело в том, что у GitHub вообще нет такого понятия, как репозиторий, написанный на фреймворке. Фреймворки, а не языки — они нигде не упоминаются явно, нигде не указано, что они использовались.
Вы даже не сможете в общем случае сделать вывод, что они вообще использовались, и тем более — оценить уровень владения ими. Для этого нужно анализировать код, и нужно понимать его — а это слишком сложная задача для методов ML. Она и для человека нетривиальна.
Ну то есть, перед вами репозиторий на языке Java, внутри используется скажем Apache Spark. Spark — это экосистема примерно такого же объема и сложности, как Java, это огромный, сложный, разветвленный навык. И при этом в метаданных проекта нигде и никак не написано, что он там вообще есть.
Вот перед вами такой репозиторий. Ваши действия?
Если рассматривать это все как источник кандидатов — то да, возможно. Но как средство оценки — ой вряд ли.
Ну, дело ваше конечно. Мой скромный опыт мне подсказывает, что формализуемого критерия для такой оценки не существует. Ну то есть, вы можете оценить, что человек коммитил код на каком-то языке (замечу — на том языке, который он сам написал, и не факт, что свой код), и подписан на какие-то репозитории на других языках. Это просто написано в метаданных проекта.
Но дело в том, что у GitHub вообще нет такого понятия, как репозиторий, написанный на фреймворке. Фреймворки, а не языки — они нигде не упоминаются явно, нигде не указано, что они использовались.
Вы даже не сможете в общем случае сделать вывод, что они вообще использовались, и тем более — оценить уровень владения ими. Для этого нужно анализировать код, и нужно понимать его — а это слишком сложная задача для методов ML. Она и для человека нетривиальна.
Ну то есть, перед вами репозиторий на языке Java, внутри используется скажем Apache Spark. Spark — это экосистема примерно такого же объема и сложности, как Java, это огромный, сложный, разветвленный навык. И при этом в метаданных проекта нигде и никак не написано, что он там вообще есть.
Вот перед вами такой репозиторий. Ваши действия?
Если рассматривать это все как источник кандидатов — то да, возможно. Но как средство оценки — ой вряд ли.
Предлагаю пока оставить тему оценки уровня владения навыками. Все же мы пока хорошего решения не реализовали. Хотя формальных правил, в том числе для оценки качества кода, довольно много.
По поводу определения какие фреймворки использовались.
Отдельный репозиторий А с Java и Spark в вакууме ничего нам не скажет. Но если это хороший репозиторий с полезным кодом, то на него подписаны пользователи, которые хотели бы его как-то использовать. В своем большинстве они знают Java и Spark, раз подписаны на него. Следовательно, у них в подписках должно быть много реп с этими и связанными фреймворками/технологиями — т. е. “навыками”. Какие-то из репозиториев на которые они подписаны имеют метаданные (топики, описания, говорящие названия...), которые можно использовать для маппинга реп на навыки. Поэтому если репозиторий А оказывается в сконструированном пространстве рядом с репозиториями, у которых есть условный маппинг, то и его можно отнести к соответствующему направлению. Причем подобная система поймет даже в каком ключе в репозитории А использовался Spark — если для ML моделей, то репозиторий буде ближе к области ML навыков, если, скажем, для Data Engineering, то ближе к этому направлению. И все это по соприсутствию подписок людей.
Но задача сопоставления навыков и репозиториев, действительно, одна из самых сложных в этой системе.
По поводу определения какие фреймворки использовались.
Отдельный репозиторий А с Java и Spark в вакууме ничего нам не скажет. Но если это хороший репозиторий с полезным кодом, то на него подписаны пользователи, которые хотели бы его как-то использовать. В своем большинстве они знают Java и Spark, раз подписаны на него. Следовательно, у них в подписках должно быть много реп с этими и связанными фреймворками/технологиями — т. е. “навыками”. Какие-то из репозиториев на которые они подписаны имеют метаданные (топики, описания, говорящие названия...), которые можно использовать для маппинга реп на навыки. Поэтому если репозиторий А оказывается в сконструированном пространстве рядом с репозиториями, у которых есть условный маппинг, то и его можно отнести к соответствующему направлению. Причем подобная система поймет даже в каком ключе в репозитории А использовался Spark — если для ML моделей, то репозиторий буде ближе к области ML навыков, если, скажем, для Data Engineering, то ближе к этому направлению. И все это по соприсутствию подписок людей.
Но задача сопоставления навыков и репозиториев, действительно, одна из самых сложных в этой системе.
НЛО прилетело и опубликовало эту надпись здесь
Все равно в среднем рейтинг растёт, кто-то изредка лайкает, рекрутеры замечают.
Просится пет проект, который берет тут дамп, после чего считает «честный» рейтинг, лучше коррелирующий с компетенцией. Можно неплохо в алгоритмах поднатаскаться.
какая-то очень сложная система для отбора матросов из кодинг-буткемпов. Самое важное, чтобы они могли копипастить код из стековерфлоу и закрывать тикеты, чтобы галера могла подороже продавать трудочасы.
Чем больше таких людей и чем меньше они просят денег/чем дольше сидят на ровном месте — тем больше прибыли для компании, вот что важно руководству
Желаю вам, чтобы вас самих так хайрили
Мне кажется, что поиск кандидатов на GitHub с учетом их собственных репозиториев и подписок на другие репозитории существенно сужает входящую воронку: вы ограничиваете поиск до людей, которые интересуются опенсорсными проектами.
Возможно, даже для профессиональной IT-компании это слишком строгий критерий предварительной фильтрации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы искали кандидатов с помощью машинного обучения