Привет, %username%! Нам не редко приходится искать работу и проходить собеседования. Главное что многие забывают – собеседование это процедура в обе стороны.

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

Типичное собеседование

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

Типичная схема проведения технического интервью на “около Ops”:

  • Тебе рассказывают о текущем стеке технологий или проекте над которым придется работать;
  • Ты рассказываешь о своем последнем опыте, достижениях и провалах;
  • Тебе задают технические и не очень вопросы;
  • Ты задаешь свои вопросы интервьюерам;

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

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

Расскажите о своем последнем месте работы?

Как интервьюер я обычно стараюсь задавать вопрос не только про общее описание: с чем работал, какие задачи выполнял, какими тулами пользовался?

Я всегда стараюсь задавать вопросы про достижения и провалы. Следовательно если кандидат рассказывает про достижения – он наверняка осознает свою полезность для команды и бизнеса в целом. Хорошим примером достижения может быть следующее: “Сделал так, чтобы проект, который падал 2-3 раза в неделю перестал падать. Причины падения были такие-то. Исправил вот так вот”

Также стоит рассказать о провалах, которые были в работе. Это как минимум покажет, что ты осознаешь последствия своих ошибок и способен их исправить. К примеру я обычно рассказываю о том, как уронил Oracle DB развернутую в единственном экземпляре и от которой зависело абсолютно всё. После чего я таки смог ее восстановить. С техдиром компании мы поискали решение, которое позволило избежать подобных инцидентов.

Еще одним не маловажным моментом является то, что стоит рассказать о том чего не особо знаешь или с чем очень плохо получается в рамках предлагаемой вакансии. Стоит рассказывать именно то, в чем плаваешь так сказать. Например в 99% случаев на всякие DevOps/Linux Admin в требованиях указано: “Отличное знание сетей и модели OSI”. Я например очень так себе разбираюсь в модели OSI и постоянно путаю уровни. И в целом по сетям я довольно таки плаваю. И тем не менее, я не стесняюсь об этом говорить как минимум потому, что у интервьюера уже сразу будет формироваться вектор вопросов: вдруг он планировал задавать вопросы по сетям, а я уже сразу на них ответил (немного не так конечно, но ответил).

Рассказать про то, чего не знаешь дает огромное преимущество про которое многие забывают: дальнейшие вопросы будут именно по темам, которые ты знаешь! А тут уж у тебя есть место для манёвров – ты же знаешь эти темы хорошо или на достойном уровне.

Технические вопросы

Тебе интервьюер(ы) задает вопросы по технологиям и тулам основываясь исключительно на твоем резюме. Ну не совсем исключительно, окай. В преимущественном большинстве случаев вопросы интервьюера зависят напрямую от двух вещей:

  1. Что написано в описании вакансии;
  2. Что написано в резюме кандидата;

Есть такие компании, интервьюеры которых прям основательно готовятся к собеседованию (привет “Express 42”). Ребята не просто проштудировали мое резюме - это слишком просто и занимает 3-5 минут перед собесом. Они ознакомились с содержимым этого блога, изучили мой профиль на GitHub, на котором они нашли репозитории с моими ansible-ролями. И знаете что? Это чертовски круто, когда тебе задают предметно вопросы: “Вот тут ты сделал именно так. Поясни почему именно так и как можно сделать лучше?”

У тебя с интервьюером общий язык на котором вы оба говорите и оба понимаете. Я могу порекомендовать со своей стороны лишь одно: веди свой GitHub/GitLab профиль! Указывай ссылки на свой профиль в резюме! Это будет играть тебе на руку в дальнейшем как минимум тем, что можно будет показывать примеры своих наработок. Те кто сейчас подняли ведра с помидорами чтоб меня закидать – остыньте! Я не говорю о том, что нужно брать и как есть выкладывать на GitHub все свои наработки. Я к примеру сделал некоторое количество ansible-ролей, в максимально унифицированном виде – их можно применить к чему угодно.

Задавай свои вопросы

Вот тут стоит хорошенько подумать и я попробую в первую очередь для себя сформировать чек-лист с теми вопросами, которые стоит задавать на техническом собеседовании. Этот этап интервью кандидат очень часто стесняется – “Как я буду задавать вопросы? Они ж вон какие большие и крутые!”

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

Собственно вот такой список вопросов как мне кажется надо задавать интервьюерам на данном этапе собеседования:

  • Как выглядит типичный рабочий день?
  • Что необходимо для того, чтобы стать действительно успешным на этой должности?
  • Какие виды навыков отсутствуют в команде, которые вы хотите получить, наняв нового сотрудника?
  • Какие самые большие проблемы, с которыми предстоит столкнуться человеку на этой позиции?
  • Предполагаете ли Вы, что основной круг обязанностей для этой должности изменится в ближайшие полгода-год?
  • Имеются ли дежурства или овертаймы? Насколько часто? Как и кем составляется график дежурств? Как они компенсируются?
  • Сколько человек в команде? Как организована коммуникация внутри команды и между смежными командами?
  • Имеются ли токсичные люди в команде куда я иду?
  • Какие учебные программы доступны для ваших сотрудников?
  • Какие существуют возможности карьерного роста и профессионального развития?
  • Кому я должен буду отчитываться? Какова координация в команде? Имеется ли тайм-трекинг? Кто отвечает за постановку задач?
  • На сколько сложно уйти в отпуск в любой момент времени (вне зависимости от задач/пожаров на проекте) просто написав заявление за 2 недели?
  • Есть ли bus-фактор на позициях коллег, с которыми мне предстоит работать?
  • Как обстоят дела с выделением времени на инкремент документации? Как в целом обстоят дела с документацией?
  • Есть ли шеринг опыта в команде? Внутренние митапы или иные регулярные встречи с участием Ops, Dev и QA?
  • Есть ли инженер безопасности? Если ли понимание DevSecOps в команде?
  • В случае изменения архитектуры инфраструктуры кто принимает решения?
  • Будет ли выделена рабочая техника? В т.ч. из соображений безопасности.
  • Обучение английскому? Участие в конференциях как спикер или доступ к докладам сотрудников/коллег на каких-либо конференциях?
  • Смогу ли я представлять компанию на отраслевых конференциях?
  • С кем из менеджерского состава предстоит взаимодействовать? Как сильно они погружены в IT в целом, в продукт, в технологию?
  • Гибкость начала и конца рабочего дня? На сколько просто при необходимости сдвинуть рабочий день, чтоб начать позже и закончить позже, но выполнив задачи?
  • Есть ли ретроспективы? Ведутся ли постмортемы?
  • Какие наиболее важные вещи, по вашему мнению, я должен буду сделать за первые 30, 60 и 90 дней работы?
  • По каким показателям моя деятельность будет оцениваться?
  • Планируете ли вы нанимать ещё людей в это подразделение в ближайшие шесть месяцев?
  • С какими подразделениями компании придется взаимодействовать чаще всего?
  • Можете ли вы рассказать мне о последнем совместном командном мероприятии?
  • Насколько, по вашему мнению, моя квалификация соответствует данной роли?
  • Как устроено обучение сотрудников?
  • Есть ли правила коммуникации?
  • Сталкивались ли с выгоранием сотрудников и что делали в этой ситуации?

Думаю на этом можно закончить. По мере необходимости буду стараться обновлять данный список вопросов.

Главное, что необходимо помнить во время интервью (ну и в период испытательного срока) это то, что не только компания оценивает тебя как специалиста, но и ты оцениваешь компанию – нравится ли тебе то, чем занимается компания, устраивает ли тебя команда в которую ты идешь, интересен ли стек технологий и т.д.

ЗЫЖ Пример тех вопросов, которые реально глупые или слишком заезженные можно найти в Собеседовании без купюр.

На это всё! Profit!

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