Когда я принимаю решение о том, какую выбрать архитектуру приложения, или как спроектировать БД, или какие нужны подготовительные работы для старта, или о том, что написать в следующем блоке кода, я думаю. Думаю о том, что я хочу получить, о том, как это решает мою проблему, есть ли более оптимальные решения. Согласитесь, такой подход будет полезен во многих сферах, причем не только интеллектуального труда. Но в данной статье я хочу поговорить про собеседование IT специалистов. Причем, специалистов с опытом, уровня Middle и выше. Приготовьтесь, я буду немного язвить.
Почему я решил об этом написать?
Я принимал участие в ряде собеседований, когда собеседовали меня. Сразу скажу, у меня до сих пор есть ощущение, что готовиться к собеседованию в техническом плане нечестно. Но это мы можем обсудить в комментариях. Пару раз я запарывал собеседование из-за пары простых базовых вопросов. После этого я укорял себя в некомпетентности. Как мог я метить в высшую лигу, если не смог протараторить принципы ООП? Позже сработала защита и я стал думать, а действительно ли я должен знать это как школьник таблицу умножения?
Специалист должен знать базовую теорию (?)
ООП, SOLID и еще целая куча принципов, без которых разработка зайдет в тупик. Если берете на работу преподавателя информатики, обязательно все это спросите.
Но, вы берете разработчика. Должен ли он это знать? Давайте разберемся.
Должен ли он это понимать? Да. Но как проверить? Самый простой способ - спросить. То есть он должен знать. В конце концов, ответить идеально на теорию сможет только что окончивший ВУЗ студент. Но это еще ничего не значит. Или надо попытаться найти способ проверить, как он их понимает? Благо, принципы эти имеют самое прямое практическое применение. Может, стоит предложить ему пару простых задач? Ведь на работе он будет именно решать задачи.
Специалист должен знать как устроен изнутри инструмент, с которым ему предстоит работать (?)
Несомненно. Абстракции для того и были придуманы, чтобы каждый раз задумываться о деталях реализации. Если вы так думаете, тогда советую вам изучить вопрос еще глубже, до принципов работы процессора и полупроводников.
Конечно, это бывает полезно знать, но ведь специалист может знать много других вещей, которые могут оказаться полезнее для ваших проектов. Если вы работаете с высоконагруженными системами, спросите специалиста о том, что может быть полезно именно для оптимизации. И даже, если он не ответит, действительно ли он вам не годится? Спросите, работал ли он с высоконагруженными системами, как решал те или иные задачи и справлялся с проблемами. Спросите, почему именно так. Быть может, данный диалог приведет его к внутреннему устройству. Ведь мозг построен на ассоциациях, а прямой вопрос может инициировать поиск в куче. Это для вас ответ связан с прямым вопросом, вы ведь готовились к собеседованию и провели этих собеседований уже не один десяток.
Так как же понять, что специалист вам подходит?
Я об этом долго думал. проблема неэффективных вопросов именно в том, что сложно понять, сможет ли человек решать ваши задачи. В результате этих раздумий я пришел к некоторым решениям, но не проверял их на практике.
Я проанализировал собеседования и вопросы/диалоги, которые отпечатались в моей памяти.
Вот один из них:
- Есть дорога, ее ширина А. Есть лягушка. Длина ее прыжка Б. Лягушка сидит на краю дороги. За сколько шагов она окажется на другой стороне дороги?
- А / Б... А нет, А / Б + 1... Хм... а что если А == Б? Или А % Б == 0... - Скажу сразу, я тут немного запаниковал. Задача то не сложная и меня не покидало ощущение, что тут есть подвох. А подвох действительно был!
- Ну да, как то так.
- А в чем подвох?
- Хорошо, что ты не начал решать через цикл.
То есть этой задачей они проверили некоторые общие показатели склада ума, которые для них полезны. И действительно, разработчик должен чувствовать, когда задачу можно решить с наименьшей сложностью алгоритма. Мне этот вопрос показался очень остроумным. Думаю, подобные вопросы подойдут всем. Главное, не путайте это с вопросом, почему люк круглый.
Так же, мне предлагали решить небольшие прикладные задачи проектирования. Чуть позже я вспомнил, что про шаблоны проектирования меня на этом собеседовании не спрашивали. Но при решении задачи мне пришлось составить композицию этих шаблонов. Тем самым я и знание этих самых шаблонов показал и умение ими оперировать. А если бы меня спросили: "Какие шаблоны проектирования вы знаете?". Вероятно, я бы замялся, вспомнил какие-то, ведь это поиск в куче. У меня в голове шаблоны связан с ситуациями, с назначениями, но никак не с "Шаблоны проектирования". Я ведь регулярно применяю их на практике, а не рассказываю про них студентам.
Просили меня и спроектировать небольшую БД под небольшую задачу. И это, на мой взгляд, эффективно.
А вот не так давно меня спросили: "Назовите типы инкапсуляции в C#".
Я представляю, собирается в переговорке группа разработчиков для решения какой-либо задачи.
- Коллеги, ну и как нам это решить?
- Я думаю, нам поможет инкапсуляция!
- Хм. А какой именно ее тип?
- Наследование!....
Я в очередной раз глупо хихикал, когда это писал, представляя эту сцену на фоне символики Comedy Club. На практике же было бы как-то так: "Смотрите, реализуем интерфейс в абстрактном классе, вот этот функционал у нас будет общий, но в нем будут особенности реализации. Вынесем их в абстрактные методы и оставим для потомков".
А откуда брать все эти задачи? Ну, вы не первый день на рынке. Уверен, ваши легендарные разработчики на своем пути сталкивались с необычными проблемами и решали их с переменным успехом. Опросите их, соберите список задач. Спросите, как они шли к решению, с какими сопутствующими проблемами столкнулись, как решали. Возможно, что-то вовремя не учли и теперь живут с этим. Будет хорошо, если ход мыслей рекрута будет похожим. А может быть, он учтет то, чего не учел ваш солдат.
Далее можно опросить разного уровня разработчиков. Своего рода игра сто к одному. То есть, если решение кандидата не совпадет с топовым, то, возможно, совпадет с одним или несколькими попроще. Это тоже позволит как-то оценить кандидата. Ведь люди, которые в вашей компании предложили эти решения работают, выполняют задачи.
Я выше писал про технических специалистов, но по факту говорю только про разработчиков. Но такой подход можно попробовать применить и к аналитикам и к тестировщикам.
А если вы берете специалиста в незнакомый еще для вас стек? Ну тут можно пошарить в интернетах и узнать, какие вопросы задавать по данному направление. Ну и конечно не забыть про SOLID. А можно отфильтровать людей без опыта, у оставшихся посмотреть портфолио (или опросить), так можно будет примерно понять, есть ли у человека релевантный, для выполнения нового проекта опыт. Ведь это именно то, что вам и нужно.
Более того, если вы будете задавать вопросы, на которые есть определенный правильный ответ, вы рискуете оказаться неправым. Это, на мой взгляд, очень глупая ситуация.
Итоги
Резюмирую все, что написал выше.
Вопросы по базовой теории стоит оставить младшим специалистам. Серьезным ребятам нужен серьезный вызов.
Серьезный вызов - это попытка балансировать между несколькими не полностью правильными решениями с целью выбрать лучшее из зол. Задавайте прикладные задачи.
Хорошо подумайте, для чего вы берете человека. Какие задачи он должен выполнять. Отсюда возьмутся сами задачи.
На этом все. Можете аплодировать, можете забрасывать камнями. Я все стерплю. Но очень надеюсь, что пройти мимо вам не хотелось.
andreyverbin
Непонятно как серьезные ребята могут ответить на серьезный вызов если они базовой теории не знают? Неоднократно я наблюдал как целые команды месяцами морщили лбы на бесконечных митингах, посвящённых решению «очень сложной проблемы». Очень сложная проблема часто возникает в распределённых системах или там где надо в несколько потоков что-то сделать. Часто решается в 200 строк кода, но только теми, кто осилил базовую теорию. Остальные морщат лбы на совещаниях и считают, что они решают очень сложные задачи и гордятся едва работающим результатом.
iRumba Автор
Ну так стоило прочитать полностью, а не только заключение. Я предлагал найти способы проверить, как специалист понимает теорию, а не проверить ка он ее вызубрил.
Maksclub
Ну для начала спросить ее.
Понимающий опишет как понимает, выучивший ответит более формализовано и графомански.
Далее перейдите к практике.
Собственно ВСЕ (и хорошие и плохие) собеседования так и проходят.
iRumba Автор
Нет не все. Если вы делаете табуретки, вас попросят предоставить портфолио. Или выстругать чего-нибудь на скорую руку. И вряд ли спросят про плотность сосны.
Я писал про поиск в куче и ассоциации не просто так. Для того, чтобы получить доступ к разделам мозга нужно точно так же выполнить запрос. Так вот, запрос про букву О в SOLID может долго блуждать по мозгу и вообще не найти результата, а задача составить абстракцию по определенным критериям покажет, что умеет специалист.
Мне в ходе решения практических задач пришлось многое узнать. Понять, почему не стоит писать код и строить архитектуру именно так. Я понял это при первых же задачах на расширение или модификацию. И, как ни странно, я начал следовать многим принципам и практикам еще до того, как про них узнал. И у меня есть подозрение, что не я один такой. Но, на своей практике я встречал людей, которые могли назвать все эти принципа от зубов, но неверно их интерпретировали. Знали целую кучу паттернов проектирования, но не умели их применять или применяли не к месту.
Есть анекдот про ситуацию, когда бодибилдера на улице останавливают гопники, а он такой раз, 2 подхода по 30 отжиманий и 50 приседаний.
alexeishch
Ну вообще вы даете человеку кусок кода и просите по нему что-то объяснить рассказать или изменить этот кусок чтобы он по-другому работал.
У меня вот лично был забавный случай, когда я устроился на работу по иронии судьбы первое же нарушение принципа SOLID, которое я увидел, было у человека который меня собеседовал. Впрочем его постоянно нарушают, например чтоб меньше кода писать или чтоб к срокам успеть. Зачем про него спрашивают — я понять не могу. А вот если бы люди руководствовались KISS, DRY, YAGNI и только потом брались за SOLID то было бы куда лучше.
strannik_k
Мне ваш случай не кажется забавным. Не нарушать SOLID в проекте — это что-то за гранью фантастики.
Процитирую из ru.stackoverflow.com/questions/551346:
«вопрос не в том, когда не нужно использовать SOLID, а в том, насколько использовать каждый из его принципов в своем, конкретном случае».
Согласен, что в первую очередь надо подумать о KISS, DRY, YAGNI, а потом о SOLID.
На позицию даже опытного джуна о SOLID нет смысла спрашивать, т.к. из-за недостатка опыта маловероятно, что к нему пришло понимание для чего и когда их использовать.
На позицию сеньора спрашивать стоит. Если не помнит принципов, можно даже дать определения, спросить их смысл, к чему может привести их нарушение, и понимает ли, что их иногда лучше нарушить. Если не может объяснить хотя бы 3 из них, вот тогда бы я это засчитал как минус.
iRumba Автор
Недавно колупался в кое каких исходниках dotnet, так там майки налево и направо нарушают эти принципы для оптимизации и упрощения сложности алгоритмов.
DistortNeo
Программист, имеющий за плечами несколько лет серьёзного опыта, сам неявно приходит к этим принципам, даже не зная их. Поэтому спрашивать действительно нужно именно понимание, а не их формальное определение.
DistortNeo
Потому что знание формализованного ответа на вопрос ? пониманию.
Существуют полно людей, которые без запинки отвечают на вопросы из базовой теории, но не способны применять эти знания на практике. И наоборот, полно людей способны решать сложные задачи, но не способны сходу рассказать о базовых вещах, потому что знания отложены в мозгу, но не в словесной форме.
Например, когда человек ходит, он не думает о том, какие мышцы надо задействовать. Когда говорит, то не думает о положении языка и правилах склонения и спряжения и т.д.
andreyverbin
Программирование это не ходьба, нет такого, что навык программирования заложен чуть ли не в ДНК.
Распределённый консенсус это сложная задача, я не видел, чтобы кто-то взял, напрягся и придумал RAFT. Мы уже лет 30 как вышли из области, где можно было знаниями отложенными в голове что-то новое и сложное порешать. Все тривиальные алгоритмы уже открыты. Можно было сесть и придумать за часок qsort. Нельзя за часок придумать упорядоченную коллекцию без блокировок. Это 2500 строк на Scala и пяток научных работ. Можно за часок придумать какой-нибудь кеш и алгоритм его синхронизации. Но если вы пытаетесь это сделать «отложенными в мозгу знаниями» то получится гарантированно хрень в каждом нетривиальном случае. И так во всем, вы знаете почему это хорошо, осознанно сравнивая с другими известными вам решениями. Это и есть базовые знания.
Есть один кейс, когда отложенные знания работают — когда однажды были изучены удачные решения и затем они применяются без разбора. «Когда в руках молоток, все кажется гвоздями», это как раз такой случай. Часто это работает, потому что за пределы ограниченной области человек не выходит.
iRumba Автор
Да, вы все верно говорите, но я не понял, как это противоречит комментатору выше или самой статье? Ваша задача, как собеседующего, понять, может ли разработчик, который перед вами сидит, выполнять задачи вашего проекта.
И, на мой взгляд, спрашивать принципы ООП тут неуместно, потому что не скажет ровным счетом ничего. Если, конечно, вы не младшего специалиста принимаете или стажера.