Кого вы хотите принять на работу?
Когда я принимаю решение о том, какую выбрать архитектуру приложения, или как спроектировать БД, или какие нужны подготовительные работы для старта, или о том, что написать в следующем блоке кода, я думаю. Думаю о том, что я хочу получить, о том, как это решает мою проблему, есть ли более оптимальные решения. Согласитесь, такой подход будет полезен во многих сферах, причем не только интеллектуального труда. Но в данной статье я хочу поговорить про собеседование IT специалистов. Причем, специалистов с опытом, уровня Middle и выше. Приготовьтесь, я буду немного язвить.
Почему я решил об этом написать?
Я принимал участие в ряде собеседований, когда собеседовали меня. Сразу скажу, у меня до сих пор есть ощущение, что готовиться к собеседованию в техническом плане нечестно. Но это мы можем обсудить в комментариях. Пару раз я запарывал собеседование из-за пары простых базовых вопросов. После этого я укорял себя в некомпетентности. Как мог я метить в высшую лигу, если не смог протараторить принципы ООП? Позже сработала защита и я стал думать, а действительно ли я должен знать это как школьник таблицу умножения?
Специалист должен знать базовую теорию (?)
ООП, SOLID и еще целая куча принципов, без которых разработка зайдет в тупик. Если берете на работу преподавателя информатики, обязательно все это спросите.
Но, вы берете разработчика. Должен ли он это знать? Давайте разберемся.
Должен ли он это понимать? Да. Но как проверить? Самый простой способ — спросить. То есть он должен знать. В конце концов, ответить идеально на теорию сможет только что окончивший ВУЗ студент. Но это еще ничего не значит. Или надо попытаться найти способ проверить, как он их понимает? Благо, принципы эти имеют самое прямое практическое применение. Может, стоит предложить ему пару простых задач? Ведь на работе он будет именно решать задачи.
Специалист должен знать как устроен изнутри инструмент, с которым ему предстоит работать (?)
Несомненно. Абстракции для того и были придуманы, чтобы каждый раз задумываться о деталях реализации. Если вы так думаете, тогда советую вам изучить вопрос еще глубже, до принципов работы процессора и полупроводников.
Конечно, это бывает полезно знать, но ведь специалист может знать много других вещей, которые могут оказаться полезнее для ваших проектов. Если вы работаете с высоконагруженными системами, спросите специалиста о том, что может быть полезно именно для оптимизации. И даже, если он не ответит, действительно ли он вам не годится? Спросите, работал ли он с высоконагруженными системами, как решал те или иные задачи и справлялся с проблемами. Спросите, почему именно так. Быть может, данный диалог приведет его к внутреннему устройству. Ведь мозг построен на ассоциациях, а прямой вопрос может инициировать поиск в куче. Это для вас ответ связан с прямым вопросом, вы ведь готовились к собеседованию и провели этих собеседований уже не один десяток.
Так как же понять, что специалист вам подходит?
Я об этом долго думал. проблема неэффективных вопросов именно в том, что сложно понять, сможет ли человек решать ваши задачи. В результате этих раздумий я пришел к некоторым решениям, но не проверял их на практике.
Я проанализировал собеседования и вопросы/диалоги, которые отпечатались в моей памяти.
Вот один из них:
— Есть дорога, ее ширина А. Есть лягушка. Длина ее прыжка Б. Лягушка сидит на краю дороги. За сколько шагов она окажется на другой стороне дороги?
— А / Б… А нет, А / Б + 1… Хм…, а что если А == Б? Или А % Б == 0… — Скажу сразу, я тут немного запаниковал. Задача то не сложная и меня не покидало ощущение, что тут есть подвох. А подвох действительно был!
— Ну да, как то так.
— А в чем подвох?
— Хорошо, что ты не начал решать через цикл.
То есть этой задачей они проверили некоторые общие показатели склада ума, которые для них полезны. И действительно, разработчик должен чувствовать, когда задачу можно решить с наименьшей сложностью алгоритма. Мне этот вопрос показался очень остроумным. Думаю, подобные вопросы подойдут всем. Главное, не путайте это с вопросом, почему люк круглый.
Так же, мне предлагали решить небольшие прикладные задачи проектирования. Чуть позже я вспомнил, что про шаблоны проектирования меня на этом собеседовании не спрашивали. Но при решении задачи мне пришлось составить композицию этих шаблонов. Тем самым я и знание этих самых шаблонов показал и умение ими оперировать. А если бы меня спросили: «Какие шаблоны проектирования вы знаете?». Вероятно, я бы замялся, вспомнил какие-то, ведь это поиск в куче. У меня в голове шаблоны связан с ситуациями, с назначениями, но никак не с «Шаблоны проектирования». Я ведь регулярно применяю их на практике, а не рассказываю про них студентам.
Просили меня и спроектировать небольшую БД под небольшую задачу. И это, на мой взгляд, эффективно.
А вот не так давно меня спросили: «Назовите типы инкапсуляции в C#».
Я представляю, собирается в переговорке группа разработчиков для решения какой-либо задачи.
— Коллеги, ну и как нам это решить?
— Я думаю, нам поможет инкапсуляция!
— Хм. А какой именно ее тип?
— Наследование!…
Я в очередной раз глупо хихикал, когда это писал, представляя эту сцену на фоне символики Comedy Club. На практике же было бы как-то так: «Смотрите, реализуем интерфейс в абстрактном классе, вот этот функционал у нас будет общий, но в нем будут особенности реализации. Вынесем их в абстрактные методы и оставим для потомков».
А откуда брать все эти задачи? Ну, вы не первый день на рынке. Уверен, ваши легендарные разработчики на своем пути сталкивались с необычными проблемами и решали их с переменным успехом. Опросите их, соберите список задач. Спросите, как они шли к решению, с какими сопутствующими проблемами столкнулись, как решали. Возможно, что-то вовремя не учли и теперь живут с этим. Будет хорошо, если ход мыслей рекрута будет похожим. А может быть, он учтет то, чего не учел ваш солдат.
Далее можно опросить разного уровня разработчиков. Своего рода игра сто к одному. То есть, если решение кандидата не совпадет с топовым, то, возможно, совпадет с одним или несколькими попроще. Это тоже позволит как-то оценить кандидата. Ведь люди, которые в вашей компании предложили эти решения работают, выполняют задачи.
Я выше писал про технических специалистов, но по факту говорю только про разработчиков. Но такой подход можно попробовать применить и к аналитикам и к тестировщикам.
А если вы берете специалиста в незнакомый еще для вас стек? Ну тут можно пошарить в интернетах и узнать, какие вопросы задавать по данному направление. Ну и конечно не забыть про SOLID. А можно отфильтровать людей без опыта, у оставшихся посмотреть портфолио (или опросить), так можно будет примерно понять, есть ли у человека релевантный, для выполнения нового проекта опыт. Ведь это именно то, что вам и нужно.
Более того, если вы будете задавать вопросы, на которые есть определенный правильный ответ, вы рискуете оказаться неправым. Это, на мой взгляд, очень глупая ситуация.
Итоги
Резюмирую все, что написал выше.
Вопросы по базовой теории стоит оставить младшим специалистам. Серьезным ребятам нужен серьезный вызов.
Серьезный вызов — это попытка балансировать между несколькими не полностью правильными решениями с целью выбрать лучшее из зол. Задавайте прикладные задачи.
Хорошо подумайте, для чего вы берете человека. Какие задачи он должен выполнять. Отсюда возьмутся сами задачи.
На этом все. Можете аплодировать, можете забрасывать камнями. Я все стерплю. Но очень надеюсь, что пройти мимо вам не хотелось.
