«Тестовое домой — это отдельный круг ада»: почему эти 6 привычных методов собеседований в IT больше не работают

Привет! Меня зовут Сергей Цветков и я в разработке ПО больше 10 лет. Сегодня я хочу поднять тему интервью. По моему мнению, проблема с собеседованиями в том, что будет плохо как их не проводи 🙂

1Задачки

Первый подход, который практикуется в FAANGFacebook, Amazon, Apple, Netflix и Google и некоторых наших компаниях — это алгоритмы-структуры данных и задачки в стиле Hackerrank или LeetCode. В мире существует целая индустрия обучения и коучинга вокруг решения этих задач.

Или можно просто прорешать их вручную несколько раз — в каждом из вышеназванных банков задач их порядка двух тысяч.

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

Как вариант, также можно таксистом в Лондоне поработать — гиппокампЧасть мозга, которая участвует в механизмах формирования эмоций, перехода кратковременной памяти в долговременную, пространственной памяти, необходимой для навигации. Отвечает за удержание внимания. вырастет. С тем же успехом можно скорость сборки кубика Рубика проверять.

2Прескрининговый тест

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

Это гуглится прямо во время выполнения теста — ну, или вы просто знаете ответы.

Скорее ориентировано на то, чтобы отсеивать никогда не программировавших людей. Да и это несколько зашкварно — компании, делающие это, обладают не самой лучшей репутацией.

3Вопросы по основам языка

Следующий вариант — вопросы по основам языка, те самые, которые выпадают в Google по запросу «<language> interview questions». Например, для Java это что-то про коллекции, сложность добавления/удаления и так далее. Смысл этих вопросов в том, что якобы вы эти знания получили в процессе работы и копания в «кишках» всех этих коллекций и структур Heap’a и Stack’a.

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

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

В дополнение к этому варианту — если начать копать вглубь, например, той же HashMap в Java на предмет коллизий, а не просто «O(1) и все», то мы отчасти попадаем в самую первую категорию вопросов, а отчасти ожидаем, что вы будете знать, как конкретно работает эта коллекция в Java.

Наверное, это зачем-то нужно и когда-нибудь пригодится в работе (мне за всю карьеру — нет), но это совершенно специфический вопрос, который, опять же, к оценке вас никакого отношения не имеет.

4Кейсы из рабочей практики

Еще вариант — давать реальную задачу из практики. Человек за час вполне может не сообразить и не наметить вообще никаких шагов, кроме «погуглить подход и посидеть-подумать».

Или у него в принципе решение задачи всегда стартует с интенсивного гугления. Или он просто растерялся. Да и час — это срок для такой задачи.

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

Если же уменьшить скоуп задачи до минимального — напиши мне REST-сервис, например, который что-то возвращает, то задача становится тривиальной и ничего не покажет, кроме того, что человек в принципе программировал.

5Системный дизайн

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

Естественно, что предполагается гигантская популярность этого сервиса. И интервьюер может быть очень дотошным — иногда придется оценить размер инстанса или записи, исходя из схемы БД, которую надо тут же задизайнить, или в принципе уместить дизайн схемы БД в 10-15 минут.

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

• Twitter
• Instagram
• Booking
• YouTube
• Slack
• Discord

Вполне можно разобраться и понять, как дизайнится тот или иной сервис. Да и вариантов дизайна весьма немного. Например, в качестве брокера сообщений чаще всего будет фигурировать Kafka, кэша — Redis, NoSQL БД — Mongo или Cassandra.

Важно понять, что вы не дизайните в вакууме и вариантов «правильного» дизайна не так много, главное — знать их/выучить заранее.

Но тут очевидно, что этот дизайн — вообще отдельная тема для изучения и разговора.

6Тестовое домой

О-о, тестовое домой — это отдельный круг ада. Его никто делать не будет, да и почти никакая вакансия на текущем рынке не стоит того, чтобы на нее 2-3-4-5 часов времени потратить и получить в результате полстрочки фидбека.

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

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

Вместо вывода

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

И не стоит думать, что ваш богатый опыт упростит вам задачу.

Часто имеет значение не только то, что вы знаете ответ и правильно отвечаете, но и сама форма подачи — если это не совпадет с образом в голове у интервьюера — интервью вы не пройдете.

Идеальный вариант — когда вы можете предоставлять ответ на вопрос как вузовский преподаватель или инструктор Udemy: развернуто, со всеми подробностями и наиболее полно.

Читайте также: «Неужели кто-то всерьез это спрашивает?»: вопросы на собеседовании по Java, которые нельзя задавать