Соглашусь, первое о чем постоянно говорю летним практикантам "Выбирайте направление". Почему-то их всех учат на фуллстеков, забывая сообщить, что времени выучить все в нужном объеме у них не будет вообще
Бизнес диктует лишь то, что в кратчайшие сроки требуется квалифицированный персонал. А как его выбрать, если собеседующий не разбирается в тематике вопроса? HR не знает разработку, Руководитель - тоже ее знает ограниченно, техлид знает свой стек, как и разработчик. У каждого своя зона ответственности, так сказать.
Вот и получаем вилку: 1) Либо сотрудник знает меньше руководителя. Как итог руководитель тешит самолюбие какой он умный молодец. На собесах задает вопросы и восторженно смотрит, как никто не может на них ответить. Хотя по сути знает он лишь тот самый 1 сложный вопрос и не более. 2) Либо сотрудник знает больше руководителя. А как понять знания истины или лишь эмуляция знания - не ясно. Оттуда и тесты разные, профильные компании по отбору и т.п. А если при этом руководитель из пункта 1 собеседует, то он такого кандидата просто развернет, так как это подрывает его авторитет.
Вот и получается, что это не бизнес "мучает людей", как вы написали, а просто на местах не знают как проверить навыки адекватно. Проверяют не те, не то и не так :)
В том то и момент, что на ГосУслугах нет теста, там только ссылка на НН. Вас переводят на НН, который просит связать учетку НН и ГосУслуг, иначе сертификат вам не получить.
Мне кажется, что кандидат должен не готовиться, а все же просто знать. Иначе это превращается в ЕГЭ, где реальный навык подменяется теорией прохождения собесов
Возможно, но так как тесты проходятся на НН, то я пишу как это воспринималось мной. Возможно упустил, где-то есть информация, что это лишь API между скилбоксами и HH?
и вы, конечно, после всех баталий, в комментариях к новостям...
с другой стороны, да - месяц прошел, а всё спокойно, как и ожидалось.
Вот эту фразу недопонял, если важно - переформулируйте, пожалуйста.
состав тестов, мягко говоря, оставляет много вопросов. от времени, отведенного на некоторые практические задания, до явных ляпов в теоретических вопросах. вероятно, когда-нибудь поправят, но осадочек остался.
подозреваю, что никто и не ждал большого наплыва тестирующихся.
что будет дальше - как лбычно, будем посмотреть.
Меня состав не очень смутил. Я ожидал значительно более низкого качества на входе. Ляпы да - есть, как писал в статье "не обошлось без казусов" :)
а хедхантер, пользуясь случаем, уже месяц, угрожает, что отберет какие-то там значки, если не перепройти то, что прошел до привязки к госуслугам. начал делать это, иди нет, пока не смотрел. не хочется консолидации госуслуг с хедхантером.
Могу ошибаться, но, вроде бы, там ранее лишь английский был. Сейчас значок дается сроком на год, кстати, в статье об этом не писал
Все эти тесты по определению не нужны: они, возможно, имеют смысл в случае, если образование непрофильное или его нет вообще, а также если при этом отсутствует опыт работы по специальности. Если есть профильное образование и опыт работы, это и есть подтверждение компетенций.
Опыт работы, к сожалению, не равен навыкам. Причем не только в IT. Без тестов пока никак, хотя подход может быть разным. Например, мы при подборе любим давать реальные кейсы к разбору. 20 минут собеса и все встает на свои места, кто что знает и в каких размерах.
Другой вопрос — что на рынке труда требуются навыки, которые не даёт образование, и часто даже опыт не обеспечивает необходимых навыков, потому что везде всё по-разному.
Здесь согласен на 100%.
Работодатели должны участвовать в подготовке (или переподготовке) кадров а не заниматься поиском специалистов предъявляя к ним фантастические требования.
Из опыта. Хотел вести лекции в одном из колледжей Москвы. Делиться с молодежью реальным опытом, а не теорией из учебников, которые не обновлялись уже лет 10.
На один час лекций мне бы требовалось заполнить столько бумаг, что желание отпало полностью, а компенсировать бизнесу мое затраченное время никто не будет, естественно.
По итогу остановились на том, что берем практикантов и 2-3 человека получают хоть какой-никакой реальный опыт. Захотят - потом к нам придут, не захотят - всегда подтвердим определенные навыки, если человек их действительно получил.
А вот требования да, иногда к джуну требования как к сеньеру в вакансиях. А ЗП даже ниже рынка при этом :)
Благодарю за ответ, давайте тогда пробовать разбираться по элементам :)
Диаграммы и картинки Сам файл диаграммы или картинки сохраняется в репозитории в исходном виде. В Markdown-файле статьи сохраняется путь до ресурса (диаграммы или картинки) в репозитории.Это позволяет нам работать локально: при загрузке всего репозитория у редактора корректно отображается как статья, так и все ее ресурсы.Так как ресурсы хранятся в самом репозитории, ситуация "Разработчик ушел, сервер потушен - ваша документация умерла, потому что отвалились все картинки" невозможна.
Предположим, что я внешний разработчик (компания) и веду разовые работы на своем компанейском git. В определенный момент мне потребуется полностью все передать в git заказчика (сдать работу). Мне свой git поддерживать уже не имеет смысла (работа сдана). Так как все ваши пути "до ресурса" будут залинкованы на мой git, то в определенный момент вы, как заказчик, имеет серьезный риск потери всех картинок. При этом перелинковка потребует значительных усилий, так как по сути нужно будет поменять каждую ссылку в документе (по сути ревизия всей документации). А бизнес не платит за переделку документации к рабочему продукту :)
Видео Так как хранить в репозитории большие файлы (а видео обычно большие) не очень хорошая практика, мы позволяем в редакторе добавить ссылку на видео из любого источника с возможностью стриминга. Это может быть YouTube, RuTube, DropBox и так далее. Видео как раз является этим динамическим элементом, о которых вы писали. Понятное дело, что в PDF оно не воспроизведется, но ссылка сохранится и по ней можно будет перейти.
Видео - интересная идея. Однако хранить документацию (а видео тут выступает в этом контексте) на внешних хранилищах вообще недопустимо, как минимум с точки зрения ИБ. Ни один сервис не гарантирует вам недоступность вашей ссылки. Как итог - есть неплохой шанс открыть всему миру полное описание того, как работает сервис на уровне админа, что дает хороший такой вектор атаки для хакера.
Информация о дизайне В статье мы описываем документацию, которая передается после завершения проекта. Это, как правило, руководство пользователя, администратора, техническая спецификация. На этом моменте нет потребности согласовывать дизайн. Описать юзерфлоу — да, нужно. Но это делается в стандартной форме инструкции или туториала, где фокус не на элементах интерфейса, а на действиях пользователя.
Из практики: юзер флоу без дизайна (хотя бы в виде набросков) - путь к переделкам. Текстовое описание никогда не сможет конкурировать с примитивным макетом в силу того, что менеджеры на стороне заказчика являются простыми менеджерами, а не техническими специалистами. Им требуются картинки для наглядности и согласования. Чисто текстовое описание приводит к разрыву "ожидание-реальность", что по итогу может сорвать вообще весь проект.
Нумерация версий Версии документации, в идеале, должны соответствовать версиям продукта. Каждая версия хранится в отдельной ветке. Например, из ветки v1.1.0 мы создадим ветку v1.1.1 и добавим в нее новые фичи + описание этих фич.
Теперь представьте простого среднестатистического менеджера, которому вы говорите "Сходите в гит, в ветку dev_v1.1.1, сделайте pull изменений к себе, чтоб получить обновление документации по вашей фиче". Все что будет понятно менеджеру - слово "документация" и ответом менеджера станет "пришлите на почту". Пользоваться гитом простой менеджер заказчика не будет, а документация при этом ему требуется.
На это я ранее и указывал, что документация в маркдаун - это документация для технарей, но, к сожалению, ее сложно приспособить для нужд менеджеров или юристов. Они мыслят pptx и doc, к сожалению. Отсюда и все ТЗ во всех тендерах в виде doc-файла и pdf. И с этим требуется как-то дружить :)
Надеюсь, правильно поняла вопросы и понятно на них ответила. Ну и не могу упустить возможность написать, что полезных и приятных возможностей у нас много. О них подробнее можно узнать в документации:https://gram.ax/resources/docs
В любом случае спасибо за продукт, думаю, что он уже занял свою определенную нишу или займет ее далее.
Мои комментарии - это больше история про универсализацию продукта. На данный момент мне кажется, что этот продукт больше подходит для технарей (внутренней документации) и полностью не подходит для заказчика (в силу того, что он не сможет с ним адекватно взаимодействовать). Как итог, придется вести двойную документацию, что нарушает саму концепцию единого документа для всех.
Однако мое мнение субъективно и пока основывается лишь на вашем описании в статье и комментариях. Как будет время - изучу поподробнее ваш продукт и, может быть, вернусь с опровержением своих слов :)
Тут загвоздка в том, что у разработчика тоже есть ограничение производительности.
Предположим, что бизнес действительно идет в рост Х2.
Разработчик не может делать в 2 раза больше, значит в какой-то момент он упрется в "вилку" своей ЗП, а далее будет нанят второй разработчик в штат. Пока он может самостоятельно тянуть процесс - проще ему доплачивать "сверху", чем искать нового спеца с половинчатой нагрузкой.
Соглашусь, первое о чем постоянно говорю летним практикантам "Выбирайте направление".
Почему-то их всех учат на фуллстеков, забывая сообщить, что времени выучить все в нужном объеме у них не будет вообще
В целом да, это именно он и есть.
Хотя, думаю, там есть и более глубокие истории по профильному поиску сотрудников для госсектора.
Там, судя по вакансиям, сейчас жарко :)
И да, и нет.
Бизнес диктует лишь то, что в кратчайшие сроки требуется квалифицированный персонал.
А как его выбрать, если собеседующий не разбирается в тематике вопроса?
HR не знает разработку, Руководитель - тоже ее знает ограниченно, техлид знает свой стек, как и разработчик.
У каждого своя зона ответственности, так сказать.
Вот и получаем вилку:
1) Либо сотрудник знает меньше руководителя.
Как итог руководитель тешит самолюбие какой он умный молодец.
На собесах задает вопросы и восторженно смотрит, как никто не может на них ответить.
Хотя по сути знает он лишь тот самый 1 сложный вопрос и не более.
2) Либо сотрудник знает больше руководителя.
А как понять знания истины или лишь эмуляция знания - не ясно.
Оттуда и тесты разные, профильные компании по отбору и т.п.
А если при этом руководитель из пункта 1 собеседует, то он такого кандидата просто развернет, так как это подрывает его авторитет.
Вот и получается, что это не бизнес "мучает людей", как вы написали, а просто на местах не знают как проверить навыки адекватно.
Проверяют не те, не то и не так :)
А нужно ли вспоминать эти самые детали?
На мой взгляд основная цель собеса/теста выяснить, что человек умеет именно сейчас, а не как он велосипедил / костылил 20 лет назад.
Если его уровень совпадает 20 лет назад и сейчас - это прям печально будет
Тут, думаю, создатели заигрались с защитой от GPT.
И поставили защиту от человека :)
Мне показалось, что для оценки кандидата инструмент в целом рабочий.
Если кандидат сидит перед вами и отвечает, конечно :)
Про перегибы логики тоже писал.
Думаю, что это связано с попытками защиты от GPT
Антипаттерны встречал, но не очень много - возможно,
что вам "повезло" с набором вопросов
Мне показалось, что для оценки кандидата инструмент в целом рабочий.
Если кандидат сидит перед вами и отвечает, конечно :)
Про перегибы логики тоже писал.
Думаю, что это связано с попытками защиты от GPT
В том то и момент, что на ГосУслугах нет теста, там только ссылка на НН.
Вас переводят на НН, который просит связать учетку НН и ГосУслуг,
иначе сертификат вам не получить.
Тесты сдать вам позволят, а вот сертификат на госуслугах получить - нет, к сожалению
100%,
Если стэк подошел - все ок.
Если нет - по сути становишься джуном.
Мне кажется, что кандидат должен не готовиться, а все же просто знать.
Иначе это превращается в ЕГЭ, где реальный навык подменяется теорией прохождения собесов
Возможно,
но так как тесты проходятся на НН, то я пишу как это воспринималось мной.
Возможно упустил, где-то есть информация, что это лишь API между скилбоксами и HH?
Вот эту фразу недопонял, если важно - переформулируйте, пожалуйста.
Меня состав не очень смутил.
Я ожидал значительно более низкого качества на входе.
Ляпы да - есть, как писал в статье "не обошлось без казусов" :)
Могу ошибаться, но, вроде бы, там ранее лишь английский был.
Сейчас значок дается сроком на год, кстати, в статье об этом не писал
Это был один из самых мощных стоп-факторов лично для меня.
Потому и выделил его в отдельный пункт, чтоб сразу было ясно в чем подвох затеи :)
Согласен, сейчас история повторяется с другими курсами
Если исходить из 1,5% подтверждений за месяц,
то именно он сейчас и происходит
Опыт работы, к сожалению, не равен навыкам.
Причем не только в IT.
Без тестов пока никак, хотя подход может быть разным.
Например, мы при подборе любим давать реальные кейсы к разбору.
20 минут собеса и все встает на свои места, кто что знает и в каких размерах.
Здесь согласен на 100%.
Из опыта.
Хотел вести лекции в одном из колледжей Москвы.
Делиться с молодежью реальным опытом, а не теорией из учебников, которые не обновлялись уже лет 10.
На один час лекций мне бы требовалось заполнить столько бумаг, что желание отпало полностью, а компенсировать бизнесу мое затраченное время никто не будет, естественно.
По итогу остановились на том, что берем практикантов и 2-3 человека получают хоть какой-никакой реальный опыт.
Захотят - потом к нам придут, не захотят - всегда подтвердим определенные навыки, если человек их действительно получил.
А вот требования да, иногда к джуну требования как к сеньеру в вакансиях.
А ЗП даже ниже рынка при этом :)
Благодарю за ответ, давайте тогда пробовать разбираться по элементам :)
Предположим, что я внешний разработчик (компания) и веду разовые работы на своем компанейском git.
В определенный момент мне потребуется полностью все передать в git заказчика (сдать работу).
Мне свой git поддерживать уже не имеет смысла (работа сдана).
Так как все ваши пути "до ресурса" будут залинкованы на мой git, то в определенный момент вы, как заказчик, имеет серьезный риск потери всех картинок.
При этом перелинковка потребует значительных усилий, так как по сути нужно будет поменять каждую ссылку в документе (по сути ревизия всей документации).
А бизнес не платит за переделку документации к рабочему продукту :)
Видео - интересная идея.
Однако хранить документацию (а видео тут выступает в этом контексте) на внешних хранилищах вообще недопустимо, как минимум с точки зрения ИБ.
Ни один сервис не гарантирует вам недоступность вашей ссылки.
Как итог - есть неплохой шанс открыть всему миру полное описание того, как работает сервис на уровне админа, что дает хороший такой вектор атаки для хакера.
Из практики:
юзер флоу без дизайна (хотя бы в виде набросков) - путь к переделкам.
Текстовое описание никогда не сможет конкурировать с примитивным макетом в силу того, что менеджеры на стороне заказчика являются простыми менеджерами, а не техническими специалистами.
Им требуются картинки для наглядности и согласования.
Чисто текстовое описание приводит к разрыву "ожидание-реальность", что по итогу может сорвать вообще весь проект.
Теперь представьте простого среднестатистического менеджера, которому вы говорите "Сходите в гит, в ветку dev_v1.1.1, сделайте pull изменений к себе, чтоб получить обновление документации по вашей фиче".
Все что будет понятно менеджеру - слово "документация" и ответом менеджера станет "пришлите на почту".
Пользоваться гитом простой менеджер заказчика не будет, а документация при этом ему требуется.
На это я ранее и указывал, что документация в маркдаун - это документация для технарей, но, к сожалению, ее сложно приспособить для нужд менеджеров или юристов.
Они мыслят pptx и doc, к сожалению.
Отсюда и все ТЗ во всех тендерах в виде doc-файла и pdf.
И с этим требуется как-то дружить :)
В любом случае спасибо за продукт,
думаю, что он уже занял свою определенную нишу или займет ее далее.
Мои комментарии - это больше история про универсализацию продукта.
На данный момент мне кажется, что этот продукт больше подходит для технарей (внутренней документации) и полностью не подходит для заказчика (в силу того, что он не сможет с ним адекватно взаимодействовать).
Как итог, придется вести двойную документацию, что нарушает саму концепцию единого документа для всех.
Однако мое мнение субъективно и пока основывается лишь на вашем описании в статье и комментариях.
Как будет время - изучу поподробнее ваш продукт и, может быть, вернусь с опровержением своих слов :)
Тут загвоздка в том, что у разработчика тоже есть ограничение производительности.
Предположим, что бизнес действительно идет в рост Х2.
Разработчик не может делать в 2 раза больше, значит в какой-то момент он упрется в "вилку" своей ЗП, а далее будет нанят второй разработчик в штат.
Пока он может самостоятельно тянуть процесс - проще ему доплачивать "сверху", чем искать нового спеца с половинчатой нагрузкой.
Опять же, далее вопрос точки взаимных договоренностей.
Бесконечно повышать ЗП нельзя, к сожалению.
Причем "точка стопа" у каждой компании своя.
У кого-то этот предел на 100к, а у кого-то на 800к.
И от крупности компании не зависит вообще :)
Как писал выше - зависит от работодателя.
Кто-то будет снижать ЗП за непродуктивность,
а кто-то учитывает даже инфляцию и гасит хотя бы ее часть ежегодно.