Мои вопросы работодателю, когда подаюсь на разработчика

Как я задаю вопросы и общаюсь с HR

За последние 10 лет я поменял 3 работы, прособеседовался с 10+ компаний на позицию разработчика (software engineer) и вел переписку с HR/рекрутерами из нескольких десятков фирм. По ходу дела заметил, что вопросы, которые я задаю на собеседовании с менеджером/командой или с HR, повторяются, и решил их структурировать. Некоторые из них являются общими, и их может задать кандидат на почти любую вакансию; другие касаются только вакансий для программистов. В этой статье поделюсь с вами наиболее типичными и важными вопросами, которые, на мой взгляд, может задать соискатель потенциальному работодателю.

Disclaimer:

• Мой опыт трудоустройства ограничен средними IT-компаниями (с продуктом или консалтингом/сервисом), имеющими от 100 до 1000 человек в штате, поэтому для FAANG и каких-нибудь S&P 500 такой подход может не работать. Если вам покажется неуместным отправлять такие вопросы по почте, то можно их задать в процессе живого общения или после получения оффера.

• Практически все интервью, которые я проходил, имели довольно стандартную схему: первичный созвон с HR -> скрининг на адекватность (по телефону или простая задачка по Google Meet / Zoom) -> несколько тех. интервью -> общение с будущим менеджером (и иногда командой) -> оффер или отказ.

Обычно я делаю так: в процессе первичного общения с HR стараюсь задать вопросы, которые являются для меня критичными (must по принципу MoSCoW). Если что-то меня не устраивает, идти дальше (на тех. интервью) нет смысла, за исключением случаев, когда вакансия уж очень классная и хотелось бы пообщаться с разработчиками на тех. интервью и попробовать свои силы. Затем говорю, что мне очень понравилась компания и я хотел бы узнать немного больше, но чтобы не затягивать телефонный разговор, отправлю свои вопросы в письме. Делаю это, чтобы для человека это не было неожиданным.

Если после общения с HR все в порядке и самые важные моменты устраивают, то тогда иду дальше на тех. интервью и параллельно отправляю HR небольшой опросник, в котором вежливо прошу ответить на некоторые вопросы. Времени для общения с HR на первичном созвоне довольно немного (обычно 30, и лишь иногда 45 минут), поэтому все HR говорили, что общаться текстом им даже удобнее, потому что они могут не знать каких-то моментов. Обычно это не к спеху, и ответы мне приходят в процессе прохождения тех. интервью (весь процесс интервью может занимать несколько недель). Вопросы, которые я задаю на этом этапе, не требуют развернутого ответа ("да"/"нет"/"иногда" может быть достаточно), и ответить на все вопросы HR может в письме за 10-15 минут. Если какие-то очень важные для вас моменты не будут включены в контракт, то хотя бы у вас будет текстовый след с договоренностями в электронных письмах (если возникнут какие-то сложности).

Помните, что у HR нет сильной мотивации тратить время на ответы на ваши вопросы, когда вы только в начале этапа интервью. Можно смело подождать, пока не пройдете первичный тех. скрининг, чтобы человек мог убедиться в серьезности ваших намерений и в том, что на вас стоит тратить время. Важно не отправлять все вопросы сразу, потому что это может создать слишком много работы для человека, а это может быть преждевременно (если тех. интервью будет завалено). Вы также можете показаться этаким smart ass, который хочет знать все и вся, и отношение к вам может быть соответствующим. Проявлять искренний интерес к тому, как устроена компания и процессы, поощряется, но терроризировать HR вопросами обо всех деталях (на этом этапе) не стоит.

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

Вопросы

Здесь, собственно, все вопросы. Под каждым вопросом небольшой развернутый комментарий. Некоторые вопросы могут быть неактуальны для вас; можете их смело пропускать. Погнали!

Вопросы перед тем, как подаваться

В каком формате проходит тех. интервью.

Это лучше всего узнать до того, как начинать процесс. Если этого не сделать, то можно попасть впросак: вдруг тех. интервью назначат через неделю, а пузырьковую сортировку вы уже забыли (или не знали). Подготовиться за неделю-другую может быть очень трудно.

Крупные компании могут описать, как проходит процесс интервью (смотрите страничку "о работе" в JetBrains и Bloomberg). Если повезет, будет написано, входят ли в интервью вопросы по алгоритмам и структурам данных. В этом случае может потребоваться дополнительная подготовка. Если же по алгоритмам гонять не будут, а дадут какое-то тестовое задание или какую-то задачку для лайв-кодинга (но не на алгоритмы), то можно подаваться!

Если на сайте компании информации об интервью нет, можно написать рекрутеру в LinkedIn или просто по электронной почте. Можно вежливо сказать, что очень хотел бы податься, но хочется уточнить, как выглядит тех. интервью. Если штудировать алгоритмы нет сил, то можно посмотреть, какие из компаний нанимают без алго-интервью. В сети даже есть такие списки, например, см. Companies that don't have a broken hiring process.

Помните, что компания может проводить алго-интервью на позиции разработчиков в один отдел, а в другие - нет. Например, какой-нибудь финтех может жестко гонять по алгоритмам на позиции разработчика систем высокочастотного трейдинга, но более лояльно относиться к инженеру на позицию в отдел системной интеграции. Если компания очень нравится и не принципиально, в какой команде или отделе работать, можно посмотреть на смежные должности помимо software engineer, например, solutions engineer, solutions architect, CI/CD или build systems engineer.

Общие вопросы о работе

1. Можно ли работать удаленно из дома?
   Если важно, чтобы была такая возможность. Если работа исключительно из офиса, и из дома работать не разрешают, то делаем выводы :)

2. Сколько времени я буду проводить в офисе (или работать из дома) и сколько в командировках?
   Может быть, вы будете 100% в офисе/дома, а может быть, придется часто ездить к какому-то клиенту на какие-то встречи, сбор требований, возможно, понадобится проводить обучение персонала (пользователей вашего продукта/системы) и что-то в этом духе. Будут ли оплачиваться такие командировки и как. О таком хорошо знать заранее.

3. Если работа в офисе (и вам так хочется), лучше уточнить, есть ли отдельный кабинет (личный или для команды) или офис открытого типа (open office)?
   Если есть личный кабинет, это классно, можно поработать в тишине (у меня был такой в течение нескольких лет). Но сейчас это редкость, и скорее всего будет общее пространство с переговорками. Если в таком пространстве есть какие-то большие комнаты, в которых можно работать командно, это замечательно. Стоит спросить, есть ли место, где можно "тихонько посидеть и поработать", потому что бегать из переговорки в переговорку не лучший вариант. Если придется все-таки сидеть в общей комнате, то стоит изучить, где вы будете сидеть, чтобы не оказаться рядом с сотрудниками, работа которых связана с общением голосом.

4. Насколько гибкий график работы?
   Есть ли какое-то формальное время работы, когда вы должны быть "онлайн"? Если такое имеется, насколько можно от него отходить (пропасть на пару часов в обед, приехать попозже и т.д.). Нужно ли "отмечаться" об отсутствии (достаточно ли кинуть сообщение в общий чат или нужно какое-то формальное одобрение начальника)? Возможно, вам будет предоставлена полная свобода, и вы сможете работать когда угодно, если задачи будут закрываться, но хорошо это уточнить.

5. Ведется ли учет времени работы разработчика?
   Например, по контракту вы работаете 40 часов в неделю, но ведет ли работодатель учет отработанного вами времени? Достаточно ли вести учет времени в системе управления проектом?

6. Как дела с переработкой?
   Как часто приходится перерабатывать? Посидеть выходные раз в год, когда залило серверную - это нормально, работать по 10 часов каждый день месяцами из-за нереалистичных обещаний начальства - нет. Оплачиваются ли переработки и как? Есть ли возможность взять отпуск в качестве компенсации за переработку? Здесь возвращаемся к вопросу об учете времени - как работодатель будет знать, что вы работали больше 40 часов в неделю и имеете право на доп. отдых?

7. Дресс-код на работе.
   Такое крайне редко, но стоит спросить.

8. Какой длины испытательный срок?
   Как правило, это 1-3 месяца, но я видел случаи с 6 месяцами. Наличие такого длинного испытательного срока может быть подозрительным, и стоит задуматься. На испытательном сроке вас могут уволить с предупреждением за неделю или даже несколько дней (в зависимости от законодательства страны), что может быть неприятно, если имеются серьезные финансовые обязательства.

Компенсация

1. Какие условия отпуска?
   Например, есть ли какие-то ограничения, когда можно брать отпуск. Возможно, будет нельзя (или "не одобряется начальством") брать отпуск в новогодний период, когда онлайн-магазин под нагрузкой и страшно, что все упадет, или в конце финансового года и так далее. Хорошо узнать, можно ли брать длинный отпуск (взять все дни подряд). Как происходит одобрение отпуска? Начальник кликает мышкой и готово? Или заявление идет длинной вереницей по череде начальников, каждый из которых не торопится отпускать вас на отдых? Хорошо понимать, может ли начальник отказать в отпуске и какие для этого могут быть причины. Есть ли возможность взять неоплачиваемый отпуск (случилась беда, и вы не можете работать месяц)?

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

3. Выделен ли бюджет на образование?
   Если есть какой-то конкретный лимит на каждого инженера, то замечательно - вы сами можете решить, как его потратить (годовая подписка Pluralsight, O'Reilly Media или две конференции, например). Если оговоренного бюджета нет, то оплатит ли фирма покупку книг и курсов? Как выглядит процесс "давания добра" (начальник пишет "ок" в чате или опять череда заявлений и одобрений идет по бухгалтериям)?

Команда и разработка

Если считаете, что такие вопросы удобнее обсудить лично в ходе интервью, а не в переписке с HR (или нанимающим менеджером), так тоже можно, спросите, как людям удобнее.

1. Какое количество инженеров в компании, как они распределены по командам, сколько человек в моей команде?
   Хорошо иметь представление о текущем положении дел. Как правило, количество разработчиков пропорционально размеру компании (об общем количестве сотрудников можно узнать на LinkedIn или спросить у рекрутера), но бывают исключения. В фирме может быть 200 человек (190 - продажи и маркетинг, а инженеров 10 штук и все держится на них). Ничего плохого в этом нет, но если вы в начале карьеры, я бы советовал все-таки пойти в фирму, где инженеров побольше. Если в вашей команде всего два человека, может быть очень уютно (если сработаетесь), а может быть тоскливо, как повезет. Рядом с вами может быть один крутой ментор, который научит вас всему, что знает, а может быть команда из 15 раздолбаев, уж как сложится :)

2. Есть ли возможность переходить с проекта на проект (или между продуктами/сервисами)?
   Например, поработав годик на бэкенде, может стать интересно переключиться на фронт, и наоборот. Как происходят такие переходы, были ли прецеденты? Если есть возможность поговорить с человеком, который поменял роль, то это очень хорошо.

3. Какой компьютер у меня будет и можно ли выбрать?
   Для кого-то это может быть важно. Но если вы всю жизнь на MacOS, а тут Windows, может быть больно, и наоборот. Хорошо уточнить, можно ли выбирать себе ноутбук самостоятельно. Есть компании, где единый стандарт - все на одной операционной системе и все ноутбуки одной фирмы (я был там, где везде HP+Windows, там, где везде Dell+Linux, и там, где везде MacBook Pro). Но есть такие, которые очень гибкие в плане компьютеров сотрудников. Однако, помните, что если вы возьмете что-то экзотическое, помочь вам может быть некому, так что выбирайте с осторожностью.

4. Как выглядит мое рабочее место (в офисе)?
   Если работаете из дома, компенсирует ли компания обустройство домашнего рабочего пространства (покупку мониторов, например)? Если из офиса, можно ли отовариться парочкой мониторов для рабочего места за счет фирмы?

5. Можно ли участвовать в опенсорс-проектах (pet-проектах)?
   Это хорошо уточнить заранее, чтобы понимать, сможете ли вы продолжать участвовать в каких-то проектах, будучи сотрудником этой компании. Тут как повезет - бывает, что достаточно подписать некоторое соглашение о том, что ваши проекты не помешают бизнесу компании (если вы работаете над платным приложением для учета финансов, то нельзя будет пилить такое же, но бесплатное приложение). Так же хорошо учесть, кто будет являться собственником продукта интеллектуальной деятельности, чтобы потом не было проблем с лицензией для вашего опенсорс-продукта/сервиса.

6. Как проходят performance review, если такие есть, и как часто?
   Если такие оценки работы инженера проходят пару раз за год, то это нормально. Я бы насторожился, если ревью чаще 3 раз в год. Но, может быть, это делается просто потому, что так захотел директор, а по факту это формальность. А может быть будут считать количество закрытых тикетов в Jira и вешать фотографии в коридоре у секции "сотрудник месяца".
   Хорошо бы спросить, с какой целью они проводятся, и какие действия предпринимаются по итогам (повышение грейда и зарплаты, премии) и, главное, по каким критериям проводится оценка производительности разработчика. Если в фирме есть четко прописанные грейды, как например, у CircleCI и Capgemini или что-то в духе Engineering ladders (с зарплатной вилкой и требуемым набором компетенций), это замечательно, потому что будет куда расти по зарплате и компетенциям. Если нет, то не страшно, но хорошо бы спросить у нанимающего менеджера, как человек собирается отслеживать ваш прогресс как инженера (про отслеживание собственного роста писал в этой статье.

7. Как выглядит испытательный срок, что от меня ожидается?
   В некоторых вакансиях это уже прописано, но такое встречается довольно редко. Обычно это краткое описание того, что от вас ожидается в течение ближайших месяцев. Например:

   • Через 1 месяц: настроите среду разработки, разберетесь, где все лежит, познакомитесь с коллегами;

   • Через 3 месяца: закончите первые задачи, сами выкатите что-то в продакшн, что-то почините в продакшн;

   • Через 6 месяцев: поучаствуете в планировании дорожной карты продукта, начнете менторить кого-то из коллег, выступите на внутренней конференции.

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

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

В продолжение темы планируется отдельная статья по вопросам, которые стоит задать нанимающему менеджеру уже на интервью (или по почте, если такая опция доступна), например, вопросы о процессах разработки, код-ревью, и взаимодействии между инженерами.

Всем удачи на собеседованиях! И желаю найти работу своей мечты!