Статья в целом хороша - и про ИТ стратегию для найма, и про обратную связь между результатами найма и процедурой найма и главное - про задание на умение рассуждать и решать проблемы.
Смущает два момента:
Отсюда, на мой взгляд, можно определить ЧТО мы ищем, и отсюда вытекает следующих набор навыков, которыми должен обладать кандидат:
Некоторые базовые знания и умения. (Большую часть этих знаний и умений получают в профильных вузах. Доверять им или нет — дело личное. Можно проводить только sanity check.) В эти знания и умения обычно входят базовые алгоритмы и структуры данных, знание хотя бы одного языка программирования и некий общий кругозор.
и
Мой топ бесполезных вопросов, которые задают на интервью:
Расскажите как работает GC в Java.
...
Как работает Hashmap?
Разве это не базовые знания? На этих вопросах можно проверить понимание зачем нужен hashcode, основы оптимизации. Даже если человек все заучил - подловить его можно. А если так заучил, что не подловишь - значит он это понял)
И второй момент:
Если в западных компания ценится самостоятельность и открытость, а также соблюдением правил, то в России могут цениться исполнительность, послушание и следование традициям. В США люди предпочитают быть вежливым и опасаются оскорбить человека правдой, в России же предпочитают правду вежливости. В США развита культура общения намеками и полунамеками, в России же предпочитают прямоту.
Искренность с полунамеками vs правда???) Следование традициям и послушание??? Разве что в филиале условной Toyota до того как она ушла) Или в компаниях с гос.менеджментом, но это совсем не типовой кейс для российского ИТ. Абзац выглядит инородным в статье.
Зачем писать: знание git, если стандартные шаги на нем учатся за полдня? (да, понимание придёт позже, но чел сможет реально работать с git после чтения короткого readme) И совсем смешно, когда пишут: опыт с Jira, Confluence. Вы серьезно? А без опыта прям никак? С полпинка не разберусь минут за 5?
Так и кандидаты есть, которые так пишут. Джуны и джуно-миддлы в основном. Получается, они созданы друг для друга)))
Что касается общительности - смотря в какую компанию. Если от разраба требуется только кодить - возьмут. А если 20-40% - это разбор багов на тестовых стендах, общение с сопроводами и DevOps, уточнение с аналитиком собственно аналитики, дейли, планирования, ретро (Agile) - скорее нет. А как понять, что Вы это сможете?) Ясно, что разработчик - это не продавец, но отвечать односложно на в все вопросы на интервью - лучше не надо)
Лично я полностью с этим тезисом согласен. Но повторюсь - вижу большую проблему в том, что команда ИБ часто "закрывается в себе", все приходящие от них требования для разработчиков не прозрачны, но при этом ИБ считает, что процесс выстроен правильно. Хотелось бы движение навстречу с обоих сторон.
Мысль "давайте чаще встречаться" - верная, двумя руками за. Но кажется, что этого мало. Разработчики редко думают о векторах атаки, поверхности атаки, моделях угроз, безопасности by design. Увы, но это факт. Поэтому их нужно учить - это раз. Как это сделать без отрыва от производства или с минимальным отрывом - отдельный вопрос. А после этого любые требования по безопасности не просто предъявлять, а объяснять - мы запрещаем вот это, потому что ... Проводить встречи, митапы. Если есть понимание важности требования, то острота конфликта снижается
Самое ценное в статье для меня - выяснил, что Microsoft влил свои изменения в master git и теперь этим могут пользоваться все.
Что касается вопроса - кому это нужно? Как выясняется, нужно монолитам, играм и большим мобильным приложениям. Хотя пример Гугла, Яндекса, Юлы, ... говорит о том, что даже с микросервисной архитектурой люди идут в монорепы для большего контроля над кодом.
Но если есть такая возможность - не используйте монорепы. Окей, git допилили под большие объемы. Но еще есть утилиты сборки, CI pipeline, статический анализ кода, IDE. Что-нибудь, да сломается)
IMHO сеньор - это в первую очередь архитектура, разработка "ядра", обучение новичков и контроль качества кода. Плюс решение каких-то сложных проблем. Но по факту вполне могут повесить обязанности тимлида. Вообще в отрасли большая путаница с уровнями сеньор, тимлид и техлид. Не говоря уже о тех, что выше.
Как правильно замечено в статье - для успешной разработки недостаточно знать некий набор правил/навыков. Стек постоянно эволюционирует, появляются новые языки, существует тысячи библиотек и т.д. Т.е. грубо говоря разработчик должен уметь думать и находить решения самостоятельно. И наличие ВО в сильном ВУЗе по технической специальности я бы рассматривал как фактор, повышающий вероятность этого. И, соответственно, как один из критериев для фильтрации резюме. В случае прочих равных и при наличии большого числа кандидатов. Естественно, ВО - это не гарантия. И ИТ кафедра как по мне играет меньшую роль, чем ВУЗ.
Статья в целом хороша - и про ИТ стратегию для найма, и про обратную связь между результатами найма и процедурой найма и главное - про задание на умение рассуждать и решать проблемы.
Смущает два момента:
и
Разве это не базовые знания? На этих вопросах можно проверить понимание зачем нужен hashcode, основы оптимизации. Даже если человек все заучил - подловить его можно. А если так заучил, что не подловишь - значит он это понял)
И второй момент:
Искренность с полунамеками vs правда???) Следование традициям и послушание??? Разве что в филиале условной Toyota до того как она ушла) Или в компаниях с гос.менеджментом, но это совсем не типовой кейс для российского ИТ. Абзац выглядит инородным в статье.
Так и кандидаты есть, которые так пишут. Джуны и джуно-миддлы в основном. Получается, они созданы друг для друга)))
Что касается общительности - смотря в какую компанию. Если от разраба требуется только кодить - возьмут. А если 20-40% - это разбор багов на тестовых стендах, общение с сопроводами и DevOps, уточнение с аналитиком собственно аналитики, дейли, планирования, ретро (Agile) - скорее нет. А как понять, что Вы это сможете?) Ясно, что разработчик - это не продавец, но отвечать односложно на в все вопросы на интервью - лучше не надо)
Лично я полностью с этим тезисом согласен. Но повторюсь - вижу большую проблему в том, что команда ИБ часто "закрывается в себе", все приходящие от них требования для разработчиков не прозрачны, но при этом ИБ считает, что процесс выстроен правильно. Хотелось бы движение навстречу с обоих сторон.
Мысль "давайте чаще встречаться" - верная, двумя руками за. Но кажется, что этого мало. Разработчики редко думают о векторах атаки, поверхности атаки, моделях угроз, безопасности by design. Увы, но это факт. Поэтому их нужно учить - это раз. Как это сделать без отрыва от производства или с минимальным отрывом - отдельный вопрос. А после этого любые требования по безопасности не просто предъявлять, а объяснять - мы запрещаем вот это, потому что ... Проводить встречи, митапы. Если есть понимание важности требования, то острота конфликта снижается
Самое ценное в статье для меня - выяснил, что Microsoft влил свои изменения в master git и теперь этим могут пользоваться все.
Что касается вопроса - кому это нужно? Как выясняется, нужно монолитам, играм и большим мобильным приложениям. Хотя пример Гугла, Яндекса, Юлы, ... говорит о том, что даже с микросервисной архитектурой люди идут в монорепы для большего контроля над кодом.
Навскидку: https://habr.com/ru/companies/yandex/articles/469021/ и https://habr.com/ru/companies/oleg-bunin/articles/531632/
Но если есть такая возможность - не используйте монорепы. Окей, git допилили под большие объемы. Но еще есть утилиты сборки, CI pipeline, статический анализ кода, IDE. Что-нибудь, да сломается)
Ну тут можно смапить на стажёр, джун, миддл, сеньор. Но путаницы добавляет, да
IMHO сеньор - это в первую очередь архитектура, разработка "ядра", обучение новичков и контроль качества кода. Плюс решение каких-то сложных проблем. Но по факту вполне могут повесить обязанности тимлида. Вообще в отрасли большая путаница с уровнями сеньор, тимлид и техлид. Не говоря уже о тех, что выше.
В первом Docker файл опечатка - ENTRYPOINT else
Как правильно замечено в статье - для успешной разработки недостаточно знать некий набор правил/навыков. Стек постоянно эволюционирует, появляются новые языки, существует тысячи библиотек и т.д. Т.е. грубо говоря разработчик должен уметь думать и находить решения самостоятельно. И наличие ВО в сильном ВУЗе по технической специальности я бы рассматривал как фактор, повышающий вероятность этого. И, соответственно, как один из критериев для фильтрации резюме. В случае прочих равных и при наличии большого числа кандидатов. Естественно, ВО - это не гарантия. И ИТ кафедра как по мне играет меньшую роль, чем ВУЗ.