Нулевой километр (Хекслет)

Hexlet (00:00.046)
У меня название очень знакомое, я зашел в почту, загуглил и действительно меня есть письма от, видимо, ваших сотрудников. Есть меня предложение карьерное от Товбайта. Сколько всего темлядов? На 10 человек? Сейчас у нас темлядов, наверное, больше чем нужно. У вас вообще часто бывают задачи, которые надо сделать вчера. Не только добавляем код, а савельев мы также достаточно агрессивно удаляем. Да, интересные темы...

Разный по-разному делает, мы стараемся делать как такая молодая, развивающая прогрессивная компания.

Hexlet (00:42.446)
Всем привет, на связи Хекслет, с вами Александр Русков. Сегодня нас распаковка компании Tough Byte. У нас в гостях Дмитрий Матвеев, технический директор компании и Олег Подсечин, ее основатель и, как я понимаю, руководитель. Ребята, привет. Привет. Скажите, пожалуйста, в двух словах, не зная, кому сейчас будет проще, чем вообще занимается компания для тех, кто они пока ничего не знают. Да, я мог поначать. мы в Tough Byte занимаемся техническим рекрутингом, то есть помогаем разработчикам.

найти работу. Но работаем мы не просто как агентство, а мы строим свою платформу, которая автоматизирует эти процессы, помогает нам делать это быстрее, более эффективно и представляет сервис более высокого уровня как и кандидатом, так и клиенту. Работаем мы в первую очередь с клиентами в Европе.

Но у нас также есть несколько клиентов в Штатах. а кандидаты у нас как бы со всего мира, но большинство кандидатов из русскоговорящих стран. Вот, ну и соответственно из Европы тоже. Если я правильно понял, вы предоставляете цифровой продукт для рекрутёров, для компаний, которые занимаются сотрудников, соответственно для сотрудников, которые хотят найти работу. То есть некая автонизированная платформа поиска предложений. Верно я понял? Да, и нам компании платят за...

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

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

Hexlet (03:09.87)
серьезные, поэтому, наверное, какие-то процессы вас тоже есть. Да, у нас структура такая, что именно в глобальном смысле есть какие-то две основные ветви. Это продукты, мы, и есть те, кто пользуется продуктом. В продукте у нас есть Олег, он является главным за идеи. Они вместе с Антоном генерят идеи. Мы их потом описываем технически, дизайнер понятно, чем занимается, и мы, как инженеры, занимаемся какой-то импрементацией. Сейчас у нас устроено так, что

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

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

Привлекаем мы людей джиннер уровня, есть люди без опыта абсолютно, мы полностью их взращиваем. В основном люди, ну наверное, сколько вот они останутся до такого уровня, они и дорастают. Мидл, Мидл Плюс у нас тоже есть люди. Я могу быть Мидл Плюс, или может быть Синьор Минус, Синьор, я не знаю, как это в других компаниях. Вот какой-то такой уровень мы стараемся как-то объединяться в плане знаний, стараемся...

какие-то знания шарить. У нас есть выступления еженедельные. Вот как-то таким образом потихонечку передаём знания более опытных к менее опытным. Наверное, важный вопрос, который мы немножко пробусили. А на каком вообще стеке вы работаете? Что за инженерный предмет, скажем так? Стэк у нас рельсы. Рельсы, последние. Я вот только сегодня выкатил седьмые рельсы. Был сложный апдейт на самом деле. Ruby тоже последний. 3.1.

Hexlet (05:26.318)
Рельсы у нас на Webpacker, мы пока не собираемся на Import Map переходить, но с Webpacker она тоже нормально. Диплой у нас идёт на Heroku базу данных, Postgres тоже в Heroku менеджится, и коллаборация через GitHub. есть налаженные тесты, CICD, это всё, rolling release, то есть... ну rolling release, наверное, нет слова, но мы каждый пушив мастер выкатываем сразу в продакшн, и так как у нас

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

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

Ну, как сказал Олег, сейчас у нас где-то 60-70 человек. Получается, что пользуются нашими ресурсами где-то 50 человек. В основном это какая-то сложная бизнес-логика. Есть несколько таких аналитических кверит, которые долго идут. Это, как, например, матчинг кандидата и позиции. Там через скелы какие-то, через локации. Это все стараемся учитывать.

Пока пользуемся нормально, нету там задержек, в хироку, 5 секунд надо ждать, чтобы появилось. У нас как-то более-менее секундочка мы стараемся держаться в таком вот плане. Насчёт, проектов, у нас есть один основной, есть какие-то поменьше проекты. Вот флагманский проект, сейчас там где-то 70 ка строк, не слишком большой, а не слишком маленький. Планы по какому-то скелингу, пока больших прям планов нет из-за того, что у нас всё-таки...

Hexlet (07:52.142)
Не какой-то там B2C рассчитан на миллион пользователей, у нас относительно мало записей базы данных, где-то вот к миллиону приближаются таблички наши. Так что пока каких-то проблем с данными нет, основной проблем именно с SQL запросами, которые требуют какие-то подробные такие полуаналитические квери-анализы. Да, звучит знакомо на самом деле. Может быть, я еще могу добавить, что когда Дима говорит, что у нас там 50 пользователей,

Если сделать шаг назад, на самом деле у нас есть три категории пользователей. есть у нас есть наши рекруторы с SalesAid, которые самые активные пользователи. есть они с утра до вечера используются и используют самый сложный функционал нашей платформы. И от них мы получаем самую высокую нагрузку. Но так как они являются частью нашей команды, мы от них также получаем самую быстро обратную связь.

Также у нас есть клиенты. У нас несколько сот клиентов, и у каждого из них по несколько представителей, но они заходят в клиентский интерфейс, может быть, несколько раз в неделю. есть не то, что они с утра до вечера пользуются нашим приложением. Ну и потом у нас есть сами кандидаты. У нас где-то зарегистрировано почти 10 тысяч кандидатов.

Ну и они заходят где-то в среднем раз, может быть в неделю, потому что многие не находятся в активном поиске работы, а просто от нас получают рекомендации о новых интересных вакансиях не чаще, раз в неделю, и заходят посмотреть, о чем мы написали. Но также у нас есть анонимные посетители сайта, и вот мы недавно бы немного продвигали, бы пиарили себя на разных площадках, вроде Hacker.News, в разных телекрам-каналах.

И их иногда бывает достаточно много. есть я смотрел на аналитику в реальном времени. У в какой-то момент на сайте в одно и то же время было около 300 человек. Не злогейных посетителей. Примерно, да. Ту метрику, которую мне было интересно узнать этим вопросом. Понятно. В общем, наверное, называть HighLog у вас было бы немножечко оптимистично. кто знает, кто знает. Да, но понятно, что...

Hexlet (10:18.222)
Живой аудиторий есть, ну, такой средний бизнес, не наколеночный проект, не стартап, можно так сказать. Я, кстати, ну, меня название очень знакомым показалось, я зашел в почту, загуглил, и действительно меня, оказывается, есть письма от, ну, видимо, ваших сотрудников, есть меня предложение карьерное от Тоббайта в том числе. Вернемся немножечко назад, я спрашивал, каких сотрудников вы берете, и вы сказали, что готовы брать людей без опыта. У меня сразу возникает вот...

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

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

И какая-то организационная такая, может быть, растропность можно назвать или щепетильность может небольшая. Такие качества, которые помогают в голове держать много моментов, так как часто Тим Литон такой многозадачный человек. Если мы видим всё это в человеке, то мы стараемся как-то ему. А вот побольше вот здесь, может быть, и по ревью немного, а вот попробуем поментировать этого человека.

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

Hexlet (12:34.638)
Вот, например, такой сигнал может быть хорошим определителем, что человек будет классным темлядом. А как насчет стуки хард-скилов? Насколько он уже готовлен именно в понимании технологий, платформы и вообще системы? Да, это, кстати, хороший вопрос. Мы его сами, на самом деле, недавно переосмыслили. У нас так сложилось исторически, что темляды были еще супер-хардовыми персонажами, которые много проработали в компании.

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

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

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

Команда не является прям совсем независимым юнитом, который работает отдельно от всего. А какие-то там общие решения по поводу архитектурных решений, по поводу продвигаемых технологий. Вот, например, апгрейд на седьмые рельсы был, там, турбостримы, турбодрайв, турбофреймы, вот это всё. Это всё продвигалось на каком-то общем уровне. Я и Team LID, мы собрались вместе, я написал дизайн документы, мы решили, что так будет. Мы это внедряем во все команды, когда мы придумали план.

Hexlet (14:55.95)
Поэтому каких-то прям таких испытаний технических у отдельной команды больших нет. Мы стараемся создать такие условия, можно уже работать по проторенной дорожке. Команде было более-менее просто справляться с такими трудностями, которых ты, наверное, говоришь. И команда как-то более-менее находит место. Насчёт масштабируемости...

Наверное, трудно сказать. Мы стараемся расти органически, наверное, на 50 человек не получится. Если там будет 16 команд, я буду с 16 командами созваниваться, наверное, такого не будет. Прежде всего, это дерево строить иерархией или ещё что-то. Но мы также пользуемся тем, что у нас такая горизонтальная иерархия, и я хотелось бы её тоже сохранить. Вот будет какой-то трудный выбор для нас как раз шевелиться. Согласен. Эти задачи...

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

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

Мне кажется, что есть немножко такое. Раньше я работал в офисе, там рекруты были, и наша продуктовая команда, ну, были близко к рекруторам. Вот что-то не получается. Дим, можешь подойти? Я подойду, мы быстренько решаем проблему, и всё как-то очень просто получается. Сейчас, например, когда общаемся через текст, там какие-то скриншоты, в общем, это гораздо сложнее воспринимается. Я думаю, самим рекруторам тяжелее как-то объяснить, в чём, естественно, проблема заключается.

Hexlet (17:12.974)
Ну и, конечно, человеческий контакт, я думаю, очень сильно из этого теряется. Вроде, пытаются видео придумывать, но лично для меня человеческий контакт важен, так что я, можно сказать, немножко пострадал от отсутствия офиса. Да, я даже не знаю, что добавить, но также есть какие-то плюсы, то есть когда у нас был офис, мы почему-то думали, что как бы нанимать...

новичков без опыта на удаленке это вообще нереально человек должен быть в офисе соответственно мы нанимали людей только из москвы но сразу как нам пришлось работать на удаленке у нас не было выбора начали нанимать как бы людей без опыта на удаленке это пошло на удивление хорошо то есть в плане найма как бы работа на удаленке как бы позволила нам быстрее масштабировать нашу команду разработок

Мы стараемся разными способами компенсировать отсутствие личного общения. Те, кто нас находится в тех же городах, то есть у нас не все разработчики в Москве, а разбросаны по разным городам России и другим странам. Дима в Казахстане, например, находится, я в Хельсинки, Финляндии. например, в Питере у нас достаточно много рекруторов.

как минимум Паша из команды разработки тоже. Вот иногда они там вместе встречаются. Также мы проводили какие-то эксперименты. Например, в слаге есть такая фича «Huddle». Мы пробовали вот эти «Huddle» устраивать голосом. Обсуждать какие-то нерабочие темы. Ну и также, да, мы раз в год встречаемся. У нас есть такой съезд, где все могут с друг другом живую пообщаться.

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

Hexlet (19:39.374)
Ну и мы, может быть, больше ценим в то время, которое мы проводим вместе. Звучит очень знакомо, на самом деле. Но вот мой следующий вопрос был бы, как вы видите дальше, какая вообще стратегия направлений у вас будет? Сейчас вроде как все ограничения пиццепины снимаются. Есть мнение, что уже людей обратно в офис не загонишь. Ну, как бы, может быть, это не так. Я знаю сам, лично, немало людей, которые с удовольствием бы то вернулись. Как вы на это смотрите? Как, вообще, дальше будете поддерживать формат работы? И вот вопрос про мероприятия тоже интересен. Все-таки...

Ну, видеть дозуга надо полезно. Планируете ли вы дальше какие-то мероприятия проводить или делать их чаще, реже или как-то еще, скажем, социализировать свой Мы планируем продолжать работать на удаленке, то есть офис мы открывать не будем, но со снятием ограничений мы будем стараться чаще встречаться как бы в коворкингах в разных городах. У нас, кстати, да, есть еще такая практика, что если член команды приезжает...

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

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

Вернемся к джунам, наверное, трепещий для меня вопрос. Все-таки с тем дайбер разобрались, что касается остальных сотрудников именно разработки. Если вы готовы брать людей без опыта, то на что вообще вы обращаете внимание? Какие критерии будут самыми главными для того, чтобы человек попал в команду? У нас есть стэк, это Ruby, JavaScript, базы данных. Если знает человек, там поверхам хотя бы, это хороший знак, мы постараемся такого человека взять.

Hexlet (22:07.662)
затем как крутятся шестеренки в плане решения задач. Некоторая такая сообразительность. есть, натаскаться на хакер-рэнг, лид-коут, код варрс, общем, такие маленькие-маленькие задачки. Это тоже, я думаю, важно. Необязательно мы не делаем какие-то алгоритмы сложные, и, наверное, я думаю, мало компаний вообще их делают, но это такой показатель того, что у человека хорошо соображалка работает и может какую-то сложную задачку более-менее растаскать, так сказать.

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

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

узнать и вообще сообщить человеку в каком направлении мы хотим двигаться и как ему будет удобно. Интересный момент затронул, что человек должен, мы говорим всё ещё про людей без опыта, что они должны примерно понимать, как писать поятный читаемый код, все прочие пититы, все понимают, в чём у отличие, думаю. А как человек может научиться сегодня от опыта, опять же, абстрактно, чтобы, может быть, ты посоветовал тем студентам, кто хочет этот вариант для себя рассмотреть? Где можно культуру кода почерпнуть?

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

Hexlet (24:33.294)
какие-то локальные правила, style-гайды, и мы стараемся как-то в том числе через комментарии отвечать по pull-request, где вот какая-то ошибочка есть, вот сразу кейсик, можно подметить, что вот здесь вот так он пишем, здесь мы пишем так. Насчет того, чтобы в принципе получить опыт, то, наверное, очень удобно в open-source уйти. Я думаю, что человеку без опыта будет трудновато в том плане, что большой проект,

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

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

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

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

Hexlet (26:54.894)
плане, если будут какие-то недостатки, мы стараемся их узнавать на вананванах и в том числе корректировать наш курс. То есть, если вам не подходит какой-то один способ, мы стараемся найти какой-то другой способ. Пока что не было такого, что кто-то там изыскал умное желание, что мне это не подходит. Наверное, без опыта, когда человек, соглашаешься на всё, потому что хочется всё попробовать. Какая-то такая ситуация получается.

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

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

и JavaScript был как-то вторым делом. Вот вам, если интересен фронт, то, нас будет интересно. То есть мы делаем по стилю Basecamp, стимулусы, это турбостримы, турбофреймы. Вот в таком плане такой. И не статический, и не совсем прям реакт какой-нибудь или ангуляр. Так. Думаю, что насчёт какого-то развития...

Здесь, наверное, всё. По гридам давайте начнём. У нас есть гриды. Относительно недавно мы их составили, наверное, месяца два назад. И у них тоже интересная история, что сначала мы старались подходить индивидуально к повышению зарплаты, к повышению квалификации. Мы придумали писать такие профессиональные планы. Например, вот этот план стать лучше в Ruby. Этот план стать мастером гитар, например.

Hexlet (29:16.494)
И старались вот тебе на полгода три таких плана выполняешь, у тебя повышение зарплаты, например. Словно так. И мы всё это как-то сократили из-за того, что очень много индивидуального подхода, очень много нужно с каждым прорабатывать. И поэтому сейчас мы пришли к грейдам. Мы себе прописали джиннёр, мидл, синьор, укажем по три левла. То есть джиннёр 1-2-3, мидл 1-2-3, также синьор. Мы прописали какие-то...

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

Да, я пробую привести пример из памяти, что я помню. Например, нас Junior 2, он должен, раз, постоянно закрывать issue. него не должно быть больших проблем с этим. Он должен уметь пользоваться как-то тулами, инструментами дебакинга. Он должен...

Наверное, я прям не вспомню дословно, но кратко у нас более-менее какие-то такие специфические. Есть несколько абстратных, есть несколько на личную субъективную оценку темлида, у которого он находится в команде. Но в основном, конечно, стараемся делать их конкретными, и когда вот ванн-он-ванны проходят, раз в месяц по ванн-он-ванну, темлит садится с своим подопечным, и они стараются понять, какая дорога у этого инженера на следующий грейд.

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

Hexlet (31:32.526)
Вот у нас есть бонус, например, если ты, Тим, где-то тебя такой-то бонус, если там менеджер, там на ступеньку повыше, тебя такой-то бонус. И у нас есть списки, каждый, кто занимает какой grade, каждый, кто имеет какой бонус. Так что каждый представляет, кто сколько получает в инженерной команде. Это у нас открыто. Это очень интересный деталь, на самом деле. Я лично всячески поддерживаю, хотя понимаю, что пока это ещё может быть не самая распространенная практика.

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

Олег, может ты начнешь как исток всех наших больших идей? Как идеи у нас рождаются? Хорошо, да. Я попробую кратко описать наши процессы Product Management. У нас есть какой-то план того, в каком направлении мы хотим двигаться.

Да, есть какие-то такие высокоуровневые, достаточно абстрактные цели, которые мы ставим там на полгода, на год вперед. Например, сейчас мы работаем над тем, предоставить клиентам так называемую Self Service Model, чтобы они могли информацию о своей компании, о своих позициях, вбивать в нашу платформу полностью самостоятельно и даже обрабатывать кандидатов тоже без…

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

Hexlet (33:54.574)
Они поступают из разных каналов. Мы проводим собеседование с пользователями. Эти предложения поступают от членов нашей команды и так далее. Мы их как-то собираем, устроим такой как бы backlog-идей. Но мы не ставим никаких жестких дедлайнов, что ровно через 6 месяцев мы должны выкатить такую-то фичу. У нас процесс разработки идет...

То есть описание больших фич идет так называемыми циклами. У Basecamp есть книга называется Shape Up. Мы общем следуем их процессу, который мы немножко под себя кастомизировали. То есть у нас есть циклы, которые сейчас у нас привязаны к месяцам. Это своего рода можно с принтом назвать. И в каждом цикле мы включаем

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

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

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

Hexlet (36:17.518)
отдельная Kanban доска, куда мы добавляем всякие более мелкие задачи, просто как и еще у GitHub. Это задачи, на решение которых уходит от 15 минут до 2-3 дней и больше. И туда тоже входят всякие bug fixes и так далее. И нас эти процессы идут параллельно.

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

Ну да, я, наверное, добавлю, что именно продуктовая часть у нас исходит из этого. У нас также есть дизайнер, который создает issue или там говорит мне, я создаю issue, который относится к дизайну, что-то здесь пофиксить, что-то здесь поправить. Я также участвую в обсуждении. Как Олег сказал, нас Teamlead участвует в разработке пичи. вот я, Саша, наша Teamlead тоже участвует часто в описании всяких…

там созвоны какие-то, с кем-то переговорить, кем-то обсудить такие вещи. И также есть, конечно же, чисто технические вещи, как, например, рефакторинг. За него пока что отвечаю я. Например, нам нужно было меняться на 7-й рельсы, и там нужно было очень много всего нам переписывать. Я там составил дизайн документы, и, например, вот сказал Олег, вот нам январь надо без пичи посидеть на рефакторинге. Да, мы договорились.

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

Hexlet (38:34.958)
Претроспективы у нас тоже такая практика есть. Вот недавно начали, на них тоже всплывают какие-то вещи, которые можно обработать в техническом плане, чтобы было удобнее дальше работать нашим инженером. Я вернусь к самому началу. Я просто выделил себе какие-то ключевые моменты. Вот с чем мы начали? Что есть некие стратегические цели, какие-то планы относительно отдаленные. А вот мне как разработчик, который задачу получает делать, у меня есть вообще понимание того, зачем это делается, куда это приведет и в каком перспективе? Или это остается вот на уровне продуктового планирования?

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

Ну и также, как бы, нас вся эта информация в открытом доступе лежит в одном и том же месте, поэтому все разработчики, если у них есть желание, могут ознакомиться с более долгосрочной стратегией и так далее. Я не уверен, что все это делают, но возможность такая есть. Может быть, стоит еще заметить, что у нас, как бы, иногда мы проводим эксперименты.

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

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

Hexlet (41:01.614)
где мы следим, затем начинается ли это фича пользоваться или нет, стараемся толкать пользователей, чтобы они эту фичу использовали. Но это длится на подержении 6 месяцев или даже дольше. Иногда тоже бывает так, что даже если это была часть нашей стратегии, мы что-то запилили, может оказаться, что это какой-то причине не взлетело, было неудобно.

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

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

Разработчики приходят, они понимают, зачем копать здесь, а не там. А какие-то, может быть, стратегические сессии вы проводите или что-то подобное? Ну, то есть, я не знаю. У вас есть нашел разглот Team Building, может быть, найдем, потому что что-то подобное происходит. Просто интересно. Да, Team Building у нас достаточно такие неформальные встречи. Где Дима играет на гитаре. Рабочие просто не опрезаются. Но да, у нас как бы есть...

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

Hexlet (43:27.566)
и теми, которые влетают. Я уверен, что постоянно, как у всех, вас тоже бывают какие-то сбои, отказы, какие-то трещинки и так далее. В каком формате, как разработчик понимает, чем он оточится, как реализировать свои усилия, где он должен отличиться на какие-то баги, на фиксы или что-то срочное сделать, а где он может идти по плану, который него был запланированный, цикл. Ну, как Олег сказал, нас бывает такое, что цикл — это большие задачи, и пичи, мы их называем.

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

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

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

Тазирую. меня просто в истории разные были случаи. Я могу вспомнить случаи, когда там у компании поменялся генеральный директор и забыли поменять его, убрать его фотографию из раздела «А нас». Это выяснили там спустя два месяца уже люди из высшего менеджмента. И естественно задача уже сразу стала сделать вчера, а точнее два месяца назад. Просто потому что он прощелкает этот момент. Такое как бывает. Business as usual. Просто поэтому интересно, как вы такие штуки хендлите. Вообще приходится с этим пока слакиваться. Или «бог милов» что называется.

Hexlet (45:49.326)
Пока милует, пока милует у нас такое достаточно редко. Ну мы и маленькая компания, у нас достаточно такая отлаженная коммуникация, пока что не страдаем особенно таким, я не припомню. Окей, какие-нибудь, может чуть больше про код поговорим, какие вообще практики вы применяете, какие у вас есть процессы для работы инвесторс-кодом. Что вообще насчет тусирования, да, самый интересный вопрос, как вообще у кем относится, сколько активно унитряете. Ну и соответственно

код-ревью и там похожие вещи, парное программирование может быть что-то из этого, что вам кажется близким, что вы применяете на практике? Да, интересные темы, разные по-разному делают, мы стараемся делать как такая молодая, развивающая прогрессивная компания. У нас есть код-ревью, нас есть тест, у нас есть CICD, у нас есть парное программирование, у нас есть Linter, RuboCop, ESLint. Вот в основном человек приходится делать задачку, выбирается задачку.

Он из каких-то вопросов есть, он задаёт какие-то вопросы либо где-то в чатике, либо в самом задаче на GitHub и начинает это делать. Когда он это сделал, отправляет на код review. У нас проходит код review, TMLite оставляет комментарии, несколько, может быть, раундов. И затем это опрувится, если CI-CD говорит «ок», мы это мержим в мастер, и мастер деплоуется на Heroku. Сразу и рекрутеры пишут, что них что-то сломалось или, наоборот, они довольны. У нас есть также канал Release Notes.

в слаке, где мы говорим рекруторам, что вот такая-то новая фича. Вот посмотрите, вот так она выглядит, вот так ей можно пользоваться. Когда в практике... про тестирование ты спрашивал. У нас нет какого-то такого религиозного отношения к тестированию. Не стараемся держать 100%, даже не стараемся держать 90%. Но такое может быть разумное, можно сказать. 60-70%, я бы сказал, какая-то цифра. Стараемся тестировать все нужные вещи.

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

Hexlet (48:15.182)
Но если что-то не удалось потестировать, мы выкатываем это в Production, мы достаточно быстро об этом узнаем от наших пользователей. это позволяет нам... То есть каждый разработчик отвечает за код, функционал. И в какой-то степени даже за то, что этот функционал будет понятен пользователям. Если, например, в описании задачи что-то...

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

Да-да, Style Guides у нас есть, и они на самом деле маленькие. Там Style Guide, как мы пишем SQL, который внедрён в Ruby, Style Guide, как мы пишем, комментарии. Там здесь вот точку поставить. Style Guide, как мы пишем некоторые вещи в Ruby. На самом деле очень много RuboCop делает автоматически линтер кода. Есть линт для JavaScript, та же самая штука, всё автоматически.

По каким-то таким прям практикам мы смотрели гугловские документы. У них, я думаю, есть прям прекрасные документы по код-ревью. Очень подробно разъяснено, расписано. Мы периодически стараемся обновлять наши знания. Вот недавно нашли какой-то курс по код-ревью. Сейчас Teamlead собирается пройти как раз на следующей неделе такой курс. Что можно ещё по код-ревью рассказать? Ну, кто его проводит и насколько много там нужно одобрений, Вообще, нужны ли они?

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

Hexlet (50:30.638)
том, если большой какой-то pitch, большая фича, то как минимум два человека не знают, если кто-то проревьюил этот код. Какие-то у нас экспериментальные практики мы не пробовали с кодами review. Пока что у нас либо Teamlead, либо какой-то условный код owner, которого мы находим, если какой-то достаточно специфический код. Например, за какие-то email-trading отвечаю я, поэтому я ревью код по email-trading.

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

поэтому она основной контактное лицо для всех кандидатов, которыми мы общаемся. Значит, где она находит? Ну, мы размещаем вакансии в таких Headhunters, в разных Telegram-каналах, сотрудничаем с разными школами для разработчиков, как, например, Hexly. Но на самом деле у нас также есть...

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

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

Hexlet (52:58.446)
Вот, а также мы предлагаем как бы бонус своим сотрудникам, если они найдут кого-то и мы возьмем этого человека в команду. Таким образом мы наняли одного человека. Надеюсь, в будущем это поможет нам нанять еще больше людей. Это основные способы найти новых разработчиков.

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

То ваши потребности соответствуют потребностям рынка или у вас какой-то свой процесс, свой подход, скажем так. Хорошо, я отвечу на второй вопрос. Первым. У нас свой процесс, потому что для интеллигентов мы нанимаем людей с опытом, то есть клиенты ищут медлов, сеньоров, сетевых архитекторов и так далее. Ну и у них часто процессы посложнее.

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

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

Hexlet (55:16.366)
например, разным языкам программирования. есть мы стараемся не то что не стать, а мы не берем в команду людей, которые говорят, что там JavaScript, мне совсем не нравится с ним работать, я совсем не хочу, или там не хочу, но если заставят, буду. То есть Вика у нас такие вещи проверяет, ну и на самом деле она в каком-то плане продает нас или кандидатом, несмотря на то, что это джунны.

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

называется remote interview, она не очень популярна, она аналогична, например, hackerrank или cadility вот таким вот решением. Там мы как бы создали свой формат интервью, но Дима может более подробно рассказать о том, какие мы просто задаем, какие там задачки просим решить и как мы, собственно, оцениваем эти задачи, потому что на самом деле

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

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

Hexlet (57:37.71)
может быть чуть больше информации, чем в резюме указано. И у нас есть тестовое задание, есть какое-то общее впечатление, насколько вообще рассчитывает кандидат. Мы задаем какие-то общие вопросы, заставляем его говорить где-то минут 15, у нас есть общие вопросы, где мы проходим все по верхам. Также у нас сейчас вот готовим такие вопросы, нас возник интересная проблема, то что если мы хотим взять человека сразу на junior level 2 или сразу на junior level 3,

Надо как-то понимать, насколько они на эти уровни наши подходят, согласно критериям, которые там есть. И вот мы хотим подготовить как раз набор вопросов, сразу человека нагреет повыше и задать вопросы, которые помогут именно на эти критерии ответить, а не какие-то общие вопросы общё. И после вопросов у нас есть какое-то техническое задание, Life Coding небольшое, чтобы посмотреть, как он программировал.

потому что были такие случаи, где вот тесты заданий ему помогли написать, и при лайф-котинге как-то очень не получалось решить всё быстро у кандидата. Вот так. Ну, наверное, стрессовка... А насколько вообще объемистая теста задания выдаёте? Само тестовое письменное дома, где-то 80 минут мы на него отводим, но вот я его могу пройти минут, наверное, за 25, что-то такое. На самом интервью стараемся улучшиться в часик, что-то очень простенькое.

Чуть более сложный фейсбаз задаём, и задаём вопросы касательно самого решения. Могут быть вопросы в поводу того, насколько это перформит хорошо, насколько там большая аннотация памяти, перформанс, такие вещи. Не слишком большие, не слишком сложные, потому что стрессовые всё-таки ситуации. Ничего так, вопросы для человека без опыта. Ну может он читал что-то, может читал. Может быть немного о тестовом, то есть...

Как я уже сказал, оно важную роль для нас играет, но и оно разбито на две части. То есть есть одна часть, где там есть вопросы и несколько вариантов, которые проверяют теорию больше. И есть часть, где нужно прямо в браузере писать код, там простенькие бы функции, методы. На рубе. А на это там уходит полчаса, 40 минут, я думаю, где-то так в среднем.

Hexlet (59:57.614)
Но стоит заметить, что далеко не все, кто проходит следующие стадии, проходит тестовая на 100%, так как мы видим запись того, как человек решал задачу, как он интерировал, набирал код и так далее. Если мы видим, что человек самостоятельно двигался в правильном направлении,

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

Это требует хорошего на мой взгляд владения технологиями, чтобы понимать, как правильно описать понимание бизнеса в том числе, тоже не совсем джоновская история. Насколько, скажем так, человек, который входит в команду, насколько он знает, что мы предстоит этим заниматься, насколько он готов и как вообще его может научить? Самый интересный момент для меня лично. Наверное, самого начала мы стараемся поменьше давать, все-таки продуктовая работа, написание это «продуктовая работа» отчасти, и надо какое-то время в продукте хотя бы побыть.

В критериях у нас написано, что где-то от middle уровня 2, кажется, если я помню правильно, нас наконец нужно потихонечку принимать участие при написании. Например, есть pitch, там написано продуктовая часть Олегом, и нужна техническая часть, как это будет выглядеть под капотом, собственно. И может человек этим заниматься. Есть варианты, где у нас есть какие-то задачки, такие локальные задачки. Мы говорим, вот задачка, возьми, создай ищу в GitHub, пиши ее хорошо.

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

Hexlet (01:02:23.118)
какие-нибудь курсы, лидературу. На что сами равняетесь, в том числе интересно знать? У нас нету каких-то прям специфичных для этого методов обучения, в основном всё идёт на опыте. Человек, собственно говоря, начиная с маленьких, у него есть примеры, потому что он в течение того, как выполняет сам issue, он читает это issue, когда он выполняет pitch, он читает эти pitch. У нас для pitch есть структура какая-то. Вот Basecamp, кстати, вот все говорят Basecamp, Basecamp, это ребята, которые рельсы написали, если что.

Вот у них Shape Up книжка, которую они сделали, у них есть структура какая-то, мы её как-то изменили. У нас есть вот такой вот темплейт, что вот мы делаем так pitch, описываем в таком плану. То есть вот это, к сожалению, минимум, который есть, но, к счастью, Олег достаточно много пишет продуктовой части, мы пишем не слишком много продуктовой части, потому что мы просто с этим, может быть, не так много соприкасаемся.

Может быть и будут такие, где мы будем взять продуктовую часть, но я думаю, тому времени, когда это будет, нас уже скилл настолько нарастёт, что мы в принципе без проблем с этим справимся. А вот в плане обучения, вот опыт, смотришь как есть, стараешься делать так же и лучше. А сами вы на кого смотрите? Для вас в том вот вопросе. У меня Олег. Олег, расскажи ты на кого. А я на вас смотрю. То есть если я что-то написал, а потом там задают много вопросов.

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

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

Hexlet (01:04:44.974)
Иногда специально пишем, на JS, несмотря на то, что мы знаем, что этот алгоритм и в хроническом итоге мы должны на Ruby заимплементить, чтобы нам легко было этот прототип потом выкинуть и написать с нуля. В некоторых случаях мы такие маленькие прототипы пишем. На самом деле отсутствие... есть эти вот pitch, может быть, все звучит очень сложно и так далее, но на самом деле...

хорошая письменная коммуникация в формате пичи, правильное общение в слаке — это база успешной работы на удаленке в команде разработки. Умение асинхронно работать, общаться друг с другом. У нас также, помимо one-on-ones, есть практика skip levels, где раз в портал

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

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

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

Hexlet (01:07:02.318)
У нас это рабочий документ, он не должен быть идеальным. есть смысл документации и смысл мокапов мы тоже с дизайнером это проговаривали. Это не создать какой-то идеальный документ или идеальный мокап, а это все инструменты, которые позволяют нам создать максимально хороший, понятный код, который мы сможем поддерживать. Обычно вот эти вот документы, их просто...

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

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

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

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

Hexlet (01:09:22.958)
мы хотя бы чуть-чуть побольше друг друга узнали. Ну вот, интересные вопросы о масштабируемости, конечно. Вот уже 10 человек на одной конференции, там, митинг в онлайне уже, когда все будут друг друга перебивать, да. Так что, ну да, да. И так что пока что вот через такие Get Together, которые у нас раз в год происходят, через такие практики пока.

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

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

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

Ну что еще раз подтверждает МТС, что вы стремитесь к такой семейной модели управления, без совсем уж формализации всего происходящего. Да, под Новый год у нас там почти вся компания участвовала в Secret Santa. То есть мы друг другу подарки высылали. Что еще? Ну еще у нас есть свой мерч, мы всем новым сотрудникам высылаем мерч. Вот народ фоткается там, выкладывает. Ну и кандидат тоже что приходит.

Hexlet (01:11:37.422)
Ну это приятный бонус, могу бы угаситься. Самый, наверное, жутрепещий вопрос, особенно для студентов Хекси, это нынешних. На раз уже берёте людей с минимальным опытом. Как вообще относятся студентам онлайн-школ? Конкретно, может, есть ли у опыт со пацаниками Хекси? Ходили ли там собеседовать или нанимать, может быть? Ну прям предобеждений никаких у нас нет к студентам онлайн-школ. Мы сейчас, например, наняли человека уже...

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

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

Я, к сожалению, не помню. Я думаю, что одно, может быть, было собеседование. Я точно не скажу. Ну, друзья, значит, вы знаете, куда обращаться. Компания, которая нанимает новичков, практически обучает очень хорошим, на мой взгляд, практикам. Это, на самом деле, приятно знать. Спасибо большое за эту информацию. Было очень интересно пообщаться. И, конечно же, ставьте лайки, подписывайтесь на наш канал. Присылайте свои резюме в Toughbite.

Если они не возьмут у вас, то точно другом работу. Да, вам спасибо большое за интересные вопросы. Спасибо, Саш, за интервью. Спасибо всей команде, кто занимается. Давайте пока. Всем пока.