Я работаю программистом последние 11 лет: первые 5 лет как PHP-разработчик, а последние 6 лет как Go-разработчик. Недавно я сходил на с десяток собеседований, и они меня очень сильно разочаровали.
Хватит спрашивать тонкости языка программирования
Вопросы вроде: "Вот у нас есть слайс в Go, мы передадим его в функцию, там вставим 3 элемента - что мы получим?" Да ерунду вы получите! Есть best practices. Если в функции модифицируете слайс - нужно возвращать новый слайс, а не играть в угадайку. Синьоры последние 5 лет своей работы так и делают. Этот вопрос максимум джуниор знает, потому что он это изучал на прошлой неделе. Синьор это изучал 5 лет назад и в реальной жизни не использует. Максимум он специально для собеседования повторил.
Хватит спрашивать тонкости фреймворка
Самый бесполезный вопрос, который я встречал в своей карьере: "А какой метод авторизации используется по умолчанию в Symfony?" Что этот вопрос скажет о человеке? Что он помнит каждую деталь фреймворка? Или что он помнит то же самое, что и собеседующий? Или вы думаете, что синьор не загуглит это за 10 секунд?
Хватит спрашивать книжные термины
"А что значит буква D в аббревиатуре SOLID? А в ACID?" Вы хоть раз в жизни за пределами собеседования этой информацией пользовались? Нет? Так к чему эти вопросы? Даже если человек и знал эту информацию - он её забыл лет 10 назад.
Алгоритмы и структуры данных
А ведь хорошая идея - попросить программиста написать бинарный поиск. Только вот загвоздка: он писал его последний раз 10 лет назад в универе, и за 10 лет работы он не пригодился ни разу. Зато джуниор, который только закончил университет, будет его знать.
Программист - это не специалист одной технологии
Синьор может выяснить требования у бизнеса, придумать архитектуру, спроектировать БД. И потом всё это реализовать на ЛЮБОМ языке программирования. Не работает так, что если до этого синьор работал 5 лет на Go, то завтра он не сможет написать проект на Java. Да, загуглит он, как создавать функции, классы и т.д. Но это не те знания, которые стоит проверять.
Мы не ракеты строим
Я бы понял, если бы все эти вопросы задавали в компании, где разрабатывают компилятор или свою базу данных - тогда вопросов нет, тогда все эти тонкости работы сборщика мусора, алгоритмы и т.д. - нужны. Но обычно бывает совершенно другая ситуация: приходишь на работу и слышишь: "Смотри, у нас тут есть табличка в БД, её надо вывести в CRM".
Чтобы пройти собеседование - надо проходить собеседования
Все эти вопросы вроде "как работает map в Go под капотом" лично у меня забываются через месяц после собеседования. А знаете почему? Потому что эта информация никак не применяется в реальной жизни. И если человек до этого работал 5 лет и не менял работу - он не ответит на этот вопрос с ходу. А знаете, кто ответит? Человек, который ходит на собеседования 24/7. Как все эти вопросы отражают твой опыт? Если для ответа на них тебе нужно специально готовиться. Никто не знает ответы на них "по умолчанию".
Современные собеседования не проверяют реальные знания и навыки, а проверяют лишь то, как человек подготовился к собеседованию.
В итоге получаем следующую ситуацию: человек, который работает и раз в N лет решил сменить работу, будет проигрывать на собеседовании тем, кто ходит на собеседования 24/7. Я не думаю, что это тот человек, которого компании хотят нанять