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

Hexlet (00:00.078)
Друзья, всем привет! На связи Хексельт, с вами Александр усков и в нашей виртуальной студии сегодня Алена Малка, ведущая инженерка и программист в компании Контур. Что означает, что у нас уже известный формат распаковки, который наверняка нравится, и чтобы снимали больше таких видео, не забывайте ставить нам лайк и оставлять комментарии.

Hexlet (00:26.094)
Алена, привет. Привет, Саш. Расскажи, пожалуйста, что за компания Contour? Она широко известна в узких кругах. Contour вообще у достаточно взрослая компания, ей в этом году ибилей 35 лет. Она, думать страшно, была основана в 1988 году, я еще не родилась тогда даже. я родился. Да. И первым продуктом, которым занималась компания Contour, это был продукт для бухгалтерии, который назывался AMBA. А вообще, Contour — это ровесник IT-индустрии у нас в России.

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

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

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

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

Hexlet (02:43.022)
Да, конечно, за движением всем следим. Хорошо, а точки зрения организации, опять же, мы общались с компаниями только с Росклиликом.ИТ, где 12 тысяч инженеров, тут полторы тысячи, но это тоже очень большая армия. Как вообще управляется все это? У нас есть руководитель нашего управления разработки, и у него есть помощники. Дальше у нас есть функциональные руководители, дальше у нас есть руководитель кластеров. А вообще, если посмотреть на контуры, у нас матричная структура.

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

Если говорить о фронт-энде, то мы не будем исключением это React, это TS-JS, Redux MobX, но вообще из-за того, что у нас достаточно много команд, каждая команда вольна привносить что-то свое, поэтому там технологии могут отличаться. Если говорить о бэк-энде, то у нас в основном C-sharp сейчас в последнее время набирает обороты Python, есть Kotlin, есть Java, но этого чуть поменьше. А также мы пробовали втаскивать ноду.

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

затаскивать ноды, потому что для того, чтобы выстраивать инфраструктуру нужны люди, нужны ресурсы, нужно время на это. Вот, наверное, время еще не пришло. Ну и понятно. общем, пока JavaScripter делает сервер, он не делает клиент, да? Да. Интересно, а то, что у вас TypeScript никак не помогло профессионалам в Sharp'ах разобраться в этом всем? Да, наверное, нет. Я могу сказать, что бэкендеры были счастливы, потому что он с некоторыми пишут frontend.

Hexlet (04:59.757)
И когда они сталкиваются с стрессом, такие, боже мой, наконец-то, потому что JavaScript — это что-то вообще непонятное, почему-то можно всё, у нас нельзя ничего. Поэтому в плане счастья бэкендеров, может быть, стало лучше. Какого вообще, ну скажем так, понятно, что всех уровней, да, на каком уровне в целом у вас команда, насколько вы стремитесь набирать с рынка или растить внутри, например? По поводу найма и по поводу, да, вот набора с рынка, на самом деле тут важно понимать,

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

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

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

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

Hexlet (07:07.149)
А, ну давай расскажу, давай сначала про гриды расскажу. У нас, наверное, тоже мы не сильно отличаемся от каких-то других IT-компаний. У нас есть стажеры, джуны, мидалы, синьоры и лиды. Сам по себе GreatMiddle, он предразделяется на Middle и Middle +, а лиды, там них есть разделение на Lit и Lit+. Собственно, в целом, есть критерии, которые нужно закрывать. Названия критериев, они плюс-минус одинаковые для каждого грида, но условия, прописанные в них разные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hexlet (16:14.413)
Если говорить про другие команды, то там вообще достаточно разная ситуация, всё зависит от того, что делаем. Есть продукты мастодонты, например, как Extern или Diadoc. Это очень большие команды, они там внутри делятся уже на подкоманды. Так что да, есть команды по 50 человек, но внутри они тоже поделены. таком случае, я предполагаю, что в такого размера струтура всегда есть некий зоопарк. То есть каждый там живёт в своём информационном вакууме, не знает о том, что делают другие.

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

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

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

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

Hexlet (18:38.189)
доказать, что нужно что-то перефакторить, нужно что-то улучшить. В общем, как-то находим взаимопонимание. Из того, что я услышал, я правильно понимаю, что, видимо, есть команды, которые устроены по agile-принципу, продуктовой, где там один frontender, один, там, два backender, аналитик, продукты, всякая. Да, есть такие. Но есть и, видимо, другие, да? То есть есть именно там... Есть какие-то команды, где прямо много frontenders или много backenders что-то одно делают?

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

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

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

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

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

Да, да. Ну, то есть у нас есть обязательно пул людей, которые приходят. Это тестировщик, потому что едет тестировать, проектировщик, аналитики. Вот остальные пожелания. Но мы все любим приходить туда и смотреть аналитику, и задавать вопросы. Понял. Ну, про front-end плюс-минус понятно, что там без дизайна как бы никуда, да. То есть, мы говорим прототипа, про проектировщик, как, конечно, делать некие моки, да. То есть, что-то, что даже можно как-то пощупать, но не работает, да. Что-то типа фигу. Ну да, ну да, типа того.

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

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

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

Hexlet (23:08.333)
не хватает, и тогда за дело берутся разработчики и тоже тестируют сервис. Разработчики пишут тесты, так понимаю, что юниты или интеграционного тоже присутствует? У нас есть юниты, чуть поменьше юнитов, есть часть интеграционных и очень мало n2m тестов. Почему? Очень мало. Но они дорогие, затратные, на каждый чиф их нужно переписывать.

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

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

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

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

Hexlet (25:23.725)
Харма написана на питоне. Это история, которая по формальным грамматикам генерирует, ну, условно, код. Ну, то есть ты описываешь, какие есть вариации вызовов методов просто с помощью там синтаксис, похожего на спецификацию HTML. Она просто генерирует листинги всех возможных вызовов, всем возможными параметрами. Вот это больше похоже на наше светлое будущее. Блин, звучит как вообще что-то классное очень. Ну, типа не надо думать, да, просто все, есть, она правда переберет. Ладно, вернемся к нашим вопросам. Скажи, пожалуйста, а с кексом там вот есть у опыт…

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

Давай сначала расскажу, что нужно, чтобы к нам попасть. Чтобы к нам попасть, нужно прийти в обучение в Хекслите по фрамтенту. Затем мы ждем ваше резюме. Будет здорово, если к этому резюме вы еще приложите выпускные работы, pet-проджекты, если таковые есть. И после этого будут назначены собеседования. По результатам собеседования уже будет известно, придет ли стажер на стажировку или нет. Чего мы ожидаем? Мы ожидаем базовых знаний, что Мельцис СГС, если...

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

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

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

читать, узнавать новое. Поэтому для Джуна это особенно важно. Я бы даже добавил сам обучаемости, есть некоторое любопытство и готовность просто покопать. Да, да, правильно сказала. Про микро-макро-таски, естественно, я занимаюсь фронтендом уже почти 20 лет и до сих пор не могу нормально объяснить, что это такое. Поэтому теория, видимо, тоже для внимания. Я так понимаю, всякими отличиями полиморфизмов вы не мучаете студентов? Нет, нет.

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

Я предполагаю, вас бывали какие-то неудачные сценарии? Может быть, не про пустотников ХЕХС, а вообще в целом? есть как часто вообще бывает такое, что приходит, условно, джунг или стажер и не выводит, скажем так? Просто для понимания, сколько у таких центов? Ну, смотри, если вообще брать по всему контру, процент такой, что 60 % стажеров у нас остается. У нас есть процесс летней стажировки, который длится с 1 июля по 31 августа, на два месяца к нам выходят стажеры.

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

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

на профильной специальности. Он может пройти онлайн-курсы и пойти дальше, потом работать в IT-индустрию. Либо же он может учиться по специальности и тоже пойти в IT-индустрию, удачно и одинаково успешно, они закрепятся там. Но если говорить про обучение студентов, мы занимаемся обучением студентов на базе университета в Екатеринбурге. Там есть Екатеринбургский уральский федеральный университет, ФИИД. У ФИИД есть направление «Фундаментальная информатика и информационные технологии». Вроде ничего не перепутала. Вот. Нам от мехи…

Да, Филипп. Да, вот. И в 2019 году направление, это направление перезапустил Контур в подминаверситете с другими компаниями и IT-сообществом Екатеринбурга. Поэтому мы вкладываемся в образование. Вот, не только какие-то свои курсы запускаем, но еще вот в университет пришли. Может быть, такой будет немножечко провокационный вопрос, но вот, опять же, я же говорил, что раньше не так много компаний занимались образованием кадров где-либо вообще.

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

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

Hexlet (32:25.005)
и они говорят, ну, блин, здорово, наверное, там хорошие условия, там классно тебя обучали, ты классно там прокачался. И тоже это хорошо работает на лояльности, просто на лояльности. Ну, нет, это правда, это правда. Я сам, человек, который довольно много проводит собеседования, всегда смотрю на то, где человек работал, если там есть компании известные своим образовательным процессом, скажем так, внутренним, то, скорее всего, с ним будет более продуктивно общаться. Очень здорово это слышать, на самом деле. Я полностью согласен, конечно, что…

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

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

И всё это заканчивается нашей вообще любимой традицией «Что, где, когда» ЧГК. Любим в неё играть. Каждый конфер заканчивается именно этим. Кроме этого у нас празднуются какие-то локальные праздники в каждом офисе разработки. В Екатеринбурге свой праздник, нас, например, Новосибирский свой, в Ижевске свой. Плюс на самом-то деле мы очень любим тусить вместе. У нас есть какие-то...

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

Hexlet (34:43.629)
А в остальные моменты, учитывая, что это распределено, я правильно понимаю, что члены одной команды продуктовой могут быть располагаться в разных офицах? То есть они общаются как-то удаленно? Да, все так. У нас очень много распределенных команд, которые там Новосибирске, например, Екатеринбурге, этот Верт наиболее часто такой сценарий. Ну и в других городах тоже. У нас есть внутренний продукт-толк, общаются как Zoom.

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

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

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

Я руководитель кластера, новосибирский. Кластер — это набор людей, которые нас соединены по принципу либо географии, либо продуктовому. Вот, у нас принцип географии. Я там входная точка для FmTent разработчиков со всякими болями и радостями. Привожу вантуваны пересмотры. Вот, плюс еще преподаю. Сейчас, сейчас уже только преподаю. В 18-19-х годах вместе с другими ребятами со...

Hexlet (37:03.277)
стартовали большую школу разработки по трем направлениям, вот, и я там отвечала за Frontend. И еще когда-то, последний раз в 2020 году, я занималась тем, что устраивало митапы. Слушайте, как очень много дел, поэтому я интересуюсь, как устроена коммуникация в таких больших компаниях, как это все вообще... Как люди находят, кому написать, если у столько чатов, как бы, и... Не знаю, вас есть там, скажем, какой-то каталог, как называется-то?

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

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

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

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

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

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

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

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

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

Hexlet (41:34.893)
У нас ценят время сотрудника как личное, так и рабочее. И всё основано на личной ответственности. У нас нет большого брата, который за нами смотрит. Мы сами замотивированы и нацелены на то, чтобы довести задачу до конца. И мы просто не хотим подрывать доверие. Поэтому да, нас всё как... Ну, мы договариваемся, и мы друг другу доверяем. Это очень ценю. При этом всём ты, я так понимаю, всё это время занимаешься пронтентом.

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

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

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

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

Hexlet (43:51.885)
У меня опыт такой, что за эти 6 лет, например, если раньше, пока реакта не было, все писали условно на джеквери, на бакбоне, иногда на ангуляре, но, тем не менее, все спрашивали про дом, как там, обновить, там, что вообще как-то работает. Сейчас, по большому счету, люди, которые начали писать front-ends реакта, вообще, скорее всего, это даже никогда в это не трогали, это крайне редко тебе приходится что-то проманипулировать, уже за тебя все делает, собственно, реакт. Но в этом есть и проблема, на самом-то деле, потому что когда приходишь, есть вообще вакансия, когда ты пишешь, что ты реактор-разработчик.

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

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

потому что сейчас эта тема популярная. Может быть, когда-то мы дойдём до момента, что спрос и предложение будут примерно на одном уровне, и не будет перекоса в одну или другую сторону. А в плане фронт-энда, что может измениться? Пока тяжело сказать. Сейчас же ещё no-code набирает обороты. Может быть, какая-то часть работы спадёт с нас.

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

Hexlet (46:12.333)
Мне вот из интересного показалось, что у нас не так давно был тоже выпуск с Нюком Хексель, который занимается прогрессивными аппликейшнами, потому что я на первый раз вижу, что в России очень активно, из-за того, что по некоторым причинам приложения больше нельзя публиковать магазинных соответствующих приложений, простой способ как бы донести до мобильных устройств, сделать ПВА, то есть чтобы тебя был сайтик, который кнопочку нажимаешь, тебя появляется рычаг. Вот. И с этим, ну лично я уверен, что Frontend будет еще как востребован, особенно вот такой, чуть более продвинутый, чем React, чем там...

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

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

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

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

Hexlet (48:27.597)
Друзья, если вам нравится такой формат, вы знаете, что делать. Внизу комментарии, лайки, колокольчики. Все нажимайте, все ставьте, подписывайтесь, подпространяйте. Мы будем снимать больше. Спасибо. Спасибо, Саша. Было приятно познакомиться.