Наши преподаватели поделились опытом прохождения технических интервью, в том числе с позиции работодателя. Раскрываем секреты, как себя проявить даже начинающему айтишнику, что делать, если не знаешь ответ на вопрос и многое другое.
Михаил Каморин
Senior Backend Developer в Skyeng, преподаватель курсов по PHP и его фреймворкам, Highload Architect.
Для middle и выше нет смысла заучивать формулировки и термины, важнее понимание.
Для джунов наоборот, понятно, что практического опыта ещё нет, и нужно хотя бы теоретически представлять себе происходящее.
Если не знаешь ответа, то стоит попытаться вывести его логически, но совсем пальцем в небо тыкать всё же не стоит, и лучше честно сказать, что не знаешь.
Если техспециалист на каждый правильный ответ задаёт вопрос всё сложнее, он не завалить хочет, а ищет «уровень незнания», и это нормально, если он его наконец находит. Другое дело, что потом это может быть использовано с целью сбить цену, но это уже не техспециалиста вопрос, его задача уровень оценить.
Вторичные навыки, смежные с компетенциями, необходимыми для вакансии, могут быть решающим фактором, но при условии прочих равных, а не сами по себе.
Чем выше позиция, тем важнее коммуникативные навыки, так как тем больше приходится общаться, обсуждать решения, планировать архитектуру и т.п.
Для джунов важнее всего иметь общее представление об используемом технологическом стеке (то есть большим плюсом является знание хотя бы в общих чертах о том, как устроен условный RabbitMQ) + решение алгоритмических задач. Также неплохо хотя бы формулировки из теории знать.
Для мидлов важно существование цельной картины. Очень часто приходят кандидаты, у которых SOLID отдельно, паттерны отдельно, например. Сразу видно, что на практике это либо вообще не применяется, либо применяется интуитивно, а теория подтянута за пару дней до собеседования.
То есть для мидлов полезно по последнему проекту посмотреть используемые паттерны, например, технологии и так далее.
Когда кандидат может привести практический пример использования какой-то теоретической вещи, это гораздо выигрышнее, чем знание формулировки.
Я часто спрашиваю вопросы типа «какой принцип в SOLID наименее нужный?» или «такой-то паттерн соответствует SOLID?» (у меня есть примеры на многие паттерны таких несоответствий). При этом если кандидат заранее такие вещи подготовит и расскажет в начальном вопросе про SOLID («что это такое?» или «когда стоит применять?»), это прямо жирный плюс
Ещё очень часто кандидаты сейчас пренебрегают знаниями по работе с БД. Везде ORM, наверное, половина кандидатов просто не знают, что там под капотом и как работает, так как никогда сырые запросы не делали. Стоит хотя бы в общих чертах посмотреть, что такое ACID, как реализуется. Как индексы и оптимизация запросов работает и т.п. Но это уже прямо конкретные вопросы под конкретную вакансию пошли.
Для middle+/senior важно ещё умение решать архитектурные вопросы. Знаю, что Яндексе есть даже специальная архитектурная секция интервью, прямо отдельный час.
Код на интервью сейчас редко спрашивают. Это довольно спорная затея, т.к. это стресс дополнительный + что-то серьёзное за время интервью покодить не получится.
Получается, что мы проверяем не то, что на самом деле нам нужно, и не в тех условиях, в которых это будет происходить на практике.
В алгоритмических задачах наоборот всегда говорю, что мне не нужен код, мне нужно описание алгоритма, его оценка, доказательство, что нельзя быстрее, например.
Сергей Голицын
Senior Software Engineer at Zillion Whales, преподаватель курса «Алгоритмы и структуры данных»
Смотрю на то, как кандидат думает, знает ли основы, прям основы. Мне хочется слушать, как рассуждает кандидат. Если, например, это алгоритмическая задачка, то хочу слышать рассуждения. Если это теория, то я могу задать вопрос близкий по теории и услышать, как кандидат будет выкручиваться и отвечать на него.
Все зависит от того, как кандидат отвечает. Если я вижу, что он отвечает по учебнику и говорит словами с известных всем сайтов, это явно говорит о том, что он готовился, и спрашивать его про это нет смысла. Лучше посмотреть, понимает ли он то, что говорит или просто заучил. Это может быть не прямой вопрос «Как работает хэш мапа?», а к примеру, как ее сломать или сломать особенным образом.
Я бы рекомендовал готовиться индивидуально к вакансии, т.к. у каждой компании свои требования к знаниям. И не пить много кофе перед интервью. Отдохнуть. Постараться расслабиться и получить удовольствие и вынести что-нибудь полезное с собеседования. Освежить знания.
Еще во время интервью смотрю, что у кандидата должны реально гореть глаза и он ооочень хочет попасть к нам. Так же у него должен быть реальный интерес к программированию, а не из-за денег. Это наверное для меня очень важный критерий при найме на любой уровень. Я ищу идейных ребят, для которых разработка — это хобби.
Владислав, СТО:
Действительно, очень многое зависит от компании и от должности, на которую претендует соискатель.
Если должность руководящая, как, например СТО, здесь многое, на мой взгляд, зависит от софт скиллов.
Главное на интервью — постараться быть самим собой и не пытаться прыгнуть выше головы, это заметно сразу же.
Ещё один совет: старайтесь не придумывать ответы на вопросы, на которые заранее не знаете ответ. Лучше пропустить вопрос. Конечно, сделать логический вывод — это плюс, но пытаться лукавить или гуглить параллельно выставит вас не в лучшем свете.
Олег А., team leader, преподаватель Java:
Процесс сильно зависит от компании. В крупных компаниях процесс выстроен четко: имеется анкета кандидата с большим количеством пунктов, и люди, которые проводят собеседование, туда вписывают свои оценки. Обычно оценивается так называемый «уровень сеньорити», который включает в себя: опыт, знание основ по основному стеку (язык программирования и встроенная библиотека) и знание проектирования софта (пресловутые шаблоны проектирования и SOLID встречаются практически везде), знание спец.инструментов, фреймворков и практик, умение работать в команде, лидерство и т.п.
Этап тех собеседования может быть и разделен: хард скилы отдельно, софт скилы отдельно, может быть совмещен, а может состоять из нескольких этапов — зависит от компании. В большинстве случаев нужно быть готовым писать код в режиме life-coding. Придется подтвердить свой опыт, ответив на связанные с ним вопросы. В итоге кандидат получает балл с оценкой уровня сеньорити. На ее основании формируется или нет оффер.
Сергей Терешин
технический pre-sale специалист по ИБ в ООО «Монт», преподаватель курса «Внедрение и работа в DevSecOps»
Я собеседовал обычно ИТ или ИБ специалистов. Обычно пытаюсь понять насколько человек в теме вопроса: от модели osi и маршрутизации до различных методик атак. Часто смотрю, как человек ведёт себя в ситуации неопределённости.
Из-за специфики направления я провожу тех. интервью в формате разговора. В информационной безопасности сложно спросить про код или написать что-то. В реальную сеть, естественно, доступ не дается. Я, как правило, прошу что-то нарисовать. Просто если ИТ\ИБ-шник как любой инженер в 3 фразе не сказал слово «схема» и не начал рисовать на бумаге, столе, в воздухе какие-то каракули, значит он сломался. Несите следующего :)
Игорь Звягин, старший frontend разработчик:
Я проходил собеседования в SberCloud, EPAM, Живосайт. Главное, правильно подать себя, навыки самопрезентации очень важны. Что я заметил, далеко не в каждой компании, даже в крупных, наседают на техническую часть. Можно честно сказать «я не знаю, я с этим не работал».
Что касается вопросов, в моей сфере обычно начинают с типов данных, как сравнивать объекты, как работает браузер, процессы как происходят, как работает React, просят написать простые функции.
И пожалуй, самое важное — нужно любить свою предметную область. Это значит, не только иметь достаточные знания, но и следить за развитием технологий, думать о перспективах. Вот это тоже стоит показать на собеседовании.
Материал подготовлен в рамках онлайн-курсов «Разработчик онлайн обучения» и «Online teacher».
Всех желающих приглашаем на открытые demo-уроки:1. «Архитектор онлайн-обучения перевернет твой взгляд на образование».
На вебинаре опишем позицию архитектора онлайн-обучения. Мечта и реальность: кто есть сейчас и почему возникает потребность в новых профессиях. Вы прикоснетесь к процессу зарождения новой профессии.
>> регистрация2. «Цели обучения: как сделать так, чтобы обучение случилось?»
Первый шаг проектирования обучения — определение предполагаемых результатов у студентов. В педагогической теории существуют таксономии Блума, Марцано, Андерсен. Как их использовать? Сравним таксономии и выберем оттуда то, что помогает проектировать обучение. >> регистрация
