<rmcreative>

RSS

Евгений Россинский про прыгунов

14 января

Когда я занимаюсь наймом, то смотрю в том числе на длительность работы на каждом месте. Если нигде человек не задерживался, это может быть индикатором многих неприятностей.

Об одной из них в интервью рассказал Евгений Россинский, СТО ivi и член ПК Highload и РИТ:

Люди, которые прыгают из одной компании в другую, проработав по году, не отвечают за свои слова. Это значит, что те архитектурные решения, которые они сделали, проверяет кто-то другой. И они не получают того самого опыта, который нужен для жизни долгоиграющего сервиса. Ты устроился работать в компании, проработал там два месяца, написал какой-то сервис или сделал какую-нибудь фичу, а когда эта фича через 7-8 месяцев перешла в суровую эксплуатацию, ты увольняешься. Но кто будет отвечать за то, что эту хрень написал ты?

Комментарии RSS

  1. №12082
    Антон
    Антон 15 янв. 2021 г., 12:39:16

    Для CTO это безусловно справделиво, но для рядовых разработчиков на мой взгляд год на одном месте вполне нормальный срок

  2. №12083
    Sam
    Sam 15 янв. 2021 г., 15:14:56

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

  3. №12084
    Василий
    Василий 18 янв. 2021 г., 13:00:43

    Если человек скачет, то может быть куча факторов. Здесь само по себе предположение, что человек, "не отвечает за свои слова" - ложное. Это одно из, а еще:

    • профессиональный рост быстрее потребностей проекта;
    • не сработался с вышестоящими людьми;
    • нужно больше денег на жизнь (семья появилась, родители вышли на пенсию, и т.п.);
    • большая нагрузка, выгорел;
    • и пр.

    Почему кто-то считает, что обратное (большой стаж на одном рабочем месте) - это, нормально? Может это одно из:

    • не желание что-то менять в своей жизни;
    • пассивность в принятии решений;
    • нерешительность;
    • нежелание обучаться и преодолевать новые возникшие трудности;
    • устаревшие знаний;
    • и т.п.

    Изначальное клеймирование кандидата по самому худшему сценарию, потому что где-то кто-то сказал, что это "важно", как мне кажется, не совсем верная тактика при найме. Вы не тот человек, что перед вами. И по большей части можете только догадываться.

  4. №12085
    Гость
    Гость 18 янв. 2021 г., 20:01:01

    Отвечать будут те, кто эту фичу апрувил, кодревюил и т.д. Давно в компании, получаете выше рядовых сотрудников, ну так несите ответственность...

  5. №12086
    Дмитрий
    Дмитрий 19 янв. 2021 г., 15:01:16

    Это очень большая проблема. Еще раз это доказывают комментарии выше. То есть у людей никакой личной ответственности и "моя хата с краю".

    У нас было несколько таких случаев, когда разработчики приходили, писали фичу и уходили. Был даже момент, когда разработчик ушел, еще не дописав фичу.

    Это очень странно. В целом, больше года никто не задерживался.

  6. №12087
    Sam
    Sam 19 янв. 2021 г., 19:13:33

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

    Но вообще при найме лучше не нанять, чем нанять не того.

  7. №12088
    Василий
    Василий 19 янв. 2021 г., 21:10:16

    Дмитрий, как Вы связываете личную ответственность и знание тонкостей бизнес-логики проекта? Я думаю многие, кто приходит в приносящие прибыль проекты, где каждое изменение не должно нарушать покупательский потенциал, мало чего знают о том, как вся эта кухня работает. А когда пул-реквест сливают в продакшен и у вышестоящих людей появляются претензии, то, мягко говоря, это не совсем верный подход к работе и ответственность хромает явно не у разработчика, кто этот код написал.

    Эта тема тонка до безобразия. Александр хороший топик сделал под трафик.

  8. №12089
    Гость
    Гость 26 янв. 2021 г., 23:04:45

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

  9. №12090
    Sam
    Sam 27 янв. 2021 г., 12:16:47

    значит он вас устраивает на этом точка

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

  10. №12091
    Дамир
    Дамир 29 янв. 2021 г., 15:17:51

    Полностью с Сашей согласен. Раньше я верил что у меня чуйка при найме людей, но чем больше нанимаешь, тем больше, понимаешь, что интервью - это не показатель того как в работе человек будет себя вести. Могут быть ситуации разные в проекте, где каждый ведет себя абсолютно по-разному.

    И да, как показывает мой опыт, люди надежные обычно работаю от 3 лет на одном месте. За это время человек в целом попробует вкусить рутины, и если остается, значит он не из тех кто перемещаются от работы к работе - тут надоело, там стало скучно. Я такое не осуждаю, но нанимать мне хочется тех кто может работать в разных условиях.

  11. №12092
    X Y Z
    X Y Z 31 янв. 2021 г., 12:46:27

    лично. работал и с новыми и с старыми проектами.

    я в бизнесе 12 лет на разных ролях в разработке. максимум работал 3 года в одной компании. в среднем 1-1.5 года. Учитывая возрастающее количество неадекватных в сфере в геометрической прогрессии, то один год в одной компании уже становится роскошью. Как раз за 1 год понимаешь - есть у компании шанс или нет. Исключение, если очень повезло с сотрудниками на всех уровнях в компании, но я такого не видел, всегда есть компромисс. И всегда этому компромиссу приходит конец в момент, когда с тебя требуют отвечать за результат, при этом со своей стороны не неся никакой ответственности за бизнес решения, точнее, вообще не отбивая дупля почему оно работает именно так и почему такой бизнес процесс вообще существует. Только не надо мне рассказывать, что это обязанность разработчика, это обязанность СТО.

    Потому на данный момент считаю "прыгающими" тех, кто работает 6 месяцев и меньше. Примерно, понять средний проект - это 3 месяца, фактическая работа с ответственностью - это 3 месяца получается. Если работать 9 месяцев - то это еще 3 месяца поддержки. Этого времени вполне хватает, чтобы понять в какой пздц ты попал, или наоборот тебе повезло. Насчет архитектуры - если разработчик, который у вас работает на живом прибыльном проекте меньше года отвечает за архитектуру, то я видел таких СТО и такие компании. Работать с ними, то еще удовольствие, никакая оплата не компенсирует такого выгорания. Пускай расскажет это индусам в Майкрософт, хочу на это посмотреть.

    Если в статье речь идет о так называемых startup, где выживаемость на уровне 0.0001%, то там никакой архитектуры нет, она там и не нужна особо. Реальность жизни - проекты переписываются с нуля в случае успешного старта. На разных этапах работают разные типы разработчиков. Я работал на всех этапах. Бичь всех компаний - ноль документации.. привет, СТО!

    подытожу, такие СТО получают свою зарплату незаслужено и всегда съезжают если припекает. Видел я таких. При первом уходе основного разработчика или пары с костяка - этот СТО полетит как фанера над Парижем. Что самое смешное, они как правило стоят за решениями об увольнении разработчиков с костяка. И меня так увольняли. И видел как других увольняли. И наблюдал весь пзд"ц после этого.

    так что ох и ах, всё сказки для малышей. И да, СТО, если читаешь этот комментарий, то быстренько беги читай требования на вакансию, которую выставляет твой HR менеджер, и удаляй строки "командная работа", "код ревью", "CI/CD", "тестирование", и свою должность можешь переименовывать как минимум в Product Owner, а лучше в Product Manager.

    успехов

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.