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

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

Все, кто сидят на стульях под инфразвуковыми излучателями, очень быстро становятся фанатами Virtuozzo
Все, кто сидят на стульях под инфразвуковыми излучателями, очень быстро становятся фанатами Virtuozzo

Проще всего устроиться на работу в группу технической поддержки. Тебе достаточно уметь разговаривать на английском, а также иметь представление о командной строке (пусть и в Windows — даже Linux знать необязательно) и понимать, как работает сеть. Подробнее о работе техподдержки расскажет Мария Антонова, руководитель группы технической поддержки.

 

Мария Антонова, руководитель группы технической поддержки

Работа: инженер техподдержки
Уровень сложности: EASY
Необходимые знания: разговорный английский, стрессоустойчивость, толерантность, знание Linux и сетей
Что получишь кроме денег: знание Linux и сетей, знание Virtuozzo, опыт общения на английском
Карьерные возможности: старший инженер техподдержки, другие должности в компании

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

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

Иногда даже сам не замечаешь, как прокачиваются какие-то фундаментальные, базовые знания ОС и сетей. Ну и конечно, приятно решать проблемы и видеть результат и довольных клиентов. Когда тебе говорят: «Чуваки, у меня горел проект, а вы все подняли, вы такие крутые», — это отлично мотивирует.

Мария Антонова
Мария Антонова

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

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

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

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

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

Из технических навыков нужно понимание работы сетей. Многие сложные случаи связаны именно с сетями. Причем нужно не только понимать, как работает сеть в нашем продукте, но и знать основы — модель OSI, стек протоколов TCP/IP, что такое VLAN и так далее. Также нужно иметь хотя бы минимальный опыт работы с Linux.

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

На самом деле у меня нет каких-то четко прописанных требований и списка навыков. Я смотрю на баланс: на английский, на понимание основ ОС. Если человек не знает Linux, но работал с командной строкой Windows и имеет представление о сетях, то ему просто потребуется больше времени и больше сил на освоение новых вещей. Главное — чтобы соображал хорошо.

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

В поддержке есть куда расти в смысле карьеры. У нас несколько градаций — от junior-инженера можно дорасти до chief-инженера. Плюс у нас сейчас только один technical account manager — человек, который работает с определенными клиентами, глубоко погружаясь в их инфраструктуру, разбирается в бизнес-планах и проектах, которые они собираются внедрять. Также мы планируем развивать направление customer success. Туда будут входить роли technical account manager и, в некотором виде, professional services. Это может быть консультирование клиента, помощь в первоначальной настройке. Плюс наши сотрудники будут писать тренинги, которые мы будем предлагать клиентам.

Для оценки эффективности работы мы используем набор стандартных метрик: время, за которое мы найдем решение нетривиальной проблемы (initial response time, time to workaround), время на решение для заявок с высоким приоритетом. Мы стараемся отслеживать общее время, которое уходит на закрытие тикета. Отслеживаем и общее удовлетворение клиента, и качество обслуживания (customer satisfaction rate и quality). Есть внутренние инструкции, где описано, как поступать в таких-то случаях, как категоризировать заявку и так далее.

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

Ребятам уровня senior иногда становится неинтересно просто делать какие-то тикеты, и я стараюсь вовлекать их в другие проекты. Опять же — тренинги: пришел новенький, понятно, что нужно его прокачать до определенного уровня, научить продукту. Ему назначается ментор, и инженеру открывается возможность проявить себя в качестве тренера и наставника.

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

Ну и конечно, в нашей работе происходит масса забавных случаев. Однажды нам пришел тикет — начинаем его читать и понимаем: что-то не то. Оказывается, человек написал его в стихах! Что делать, отвечать пришлось тоже стихами. Потом с клиентом посмеялись, он сказал: «Спасибо, что поддержали, прямо можно распечатать и на стенку повесить».

Как видишь, техподдержка — это совсем не скучно, во всяком случае в Virtuozzo. Но если ты умеешь программировать на С, знаешь один из скриптовых языков (например, bash) и тебе совсем не хочется общаться с не всегда уравновешенными клиентами, тогда обрати свое внимание на команду разработчиков Virtuozzo Linux. О том, что представляет собой эта команда, расскажет ее лидер — Денис Силаков.

 

Денис Силаков, лидер команды Virtuozzo Linux

Работа: разработчик
Уровень сложности: MEDIUM
Необходимые знания: продвинутое знание Linux, желательно знание C/C++ и одного из скриптовых языков
Что получишь кроме денег: еще более продвинутое знание Linux, опыт разработки дистрибутива, опыт работы в команде
Карьерные возможности: senior developer, работа в любой другой компании, связанной с Linux

Я руковожу командой, создающей Virtuozzo Linux. Это наш собственный дистрибутив — практически собственная ветка CentOS с нужными нам изменениями, которые используются во флагманских продуктах Virtuozzo. Мы предлагаем Virtuozzo Linux и как отдельный продукт, но его главное применение — служить основой для наших флагманских продуктов, то есть Virtuozzo, OpenVZ и Virtuozzo Storage. Сам Virtuozzo — это ядро и некоторые компоненты, но для его работы нужны многие вещи из пользовательского пространства. Вот это пользовательское пространство как раз и предоставляется Virtuozzo Linux.

Денис Силаков
Денис Силаков

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

Человек, который придет к нам в команду, получит массу знаний о Linux и его устройстве. Как он загружается, как загружаются библиотеки, что такое systemd, как он устроен, где и какие сервисы стартуют, как устроена сеть. В силу специфики всякими графическими штуками мы не занимаемся, так что, как пропатчить KDE под Virtuozzo, мы не расскажем. В целом нормальное такое системное программирование — слой, который лежит повыше ядра и обслуживает всю систему. В любых его компонентах приходится копаться.

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

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

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

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

Анализ кода мы делаем через запросы на включение (pull request. — Прим. ред.). Для этого используем Git stash и свою утилиту, которая позволяет отсматривать и комментировать патчи обозримого объема, то есть где-то до тысячи строк. Если изменения большие — скажем, это первая выкладка какого-то большого компонента, — общение идет либо в Jira, либо просто по почте.

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

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

Еще нам важно проверить, насколько человек хорошо ориентируется в Linux — как пользователь или как сисадмин. На собеседовании можем, к примеру, дать ему написать какой-нибудь shell-скриптик и посмотреть, как он будет бодаться с синтаксисом bash и с командами.

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

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

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

Так офис выглядит при отключенной системе виртуальной маскировки
Так офис выглядит при отключенной системе виртуальной маскировки

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

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

 

Андрей Моруга, директор управления программами компании Virtuozzo

Работа: program manager
Уровень сложности: HARD
Необходимые знания: технический бэкграунд, опыт управления и разрешения конфликтов, опыт в техподдержке или разработке, способность не терять точку зрения пользователя на продукт, даже находясь внутри команды разработки
Что получишь кроме денег: еще больше опыта в управлении, знакомство с Linux и рынком виртуальной инфраструктуры, расширишь свой кругозор в современных технологиях управления виртуализацией и приложениями
Карьерные возможности: старший менеджмент

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

Андрей Моруга
Андрей Моруга

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

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

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

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

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

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

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

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

Дарт Вейдер готовится угнетать врагов Virtuozzo
Дарт Вейдер готовится угнетать врагов Virtuozzo

А теперь настало время познакомиться с человеком, который заменяет собой целую команду, — Павлом Емельяновым. Он главный архитектор Virtuozzo, и именно благодаря его стараниям теперь ядро Linux официально обзавелось CRIU (Checkpoint/Restore In Userspace) — софтом, позволяющим создать извне во время выполнения произвольной программы контрольную точку с возможностью возобновления работы программы с этой точки, в том числе в другом экземпляре операционной системы.

 

Павел Емельянов, главный архитектор Virtuozzo

Работа: разработчик ядра Linux
Уровень сложности (сложно ли попасть): IMPOSSIBLE
Необходимые знания: знание C и ядра Linux, левитация, телекинез
Что получишь кроме денег: полное погружение в любимую работу, знакомства в сообществе, опыт решения нетривиальных задач
Карьерные возможности: разработчик ядра Linux

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

Павел Емельянов
Павел Емельянов

Для примера расскажу историю появления CRIU. Изначально все модификации Virtuozzo не шли в основную ветку ядра (так называемый upstream) — то есть в ядро Linux. Они были открытыми, но это, по сути, у нас была своя собственная ветка ядра. В какой-то момент мы начали отправлять всю эту функциональность Линусу Торвальдсу. Так появились подсистемы cgroups и namespaces, которыми сейчас все пользуются. А еще был третий компонент — живая миграция, которая у нас была целиком в ядре. Чем-то похожим занимались не только мы, но и IBM и еще несколько исследователей из Колумбийского университета.

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

В какой-то момент Линусу все это надоело, и он сказал: «Все, дальше можете даже не пытаться, я это брать не буду». Тогда я решил попробовать вынести в пользовательское пространство максимум. И написал прототип, который впоследствии и превратился в CRIU. Не помню, сколько в нем было строк, но даже тысячи, кажется, не набиралось. Он сохранял и восстанавливал программку, которая работала с открытым файлом. У нее не было ни сокетов, ни пайпов, ни сигналов, никаких хитрых отображений в памяти — несколько небольших патчей для получения о процессе то ли памяти, то ли регистров и для создания процесса с заданным идентификатором (PID). Это можно было сделать в режиме отладчика, но тогда операции происходили бы побайтово, а мне была важна скорость. В общем, в результате появилось два патча и та малюсенькая программулинка. Народ посмотрел и решил, что это интересно — всего два патча, а возможностей открывается масса. Попросили развить эту идею.

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

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

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

Так мы сделали CRIU 0.1. Мортон влил патчи в ядро, об этом были написаны статьи, я выступил на конференции с докладом. Тогда в Virtuozzo поняли, что, видимо, мы наконец-то выкинем из нашего ядра checkpoint restore (это та самая живая миграция) и перейдем на мой вариант. Так CRIU перестал быть моим pet project и стал поддерживаться официально.

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

 

Алексей Кобец, старший вице-президент по разработке Virtuozzo

Работа: старший вице-президент по разработке Virtuozzo
Уровень сложности (сложно ли попасть): IMPOSSIBLE

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

Если высшего образования у кандидата нет, но есть опыт, мы обязательно поговорим с ним и, возможно, возьмем. В первую очередь нужно разбираться в ядре ОС. Если ты успел засветиться в сообществе и занимаешься вещами, связанными с производительностью, с разработкой гостевых драйверов, с разработкой систем виртуализации, то это огромный плюс. В последнее время мы сильно фокусируемся на средствах управления и на UI/UX, такие знания будут по достоинству оценены на собеседовании.

Алексей Кобец
Алексей Кобец

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

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

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

3 комментария

  1. Jlenin

    31.05.2017 at 23:28

    Интересно, а возможно-ли пойти к ним работать сразу после универа ? 🙂

  2. Skybad

    02.06.2017 at 10:29

    Ребата умеют вдохновлять.

Оставить мнение

Check Also

Конкурс хаков: пишем на PowerShell скрипт, который уведомляет о днях рождения пользователей Active Directory

В компаниях часто встречается задача уведомлять сотрудников о приближающихся днях рождения…