От DBA и работы в стартапе до Vue.js Core team member и Staff Frontend Engineer в GitLab: история Натальи Теплухиной

Наташа Теплухина — Open Source контрибьютор, автор документации для фреймворка Vue.js, и Staff Frontend Engineer в GitLab. Путь Наташи в индустрии начался с «Факультета информационных технологий» Национального авиационного университета Украины в Киеве, после 8 лет она занималась системным администрированием, работала в маленькой студии-стартапе с WordPress и Pixel Perfect вёрсткой, а сейчас она первый Staff-инженер во фронтенде в GitLab. 

Мы расспросили Наташу как она решила заниматься Computer Science, почему начала изучать JS, какова роль участия в Open Source проектах в развитии разработчика и почему переехала в Нидерланды. А также, как проходил отбор в GitLab и о его особенностях, о прозрачности и отсутствии культуры наказаний, и как она стала первым Staff-инженером во фронтенде в компании.

Примечание: мы решили не добавлять вопросы в материал, поэтому здесь и далее — прямая речь Натальи.

Факультет информационных технологий, DBA и фронтенд

Можно сказать, что путь в профессию начался со школы, которые выпали на конец 90-х, когда от привычных текстовых интерфейсов начался переход к Windows: до нас только добрались Windows 3.11 и Windows 95. Мой папа работал системным администратором, интересовался разработкой ПО и немного учил меня и брата основам. У него на работе как раз был доступ в Интернет (позже он появился и дома) — место свободы, в котором хотелось делать чуть больше, чем просто чатиться.

Хотя я изначально хотела помогать людям как медик, но пошла по стопам отца и решила поступать на «Факультет информационных технологий» Национального авиационного университета Украины в Киеве. Родители предупредили меня: «Ох, это будет сложно. Но у тебя получится». Так оно примерно и вышло. Примерно 15 лет назад я и выбрала Computer Science как профессию.

После вуза я переключилась на системное администрирование и DBA, где проработала примерно 8 лет, пока не ушла в декрет. Через пару лет ребёнок подрос, я заинтересовалась фронтендом и начала учить JS — поняла, что мне важно ощущать результат работы «на кончиках пальцев» и видеть, как всё работает. Из декрета я вышла начинающим фронтендером.

Первую работу получила в маленькой студии-стартапе. Ребята занимались всем, что просил клиент: был WordPress и Pixel Perfect вёрстка, и задачи сложнее, где требовалась логика на JS. Последнее получалось лучше всего, и постепенно я переключилась на эту область.

Потом добралась до JS-фреймворков. Свой первый проект сделала на Vue и после него сменила компанию: ушла в польский аутсорс Scalac. У них была очень хорошая remote-культура, грамотный процесс код-ревью и приятные коллеги. Был Handbook, где они объясняли, как работают, как обучают, какие бюджеты на конференции. Но один минус: не было проектов на Vue, и мне этого не хватало. Хотелось коммерческих задач вместо домашних экспериментов с фреймворком.

В 2018 году на конференции Vue.js London я пересеклась с сотрудниками GitLab: они решали какую-то задачу с Vuex, и я нашла решение, которое им понравилось, и они предложили подать к ним резюме. На тот момент меня пугала многоэтапная система отбора, и я отказалась. Но через несколько месяцев решила попробовать. И на удивление легко прошла. 

Отбор в GitLab

Процесс отбора GitLab описал в большом материале «Interviewing at GitLab». Там есть инструкции как для внутренних, так и внешних кандидатов. Для вторых весь путь занимает 16 этапов, которые могут группироваться и сокращаться таким образом.

Мой отбор проходил в 6 этапов:

• письменное задание;

• скрининг-интервью;

• техническое интервью;

• behavioral интервью;

• сбор референсов;

• завершающее интервью с вице-президентом.

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

Здесь мне пригодился опыт работы с документацией.

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

Техническое интервью: включает общение с будущим менеджером, теоретические вопросы и лайвкодинг. Очень спокойная и расслабленная атмосфера, никакого стресса — в итоге справилась лучше, чем сама ожидала. И снова сразу же сказали: «Да, прошла, готовься к behavioral интервью с директором».

Behavioral интервью. Здесь меня ждали вопросы о самых сложных задачах: как с ними справлялась, вопросы об архитектуре, производительности, оптимизации.

Сбор референсов: отзывы от коллег по работе и руководителей — GitLab запрашивал контакты.

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

Примерно за 8 рабочих дней я получила положительное решение и оффер на позицию Senior frontend.

Онбординг в GitLab: чек-листы и плавное погружение в задачи

Во время онбординга я постоянно переживала: «А не пора ли начинать пилить таски?», потому что процесс онбординга медленный — от 2-3 недель до месяца. Это было необычно. Про онбординг у GitLab также есть подробный «гайд».

Некоторые особенности онбординга.

В GitLab тебя никто не торопит и плавно погружает в работу. Но можно работать и быстрее, чем предполагает процесс, если хочешь. 

К новичку относятся как к равному коллеге. Я помню, как работала над самой первой задачей и в коде наткнулась на вещь, которую во Vue делать нельзя. Хотелось исправить ошибку, но тут задумалась о том, что я тут работаю 3 дня — кто меня послушает? Но нет — менеджер предложил озвучить проблему и описать её во фронтенд-канале. Я так и сделала: объяснила ошибку и её последствия, и все спокойно восприняли без подхода: «А ты кто?»

Более того, этот комментарий моя коллега показала в своем докладе на конференции Vue.js Amsterdam. Доклад был о стратегиях стейт-менеджмента. Мне было приятно: с одной стороны, что меня онбордят как новенькую, а с другой — принимают, как равную со всеми, кто здесь работает. 

Сложности. Сложной задачей было сделать пять coffee calls с незнакомыми коллегами. Coffee call — это 30-минутный звонок с коллегой, на который можно договориться даже с СЕО. Вы разговариваете, о чем хотите: о GitLab, о погоде, о том, как ловится рыба. Это круто работает, когда ты в компании давно, но новеньким всё же сложнее. 

Культура в GitLab и Full Remote 

В GitLab нет культуры наказаний.

В январе 2017 у GitLab упала база данных, что повлияло примерно на 5000 проектов, 5000 комментариев и 700 новых учетных записей пользователей. Компания тогда круто среагировала: они устроили стрим, на котором показали, как восстанавливают базу,  а потом написали об этом в блоге и выложили публичный постмортем.

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

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

Ведь если один человек может сломать всё, значит система устроена неправильно.

Всегда должны быть дополнительные уровни защиты. Мы поговорили об этой истории и работе. Например, я узнала, каким был GitLab, когда в компании работало 8 человек, притом, что сейчас их больше 1000.

Примечание. О своих ценностях GitLab подробно рассказал в большой статье.

Поэтому в ней много удалённых сотрудников. Но рассказать о remote-культуре в двух словах не получится — об этом написан Handbook на сотни страниц.

Но если кратко, мы работаем так:

• документирование процессов;

• прозрачные и гибкие рабочие часы;

• асинхронная (письменная) коммуникация;

• прозрачность.

Эти пункты — логическое следствие того, что команда распределена по всему земному шару. Чуть подробнее о пунктах.

Документирование. Принцип простой: если вы отвечаете на одни и те же вопросы и обсуждаете одни и те же проблемы, проще их документировать и выложить документацию в общий доступ — так и появился Handbook. Теперь некоторые обсуждения даже не начинаются — информацию можно найти самостоятельно.

Гибкий рабочий график. Фактически у нас нет рабочего графика — мы сами определяем границы рабочего времени. Нет никакого «должен присутствовать на созвонах и отвечать в чате». Есть обязательный one-on-one с менеджером, но если не получается, его можно перенести или даже отменить.

Коммуникация. Если бы мы решали важные вопросы только на созвонах, всё бы сломалось: кому-то пришлось бы звонить в 3 часа ночи, что из-за разницы во времени просто невозможно. Поэтому критически важно обсуждать дела асинхронно. Наверное, люди, которые привыкли к быстрому темпу аутсорс-разработки, скажут: «Это же придется ждать по полдня, пока мне ответят!». Для нас как продукта этот темп приемлем. Но допускаю, что кто-то увидит в этом недостаток.

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

Иногда такой открытый подход вылезает компании боком. Когда появилась новость о том, что Gitlab не будет нанимать сотрудников на 2 позиции из России, это восприняли как отказ от найма в РФ вообще.

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

Примечание. Кроме Handbook об удалённой работе у GitLab есть статья поменьше.

Как стать Staff Frontend Engineer в GitLab?

Staff Engineer — это следующая ступень после позиции Senior. У меня не было цели занять её как можно скорее, но путь занял примерно 1,5 года.

Повышения в GitLab не дают авансом — ты уже должен работать на этом уровне.

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

Примечание. Позже Наташа выступала с докладом про Apollo Client на VueConf US 2020.

После внедрения стало понятно, что не хватает инструментов для тестирования. В интернете на эту тему ничего полезного не было, кроме небольшой библиотеки mock-apollo-client. Поэтому пришлось сначала научиться правильно её использовать в связке Vue и Vue Apollo, написать и опубликовать статью об этом, показать команде, написать инструкции и начать потихоньку внедрять как «хорошую практику».

Со временем моё влияние разрослось за рамки команды и я формально доросла до заявки на Staff-инженера. Здесь обучение было даже важнее, чем внедрение: технология не простая для освоения — люди путаются в ней по сей день. 

А в целом, обучение команды — ключевой момент в повышении. Не нужно быть «незаменимым специалистом», нужно уметь себя «масштабировать».

В моем повышении была проблема: Staff-инженеров во фронтенде не было и никто не знал, как их повышать. Считали, что фронтенд в продукте слишком простой, и эта позиция не нужна. Но когда подключился мой менеджер вопрос начал сдвигаться с «мёртвой точки»: после долгих обсуждений GitLab открыл позицию, и я стала первым Staff Frontend Engineer. 

Я — единственная девушка Staff Frontend Engineer в GitLab. Могут возникнуть вопросы про дискриминацию, но в GitLab она не так выражена, как в других компаниях. Например, в индустрии все ещё бывают дикие случаи, когда на интервью работодатель спрашивает возраст или про планы родить ребенка. В GitLab такого нет, здесь немного иначе, например, если женщина выбирает дорогу менеджера, а не Staff-инженера, она быстрее получит одобрение. 

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

Про переезд в Амстердам

О переезде я не думала серьезно до 2020 года — всё было в формате «А неплохо было бы переехать, наверное». А у GitLab как раз есть программа релокации в Нидерланды с визовой поддержкой, и мы с семьёй приняли решение переехать.

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

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

Несколько раз я бывала в Амстердаме на конференциях — страна мне нравилась. 

У неё есть несколько плюсов, которые меня и привлекли.

• Общая позитивность — Нидерланды стабильно входят в топ-10 стран с самым счастливым населением.

• Один из крупнейших аэропортов под боком. Удобно летать на конференции куда-нибудь через Атлантику — минимум пересадок.

• Амстердам (куда я и переехала) — красивый город.

• Потенциальное гражданство через 5 лет.

• Внезапно — вкусная еда. Серьёзно, качество овощей, фруктов, сыров прямо заметно выше, чем в Украине. 

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

• Это Европа — нет сильного культурного шока.

• Страна открыта для мигрантов — экспаты это норма.

• Английский не экзотика — для меня это важно, а Нидерланды под эти критерии отлично подходят.

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

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

Что даёт Open Source?

Я пишу документацию для фреймворка Vue.js в Core Team Member в Vue.js. 

Без преувеличения — больше половины инструкций для последней, третьей версии, написала я. Так что, если вы разрабатываете на Vue, то теперь знаете, кого ругать за непонятные места в документации :)

Я попала в команду стандартно для Open Source — начала контрибьютить: добавляла небольшие правки в документацию фреймворка, потом перешла на гайды побольше во Vue CLI и Vue Apollo, делала мелкие фиксы в сам фреймворк. Когда я менторила людей и объясняла, как работает Vue, то находила пробелы в документации, неточности, опечатки, сложные объяснения, которые понятны только опытным разработчикам. Параллельно коммуницировала с командой онлайн и лично, на конференциях — так вовлекалась в другие задачи по документации.

Однажды, на конференции JSHeroes в Румынии меня представили как Core member, и я вынуждена была это поправить. В ответ на это один из настоящих Core member добавил: «Да она уже практически Core!». Через неделю я получила официальное приглашение в организацию Vue.js на GitHub.

Примечание. Наташа на конференции JSHeroes’19 в Румынии с докладом «The Magic of RxJS».

Конечно, вклад в Open Source безвозмездный, а значит даром, но это не значит, что у этой работы нет «профитов».

Известность и общение с комьюнити. Меня знают в комьюнити, и, если хорошо делаешь свою работу, рекомендуют для консультаций, на конференции как спикера. Например, меня порекомендовали в SmashingMagazine, где я провела воркшоп.

Экспертность и уровень доверия. С мнением считаются не только в комьюнити, но и на работе — в GitLab я считаюсь экспертом по Vue. В моем случае, если возникают спорные вопросы по Vue, я знаю, что ответить и как объяснить, и в обсуждениях мои слова имеют больший вес, чем у других коллег.

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

Вряд ли кто-то станет интервьюировать человека по фреймворку, зная, что он писал к нему документацию.

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

Но время на эти задачи уходит. Сейчас работы с документацией не много, и я на поддержке по 2 часа в неделю. В режиме интенсивной работы мы от релиза до релиза. Например, когда писали документацию третьего Vue, это была вторая работа. Фреймворк нельзя выпустить без документации — мы торопились. А после релиза пришел огромный фидбек с описанием неточностей. В результате я потратила примерно столько же времени на фикс. Сейчас идет тяжелый период, потому что мы дописываем Vue.js 3.1: уже готов Migration Build и готовится документация. 

Совет. Нет смысла контрибьютить без разбора. Ценность в том, чтобы инструмент, которым ты пользуешься, стал лучше. Это мотивирует делать работу хорошо. 

Планы

Сейчас я в команде Plan и занимаюсь вещами, которые знает любой пользователь GitLab — правлю архитектуру наших issue, улучшаю производительность, учу команду правильно выстраивать архитектуру и писать переиспользуемый и скалируемый код. Думаю продолжить свой карьерный путь в том же направлении и дойти до позиции Principal. 

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

Примечание: доклады Натальи вы можете посмотреть на её сайте в разделе «Видео».

Будет интересно почитать:

— Поиск работы в Сингапуре: галеры, карьерные агентства и много собеседований.

— «Специалист с опытом зарабатывает от 100 тыс AUD в год». История переезда российского разработчика в Австралию.

— Как подготовить хорошее резюме для IT-специалиста.

Хорошие вакансии с релокейтом и без есть на headz.io. Присоединяйтесь!