Евгений Россинский про прыгунов
14 января 2021
Когда я занимаюсь наймом, то смотрю в том числе на длительность работы на каждом месте. Если нигде человек не задерживался, это может быть индикатором многих неприятностей.
Об одной из них в интервью рассказал Евгений Россинский, СТО ivi и член ПК Highload и РИТ:
Люди, которые прыгают из одной компании в другую, проработав по году, не отвечают за свои слова. Это значит, что те архитектурные решения, которые они сделали, проверяет кто-то другой. И они не получают того самого опыта, который нужен для жизни долгоиграющего сервиса. Ты устроился работать в компании, проработал там два месяца, написал какой-то сервис или сделал какую-нибудь фичу, а когда эта фича через 7-8 месяцев перешла в суровую эксплуатацию, ты увольняешься. Но кто будет отвечать за то, что эту хрень написал ты?
Комментарии RSS по email OK
Для CTO это безусловно справделиво, но для рядовых разработчиков на мой взгляд год на одном месте вполне нормальный срок
Антон, смотря какая ответственность у разработчика. Если он просто пишет код чётко по готовой архитектуре, не стоит обращать внимания. А если затрагивает архитектуру, то лучше чтобы он в прошлом видел последствия своих решений.
Если человек скачет, то может быть куча факторов. Здесь само по себе предположение, что человек, "не отвечает за свои слова" - ложное. Это одно из, а еще:
Почему кто-то считает, что обратное (большой стаж на одном рабочем месте) - это, нормально? Может это одно из:
Изначальное клеймирование кандидата по самому худшему сценарию, потому что где-то кто-то сказал, что это "важно", как мне кажется, не совсем верная тактика при найме. Вы не тот человек, что перед вами. И по большей части можете только догадываться.
Отвечать будут те, кто эту фичу апрувил, кодревюил и т.д. Давно в компании, получаете выше рядовых сотрудников, ну так несите ответственность...
Это очень большая проблема. Еще раз это доказывают комментарии выше. То есть у людей никакой личной ответственности и "моя хата с краю".
У нас было несколько таких случаев, когда разработчики приходили, писали фичу и уходили. Был даже момент, когда разработчик ушел, еще не дописав фичу.
Это очень странно. В целом, больше года никто не задерживался.
Василий, так я и пишу что "может быть индикатором многих неприятностей". Это не обязательно так. Это значит что нужно обратить на этот момент внимание и выяснить причины.
Но вообще при найме лучше не нанять, чем нанять не того.
Дмитрий, как Вы связываете личную ответственность и знание тонкостей бизнес-логики проекта? Я думаю многие, кто приходит в приносящие прибыль проекты, где каждое изменение не должно нарушать покупательский потенциал, мало чего знают о том, как вся эта кухня работает. А когда пул-реквест сливают в продакшен и у вышестоящих людей появляются претензии, то, мягко говоря, это не совсем верный подход к работе и ответственность хромает явно не у разработчика, кто этот код написал.
Эта тема тонка до безобразия. Александр хороший топик сделал под трафик.
После сделаного офера уже компания должна понравиться работнику. Раз вы взяли сотрудника значит он вас устраивает на этом точка. При найме на работу работник не может знать всех порядков в компании и если он ушел, значит его что-то не устроило. Компания в глазах работника также проходит испытательный срок как и работник в глазах компании. По поводу после года никто не задерживался, ну так разберитесь в чем у вас проблема в компании, раз есть текучка.
Нет, это так не может работать. По интервью не понять, насколько будущий сотрудник отвественный и насколько он впишется. Например, у меня был эпический провал когда в свой второй день сотрудник просто не вышел... ушёл в запой. На собеседовании при этом показал себя замечательно.
Полностью с Сашей согласен. Раньше я верил что у меня чуйка при найме людей, но чем больше нанимаешь, тем больше, понимаешь, что интервью - это не показатель того как в работе человек будет себя вести. Могут быть ситуации разные в проекте, где каждый ведет себя абсолютно по-разному.
И да, как показывает мой опыт, люди надежные обычно работаю от 3 лет на одном месте. За это время человек в целом попробует вкусить рутины, и если остается, значит он не из тех кто перемещаются от работы к работе - тут надоело, там стало скучно. Я такое не осуждаю, но нанимать мне хочется тех кто может работать в разных условиях.
лично. работал и с новыми и с старыми проектами.
я в бизнесе 12 лет на разных ролях в разработке. максимум работал 3 года в одной компании. в среднем 1-1.5 года. Учитывая возрастающее количество неадекватных в сфере в геометрической прогрессии, то один год в одной компании уже становится роскошью. Как раз за 1 год понимаешь - есть у компании шанс или нет. Исключение, если очень повезло с сотрудниками на всех уровнях в компании, но я такого не видел, всегда есть компромисс. И всегда этому компромиссу приходит конец в момент, когда с тебя требуют отвечать за результат, при этом со своей стороны не неся никакой ответственности за бизнес решения, точнее, вообще не отбивая дупля почему оно работает именно так и почему такой бизнес процесс вообще существует. Только не надо мне рассказывать, что это обязанность разработчика, это обязанность СТО.
Потому на данный момент считаю "прыгающими" тех, кто работает 6 месяцев и меньше. Примерно, понять средний проект - это 3 месяца, фактическая работа с ответственностью - это 3 месяца получается. Если работать 9 месяцев - то это еще 3 месяца поддержки. Этого времени вполне хватает, чтобы понять в какой пздц ты попал, или наоборот тебе повезло. Насчет архитектуры - если разработчик, который у вас работает на живом прибыльном проекте меньше года отвечает за архитектуру, то я видел таких СТО и такие компании. Работать с ними, то еще удовольствие, никакая оплата не компенсирует такого выгорания. Пускай расскажет это индусам в Майкрософт, хочу на это посмотреть.
Если в статье речь идет о так называемых startup, где выживаемость на уровне 0.0001%, то там никакой архитектуры нет, она там и не нужна особо. Реальность жизни - проекты переписываются с нуля в случае успешного старта. На разных этапах работают разные типы разработчиков. Я работал на всех этапах. Бичь всех компаний - ноль документации.. привет, СТО!
подытожу, такие СТО получают свою зарплату незаслужено и всегда съезжают если припекает. Видел я таких. При первом уходе основного разработчика или пары с костяка - этот СТО полетит как фанера над Парижем. Что самое смешное, они как правило стоят за решениями об увольнении разработчиков с костяка. И меня так увольняли. И видел как других увольняли. И наблюдал весь пзд"ц после этого.
так что ох и ах, всё сказки для малышей. И да, СТО, если читаешь этот комментарий, то быстренько беги читай требования на вакансию, которую выставляет твой HR менеджер, и удаляй строки "командная работа", "код ревью", "CI/CD", "тестирование", и свою должность можешь переименовывать как минимум в Product Owner, а лучше в Product Manager.
успехов