Я вам перезвоню
Привет, я Катя, я нашла работу. И написала методичку по общению с работодателем. Расскажу, что спрашивать на собеседовании, чего не спрашивать и как это делать правильно.
Весь месяц гоняла по собесам. Посмотрела и на стартапы и на Яндексы. Компаний много, выбирать сложно. Чтобы найти ту самую, нужно учесть много факторов. Для каждой компании я составляла индивидуальный список вопросов. Универсальные оформила в этот faq. В нем ключевые вопросы соискателя и их аналитика. Часть вопросов заточена под разработчиков, остальные подойдут всем. Го под кат!
TL; DR
Не знаю, что и как спросить.
Держи алгоритм!
- Рефлексируй.
Что нравилось на прошлой работе? Что не нравилось? Почему ушел?
Отобрази эти ключевые поинты на вопросы. - Составь роадмап.
Что хочешь от новой работы?
Отобрази эти требования на вопросы. - Отфильтруй.
Убери лишние вопросы. Вопрос лишний, если попадает под пункты из списка:
— ответ можно нагуглить;
— ответ не будет стоить затраченного времени;
— большой шанс получить социально-ожидаемый ответ;
— вопрос неудобный, тебе скорее всего соврут;
— ты не знаешь правильный ответ;
— ты не знаешь, что хочешь услышать;
— ты не знаешь, чего не хочешь слышать;
— ответ не повлияет на решение. - Уточни.
Открытые вопросы конкретизируй.
Если ответ зависит от обстоятельств, задай конкретный кейс. - Сформулируй ожидания.
Чего хочешь? С чем готов смириться? Что неприемлемо?
Отметь красные флажки. - Старгетируй.
Что учесть:
— размер компании;
— должность;
— описание вакансии;
— цель встречи (этап).
Зачем так сложно?
Чтобы не жалеть о выборе. Чтобы найти компанию, которая даст тебе все то, что ищешь: задачи, перспективы, условия — мы же тут не за деньги работаем :)
Время интервью ограничено. Мы не хотим тратить его на социально-ожидаемые ответы, отговорки, ненужную информацию. Получить нужную непросто. Надо знать, где проткнуть, чтобы инфа потекла. И не тыкать без разбора, чтобы в ней не захлебнуться. Подготовим тонкие прицельные вопросы. Построим на них последовательный содержательный диалог.
Disclaimer
Цель статьи — сориентировать, что спрашивать и зачем. Здесь нет сакральных знаний и волшебных вопросов. Составь подходящие на основе перечисленных. Используй алгоритм выше.
Я помогу распарсить ответы. Под каждым (не каждым) вопросом есть аналитика по параметрам:
- «Ask yourself»: что можно услышать, о чем стоит задуматься;
- «Good to hear», «Red flags»: какие сделать выводы, с какими не спешить;
- «Discuss»: что уточнить, куда перенаправить диалог.
Аналитика не исчерпывающая и основана на личном опыте. Если какого-то раздела нет, значит я не считаю свое мнение объективным или мне нечего добавить. Мои «Good to hear» и «Red flags» могут не совпадать с твоими. Аналитика нужна не везде: я же не знаю, что у тебя в голове, чего хочешь, что ищешь. Разберись с этим, прежде чем идти на собес.
В секции «Дурацкие вопросы» я собрала специфичные и бесполезные. Мне они не нравятся, причины я перечислила. Хочешь — используй.
Я обкатала 70% того, что написала, остальное не успела. Если я не права, все не так, у тебя было по-другому — напиши в комментариях, как правильно, это поможет остальным.
Бизнес
«Покажи заинтересованность — спроси про компанию.» Bullshit. Не интересно — не спрашивай, нагуглишь.
1. На чем вы зарабатываете? Какой продукт — основной источник дохода?
Кейс 1. Твой проект — локомотив.
Основной продукт — святая корова: все на него молятся, заливают деньгами, ресурсы предоставят еще вчера, но и ожидания соответствующие. Готов работать на передовой со всеми вытекающими?
Кейс 2. Тебя приглашают в новый молодой проект.
В таких гибче стек и процессы, но они могут схлопнуться: работа в стол, сотрудников сократить. Хорошо понимаешь риски?
Оффтоп. Зная бизнес-модель и источники дохода, можно прикинуть текущее положение компании на рынке, перспективы развития. Нет смысла глубоко анализировать крупную компанию. Оценить стартап лишним не будет, если ориентируешься в области.
Discuss
Если берут в основной проект, удели внимание вопросам про сроки и приоритеты разработки. Если в новый, выясни, что с тобой будет, если проект не полетит.
2. В каких направлениях работаете? Какие есть b2b проекты, b2c, R&D?
Есть другие интересные проекты? Если этот надоест, есть куда ротироваться?
Оффтоп. Вопрос скорее для крупных компаний, но ответ бывает неожиданным в небольших — могут оказаться масштабнее, чем ты думал.
Good to hear
Компания анализирует рынок, ищет новые направления для развития, участвует в совместных проектах с другими компаниями. Много разных продуктовых команд. Есть интеграции с другими сервисами. Вкладываются в R&D.
Мотивация
Про ништяки рекрутер сам расскажет. Если что-то критикал, уточни.
Попроси показать офис. Скорее всего покажут. Пуфики, кухня, спортзал — круто, если рабочее место тоже удобное. А то пуфики на пятом этаже, а работать будешь на втором, где идет ремонт.
1. Что влияет на мою зарплату кроме повышения? От чего зависит премия?
2. Какие есть поощрения? Как их заслужить?
3. Какие компы/ноуты? Можно работать на них из дома?
4. На конференции отправляете ребят? А на международные? Куда ездили последний раз? Как решается, кто поедет?
Отдел
1. Сколько человек в отделе? Как они общаются? Как тесно взаимодействуют?
Команды/подразделения знают, что происходит в соседних командах/подразделениях? Как шарятся знания?
Discuss
— Какие вопросы решаются сообща?
— Для чего последний раз вместе собирались?
— Сколько человек пришло?
— Какой был результат у встречи?
Good to hear
Ключевые решения принимаются сообща, с учетом разных мнений. Сохраняется необходимый уровень самостоятельности. У всех есть понимание, что происходит в других проектах, чтобы помогать с код-ревью и знать, у кого можно стащить решение своей проблемы. Решения и знания фиксируются и всем доступны. Формальные встречи для обмена новостями и опытом это вин.
2. На какие команды делятся разработчики?
Кроме продуктовых бывают узкоспециализированные: разработка общих компонентов, разработка инструментов, команда рефакторинга, архитектурная команда.
Кейс 1. Много команд.
Лучше концентрация на задачах, выше экспертиза разработчиков в своей области, но ниже в других, снижается их интерес к «чужим» задачам. Я за специализацию + ротации. Ты со мной?
Кейс 2. Мало команд.
Выше вовлеченность, шире спектр задач, но шире и круг ответственности. Готов к роли «и швец, и жнец»?
Discuss
Уточни, как распределена ответственность за проекты и микросервисы среди команд.
3. Сколько человек работают в отделе дольше 3 лет? Есть такие?
Сколько людей смогут тебя сориентировать, когда будешь рефачить значимый функционал или очень древнее легаси?
Оффтоп. Не пытайся оценить текучку. Слишком много факторов влияет на то, уходят люди или остаются. Куча олдов может отражать не только комфортные условия работы, но и кучу ленивых безамбициозных жоп в отделе.
Good to hear
Если их больше двух, это вин. На прошлой работе было много олдфагов, это выручало меня пару десятков раз.
Команда
Команды бывают похожи по составу, задачам, процессам и стеку, а бывают абсолютно независимы друг от друга. Если тебя приглашают в команду, которая не отличается от других, вопросы из секций «Команда», «Задачи», «Процессы» и «Стек» можно задать сразу. Иначе попроси дополнительную встречу с командой после прохождения интервью. Скорее всего тебе не откажут. Часто такая встреча уже запланирована. Тогда переходи сразу к секции «Развитие».
1. Кто в команде?
Кейс 1. Большая дружная команда. Возможно, кросс-функциональная.
Больше коммуникаций, больше встреч и планирований. Ты командный игрок?
Кейс 2. Будешь все делать сам, ни от кого не зависеть.
Шире круг задач, выше ответственность. Ты этого хотел?
Кейс 3. Есть удаленщики.
Это не развернулся и спросил. И на обед вместе не сходить. Тебе норм?
Discuss
Если кросс-функциональная:
— Что делаете, если закрепленных тестировщиков не хватает?
Если сами по себе:
— Кто тестирует? Сколько дней обычно ждете свободного тестировщика?
— Кто согласует планы с руководством?
2. Кто заказчик (product owner)? Есть менеджер (project manager)?
Кейс 1. Продакт с невалидным бэкграундом в разработке (oh, my!), или чересчур амбициозный, или неопытный и плохо знает продукт. Проджект слабый/его нет/он же продакт.
Будешь защищать свои интересы самостоятельно. Прокачаешь софт-скиллы, научишься аргументировать свои хотелки и искать компромиссы. Это входит в сферу твоих интересов? Ты к этому готов?
Кейс 2. Нет ни продакта, ни проджекта, ни тимлида.
Будешь сам согласовывать планы, планировать ход работ. Справишься?
Оффтоп. Проджекты ничего нам не должны. Они могут сделать нашу работу проще и приятнее, но не избавят от общения с продактом и не гарантируют интересных задач.
Discuss
— Кто ставит приоритеты задачам?
— Кто и как оценивает работу команды?
Если нет обоих:
— Кто ставит задачи?
— Кто согласует планы с руководством?
Если есть продакт:
— У каждой команды есть свой продакт?
— Сколько лет опыта у вашего? Сколько из них он работает в компании? Сколько — в команде?
Если есть проджект: все то же самое про проджекта.
3. Когда был тимбилдинг? Сколько человек пришло? Видитесь вне работы?
Похоже на дружную атмосферу? Компания работает над тем, чтобы ее создать?
Good to hear
Вместе обедают. Гоняют вместе на внешние конфы. Организуют обучения и мастер-классы друг для друга. Так бывает не только в крупных компаниях. Собираются всем отделом в неформальной обстановке — это вин, тут точно дружно. Потому что собрать вместе 5 человек — сложно, собрать вместе 5+ человек — практически невозможно, если они просто коллеги.
Задачи
Самый важный для меня пул вопросов. Но крутые задачи — не панацея. Я не сразу и не сама до этого дошла.
Во-первых, ты в реальном времени можешь и должен влиять на то, какие задачи решаешь. Ключевую роль играет инициатива и твой личный роадмап (есть он у тебя?).
Во-вторых, в любой задаче можно найти для себя что-то новое и интересное. Интересная задача это не только новые технологии, сложная логика, красивые интерфейсы, проработка архитектуры. Сделать самостоятельно, сделать быстро, сделать лучше, чем планировал, лучше, чем в прошлый раз. Придумать, согласовать, порефакторить, поисследовать. В этом проекте, в соседнем, в том, который ты только что придумал.
В третьих, крутой коллектив и приятная атмосфера нивелируют рутинные задачи. В обратную сторону работает реже. Не зацикливайся на задачах. Лучше вообще ни на чем не зацикливайся. Ставь приоритеты, но учитывай все факторы.
1. Какие задачи я буду решать?
2. Что входит в обязанности, кроме разработки?
3. Какие два последние проекта сделали? Какие проекты на очереди? Как планируете развивать сервис в ближайшее время?
4. Какие задачи из последних больше всего запомнились, понравились?
5. От каких задач хотели бы избавиться? С чем сейчас приходится мириться (нет людей, еще не автоматизировали)?
6. Что последнее сделали для души, для отдела, из непродуктовых задач?
Обычно беседу ведет тимлид, у них на их хотелки больше ресурсов или полный карт-бланш. Задавай вопрос разработчику продуктовой команды или самому молчаливому.
7. Есть бэклог непродуктовых задач?
Иногда всем разработчикам выделяется процент времени для решения непродуктовых задач: техдолг, эксперименты. Бывает отдельный пул задач из категории «решите, кому не лень». Это задачи для саморазвития и помощи другим командам/отделу. Часто для них есть отдельная борда в джире. Если такие задачи тебе интересны, оцени их релевантность. Это может быть всякий шлак, в который никто не хочет лезть, а могут быть крутые задачи, в которые никто не смог или всем некогда. Попроси привести примеры таких задач, чтобы понимать, для каких задач не хватает рук/времени/желающих/экспертов.
8. Для чего используется такая-то технология/библиотека/фрэймворк?
Уточни, какие задачи решаются с помощью выбранных инструментов и ключевых технологий. Чтобы знать, как тесно ты будешь с ними работать, как хорошо должен/будешь их знать.
9. Сколько процентов времени занимают такие-то задачи?
Важно понимать процентное соотношение разных задач. Не спрашивай про все. Оцени количество тех, которые не хочешь решать. Заранее определи комфортные границы.
Процессы
1. Как готовитесь к планированию спринта/квартала?
Продакт обсуждает проекты с командой до составления ТЗ? Ты бы не хотел принимать больше участия на этапе анализа и разработки требований?
Discuss
Уточни, насколько активно тестировщики участвуют в анализе проекта. Тестирование требований напрямую влияет на качество ТЗ.
Если шаришь, как надо, уточни остальные аспекты планирования. Только точечно, иначе получишь пересказ главы из книжки про скрам.
Good to hear
Планирование двухэтапное. Обсуждают цель проекта. Читают тз, ищут, что упустили. Исследуют код, в который полезут (этот код, может, рефачить придется, а еще библиотеки по пути обновить). Заходят в сб и архитекторов: вдруг так нельзя/неправильно/можно проще/такое уже есть. Собирают требования по доработке инфраструктуры.
Red flags
Команда не осознает важность подготовки. Команда впадает в аналитический паралич.
2. Какой code coverage?
Сколько тестов ты готов сам дописать, когда прижмет?
Discuss
— Сколько процентов кода покрыто модульными тестами?
— Сколько процентов функционала покрыто интеграционными тестами?
— Кто пишет автотесты?
Good to hear
В крупном проекте я ожидаю 70%, это хороший достижимый показатель. Не все ручные тестировщики любят и умеют писать автотесты: хорошо, если это контролируется.
Red flags
Низкий показатель может означать низкое качество продукта, безответственность команды, невменяемость менеджера: «кати так, тесты потом напишешь» или «мы же не собираемся ничего обновлять». Может означать != точно означает. Code coverage непростая метрика: можно получить высокий показатель, покрыв по максимуму простые кейсы и не покрыв ключевую логику. Стартапам низкий показатель простителен.
3. Кто будет ревьюить мой код?
Кейс 1. Все в теме, по 10 ревьюеров на пулл-реквест, всем есть дело до тебя.
А тебе есть дело до всех? Ты готов отсматривать 5+ пулл-реквестов в день?
Кейс 2. Тимлид посмотрит твой код, если будет время.
Нет ревью — никто не скажет, как надо, как правильно. Ты точно знаешь, как правильно?
Оффтоп. Хорошо организованный процесс код-ревью не гарантирует его качество. На словах «глубоко анализируем логику», а на деле — 50 сообщений в треде про какую-то абсурдную вкусовщину. Узнай необходимый минимум, но не спеши с выводами.
Discuss
— Сколько твоя последняя задача на ревью висела? Быстро прогнал. Всегда так?
— У пулл-реквестов есть приоритеты?
— Сколько пулл-реквестов в день смотришь ты?
Good to hear
Члены команды — обязательные ревьюеры. В обязательных есть кто-то, кто шарит за архитектуру. Пулл-реквест не висит дольше 3х дней без особой причины. Заброшенные пулл-реквесты автоматически удаляются. Команды ориентируются в коде других проектов, проводят код-ревью других команд.
Red flags
Твой код смотрят два с половиной калеки.
4. Как проходит сборка и деплой?
Кейс 1. CI/CD, все автоматизировано.
Обычно автоматизацией занимаются админы/девопсы. Но могут и тебя привлечь. Не ссышь?
Кейс 2. Все вручную.
Сам собирай пакеты, связывай задачи, создавай релизные таски, контролируй приемку. Тебе норм, или ты уже разнежился?
Discuss
— У команды собственный тестовый стенд?
— Сколько времени нужно для создания нового стенда с конкретным окружением?
— Кто проводит релиз? Кто ответственный?
— Сколько времени занял твой последний релиз?
— Как часто релизите?
— Если релиз упадет в 10 вечера, какой план действий?
Good to hear
CI/CD настроен по максимуму: мастер срезается по коммиту/расписанию, а схему можно создать по кнопке. У команды свой тестовый стенд и никто в него не ходит. Катить будет админ, но ответственность вы несете все. В компании это понимают и не ищут одного виноватого.
Red flags
Много рутинных операций. Много релизов, но условия не адаптированы.
5. Как часто проводите ретро?
Нравится формат? Меня, например, бесят ретро в игровом формате.
Discuss
— Сколько времени длилась последняя встреча?
— Сколько человек пришло?
— Что удалось выяснить?
— Что планируете с этим делать?
— Что последнее улучшили благодаря ретро?
— Что является показателем эффективности команды?
Good to hear
Плановые ретро, чаще — лучше. Есть план и жесткий тайминг. Присутствуют все, кто принимал участие в обсуждаемых проектах, а не только команда. Результаты фиксируются, делаются выводы, планируются конкретные действия по улучшению ситуации. Отслеживаются результаты этих действий.
Red flags
Ретро проводится только в случае факапа. Длится дольше двух часов, это значит обсуждение не структурировано, к ретро не готовятся, разводят холивары. Никто не контролирует исполнение принятых решений.
6. Когда отрабатываете техдолг?
Менеджер/продакт/руководитель понимает, зачем это нужно? Что он делает для того, чтобы не увязнуть в техдолгах? Что для этого делают сами разработчики?
Discuss
— Что последнее отрефакторили?
— Какие непродуктовые задачи брали в этом квартале?
Good to hear
Техдолг разгребается планово. Учитывается при планировании. Выделяется фиксированное время (% рабочего времени/часть спринта) на улучшение кодовой базы, эксперименты, инициативу. Сложность кода анализируется автоматически.
Red flags
Продуктовый бэклог не отличают от техдолга.
Стек
Не пытайся понять всю систему: монорепы, микросервисы, на чем и почему, как дружатся. Хорошо, если разберешься во всем этом во время работы. На собесе достаточно выяснить, какая логика на чем написана, где лежит и кто ее поддерживает.
1. На чем легаси написано?
Готов с таким возиться?
Discuss
— Это легаси просто есть или активно поддерживается?
— Планируется перевод, рефакторинг? Почему? Когда? Кем?
— Какой процент легаси-кода задокументирован?
Good to hear
Ничего сильно зашкварного нет. Есть есть — это известные технологии. Если велосипед — есть те, кто шарит. Если собираются переводить — есть план и команда, а не козел отпущения (ты можешь им стать).
Red flags
«Перепиши чужой проект, больше некому».
2. Почему (не) выбрали технологию/библиотеку такую-то?
Кейс 1. Есть решение проще.
Была весомая причина выбрать более мощное и сложное решение?
Кейс 2. Есть более надежное/удобное/дешевое решение.
Есть весомые причины не внедрять его?
Кейс 3. Подозрительное/ключевое решение.
Сколько шишек соберешь, переезжая на другое решение? Причины выбора и обзор нюансов где-то зафиксированы? Или придется аналитить с нуля?
Discuss
— Рассматривали альтернативы?
— Кто принимал решение?
— Были сомнения?
— Каких проблем уже успели отхватить? Как решали?
— Не думали отказаться/перейти на другое решение?
— Какая версия? Че такая старая?
Good to hear
Учтена специфика сервиса. Решение принималось сообща, устроило большинство. Провели предварительный рисерч. Результаты обсуждений и согласований фиксировались и доступны.
Red flags
Она была, мы не меняли. Мы только попробовать. Мы хайпожоры.
3. Какие технологии внедрили за последние полгода/год?
Следят за развитием области и инструментов? Выбирают осознанно? Если не проявляют инициативы, готов взять ее на себя?
Discuss
— Может, наоборот убрали что-то из стека? Почему?
— Может, что-нибудь пытались внедрить, но не прижилось? Почему?
Good to hear
Проводят рисерчи, пытаются сделать лучше/проще/надежнее, но в рамках разумного.
Развитие
Джуну развиваться легче: вся область — непаханое поле, ниже ответственность, инициативу заметят и поощрят. Старшему сложнее: выше ожидания, сложнее их оправдывать, для роста нужны определенные условия, для повышения — адекватная оценка. Чем выше уровень, тем важнее эта секция.
1. Кто меня оценивает? По каким критериям?
Требования и ожидания фиксируются? Они тебе понятны?
Ты сможешь оправдать эти ожидания? Не смущает уровень давления?
Где потолок?
Good to hear
Вас оценивают те, кто работает с вами бок о бок.
Формальные критерии дополняют субъективную оценку коллег. Есть четкие критерии оценки: скорость работы, объем задач, выход за зону ответственности, рост хард-скиллов, развитие софт-скиллов. Если есть грейды, они обкатаны и действуют не первый день.
Red flags
Тебя оценивает формальный руководитель или кто-то левый. Оценка максимально субъективная. Оценка учитывает только измеримые показатели: сколько решил задач и пр. Не понятно, куда можно развиваться и как это делать.
2. На что влияет оценка? На что влияет грейд?
Ты можешь напрямую влиять на ништяки?
Ты готов на них влиять или просто хочешь много денег?
Good to hear
Результаты оценки моментально (моментально не будет) отображаются на ништяки: зарплату, должность, возможности или условия работы. Или хотя бы дают приоритет для их получения. Грейды не только про ответственность, но и про возможности.
Red flags
Оценка ничего не дает, тебя погладят по головке и не уволят.
3. Есть возможность ротироваться в другую команду?
Ротации это знакомство с другими продуктами и людьми, увеличение экспертизы, новые задачи, и все это не меняя работы. Тебе это интересно? Или тебе проще сменить работу, когда надоест?
Discuss
— Как часто происходят ротации по инициативе сотрудников?
— Есть ограничения на ротации (частота, сроки)?
— Возможна принудительная ротация (для обмена опытом)?
Good to hear
Ротации возможны и практикуются. Ограничения адекватные.
Ожидания
«Чего от меня ждут?» — очень важный вопрос. Если спросишь в лоб, получишь стандартное «справляешься с задачами, много успеваешь, ладишь с командой». Пробуем не в лоб.
1. Почему нужен человек в команду?
2. Какого специалиста не хватает в команде? Каких хард-скиллов не хватает ребятам в команде? Какого экспириенса не достает?
3. Какие задачи некому передать? Почему?
4. Каких специалистов не хватает в отделе кроме тимлидов?
5. Что нужно сделать, чтобы превысить ваши ожидания? Приведи пример задач.
6. Какие сомнения остались на мой счет?
7. Какие сложности точно будут на старте?
8. Какие задачи дадите мне в начале?
9. За мной будет закреплен куратор? На какой период?
Оффтоп
Личные вопросы. Встреча должна быть интересной для обеих сторон. Дай человеку возможность рассказать о том, чем он гордится, чего достиг, поделиться опытом. Все любят про себя рассказывать. Тебе это выгодно. Во-первых, разговоришь собеседника, можно будет подбросить неудобные, компрометирующие вопросы. Во-вторых, понравишься и запомнишься ему, ты ж хочешь пройти собес? В-третьих, общение с классным чуваком — отдельный повод сходить на собес.
1. Давно здесь работаешь? Это много. Что так цепляет?
2. А где до этого работал? А че ушел?
3. Чему научился на работе за последний год?
4. Сколько часов в день кодишь? На что уходит остальное время? Остаются силы дома прогать?
5. Во сколько на работу приходишь? Во сколько все расходятся?
6. Где можно вне рабочего места поработать? Где сам обычно тусишь?
7. Пользуешься сам вашим сервисом? Что хотел бы улучшить в нем? Пробовал забросить это в продакта? Можно повлиять на развитие сервиса? А на решения продакта? Удавалось что-нибудь продавить? Расскажи.
8. Какие метрики отслеживаете?
9. Как обеспечиваете безопасность?
Если собеседует тимлид/руководитель:
1. Какими процессами сейчас не доволен?
2. Над чем планируешь в ближайшее время работать? Какие приоритеты?
3. Менторишь кого-нибудь из отдела?
4. Как справляетесь с нехваткой тимлидов?
Как закончить
Часто собесы проводишь? Много времени отнимает?
Тогда не буду тебя задерживать. Спасибо, что уделил время. Мне было очень интересно с тобой. Надеюсь, не прощаемся ;)
Дурацкие вопросы
Попадают под определение «лишний вопрос» (см. алгоритм в «TL; DR»). Предложу, на что заменить. Хочешь — используй и эти вопросы, тебе виднее. В специфичных случаях они дадут нужную информацию. Подойдут для «развязать беседу». Я начала обходиться без них.
1. Чем вы лучше конкурентов (УТП, конкурентные преимущества)?
2. Кто финансирует проекты (ключевые инвесторы)?
3. Какие сложности сейчас испытываете?
4. Какие планы на ближайший год?
Why not. Ответы можно нагуглить. Если их нет в открытом доступе, тебе не дадут их на интервью. Рекрутеры — селл-сайд, они не расскажут неудобную правду.
Solution. Ее расскажут финансовые отчеты (если компания публичная).
5. Переработки оплачиваются?
Why not. Их быть не должно. Если они есть, скажут, что их нет. Если это норма, скажут, что оплатят. На деле может быть иначе.
Solution. Найди такую компанию, где не придется задавать этот вопрос. Если не планируешь поднять денег на переработках.
6. Сколько в отделе тимлидов/ведущих/экспертов? Чем они занимаются?
Why not. Тимлид в каждой команде — отлично, но это вряд ли. Их всегда не хватает. Про своего тимлида узнаешь, обсудив состав команды. В идеале те, кто постарше, тратят часть времени на решение непродуктовых задач. Если это формальные требования, они могут не соблюдаться.
Solution. Если собеседует тимлид, задай прицельные вопросы (см. секцию «Оффтоп»).
7. Кто мой непосредственный руководитель? Чем он занимается? Как он тебе?
Why not. Квалификацию руководителя ты так не распарсишь. Разработчик не станет оценивать при вас руководство. Если станет, он или врет или необъективен.
Solution. Если критикал, попроси назначить личную встречу с руководителем. Если он сам тебя собеседует, задай прицельные вопросы (см. секцию «Оффтоп»).
8. Как оцениваете задачи?
Why not. Есть шкала для оценки в сторипоинтах и есть велосити. Их точность и адекватность ты не распарсишь на интервью. Оценка в днях не покажет качество декомпозиции — подозрительных кейсов не озвучат. У задач есть приоритет. Качество расстановки приоритетов ты не распарсишь на интервью.
Solution. Возможно, поможет:
— «Что учитываете при оценке времени?» Good to hear: играют в planning poker, закладывают риски, учитывают экспертизу исполнителя, возможность рефакторинга, связанные задачи из бэклога.
9. Сколько времени в среднем занимает разработка новой фичи? А включая сопровождение?
Why not. Время разработки не поможет оценить количество отвлекающих факторов. Время сопровождения не поможет оценить скорость тестирования и ревью. Слишком условно, все зависит от обстоятельств.
Solution. Возможно поможет (в качестве оффтопа):
— «Что последнее решал? Сколько времени убил? Че так быстро/долго?»
— «Сколько времени последняя задача висела в тестировании/на ревью? Это хороший показатель?»
10. Митинг под всех подстроен?
Why not. Тебя остановит, если нет? Не приедешь на полчаса пораньше? Взаимоотношения в команде ты так не распарсишь.
Solution. Возможно поможет:
— «Во сколько митинг? В это время я обедаю/еще сплю/уже дома. Сможем перенести на другое время?»
11. Есть дежурные на время праздников?
12. Есть маратории?
Why not. Маратории нарушаются, а дежурные есть админы.
Solution. Возможно поможет:
— «Когда последний раз нарушали мараторий? По какой причине?»
— «Если я катну релиз и заболею, кто будет откатывать?»
13. Как часто дается обратная связь?
Why not. Обратная связь по запросу есть везде. Часто только по запросу. Я считаю, такие встречи должны проводиться планово, но мало ли, что я считаю.
Solution. Если есть проблема, не держи ее в себе.
14. Я заявляю о проблеме на ревью. Как она будет решаться?
Why not. Большой шанс получить социально-ожидаемый ответ. Если общаешься со своим тимлидом/руководителем, обсуди конкретные кейсы.
Solution. Возможно, поможет:
— «Продакт не дает разгрести техдолг. Он не прав.» Good to hear: для решения проблемы запланированы конкретные действия. «Я с ним поговорю» — плохо. «Я приду на планирование, оценю ситуацию и помогу найти компромисс» — хорошо.
15. Компания купит мне софт для работы?
Why not. Хорошая купит, плохая — нет. Хорошая или плохая поймешь по другим вопросам. Лицензию на IDE купят, сами заинтересованы. Если нужно что-то конкретное и дорогое, задай прицельный вопрос.
Solution. Например:
— «Хочу Wallaby. Потому что смотрите, какой профит… Можно мне?»
— «Хочу подписку на Курсеру. Затраты оправдаю. Договоримся?»
16. Сколько джунов в отделе? Сколько мидлов и старших?
Why not. Возможности роста, сложность задач и опытность сотрудников ты так не распарсишь. Бывают скиловые джуны, бывают инертные старшие. Не все хотят расти. Первых больше — они выгоднее, вторых меньше — сложно схантить.
Solution. Если боишься отхватить всю черную работу (единственный джун) или хочешь с кем-то делить ответственность (единственный старший), отталкивайся от других вопросов (см. секцию «Ожидания»).
17. Сколько длится спринт? Как пришли к этой цифре?
Why not. Качество планирования ты так не распарсишь. Это переменная, и она не берется с потолка. Сильно подозрительных кейсов я не встречала.
Solution. Возможно поможет:
— «Сколько задач переехало в текущий спринт из предыдущего? Почему?»
18. Как синхронизируетесь с другими командами?
19. Как решаются конфликтные ситуации?
Why not. Слишком условно, все зависит от обстоятельств. Большой шанс получить социально-ожидаемый ответ.
Solution. Возможно поможет:
— «Двум командам нужно сделать одно и то же (написать общий компонент/потестировать/порисерчить), кто будет делать?»
— «Вы хотите внедрить в общий стек новую технологию, как будете принимать решение?»
20. Если план не выполнить, как накажут?
Why not. Никто не придет настучать тебе по шапке. Максимум премии лишат. Про премию уточни отдельно.
Solution. Найди такую компанию, где не придется задавать этот вопрос.
21. Микросервисы или монорепа? Как пришли к такой архитектуре?
Why not. Проект живет, требования меняются, монорепу растаскивают на микросервисы, иногда наоборот, но не обязательно и не каждую. Сегодня так, завтра по-другому.
Solution. Если шаришь за архитектуру и «просто любопытно» — уточни. Ты сам знаешь, что уточнять.
22. Как разработчики узнают о планах и достижениях компании?
Why not. Обязательная рассылка, митапы с директором, презентация перед новым годом, блог на Хабре, продакт присылает фидбэк от юзеров в общий чат — что-нибудь да будет.
23. Почему решили перейти на канбан?
Я верю, что это полезный вопрос, но не умею парсить ответ.
5 правил
Для тех, кто дочитал.
- Перейди на «ты» по возможности.
- Запомни имена. Обращение по имени — +100 к карме.
- Не игнорируй. Личные вопросы задавай всем присутствующим: вдруг обидятся, что у всех спросили, а у них не спросили.
- Не дай себя очаровать. Приятная дружеская беседа может здорово подкупить. Собеседующие — селл-сайд, поэтому все так подходит и здорово. Ты удивишься, как сильно это может приблизить тебя к неправильному решению.
- Не додумывай ничего, ориентируйся на факты. Будь бдителен.
Самый важный поинт
Интервью это беседа, а не допрос. Вопросы это всего лишь опорные точки для этой беседы. Куда ее уведешь, то и п
