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

Hexlet (00:00.142)
Идея компании — это ему приснилось, когда он отдыхал у себя на диване. Мы не фриланс-компания, мы именно удаленная компания. Это большая разница. Удалёнка без доверия невозможна.

Там, где ты начинаешь чему-то не доверять, это начинается какая-то паранойя. Разработчик работает, никогда пишет код, когда он решает задачу. Люди не любят тестовый, и понятно, какой причине. Это траты их времени без, возможно, какого-то результата. Middle, Jun, Senior — это все, это просто точки на опыте человека. Если человек может придумать, как оно работает с нужными вводными, то вот он классный разработчик.

Hexlet (00:41.678)
Всем привет, у нас Сядья Хекслит, с вами Александр Усков, у нас в гостях Сергей Головин, руководитель компании CSSSR, которую, возможно, многие из вас знают. Немало людей в Хекслете, как мне известно, работает эта компания. Сергей, добрый день. Сегодня мы поговорим, собственно, про эту компанию, уже известную о форматах распаковки. Начнем с истории. Расскажи, пожалуйста, как вообще компания образовалась. Да, я перед тем, как...

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

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

А я в компании уже был 5 лет, буду 6 год. То есть я, получается, практически ровно в серединке ее жизни пришел. Скажи, пожалуйста, а чем сейчас вообще вы занимаетесь? Мы занимаемся разработкой кучи разных проектов. То есть мы от Source-компания. При этом здесь важно подчеркнуть, что мы продаем именно экспертизу. И это наша фишка. Мы очень долго во фронт-энде.

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

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

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

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

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

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

Hexlet (05:06.254)
И на самом деле, что для больших компаний, что для маленьких, нас плюс-минус уже... Мы посмотрели вообще на кучу разных процессов внутри разных компаний. Кажется, выработали такой универсальный, который всем подходит. И вот это, и стартапы, и там крупные компании, технологические, и fintech, вот это все, и вот мы с ними работаем. Ну а если как-то не называя имен, просто обобщить, это B2C, B2B-сегменты, такие-то публичные сервисы, внутренние сервисы, или все в порядке.

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

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

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

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

Hexlet (07:06.51)
И да, нас очень важный принцип заключается в том, что мы хотим работать вместе с заказчиком над его проектом. Поэтому нас все абсолютно там доступы есть у заказчика. Он может смотреть в режиме реального времени, как у нас все там деплоатится на наши DevStands. У него есть доступ к коду, к доске в Giri. Короче, вообще все. И мы стараемся, естественно, чтобы нас все состояние было актуальное. Ну, я имею на доску ты если зайдешь, там откроешь какую-то задачу, там вся информация есть. Это помогает нам, потому что мы...

как я уже говорил, да, full remote и исторически всегда были full remote. И мы поняли, что очень важно, там коммуникации были таким образом выстроены, чтобы не нужно было друг друга дёргать. А для этого информация должна быть актуальна. Поэтому мы, если что-то поговорили, допустим, зафиксировали, что договорились вот до этого. Мы идём в задачу и написали, договорились до такого-то, И у нас, в принципе, практически всегда вся инфа актуальна. То есть если мы ушли там в отпуск, разработчик ушёл в отпуск, ему не нужно писать, знаешь, что...

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

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

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

Hexlet (09:26.894)
То есть у нас там для того, чтобы человек мог получить зарплату, ему практически не нужно ничего делать. Да, нас ругают очень часто. Этот вопрос, скорее всего, мы никак не обойдем, поэтому лучше я сразу расскажу. У нас есть трекинг времени, но очень часто путают вообще трекинг времени и трекинг как таковой. Мы вообще никак не следим за нашим сотрудником, мы полностью доверяем, мы понимаем, что удалёнка без доверия невозможна. Там, где ты начинаешь чему-то не доверять, всё, это начинается какая-то паранойя, начинается нездоровое отношение в команде, всё, это...

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

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

Да, причем, нет, по рабочему времени, иногда люди пугают с того, типа, а если я пошел чай попить, то есть это, ну, там отвлекся, поставил чайник, мне нужно stop и track? Нет, не нужно. То есть если ты пошел, не знаю, в окошко поглядеть, и ты при этом думаешь о задачи, то есть мы такой рандомной не занимаемся. То есть нам важно, что вот человек просто работал на задачи. Как он работал на задачи? Ходил по комнате кругами, не знаю, полежал на диване, подумал, как ее решить. Мы не упоруемся в то, что типа человек вот работает, это когда пишет код, это все неправда.

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

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

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

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

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

Он говорит, что есть рекомендации, а дальше вы там подтачиваете уже по то, как вам удобно. Ну вот мы подтачили... Скраб же сами авторы называют фреймворк, а фреймворк значит, нужно выкинуть и все использовать. Именно так, да. есть у нас в двух словах как-то... Да, конечно. Но да, если большими масками, то недельные спринты, что важно, есть Daily Sinks, где мы быстренько собрались, наша команда и плюс...

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

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

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

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

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

Hexlet (16:25.037)
И, соответственно, другому человеку не приходится тебе отвечать. Поэтому мы все коммуникации ведем в общих каналах. Мы там особо ничего никогда не скрываем. Мы заводим общие каналы с нашими заказчиками в том числе. То есть и все обсуждаем там. Мы очень стараемся создать такую здоровую атмосферу в компании. И для этого используем кучу разных средств. То есть у нас есть внутренний подкаст, который выходит ежемесячно, в котором мы рассказываем вообще все. И про удачи, и про неудачи, вот куда вообще компания движется, какие решения приняла.

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

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

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

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

Hexlet (18:46.349)
Мы играем просто видеоигры, мы просто у нас есть флудилка, когда там... Иногда заходишь в дискорд, у нас есть дискорд свой, тоже такой условно-корпоративный. На самом деле, когда люди даже уходят из компании, мы оставляем их всегда в дискорде, и мы всегда рады, мы очень соногими поддерживаем отношения. Что интересно, на последний кемп, ну не знаю, не половину, знаю, человек, Ти-10, наверное, точно был из... Те, кто уже там не работает с нами давно или недавно, но до сих пор...

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

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

А, ну, Эльбрус – немножко другое. Это как раз основатель нашей компании Дима Чекин. Он просто сам взял, и у нас есть флаг СССР, и он этот флаг СССР поднял на Эльбрус. Этот флаг еще опускался вроде под воду на какую-то глубину. У него есть история, я сейчас боюсь соврать. Это его личный, да, все проект инициатива? Эльбрус – да, это его личный проект. Это он хотел подняться на Эльбрус. Он поднялся, но захватил еще собой флаг СССР.

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

Hexlet (21:00.941)
Как и наоборот, есть романтическое представление о продуктовых компаниях, а бывают очень плохие продуктовые компании. Куда ты придешь, и когда говорят типа «галера равно оодсорс», на самом деле это вообще абсолютный миф. То есть «галера» это равно «галера». То есть ты придешь в продуктовую компанию, и там будет галера похлеще любого оодсорс. Согласен. Но да, тембилдинг у него тоже есть, мне кажется, плохая конутация, потому что это воспринимается как такое искусственное мероприятие, навязанное извне, когда людей сгоняют вместе, они там как-то провели время и вроде как типа потембилдились.

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

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

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

Наши организаторы – это герои. Я, например, не участвовал особо никогда в организации этого процесса, но я видел, насколько они замучивались. Но в каком-то смысле это, знаешь, типа, приятная усталость, когда ты сделал настолько крутую штуку. Потом еще сам наверняка там же… Конечно, конечно. Это же как-то из профессионального роста, вообще профессионального мотивации, скажем так. Какие у в какие-то практики? У нас целая система.

Hexlet (23:15.725)
создан для того, чтобы наши сотрудники развивались. У нас есть система Performance Review, которая проходит либо раз в полгода, либо раз в год. Ну, это такие дефолтные промежутки временные. Они могут быть на самом деле либо чуть раньше, либо чуть больше, зависит от того, как человек сам себя ощущает. Но они проходят обязательно в какой-то промежуток времени, где мы просто чекаем, насколько человек подрос, говорим, что вот ты теперь, например, вот это ты знаешь, что это ты не знаешь, и строим вместе совместный план, куда человек...

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

Как это происходит? Когда мы работаем с какими-то задачами, Team Lead, зная про цели своих коллег, он может запланировать какую-то задачу, что вот, например, лучше не Вася сделает это, а Ваня сделает вот эту задачу. Потому что у Вани здесь опыта не хватает, и он, да, чуть побольше времени потратит, но он научится. Как, ну, это можно объяснить даже, тут казалось бы, зачем заказчику такое оплачивать? На самом деле, банально от… Ответ – бас-фактор.

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

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

Hexlet (25:37.133)
практически кто угодно к кому угодно может напрямую зайти если нужна помощь мы всегда открыты мы любим именно вот такого такого рода общения формально это в том плане что неважно там допустим сетей о не сетей о сепи о кто угодно если есть какой-то вопрос ко мне то без проблем там приходи мы все обсудим возможно это потому что у нас что не 10 тысяч человек работает да но тем не менее пока мы позволяем можем себе такое позволить мы это используем и плюс ко всему у нас есть еще внутренний

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

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

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

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

Hexlet (27:41.965)
Последний рубеж обороны, когда даже Stack Overflow не дал тебе ответ, ну и вообще там гугление не дал тебе ответ, туда приходят люди, чтобы какой-то опыт прямо с первых рук получить. А вот насчёт качества кода, как у вас это обеспечивается? Этот процесс как-то состроен, а вот ревью или... Есть на самом деле несколько точек зрения на эту штуку, то есть можно как-то ревьюить, можно не ревьюить, и в большинстве случаев, например, если у вас команда, например, все синиыр, и вы все очень хорошо знаете друг друга, доверяете друг другу, и у вас уровень самый важный.

что вас уровень плюс-минус один тот же, то review можно делать. Можно парно программировать всегда, и все будет хорошо. Потому что, ну, там типа, особо больше... После того, как вы парно программировали, больше ничего вряд ли вы найдете. То есть все равно будет все уже синхронизировано. Мы понимаем, что у нас команда немножко разношерстная. То есть у нас есть, например, синиор, который Team Lead, у нас там есть HighMiddle, есть Middle. Ну, джунов у нас практически нет, но на некоторых проектах есть. И у них уровень совершенно разный.

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

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

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

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

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

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

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

Я не буду тут лукавить, у нас опять-таки разные по опыту команды внутри компании. И есть команды, которые суперопытные, они понимают, когда нужно писать тесты, когда не нужно. И я тут не ставлю знак равновесия. Опытная команда, значит, навсегда, не знаю, 100 % покрытия кода. Потому что 100 % — это безумие. Даже в случае написания на самом деле медицинских систем покрытие кода не говорит о качестве тестов, которые ты написал.

Hexlet (32:09.677)
Нужно покрытие тест-кейсов. И, соответственно, команды по-разному имеют разный опыт с тестами, но в целом плюс-минус все пишут. То есть нет такого... У нас нет, не знаю, никакого такого требования, что обязательно, не знаю, 80 % кода должны покрыть. У нас такого ничего нет. Просто мы... На самом деле интереснее как раз, да, было услышать, что у вас нет обратного, какие тесты, давай быстрее, фичу, за кубик да поехали.

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

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

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

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

Hexlet (34:26.765)
И самое интересное, ну, возможно, когда-то мы платили. Во-первых, мы каждый год индексируемся. И, допустим, в этом году у нас был челлендж, ну, наверное, не секретный для кого, что рынок в этом году очень сильно вырос. Ну, и, соответственно, мы точно также будем индексироваться, стараться это делать по рынку. Но здесь важно понимать, что мы, сути, опять-таки не продуктовая компания, мы зарабатываем на том, что вот предоставим экспертизу.

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

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

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

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

Hexlet (36:42.125)
Мы, например, в своей компании, мы сами приходим к человеку и говорим, вот тебе повышение. Причем даже если человек не прошел Performance Review, как я говорил, у нас есть индексация. И независимо от того, он может вообще не хотеть никогда проходить Performance Review, и него зарплата будет расти, потому что рынок растет. Если он перешел в следующий grade, и даже на самом деле в своем grade у нас еще есть такие микрошашки, если он в своем grade тоже подвинулся ближе к следующему grade, мы все это отмечаем, мы все это фиксируем, человек всегда знает.

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

И мы очень заинтересованы в этом. Поэтому у нас нет никаких историй про то, что на этом проекте, допустим, заказчик русскоязычный, поэтому мы будем тебе платить меньше, извини. А вот на том проекте, например, Иван получает больше, потому что, ну извини, у него как бы заказчик из США, ты что думал? Мы стараемся, чтобы Хороший пример. Да, то есть у нас все в равных ситуациях находятся. Именно поэтому там есть определенные обязательства, которые мы на себя взяли. Поэтому, как я говорил, нас никто из руководства яхты себе не...

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

Два тестовых лично вот я как раз делал. Это про Slomax. Это типа такой сломанный аналог редакса. там задача в том, чтобы его починить. И там сразу заложено на самом деле несколько уровней того, что человек может сделать. Самое очевидное — это починить, заработало. И есть несколько не самых очевидных. И так это, во-первых, задача очень маленькая. есть я знаю, люди не любят тестовый. И понятно, какой причине. Это всегда траты их времени без возможных какого-то результата. Поэтому мы постарались сделать его максимально...

Hexlet (39:03.853)
маленький, то есть это какая-то такая задачка, которая может, во-первых, интересной быть. Я очень часто встречал эту задачку, что в других компаниях ее тоже дают. И плюс ко всему, чтобы эта задача помогала человека раскрыть как разработчика, чтобы он там где-то что-то сам мог провить какую-нибудь инициативу. Вторая задачка, эта на Джунов была, это, типа, простой, наивный интерпретатор Лиспа. И тоже, когда мы ее сделали, она тоже на самом деле выглядит как что-то страшное. У нас даже синий уровень некоторый...

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

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

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

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

Hexlet (41:21.037)
потому что мы хотим, чтобы человек был инженером в общем-то смысле, чтобы он мог решать в принципе задачу, а не просто писать на реакте. Поэтому мы задаем там различные вопросы в зависимости от уровня, в том числе, про то, как может работать интерпретатор Javascript. Почему, я говорю, здесь может. Кстати, можете опять-таки на канале Хексата посмотреть, я проводил публичное собеседование. Почему я задаю такие вопросы? Потому что даже если человек не знает, он просто не знает ответа.

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

Ну, там нет, ну, весь интерпретатор — это очень сложная тема, там очень много нюансов. Я, например, там event loop, тот же самый, то есть, типа, вот как он работает в трааке браузера, да, как он связан с процессом. Как в уровне человека должен уже прям уверенно понимать или в любом случае даже объяснить? Ну, узнать про это желательно, наверное, уже на уровне needle, потому что там очень много аспектов, которые так или иначе с этим связаны. Сама ассинхронность, отрисовка браузера, вот Repaint reflow, да, циклы, то, как ты можешь оптимизировать какую-то анимацию. То есть, на самом деле, эти все вещи взаимосвязаны. Если ты не понимаешь природу этих взаимосвязей, то ты, скорее всего, либо будешь

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

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

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

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

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

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

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

Hexlet (46:02.957)
Нужно воспринимать только в контексте компании. У всех это разные. Это просто точки на опыте человека. Каждый ставит эту точку в разные места, придумывает другие грейды. У нас, например, их вообще пять. Это junior, middle, high middle, senior, principle. И, соответственно, principle — это самая верхняя точка у нас сейчас. Но вот такая гордация нам позволяет примерно формировать там команды. И плюс еще немножко... Вот principle — это уже люди про...

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

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

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

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

Hexlet (48:22.605)
Вообще далеко не все про него знают. Да, ну хорошо, многие знают, но Джун может ответить. Ну, корс — это такая штука, которая мешает разработке. То есть ты пытаешься к серверу обратиться, что-то там не получается, да, фигня какая-то, ну, условно. Но на самом деле очень часто люди, даже вот на синеврские гряды, которые претендуют, когда ты начинаешь про корс спрашивать, я спрашиваю не что это такое зачастую, а для чего, какую проблему это решает. Потому что всегда важно не знать просто описание, ну, на Википедии написано или там на MDN написано, что это вот то-то-то.

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

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

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

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

Hexlet (50:43.533)
одинаково выгодные эти условия. есть они могут себе позволить действительно просто сосыпать деньгами. Мы такого позволить себе не можем. Мы не можем пойти, например, и купить какого-то супердорогого разработчика, потому что его, естественно, могут перекупить. То есть и всегда есть Google тот же самый. Поэтому для нас мы создаем такие условия, чтобы разработчикам было комфортно. Ну, я знаю, что это тоже ругают, что типа вот есть позиция, что деньги есть деньги, какая разница, где работают там, ну...

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

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

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

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

Hexlet (53:03.821)
Давай немножко подытожим, как вы смотрите в будущее? Что ожидает СССР в следующие годы по вашим оптимистическим планам? Тут сложно сказать. Мы всегда стремимся к одному и тому же. Мы стремимся наращивать экспертизу, усложнять наши проекты, и это пока получалось. есть мы из года в год, у нас получалось там все новые новые какие-то горизонты для себя открывать.

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

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

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

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

Hexlet (55:23.021)
И не потеряем экспертизу. Да, вот это тоже важный момент. Мы никогда не стремимся именно расти численно. То есть это нас происходит просто естественным образом. скорее всего, через год вы не услышите о нас, о гиганте, где тысячи сотрудников уже работают. Скорее всего, и через два года тоже не услышите. Вот. Ну и... Поздравляю. Найти столько, знаешь, людей с высокой экспертизой гораздо сложнее, кажется в любом случае.

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

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

Да, спасибо.