Мы в hh постоянно находимся в активном поиске истинных талантов и проводим массу собеседований. Как правило, они состоят из двух этапов — технического и продуктового. На каждом из них у кандидатов возникает множество вопросов. Чтобы облегчить всем жизнь, мы отобрали самые популярные и отвечаем на них в этой статье.
Вопрос 1: Какой у вас актуальный стек?
Весь новый код мы пишем на Swift, а для генерации проектов используем инструмент Tuist. Что касается архитектуры, наш выбор пал на MVVM и MVI — своего рода стейт-машину, которую мы позаимствовали у коллег из Аndroid-команды.
В роли реактивного фреймворка мы используем OpenCombine (пытались перейти на нативный, но с первого раза не удалось — поймали гору крашей), а для подключения внешних зависимостей — Carthage. Также в наличии присутствует внушительное количество средств генерации кода. Например, для подключения к локализации и картинкам мы используем SwiftGen, для генерации бойлерплейт-кода — Sourcery, для экспорта стилей с Figma — FigmaGen. Более того, в нашем арсенале есть и собственное решение, которое мы юзаем для генерации фичей внутри проекта. А также пишем свои Xcode-шаблоны.
Наш техрадар.
Вопрос 2: Каковы масштабы легаси?
Приложение довольно старое — ему больше девяти лет, и в проекте есть файлы, датируемые 2013 годом. Но за последнее время уровень Objective-C в нем снизился на 14% и сегодня составляет лишь 2%. Цель на ближайший квартал — избавиться от остатков.
Стоит отметить, что большинство наших модулей использует VIPER, который, как и Objective-C, считается устаревшим. Но специально переписывать их мы не намерены. Это может происходить только в рамках каких-то доработок и задач, направленных на трансформацию модуля под новую архитектуру. Также мы можем использовать их в качестве самих задач, чтобы погрузить разработчика в наш стек в период испытательного срока.
Вопрос 3: А что у вас с тестами?
Каких-то жестких правил у нас нет. Есть UI-тесты, которые пишут тестировщики. А разработчики отвечают за их стабильность. В общем, при внесении любых изменений ничего не ломается и не падает.
С помощью юнит-тестов мы стараемся покрывать сложную бизнес-логику и ключевые участки кода. Здесь у нас тоже нет определенных алгоритмов, в каждой задаче разработчик принимает решение самостоятельно. Если он посчитает, что юнит-тест не нужен, так тому и быть.
Кроме того, мы используем Gitflow, поэтому не гоняем UI-тесты на каждом пул-реквесте. Еще мы настроили специальные ночные сборки, которые прогоняют UI-тесты на каждой из фича-веток. Для этого мы юзаем fastlane-скрипты, которые запускаем на Bamboo от Atlassian, и максимально интегрируем с GitHub.
Вопрос 4: Что по профессиональному развитию?
Мы очень серьезно относимся к профессиональному росту и развитию наших разработчиков. Для этого мы создали специальную модель компетенций. Это гигантская доска в Miro с массой разных стикеров, каждый из которых описывает определенный навык, которым обладает (или нет) разработчик.
Например, он мастерски владеет техниками стирания типа, но не разбирается в протоколах на уровне Witness-таблиц. После окончания испытательного срока разработчик самостоятельно оценивает свой уровень в рамках нашей модели компетенции. Свое мнение составляет и тимлид. В итоге для нового коллеги разрабатывается индивидуальный план развития и задается вектор, которому мы будем следовать.
Для этого каждые две недели будут проходить встречи с тимлидом, где обсуждаются успехи и конкретные задачи, позволяющие ему прокачать свой скилл. Например, разработчик не умеет писать запросы в hadoop, но очень хочет научиться. Мы не будем его ни отговаривать, ни заставлять. В hh нет такого, что все поголовно должны знать CI или уметь писать запросы к аналитическим системам. Тут каждый сам выбирает свой путь.
Мы всеми силами помогаем коллегам с задачами развития. Уровень заработной платы, кстати, мы также стараемся привязать к индивидуальному плану — это позволяет сделать весь процесс прозрачным и понятным для сотрудника.
Вопрос 5: Много ли у вас команд и как они работают?
В нашем Техническом департаменте работает более 200 человек и 30 команд. В мобильном направлении прямо сейчас шесть полноценных команд, а скоро их станет еще больше. Первая — это команда мобильного бэкенда, которая помогает нам с API, различными интеграциями и прочими бэкенд-штуками. Вторая — кор-команда, она отвечает за инфраструктуру, архитектуру, навигацию и все те прекрасные вещи, которые делают жизнь продуктового iOS-разработчика легче.
Следом идут четыре продуктовые команды. Одна из них занимается развитием нашего работодательского приложения, три другие реализуют фичи в приложении hh. За каждой из команд условно закрепляется тот участок приложения, в котором команда внедряет наибольшее количество новых продуктовых фич. Тем не менее, все команды так или иначе взаимодействуют со всем кодом и не замыкаются на одной определенной роли.
Каждая команда состоит из пяти талантливых человек — два Android-разработчика, два iOS-разработчиков и QA-инженер.
Вопрос 6: Есть ли в hh переработки?
Нет, мы бежим марафон, а не спринт. Никто и никогда не потребует от вас работать в выходные или сверхурочно.
Вопрос 7: Как выстроены процессы?
В основе всех наших процессов лежит OKR — метод, благодаря которому мы оперируем не задачами, а целями. Цели тоже могут быть разные. Например, совсем уж верхнеуровневые или всего на один квартал. Ежеквартально мы собираемся всей командой с продактами, проджектами, дизайнерами и пытаемся сформировать цели на ближайшие три месяца.
Как только цели сформированы, мы начинаем определять, как именно они будут достигнуты. Например, чтобы сделать пространство hh безопаснее, нам определенно стоит добавить возможность оставлять отзывы. А если цель — увеличить охват, нам следует понять, как удержать пользователя в приложении подольше.
После того, как задачи определены, мы приступаем к их проработке и составлению бэклога. Если нужно добавить те же отзывы, нам понадобятся не только доработки с API, но и помощь других команд. В итоге через неделю-две мы получаем целый набор конкретных метрик и задач. Например, увеличить количество откликов на 20 тысяч в день с помощью редизайна поисковой выдачи.
Работаем мы по методике Kanban. Все задачи формируются в так называемые портфели. Так мы называем какую-то законченную фичу, за который закрепляется ответственный юнит — один из разработчиков. Он и формирует финальное описание портфеля, по которому мы проводим декомпозицию. Затем всё это переходит в разработку, тестируется и попадает в develop. Используем ли мы код-ревью? Да, но не жестим. Обычно хватает одобрения одного человека.
Когда портфель попадает в develop, он ожидает релиза. Мы используем ниндзюцу релиз-трейна. Так что практически каждый вторник в районе полудня от develop создается релизная ветка, и всё, что туда попало, закономерно уходит в релиз.
Еще мы обожаем A/B-тесты — проводим через них практически всё. Если портфель попал в релиз, в игру вступает наш A/B-тест. Обыкновенно это тоже занимает одну-две недели. Этого времени нам достаточно, чтобы собрать необходимую информацию и сделать кое-какие выводы. Затем мы общаемся с аналитиками, а они уже рассказывают, что получилось, а что не очень. В зависимости от результата встречи мы принимаем соответствующие меры. Чаще всего эксперименты успешные или требуют лишь небольших доработок, однаком иногда мы можем признать неуспешным и выкинуть результат даже длительной работы: метрики наше всё.
Кроме того нужно отметить, что четверть своего рабочего времени разработчик будет тратить на технические вещи, которые коррелируют с его индивидуальным планом развития, о котором говорилось выше.
Вопрос 8: Как будет выглядеть мой рабочий день? Много ли встреч?
У нас существует ряд негласных правил по организации встреч, которым мы стараемся соответствовать. Например, вторник — это день, свободный от встреч. Главное, присутствовать на рабочем месте, пусть и удаленном, с 11 до 17, чтобы не пропустить какую-нибудь внезапную встречу.
Но и уйти в любое время тоже всегда можно, заранее предупредив всех сообщением в общий чат в Слаке.
Общие встречи с командой мы проводим на ежедневной основе, там мы обсуждаем насущные проблемы и рабочие моменты. Также есть встречи по планированию задач на неделю и подведению итогов наших экспериментов. Существуют и отдельные встречи для Android- и iOS-разработчиков.
Периодически проводятся демо-встречи, например, с дизайнерами или технические, где мы показываем свой функционал. Обязательные встречи редко занимают более одного часа в день. Другие встречи опциональные — их всегда можно посмотреть в записи.
Если пришлось по вкусу все вышеперечисленное, всегда можно пойти к нам работать. Наши вакансии широко открыты для всех желающих
Интересные статьи
Интересные статьи
