Pull to refresh

Comments 20

— 70 человек вам хватает?
— Нет. У нас план взять за год 20 DevOps-инженеров минимум.
Вот это бодрые и очень адекватные планы, так держать! 70 человек в 90. Сразу вспомнил, что Додо-пицца хочет нанять +250 разработчиков к своим 50, потому-что: «300 много, а 250 нормально».
Всякое бывает… Мы вот недавно писали про Reddit, где:

В начале 2016 года у сервиса, реализованного в виде монолитного приложения, было всего около 20 инженеров [..] Однако этот год принёс большие перемены: уже к его концу в компании работали более 60 инженеров (а к концу 2018-го года их число увеличилось до 200, т.е. всего за 3 года случился 10-кратный рост штата).

И всё выглядит так, что ребята ещё на плаву ;-) Но этой кадровой революции внутри компании сопутствовала и технологическая…
Кстати обновлённая версия реддита до сих пор сильно глючнее старой, у меня постоянно не прогружаются части страницы и в целом всё грузится медленнее. Но красиво, да
мы стремимся платить полностью московскую зарплату в регионах

Это действительно здо'рово и здраво для духа команд! Вообще все описанное устройство компании — как научно-популярная фантастика) Дальнейших успехов!
Здорово, что ребята развиваются. Был опыт сотрудничества, пока работал в futurico, одни позитивные эмоции, с тех пор всем их советую.
Наш тест довольно долгий, у среднего кандидата, он занимает 8 часов.

Много где был на фейс ту фейс но по 8 часов ни разу.

У нас реально год за три по опыту и скиллам.

А вот это ну очень сомнительно. И почему каждая компания считает что именно ИХ проекты самые сложные.
Флант
По сути ничего нового, обычный аутсорс, а скорее всего еще и скрытая реклама Флант.
Много где был на фейс ту фейс но по 8 часов ни разу.

С определённых (и уже довольно давних) времён тест у нас проводится удалённо. О своём прогрессе/результате кандидаты пишут в Slack.
8 часов на тест по Linux, который состоит из множества вопросов. На позицию DevOps. Весьма любопытно, что же туда можно аж на 8 часов напихать.
А есть ли у вас возможность пошарить это тест? Можно даже с измененными вводными, один вариант, так сказать. Прям интересно стало, что же там такого на полный рабочий день плотной работы. Если там нет задачки «напиши приложение, которое...», то совсем непонятно что может так долго занимать.
Спасибо за ссылку, посмотрел. В целом понятно, ничего особенного, обычный кейс «мы все специально поломали, теперь почини». Жаль, я думал что-то более оригинальное и близкое к современной реальности, кубик там поднять в хитрой конфигурации или canary сделать веб-сервису управляемое.
Известный нам рынок труда ещё не готов к тому, чтобы требовать от каждого неплохих практических знаний Kubernetes на старте работы в компании… :-) Этому мы уже обучаем внутри. Сборка/запуск приложений, впрочем, вполне близки к реальности, при этом компетенции — более массовые.
В вашей статье про тестовое задание скриншот выглядел так, что там как будто даже не в контейнерах все. Это кстати распространенная проблема, когда люди вроде как более-менее знают Linux, но совершенно не понимают как работаю контейнеры-орекстрация-лимиты и вот это все, что порождает проблемы (и франкенштейнов) пострашнее чем кривые настройки apache. Поэтому-то и мне показалось это отдаленным от реальности, т.к. система не должна пребывать в состоянии, данном в тестовом задании и этого можно успешно избегать. Наводит на мысль что работка на 80% состоит из разгребания того, что нагородили до тебя при условии что координально ничего менять нельзя. Как-то пугает.

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

У вас сейчас десять человек, а надо 11. Вот 500 тысяч на одиннадцатую позицию

так 500 это за что? за поиск + адаптация?
Поиск сотрудника происходит усилиями HR'а и к этому не относится. Речь про адаптацию. Эта сумма — фактически ЗП нового члена команды на испытательный срок, но устроено всё таким хитрым образом (вместо прямой оплаты этой ЗП из «федерального бюджета» компании, как было раньше), чтобы сама команда была мотивирована минимально рисковать и брать людей, в которых она уверена/которые ей подходят. (Команда сама принимает решение о том, берёт ли такого-то найденного и протестированного человека к себе.)
В чем разница между тем что директор выдаст зарплату или команда? Разве в обычной компании тимлид не влияет на подбор сотрудников?!

Большая разница — мы это наблюдаем на практике. Появляется бОльшая автономность, перераспределяется ответственность. Тимлид не просто влияет на подбор (и не только сотрудников, но и новых клиентов), а именно принимает решение (вместе со своей командой — обычно привлекается хотя бы его заместитель), тут же и обратная сторона — отвечает (перед командой) за последствия. Команда может регулировать распределение финансов, в команде становится более прозрачным влияние работы каждого на общий результат.

В чем автономность? Команда может и не заплатить сотруднику?! Или приятно подержать чужие деньги в руках и почувстаовать власть их отдать?
В статье рассказано, как девопс-команды тратят деньги и как работают над текущими проектами. Но ни слова о том, кто находит новых клиентов, продаёт новые проекты, занимается пиаром и тп. Это не «команды сами управляют деньгами», это «команды сами тратят деньги». Всё ли есть у этих команд на случай, если «5-6 нетехнических людей» уйдут из компании?
Тема поднята хорошая, но просто невозможно охватить всё и сразу в интервью (тут вопрос больше о его целях у самих авторов).

«5-6 человек уйдут из компании» — это же вряд ли сразу случится (а если столько же инженеров сразу уйдут, тоже хорошего мало). И вообще: когда люди уходят, им находят замену, разве нет? :-) Поэтому в таком срезе вопрос немного странный.

В целом же, вот ещё несколько тезисов по теме:

  • Хорошо поставленный процесс означает, что он будет (пусть хуже и какое-то время, но будет) продолжать работать и в случае ухода некоторых людей. Т.е. клиенты не перестанут сразу же к нам приходить даже в том случае, когда ключевой(ые) человек внезапно уйдёт.
  • Отдельные подразделения маркетинга, продаж для каждой команды — это большой overhead. Когда это разделяемый ресурс, всё получается очень красиво. По крайней мере, в наших масштабах и процессах сейчас это так.
  • Команды участвуют и в маркетинге, и в продажах. Не на всех этапах, конечно, но всё же. Тимлиды встречаются с потенциальными клиентами (чтобы обсуждать технические вопросы). Инженеры, например, помогают со статьями на хабру, описывая свой опыт. Есть ещё доклады на конференциях, где тоже задействованы представители команд.
Sign up to leave a comment.