Вообще, почитал написанное выше, и пришёл к выводу, что формат собеседований довольно странный. Можно охватить много всего такого, как правило, в 2 (ну или 3) случаях: первый — это если работаешь на «галере» (аутсорс, аутстафф, и заказанная разработка), но сейчас по понятным политическим причинам в РФ и РБ такое почти что мертво, я сам был вынужден из заказанной разработки в продукт уйти, 2 случай — продолжение первого своего рода, а именно — проектная работа, но, опять же, по тем же причинам из РФ и РБ на забугор почти не устроиться, а внутри проектной работы мало, и 1 и 2 случай — это если повезло, и проекты с охватом разных предметных областей и технологий, 3 случай — когда скачешь с работы на работу.
Но 3 случай (частая смена работ) — даже в более сытые приятные времена было (как сейчас модно говорить у молодёжи) «ред флаг» 🚩 для HR, а сейчас и подавно.
И вот если так подумать, то я вот работаю уже скоро три года как в одном продукте и не хочу уходить, многие и по 6 лет в этом продукте из команды, соответственно, для эффективности на благо нашего бизнеса мы сконцентрированы на своих задачах, своей предметной области, и откуда ж нам знать нюансы и тонкости того, что вне нашего продукта? Вариант «ну так сиди штудируй вечерами», во-первых, сам по-себе не особо хороший (у людей за 30 так-то в основной их массе есть семьи, дети, свои жизни, в общем), во-вторых, даже если сидеть и штудировать, то что именно? Море всего есть, а просто по верхам — ну это уже эрзац какой-то, а не нормальные знания. То есть так собеседовать — априори тупой подход.
Мне понравилось, как я собеседовался на прошлую работу: я никогда не работал с AWS S3 и Mongo, но честно сказал, что готов быстро вкатиться и разобраться. И не солгал: уже через пару недель были готовы пара сервисов для работы с этим, и на ревью лид (британец, кстати, Эдмунд, классный мужик, с ним было круто работать) дал пару советов, но, в целом, был доволен. И ничто страшное не случилось. Потому что важен человек и его умение думать и разбираться, а не знание всех на свете технологий. В конце концов, даже перед много лет работающим в продукте или на проектах сотрудником может встать необходимость разбираться в новом и/или что-то внедрять с нуля, так не увольнять же его.