Содержание статьи
Как и в любой другой компании, в Virtuozzo есть несколько отделов, или команд: команда технической поддержки, команда разработчиков, команда програм-менеджеров, а также один человек, заменяющий собой целый отдел, — разработчик ядра Linux. Теоретически ты можешь попытаться трудоустроиться в любую из этих команд, но обрати внимание на уровень сложности.
Проще всего устроиться на работу в группу технической поддержки. Тебе достаточно уметь разговаривать на английском, а также иметь представление о командной строке (пусть и в 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, и именно благодаря его стараниям теперь ядро 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. Через один-два года стажировки студенты приходят к нам на полный рабочий день и подключаются к серьезным разработкам. Если посмотреть на команду, у нас достаточно много людей прошли такой путь, в том числе и я сам.
Недавно заметили, что студенты на стажировку к нам идут труднее. Начали разбираться почему, оказалось, что просто стали мало выдавать для дипломов тем с математикой. А куда на физтехе без математики? Шанс защититься куда меньше. От этого и студенты стали меньше брать наши темы.
Что касается условий работы: я считаю, что мы все должны работать в офисе. На самом деле практика показывает, что многие задачи в офисе решаются быстрее и эффективнее. Рабочий день ненормированный. День начинается в одиннадцать, а заканчивается очень поздно, потому что мы работаем с Америкой и нужно, чтобы мы пересекались с клиентами по часам. Тестеры и разработчики должны обязательно работать в одно и то же время. Чтобы не допускать абсурда, когда тестер нашел ошибку, а разработчика нет, приходит разработчик, воспроизвести не может, а тестера уже нет.
