Представь, что тебя попросили провести собеседование бекендера. Что бы ты спрашивал(а) у кандидатов?
Может, алгоритмы? Или в вашей работе они не нужны и мы пойдём по классике - механизмы языка, докер, бд? Или мы будем отталкиваться от той логики, что всё знать нельзя и проще понять, ориентируется ли человек в фундаментальных вещах? Аля спросим про то как написана JVM, как работает V8 или как устроен zend engine? А может дадим задачки на SQL, код ревью или вообще сисдиз? Или вообще просто пообщаемся за его опыт, спрашивая почему в той ситуации было принято такое то решение, какие были альтернативы?
На каждый из таких подходов найдётся 3 человека кто пройдёт собес хорошо и ещё 30, кто посчитает вас странным. Кому то нравится изучать подкапотку, кто то изучает только то, что нужно на практике, кто то знает обо всём понемногу, а кто то потратил 10 лет на изучение базы, а в прикладных вещах не особо опытен, хоть и может быстро разобраться. Выбирая один из этих подходов к собесу ты обрекаешь себя на то, что отметёшь десятки людей, которые легко справятся с работой, но не смогут пройти собес. Волков, менторов и прочих критиков рынка постоянно обвиняют что нет конструктива, так вот принесу вам одно рацпредложение, но есессна начну с истории.
Впервые собеседовать я начал, работая в небольшом стартапе (Руслан, привет!). Для меня это было очень неожиданно, в формате "завтра надо провести собес, го?", а я сам при этом достаточно зелёный и знаю примерно тыщу тем, в которых я полный ноль. Я согласился и начал проводить собесы. Начал я как и все - загуглил "Топ 100 вопросов пхпшнику" и задавал те, ответы на которые сам знал. Не скажу, что этот подход был ужасен, но по итогу у меня оставалось представление о человеке "вроде знает темы 1, 5 и 7, вроде приятный в общении". На этом всё. Вроде и есть общее понимание о кандидате, но при этом нет полной картины перед глазами.
Потом я перешёл к подходу, где у нас глобально есть 7-10 тем, которые реально важны для работы, мы не идём по бесполезному списку, но обсуждаем кучу теории по поводу важных для проекта тем. Условно, мы не обсуждали garbage collector и late static binding, потому что они не были важны для проекта, зато глубоко погружались в составные индексы, полнотекстовый поиск и.т.д. Это давало уже иную картинку. У тебя нет полноценного понимания компетенций кандидата, зато есть представление о том, насколько он разбирается в важных для НАС темах. Но тут уже другой подводный камень - если у человека куча опыта, искренний интерес к айти, но при этом так уж случилось, что он не касался 2-3 из важных для нас тем, неужели мы ему откажем? Человек с опытом разберётся с парой новых технологий за 2-3 вечера. Неужели мы откажем опытному синьору, просто потому что он никогда не работал с graphql и мантикорой?
Заметьте, мы перебираем подходы, но делаем это неосознанно. Мы не задаёмся главным вопросом - а какую вообще информацию мы хотим получить о кандидате? Что для нас критически важно, что второстепенно, но плюс, а на что нам вообще плевать? И большинство собеседующих не задаются такими вопросами. Они знают как собеседовали их, они сами где то начитались интересных, но зачастую не сильно полезных вещей и теперь спрашивают её на собеседованиях. Некоторые более осознанные переходят к тому уровню, где ты начинаешь спрашивать уже конкретные важные для вакансии темы, но этого всё ещё мало. Следующий пост будет про мою идеальную формулу для собеседований.