В Москве семь часов вечера. Рабочий день подошел к концу. Коллеги прощаются, закрывают лэптопы и выходят из Zoom’а. Город потихоньку засыпает, просыпаются айтишники. 19:00 по Москве — это 08:00 в Сан-Франциско. Моя подруга из VMware Маша Шалдыбина делает утренний кофе, логинится и… впрочем, обо всем по порядку.
Привет, Хабр. Меня зовут Катя Юдина, я руководитель контент-маркетинга облачного бизнеса МТС. Буквально на днях я взяла небольшое интервью у своей давней подруги, которая сейчас работает в центральном офисе хоум-офисе компании VMware. Под катом вас ждет интересный рассказ о карьере ИТ-специалиста в крупной международной компании. Поговорим о том, как происходит трудоустройство на западе, как устроена работа в VMware и почему мировой карантин почти никак не затронул отдел разработки.
Кстати, у нас отличная новость! Если у вас нет времени на чтение, можно прослушать подкаст-версию статьи по этой ссылке.
— Маша, как начался твой путь в ИТ?
— Скорее, не «как», а «когда» — в раннем детстве. Повлияла семья: оба родителя у меня — физики. Так что у нас дома постоянно была разная электроника, даже компьютеры (что на тот момент было большой редкостью). Я достаточно рано освоила Бейсик. Помню, устраивала себе развлечение: писала программы, которые рисовали разные картинки на экране. Уже в школе заинтересовалась онлайн-играми, они как раз тогда только-только пошли. Когда я училась в 10 классе, была очень популярна Ragnarok Online. Игрушка меня заинтересовала, но сам геймплей показался неторопливым. Нужно было постоянно фармить и ждать. Так что я развернула свою собственную версию и начала копаться в ее коде, чтобы настроить игру под свои хотелки.
Мы тогда жили в Ташкенте, и ВУЗ я выбрала достаточно быстро. Моя альма-матер — Ташкентский Университет Информационных Технологий. Собственно, направление «Информационные технологии» тогда только открылось. Мы много экспериментировали, делали что-то новое. Преподаватели тоже не отставали, учились вместе с нами. Там же я защитила диссертационную работу, самописную CMS для веб-сайтов.
— Ты помнишь свое первое место работы?
— Еще бы! Курсе на четвертом моя подруга, Юлия Яковлева, схантила меня поработать в местном интернет-провайдере. К своему удивлению, собеседование я прошла быстро и без проблем, чего нельзя сказать о первых месяцах моей работы. Вышло так, что разработчик, писавший биллинговую систему для компании, через две недели уволился. Я осталась один на один с этой системой. Пришлось очень много выучить в кратчайшие сроки — на собственных ошибках, с помощью коллег-администраторов…
Еще в ВУЗе я познакомилась с будущим мужем, Олегом. Дальше мы двигались вместе. Стало понятно: если мы хотим добиться большего, понадобится переезжать. Из Ташкента мы отправились в Санкт-Петербург. Там мы продолжили карьеру веб-разработчиков: я — в Daxx, а Олег — в Murano.
Тем не менее, мы все время находились в поисках лучшего. Через какое-то время муж прошел интервью в Microsoft, и его пригласили на работу в парижский офис. Но судьба распорядилась иначе. У компании, в которой он тогда работал, было много клиентов из США. Когда одному из них стало известно, что муж увольняется, он предложил ему дальше работать напрямую. Почему бы и нет?
Дальше началась маета с визами. После первого интервью в посольстве США на J-визу мы получили отказ. Пришлось «штурмовать» Америку заново. Наученные горьким опытом и добрым послом, мы подготовили новый пакет документов и подали на визу H1B. Шел 2008-й, год финансового кризиса, даже лотерея тогда не проводилась из-за недобора запросов (если в первый день подачи документов на визу, первого апреля, не набирается 65000 запросов, лотерею не проводят).
Для визы пришлось подготовить действительно много документов — с базовым списком можно ознакомиться на сайте посольства. Вдобавок мужу пришлось в деталях расписать, ради какого проекта он едет в Штаты: архитектура веб-сайта, предстоящие задачи и все в таком духе. Все это проверялось в посольстве, так что схитрить вряд ли бы вышло.
Эти же документы мы взяли с собой в Америку. Таможенник на границе проявил компетентность и долго расспрашивал нас про этот сайт. Нам показалось даже, что он украдкой зашел на него во время беседы. Когда очередь дошла до меня, я сказала, что работать не планирую — виза не позволяет. Таможенника этот ответ устроил, и мы, наконец, услышали заветное: Welcome to the United States.
— Ты сразу пошла на работу в VMware?
— Нет (смеется), еще целый год после переезда я не могла устроиться на официальную работу. Нам очень помог работодатель Олега: встретил нас, поселил в своем доме, пока мы не нашли собственное жилье. Помог купить подержанный автомобиль — без машины здесь никак.
Самый главный документ США, SSN (номер социального страхования, который присваивается всем гражданам и резидентам США), мы оформили быстро и без проблем. Всю информацию в доступной форме можно найти на сайтах агентств.
Разумеется, сложа руки я не сидела. Постоянно решала задачи на всяких Topcoder’ах и CodeSprint’ах, готовилась к интервью. Есть такая хорошая книга — Cracking the Coding Interview. В ней описано, как проходить собеседования в крупных ИТ-компаниях, таких как Google или Facebook. Много хороших задач с решениями, рекомендую. Еще я прошла сертификацию на знание языков программирования, создала приложение для iPhone — то есть, всеми силами старалась сформировать хорошую базу для устройства на работу.
Cracking the Coding Interview
Когда через год я получила разрешение на работу, началась фаза активных поисков «компании мечты». У меня были друзья в Facebook — с их помощью удалось получить приглашение на интервью. Здесь важно понимать: в Америке как нигде сильно понятие leverage — потенциальный работодатель может заинтересоваться тобой, если ты упомянешь о собеседовании в другой компании того же ранга. Так что интервью в Facebook мне помогло получить приглашение от VMware. Они устроили все очень быстро, предложили даже пропустить «телефонный» этап и сразу пригласили on-site — в офис. Дальше все достаточно стандартно: мне дали несколько задач, после решения я лично поговорила с руководителями и получила оффер. Собственно, так я и попала в VMware.
— Расскажи подробнее об интервью. Что требуется, какой бэкграунд нужен кандидатам? Как проходит собеседование в деталях?
— Универсально рассказать не получится, тут все зависит от должности, на которую ты подаешь резюме, и от людей, которые будут проводить собеседование. В целом за день может быть четыре-пять разных бесед. Из них три, например, могут вести программисты — кандидату предложат решить задачки на программирование (перевернуть связанный список, решить задачу с установкой зависящих друг от друга приложений и т.п.). Чаще всего код пишется на белой доске маркером.
Может быть беседа с HR — спрашивают про карьеру, цели, «почему именно к нам?». Еще одна интересная разновидность интервью — на дизайн. Писать код уже не придется — вам зададут некий общий вопрос из серии «как бы вы построили подобное приложение?» и попросят обосновать свой выбор.
— А что после собеседования? Сразу в поле или есть какая-то адаптация?
— На самом деле, ввод новых сотрудников в эксплуатацию у нас поставлен очень грамотно, что называется «на потоке». Первые пару недель занимают групповые тренинги и лекции. Тебя знакомят с компанией, ее целями, продуктами и историей. Затем прикрепляют к конкретной команде разработчиков и дают менеджера. Задания выдают попроще. В VMware для учета багов и фич используется Pivotal Tracker — весьма удобный инструмент, а для команд менее 5 человек он доступен бесплатно. Обычно раз в неделю обсуждается, кто из сотрудников над какой задачей будет работать. Вливание в работу очень мягкое и спокойное. Все хорошо документировано, так что типовых проблем «надо срочно что-то делать, но непонятно как» не возникает.
Pivotal Tracker
Когда я присоединилась к VMware, мне поручили работу в проекте Cloud Foundry. На тот момент он существовал всего год. В двух словах, Cloud Foundry — это система, которая позволяет разработчикам запускать свои приложения в облаке. Лично я работала над компонентами, отвечающими за корректную работу приложений, написанных на Node.js, — он тогда как раз был на пике популярности.
Интересный момент — как известно, основная деятельность VMware долгие годы была сосредоточена на решении достаточно низкоуровневых задач, «близко к железу». А Cloud Foundry — это уже software-level, он выбивался из концепции. Поэтому все высокоуровневые проекты решено было объединить в компанию Pivotal. То есть фактически это родная сестра VMware, обе находились в собственности Dell.
Таким образом, я перешла из VMware в Pivotal. Кто-то из моих коллег был против перехода, они остались в VMware, ушли на другие проекты. Дело было в экстремальном agile-подходе к написанию кода, принятом в Pivotal. Парное программирование, SCRUM-собрания. Мне это показалось интересной возможностью научиться чему-то новому, да и с людьми мне общаться легко. Почему бы и нет?
Так началась моя карьера в Pivotal. Спустя семь лет после начала моей работы компанию купила VMware, и я вернулась туда, откуда начинала (смеется).
На самом деле, все оказалось не так страшно. Сессии парного программирования устраиваются ежедневно с 9 утра до 6 часов вечера. Все очень хорошо организовано: на утреннем стендапе мы определяемся с пулом задач и выбираем себе пару. Садимся за один компьютер, работаем над одним и тем же кодом, но при этом у каждого свои монитор, клавиатура и мышь. Практика парного программирования обычно подразумевает, что один из нас — драйвер, ведущий, а второй — ведомый. Роли распределяются так: драйвер печатает код, фолловер — проверяет и смотрит наперед, какие ошибки могут возникнуть в его работе. Идет постоянное обсуждение, как можно улучшить то или иное решение. Это очень помогает решать сложные задачи — как известно, одна голова хорошо, а две — лучше. Для продуктивности роли внутри пары меняются, обычно в середине дня. Кстати, у нас есть инстаграм, там можно посмотреть, как выглядят наши рабочие будни и праздники.
На самом деле, такой подход дает очень много свободы. Не стоит менеджер над душой, не приходится ждать code review — мы самостоятельно вычитываем код друг друга и решаем, как сделать его еще лучше. И сразу сабмиттим в тестовую ветку.
Минусы тоже есть. За неделю накапливается эмоциональная усталость от постоянного общения с другим человеком. Приходится говорить, о чем ты думаешь. Описывать ход своих мыслей. Чтобы сотрудники не выгорали, по пятницам у нас этакий день разработчика — никакого парного программирования, все занимаются тем, что сами считают нужным для развития.
— А как вы уходили на карантин? Были сложности с построением коммуникации с удаленным партнером по программированию?
— Мы начали переход на удаленный режим работы еще до карантина. У нас было много офисов — в Нью-Йорке, Лондоне, Мюнхене. Иногда члены одной команды могли жить в разных городах. Да мы и ранее занимались парным программированием удаленно. Например, в моей команде были ребята из Нью-Йорка. Утром мы все встречались в Zoom, обсуждали дела и разделялись на пары. Собственно, на карантине все происходит точно так же. Ведущий включает демонстрацию экрана, ведомый может делать аннотации и по необходимости перехватывает управление. С кодом работаем в основном в Visual Studio Code. При необходимости разворачиваем виртуальную машину и работаем на ней. В этом сценарии для совместной работы в терминале используем Tmux, а код пишем в Vim. Мы привыкли к такому формату, так что карантин не стал для нас шоком.
У моего мужа, например, сложилась обратная ситуация. Он работает в Google, а там любят, чтобы сотрудники приходили на работу. Удаленка им претит. Офисы для них — второй дом: и накормят, и стиральная машина имеется, и поспать можно. Хоть живи, главное из дома не работай. Конечно, им перестроиться было на порядок сложнее.
Вообще, если не говорить о причинах карантина, я вижу в нем много плюсов. Не нужно тратить время на дорогу. В любое время я могу взять перерыв и провести время с дочерью. Благодаря парному программированию после шести вечера ты полностью свободен, никаких овертаймов, связь между сотрудниками осуществляется асинхронно. Никто никого не дергает. Я рада, что в свободное время я могу забыть о работе и быть со своей семьей. Моему сыну три, дочке нет еще и года, справляться с ней помогают родители — они всегда рядом и с радостью приходят на помощь.
— В двух словах: над какими продуктами ты работала/работаешь?
— Над Tanzu Application Service. Я участвовала практически во всех командах разработки: различные бэкенд-подсистемы, фронтенд, интерфейс командной строки, непрерывная интеграция и релиз. Примерно раз в год в проекте происходит ротация, и команды «перетасовываются». Это не только предотвращает выгорание, так как не приходится годами «долбить» одно и то же, но и не порождает новых проблем, что тоже важно. Наоборот, свежий взгляд на код помогает делать его лучше и чище.
— Маша, спасибо! Надеюсь, следующий раз получится рассказать об одном дне из жизни разработчика Google :)
***
По традиции, ждем ваших комментариев. Поделитесь своим опытом, расскажите, понравился ли вам такой формат статьи, что стоило бы добавить или изменить. До встречи, друзья!
vtolstov
Прочел про парное программирование, никогда такого раньше не видел. Поделитесь — кто в России такое практикует, не хочется ли прихлопнуть чем-нибудь человека за неделю работы?:)
Какие плюсы и минусы дает такой подход?
slonopotamus
Ну вот на хабре недавно статья была, например: https://habr.com/ru/company/barsgroup/blog/533630/
Sergunka
Технически парное программирование можно разделить на два этапа:
1) этап он знаком каждому когда один более опытный и знающий код объясняет другому возможно даже не менее опытному как и что там работает и как быстро закодить задание т.е. говоря обычным языком вводит в курс дела.
Польза тут очевидно быстро ознакомить с проектом еще одного человека.
2) этап то, что практикует Пивотал это когда двум кодерам дается одно и тоже задание на один день (предполагается, что задание можно сделать за один день) и тут начинается кодировка на одном экране с двумя клавиатурами. При определенной сноровке такой метод работает если задания хорошо прописаны и работа довольно рутиная. Здесь в Долине этот метод прижился исключительно в Пивотал, я как один из бывших пользователей и разработчиков сервисов Cloud Foundry не скажу, что метод хорош, но «париться» с приятной девушкой я бы не отказался. С мужиками как-то особо больше получаса не имеет смысла. На практике обсудили, закодили тест кейс совместно вполне достаточно получаса.
Основной вывод метод неплох и им владеть надо так как бывают ситуации когда имеет смысл парное программирование ИМХО.