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


Михаил Каморин

Senior Backend Developer в Skyeng, преподаватель курсов по PHP и его фреймворкам, Highload Architect.

  1. Для middle и выше нет смысла заучивать формулировки и термины, важнее понимание.

  2. Для джунов наоборот, понятно, что практического опыта ещё нет, и нужно хотя бы теоретически представлять себе происходящее.

  3. Если не знаешь ответа, то стоит попытаться вывести его логически, но совсем пальцем в небо тыкать всё же не стоит, и лучше честно сказать, что не знаешь.

  4. Если техспециалист на каждый правильный ответ задаёт вопрос всё сложнее, он не завалить хочет, а ищет «уровень незнания», и это нормально, если он его наконец находит. Другое дело, что потом это может быть использовано с целью сбить цену, но это уже не техспециалиста вопрос, его задача уровень оценить.

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

  6. Чем выше позиция, тем важнее коммуникативные навыки, так как тем больше приходится общаться, обсуждать решения, планировать архитектуру и т.п.

Для джунов важнее всего иметь общее представление об используемом технологическом стеке (то есть большим плюсом является знание хотя бы в общих чертах о том, как устроен условный 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. «Цели обучения: как сделать так, чтобы обучение случилось?»
Первый шаг проектирования обучения — определение предполагаемых результатов у студентов. В педагогической теории существуют таксономии Блума, Марцано, Андерсен. Как их использовать? Сравним таксономии и выберем оттуда то, что помогает проектировать обучение. >> регистрация

Комментарии (5)


  1. lab412
    30.08.2021 17:37

    а может просто "НЕ ВРАТЬ" и пройдёте? а то потом сами обижаться будете что вас уволили, а на практике просто напи***ли о том что умеете и зря потратили деньги и нервы нанявших вас! и ладно если просто потратили время конторы, а то еще сделали хуже своими кривыми ручками и контора еще и на бабки попала из за вас в итоге.

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


    1. DeniSun
      30.08.2021 19:35

      Была статья, в которой рассматривали потенциальные результаты после приема на работу если: кандидат врет/не врет и работодатель врет/не врет. В итоге лучшим вариантом было, когда все говорят правду. Но стоит отметить, что и в других вариантах для каждой из сторон были разные кратковременные плюсы.


  1. HellWalk
    31.08.2021 11:37

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

    Ну как такое можно писать. Сейчас же сотни «вайтишников» сделают вывод, что главное не знания и опыт в технической части, а некие секреты, зная которые вжух и получаешь везде оффер.

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

    Самое забавное, когда сеньер собеседует сеньера - оба могут закончить собеседование с мыслью «да какой он сеньер, обычный джун с ЧСВ»


  1. DSL88
    31.08.2021 16:27
    +3

    Обожаю эти пункты «он должен хотеть в нашу компанию не ради денег». Ребят, у меня 10+ лет опыта. На работу я хожу зарабатывать деньги


  1. web1nick
    03.09.2021 10:13

    Как проходить техническое собеседование?

    Не проходить его вообще. Тех. собеседование - это экзаменация, с набором рандомных технических вопросов, которые взбредут в голову у конкретного задающего, конкретной фирмы. Никакой стандартизации, набора будущих тем, да и времени на подготовку у вас не будет.

    И к общему бэкграунду рандома вопросов добавится еще и волнение экзамена. Соответственно вы завалите это всё с вероятностью 90%. Процентов 10% остаются, если так сложатся звезды, что темы на которые задавались вопросы вы недавно повторяли и/или сталкивались по работе. Плюс экзаменатор не сильно грузил вопросами и был в хорошем настроении. Ну или вакансию им надо уже побыстрей закрыть.

    Собственно у таких фир, которые отбирают претендентов по тех. собеседованиям, и висят их вакансии туеву кучу времени. Пока наконец нехватка кадров не прижмет и возьмут уже кого-нибудь. А потом еще такие фирмы жалуются про нехватку кадров в IT. Конечно она будет, если вы процентов 90% отсеяли своими экзаменами рандома.

    Исключения пожалуй тут может быть только два.

    1. Очень крупные фирмы, у которых их технические вопросы утверждены и так просто не меняются. Собственно тематика этих вопросов оглашается заранее, и время на подготовку выделено очень большое (до несколько месяцев).
      Тут решение кандидат уже может принять заранее, - если хочет в неё попасть, надо готовится.

    2. Сертификация. Опять таки если это сертификация не от NoName, а известный сертификат, который есть желание получить, то можно выделить сколько угодно времени на подготовку и записаться на сертификацию. Тематика вопросов известна заранее, да и все вопросы нередко известны заранее (а какие конкретно из них попадутся на экзамене-сертификации это уже другое дело)