Привет! Меня зовут Сергей Цветков и я в разработке ПО больше 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 минут.
Ключ к взлому этого этапа интервью в том, что, вообще говоря, вариантов сервисов не много:
- Booking
- YouTube
- Slack
- Discord
Вполне можно разобраться и понять, как дизайнится тот или иной сервис. Да и вариантов дизайна весьма немного. Например, в качестве брокера сообщений чаще всего будет фигурировать Kafka, кэша — Redis, NoSQL БД — Mongo или Cassandra.
Важно понять, что вы не дизайните в вакууме и вариантов «правильного» дизайна не так много, главное — знать их/выучить заранее.
Но тут очевидно, что этот дизайн — вообще отдельная тема для изучения и разговора.
6Тестовое домой
О-о, тестовое домой — это отдельный круг ада. Его никто делать не будет, да и почти никакая вакансия на текущем рынке не стоит того, чтобы на нее 2-3-4-5 часов времени потратить и получить в результате полстрочки фидбека.
У меня не раз бывало, когда тратишь полдня на разработку и получаешь реджект в одну строчку. С точки зрения интервьюера — нет вообще никаких гарантий, что его делал именно нанимаемый специалист.
Скажем, я код писать люблю и для кого-то его написать — вообще не проблема, да и времени это не много займет, потому что типичное тестовое — там не rocket science.
Вместо вывода
Подводя итог, замечу, что интервью для разработчиков давным-давно превратились в отдельный навык или набор навыков, и им нужно серьезно заниматься.
И не стоит думать, что ваш богатый опыт упростит вам задачу.
Часто имеет значение не только то, что вы знаете ответ и правильно отвечаете, но и сама форма подачи — если это не совпадет с образом в голове у интервьюера — интервью вы не пройдете.
Идеальный вариант — когда вы можете предоставлять ответ на вопрос как вузовский преподаватель или инструктор Udemy: развернуто, со всеми подробностями и наиболее полно.
Читайте также: «Неужели кто-то всерьез это спрашивает?»: вопросы на собеседовании по Java, которые нельзя задавать
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: