Комментарии 36
Вопросы по базовой теории стоит оставить младшим специалистам. Серьезным ребятам нужен серьезный вызов.
Непонятно как серьезные ребята могут ответить на серьезный вызов если они базовой теории не знают? Неоднократно я наблюдал как целые команды месяцами морщили лбы на бесконечных митингах, посвящённых решению «очень сложной проблемы». Очень сложная проблема часто возникает в распределённых системах или там где надо в несколько потоков что-то сделать. Часто решается в 200 строк кода, но только теми, кто осилил базовую теорию. Остальные морщат лбы на совещаниях и считают, что они решают очень сложные задачи и гордятся едва работающим результатом.
Ну для начала спросить ее.
Понимающий опишет как понимает, выучивший ответит более формализовано и графомански.
Далее перейдите к практике.
Собственно ВСЕ (и хорошие и плохие) собеседования так и проходят.
Я писал про поиск в куче и ассоциации не просто так. Для того, чтобы получить доступ к разделам мозга нужно точно так же выполнить запрос. Так вот, запрос про букву О в SOLID может долго блуждать по мозгу и вообще не найти результата, а задача составить абстракцию по определенным критериям покажет, что умеет специалист.
Мне в ходе решения практических задач пришлось многое узнать. Понять, почему не стоит писать код и строить архитектуру именно так. Я понял это при первых же задачах на расширение или модификацию. И, как ни странно, я начал следовать многим принципам и практикам еще до того, как про них узнал. И у меня есть подозрение, что не я один такой. Но, на своей практике я встречал людей, которые могли назвать все эти принципа от зубов, но неверно их интерпретировали. Знали целую кучу паттернов проектирования, но не умели их применять или применяли не к месту.
Есть анекдот про ситуацию, когда бодибилдера на улице останавливают гопники, а он такой раз, 2 подхода по 30 отжиманий и 50 приседаний.
У меня вот лично был забавный случай, когда я устроился на работу по иронии судьбы первое же нарушение принципа SOLID, которое я увидел, было у человека который меня собеседовал. Впрочем его постоянно нарушают, например чтоб меньше кода писать или чтоб к срокам успеть. Зачем про него спрашивают — я понять не могу. А вот если бы люди руководствовались KISS, DRY, YAGNI и только потом брались за SOLID то было бы куда лучше.
Процитирую из ru.stackoverflow.com/questions/551346:
«вопрос не в том, когда не нужно использовать SOLID, а в том, насколько использовать каждый из его принципов в своем, конкретном случае».
Согласен, что в первую очередь надо подумать о KISS, DRY, YAGNI, а потом о SOLID.
На позицию даже опытного джуна о SOLID нет смысла спрашивать, т.к. из-за недостатка опыта маловероятно, что к нему пришло понимание для чего и когда их использовать.
На позицию сеньора спрашивать стоит. Если не помнит принципов, можно даже дать определения, спросить их смысл, к чему может привести их нарушение, и понимает ли, что их иногда лучше нарушить. Если не может объяснить хотя бы 3 из них, вот тогда бы я это засчитал как минус.
Программист, имеющий за плечами несколько лет серьёзного опыта, сам неявно приходит к этим принципам, даже не зная их. Поэтому спрашивать действительно нужно именно понимание, а не их формальное определение.
Непонятно как серьезные ребята могут ответить на серьезный вызов если они базовой теории не знают?
Потому что знание формализованного ответа на вопрос ≠ пониманию.
Существуют полно людей, которые без запинки отвечают на вопросы из базовой теории, но не способны применять эти знания на практике. И наоборот, полно людей способны решать сложные задачи, но не способны сходу рассказать о базовых вещах, потому что знания отложены в мозгу, но не в словесной форме.
Например, когда человек ходит, он не думает о том, какие мышцы надо задействовать. Когда говорит, то не думает о положении языка и правилах склонения и спряжения и т.д.
Программирование это не ходьба, нет такого, что навык программирования заложен чуть ли не в ДНК.
Распределённый консенсус это сложная задача, я не видел, чтобы кто-то взял, напрягся и придумал RAFT. Мы уже лет 30 как вышли из области, где можно было знаниями отложенными в голове что-то новое и сложное порешать. Все тривиальные алгоритмы уже открыты. Можно было сесть и придумать за часок qsort. Нельзя за часок придумать упорядоченную коллекцию без блокировок. Это 2500 строк на Scala и пяток научных работ. Можно за часок придумать какой-нибудь кеш и алгоритм его синхронизации. Но если вы пытаетесь это сделать «отложенными в мозгу знаниями» то получится гарантированно хрень в каждом нетривиальном случае. И так во всем, вы знаете почему это хорошо, осознанно сравнивая с другими известными вам решениями. Это и есть базовые знания.
Есть один кейс, когда отложенные знания работают — когда однажды были изучены удачные решения и затем они применяются без разбора. «Когда в руках молоток, все кажется гвоздями», это как раз такой случай. Часто это работает, потому что за пределы ограниченной области человек не выходит.
И, на мой взгляд, спрашивать принципы ООП тут неуместно, потому что не скажет ровным счетом ничего. Если, конечно, вы не младшего специалиста принимаете или стажера.
Угадали. Только ввязаться в бой заставил отвлечённый от темы вопрос.
Вот дети, когда играют, очень мало думают о последствиях. Потому что это отвлекает от игры и детям становится скучно. Потом дети вырастают и… тоже мало думают о последствиях. А работать они идут, например, в ИТ. Да, потому что там не нужно думать о последствиях, да и вообще о сложном, ведь правда?
Вот пример:
>> Позже сработала защита и я стал думать, а действительно ли я должен знать это как школьник таблицу умножения?
Очень наглядно. Автор (как и многие другие) вполне освоился со своим безмятежным образом существования и теперь уже даже таблицу умножения не хочет запоминать. Да, он возразит, мол я совсем не то имел в виду, и таблицу я помню, но просто хотел сказать что незачем про неё спрашивать на собеседованиях. В общем вы поняли — отвертится. А всё почему?
Потому что реально многие привыкли к лёгкой жизни. Не то что бы жизнь должна быть тяжёлой, но из-за её лёгкости, как в детстве, люди забывают думать о последствиях.
Теперь задам один очень простой вопрос — зачем автор совершенствует свой навык отбора персонала?
Автор (как и многие другие) в ответ начнёт рассказывать про необходимость развиваться и всё такое прочее и очень расплывчатое. Но на самом деле автор просто не знает точного ответа на вопрос. Потому что он (как и другие) просто играется в своей детской песочнице и получает от этого удовольствие. И плевать ему на вопрос «почему». Потому что приятно. И всё. И отстаньте.
И вот так в своём взрослом детстве живут десятки тысяч считающих себя умными и очень достойными представителей сообщества «айтишников». А что, бабло капает «выше рынка», делать почти ничего не надо, а то, что надо, вызывает интерес и приятные ощущения. Вот только ещё пообсуждать с другими все эти приятности надо, поэтому и статья появилась. Правильно?
Автор в ответ опять уйдёт в несознаку и начнёт сочинять про всё то же замусоленное развитие. Ну ладно, развитие, так развитие. Но каков итог-то?
А итог простой — для инвесторов твоего банка, твоего гугла, или другого очень уютного айтишного дупла, случится больше счастья. Потому что ты им на блюдечке принесёшь свои умные мысли. Это, разумеется, достижение. Ведь его даже измерить можно. В деньгах инвесторов, например. Или в твоей зарплате. Вот ведь какая радость!
Вот и вся цель — удовольствие и бабло. Поздравляю, ваш начальник вами доволен, вы оправдали ожидания инвесторов. Прекрасное достижение! Продолжайте в том же духе и принесите инвесторам ещё больше биткойнов и прочих атрибутов безумного счастья.
А если бы наш школьник всё-таки подумал о последствиях, то он мог бы (ну вдруг?) вспомнить и о других радостях в этой жизни. И о других достижениях. Например — вместо денег инвестора считать улыбки коллег. Или «не круто»? Ну да, инвесторы не одобрят. Поэтому правильно — пишите нам про отбор персонала, про модные на рынке практики, про выгодные инвесторам компетенции и (обязательно!) про повышение собственной стоимости на рынке обслуживания инвесторов. Вот тогда вас точно ждёт прекрасное будущее и огромное спасибо от… От кого? Ну да зачем отвлекаться на мысли о сложном!
А работать они идут, например, в ИТ. Да, потому что там не нужно думать о последствиях, да и вообще о сложном, ведь правда?Тсс. Не палите контору.
Теперь задам один очень простой вопрос — зачем автор совершенствует свой навык отбора персонала?Вы абсолютно верно ответили на поставленный вопрос в итоге. Но я не понял, к чему все это? Демагогия ради демагогии? Выразите мысль яснее и мы обсудим это.
Вот и вся цель — удовольствие и бабло.
Ну как бы да.
Можно подняться по пирамиде хлеба с маслом повыше и поговорить о несении добра в массы, но круг заинтересованных сразу сузится в разы, если не на порядки.
Например — вместо денег инвестора считать улыбки коллег.
Так и до клоуна дорасти можно. Только работу в IT потеряешь, скорее всего.
Несмотря на всю лирику — работа, она чтобы деньги зарабатывать. И если упирать на что-то в ущерб заработку — то долго так не протянуть. Можно пойти в философы, только вряд ли это то, к чему хочется стремиться среднему IT-нику.
Всё, что не ведёт к увеличению дохода — будет оценено гораздо скромнее, как работодателем, так и читателями.
А на деле одной компании нужен просто скиллованный разраб, что немного последит за мидлами, поможет по необходимости; в другую архитектор/разраб, т.к. у людей нет опыта; в третью, дабы исключить пословицу про лебедя, рака, и щуку; в четвёртую — воодушевить команду разработки; пятая компания ищет менеджера-программиста для планирования и контроля сроков. Но причину часто не узнать, они это прямо таки скрывают, иногда стесняются.
PS: Есть, конечно, исключения, но их много меньше.
Ведь мозг построен на ассоциациях, а прямой вопрос может инициировать поиск в куче.Важный момент, который почти никто не учитывает. Результат будет гораздо лучше, если вместо вопросов вроде «перечислите список методов такого-то стандартного класса, список значений такого-то css-свойства» дать список и спросить, про что из этого кандидат может рассказать и попросить рассказать про назначение известных ему свойств/методов.
Добавлю, что стандартный вопрос «расскажите про самую сложную/интересную задачу» тоже к этому относится. Неподготовленный к такому вопросу надолго зависнет и вспомнит неподходящую задачу. Такой вопрос уместней было бы задавать по email до интервью.
Или вопрос «плюсы и минусы технологии X, с который вы работали на позапрошлом проекте». Вопрос хороший, но для хорошего ответа требуется много времени, чтобы вспомнить, какие были связанные с ней проблемы, что в ней понравилось.
Про базу тоже верно сказано. База это или нет, если в работе она годами не используется, то она забудется. Так уж мозг устроен. Если что-то часто тренируешь, используешь, то нейронные связи формируются так, чтобы лучше выполнять это действие. Без повторения какого-либо действия, связанные с ним нейронные связи со временем разрушаются.
К тому же, опыт и знания у всех разные. В зависимости от опыта, вузов, курсов у всех в какой-то степени отличается то, что они относят к базе.
Не то, чтобы я был совсем против вопросов по базе. Просто не стоит считать разработчика плохим только потому, что он что-то забыл или не встречал из базы.
Хотите вызов, отлично — придумайте с нуля архитектуру полнотекстового поиска (строк 100к будет с тестами). Только давайте с деталями и прочее. Тонкостями языка. Вы же не хотите экспоненциальную сложности разработки и потом утонуть в багах?
Просто ваш пост это что-то уровня «1С программист и администратор баз данных учит как нанимать людей на проект Илону Маску». Вы описали как нанимать админов БД и сервис-инженеров. Но не программистов и инженеров по разработке ПО.
Да, у меня бомбануло от несуразицы из вашего поста.
Да, я писал проекты по 5кк строк кода с TDD и запускал их в космос.
Да, если кандидат тупит в принципах SOLID, то он не сможет сделать вообще ничего.
Да, я про программистов, а не админов БД и сервис-инженеров.
И мне не 15 лет, чтобы брать меня на слабо.
Хотите поиск — будет вам поиск. Могу тариф назвать. Или можем вместе в опенсорсе поработать над этим интересным проектом. Всегда приятно поработать плечом к плечу с опытными людьми.
И все же у меня остается ощущение, что либо вы меня не поняли, либо я вас.
если кандидат тупит в принципах SOLID, то он не сможет сделать вообще ничего.Если тупит в них, то да, вы правы, ну так и я сказал об этом. Но если он просто не может их перечислить, то это не проблема. Это о нем не скажет вообще ничего. Не поможет сделать адекватные выводы. Тогда зачем задавать этот вопрос?
Просто ваш пост это что-то уровня «1С программист и администратор баз данных учит как нанимать людей на проект Илону Маску».Всегда любил аналогии :)
Да, я писал проекты по 5кк строк кода с TDD и запускал их в космос.Увы, таким я похвастаться не могу. А вы в роли кого их писали?
Похоже нынче если не пускаешь проекты в космос ты не инженер, а так админ БД. В любом случае мне кажется вы немного перегорели. Пускать ракеты в космос, я уверен сложно, но вопрос скорее в цене ошибки. У каждого проекта свои приоритеты.
Задеплоить фичу в приложение\веб-сайт конечно проще, и вы с легкостью сможете пофиксить баг и передеплоить в течении минут\часов, и это скорее всего не сильно скажется на проекте\компании, а вот релиз фичи\проекта на неделю\месяц\3 месяца раньше, может принести вашей компании\проекту успех, а задержка провал, так что это то с чем миримся мы, те кто не пускает свои проекты в космос.
С ракетой так не выйдет (пока?), но как только вы сможете пускать по несколько ракет в день, это изменится. Просто потому что практические испытания часто бывает сильно эффективнее (время) теоретического, посмотрите на тот же спейсХ сколько у них уже там ракет бомбануло.
А какое с вашей точки зрения соотношение "запускающих в космос" разработчиков к обычным, которым надо просто пилить небольшие проекты? 1 к 10k? или даже 1 к 100k?
Ваш вопрос по сути похож на вопрос "сколько зарабатывают футболисты?" и ответ "около миллиона долларов в месяц", только без уточнения, что таких футболистов пара десятков на всю планету, а миллионы остальных получают совершенно иные суммы.
Да, подход автора не подойдёт для найма тех тысяч звёзд для работы в рокет-сайнс, но совершенно корректен для найма миллионов остальных.
Вместо одной пачки идиотских вопросов, которая вам не понравилась, вы просто предлагаете другую. Но которая понравилась лично вам :)
Каждый день вижу эти бесконечные конюшни, сотворенные всеми, кто рассуждает про О-нотации и абстракции. Чудно даже, насколько не связаны собесы с работой. Но, если подумать, все же логично. К собесам же готовятся. Это как подтянуть экономику перед экзаменом — все эти знания рассосутся уже на обратном пути домой
Сначала я негодовал по поводу того, что не могу ответить на все базовые вопросы, хотя какое то время назад ответил бы с легкостью. Я думал, что я безнадежен.
Затем, я стал думать, а почему я их забываю. Тогда я пришел к выводу, что ЗА НЕНАДОБНОСТЬЮ. То есть прямые ответы на прямые базовые вопросы не требовались мне в работе. Но, почему-то, нужны были на собеседовании.
Тогда до меня дошло: мало кто умеет собеседовать разработчиков, аналитиков, тестировщиков. И действительно, как понять, сможет ли специалист выполнять задачи и приносить прибыль? Мне тогда казалось нормальной практикой, задать несколько базовых вопросов для проверки знания азов, а потом разберемся на испытательном… ведь по другому никак не проверить.
Но несколько лет эта мысль таки не давала мне покоя и с каждым новым успешным или провальным собеседованием я пытался отмечать для себя, сумел ли я показать свой потенциал. И, к моей огромной печали, я сделал вывод, что нет. Ну или очень малую его часть. Почему я сделал такой вывод? Мне рассказывали про проект, про стек, про предстоящие задачи. Некоторые из этих работ мне уже приходилось делать, некоторые я абсолютно четко представлял, как реализовать.
И заметьте, я не предложил никакую пачку вопросов. Я лишь предложил подумать, кого и для чего вы нанимаете на работу. Что он должен будет делать? Как вы можете понять, что он справится?
И вместо вопросов предложил нагенерить прикладные задачи.
К собесам же готовятся. Это как подтянуть экономику перед экзаменом — все эти знания рассосутся уже на обратном пути домойНикогда не готовился к собесам.
Не претендую на истину, но такие подходы к собеседованию кажутся странными только если думать о собеседующих как о профессионалах своего дела, добросовестно выполняющих свои обязанности и ставящих приоритеты владельца компании выше своих. Ну, я пока что таких не встречал. Как правило, люди просто хотят побыстрее со всем этим разобраться и копипастят одни и те же методики отбора, которые где-то видели. Голова тут не подключается совсем, а список вопросов обычно гуглится.
Вторая категория — те, кто искренне пытается "сделать хорошо" и подойти индивидуально. Они читают как делает условный гугл, выкидывают все что непонятно и "странно", и мы имеем уже не список вопросов, а вот эти идиотские задачи на прыгающих через дорогу лягушек. Не поймите превратно — задачки полезны исключительно для саморазвития и прокачки каких-то узких скиллов. Я лишь упираю на то, что оптимальные алгоритмы и элегантные решения в 99% компаний что мне втречались заканчиваются на интервью. А дальше вы будете в основном очень эффективно строгать формочки, пилить очередной GET для е-коммерса, и тп.
Третья категория собеседующих обычно говорит "за жизнь, но про технику" и ваши познания становятся понятны просто в ходе разговора. Как по мне, это идеальный способ интервьюирования: и кандидат не чувствует себя в цирке или за партой, и интервьювер не провоцирует вранье прямыми вопросами. Надо ли говорить, что все это требует больших мыслеусилий, опыта и желания такой навык прокачивать? Ну вот и прикиньте сколько людей готовы этим заниматься.
Никогда не готовился к собесам
Подозреваю, результат этого через раз закономерен и послужил поводом для статьи. К сожалению, если вы захотите попасть в тот же FAANG — шансы без подготовки минимальны, просто потому что ваша нейронка не обучена на их видение прекрасного :)
Подытожу свой мини-опус: пройти собес и быть закономерно хорошим специалистом — никак не связано. Это как "учиться на отлично" и ожидать что все у тебя в жизни сложится.
Подозреваю, результат этого через раз закономерен и послужил поводом для статьиРезультат закономерен. Но я хочу работать в адекватной компании, которая знает, зачем я им нужен. Готовиться к собесам в компанию, которая мне самому не подойдет, смысла не вижу.
пройти собес и быть закономерно хорошим специалистом — никак не связано.К этому нужно стремиться. Со стороны ревьюеров. Повышать КПД.
Серьезным ребятам нужен серьезный вызов.
Серьезные ребята обязаны знать базовые вещи.
Мы при наборе руководствуемся той истиной, что чем человек больше знает, тем ему это направление интереснее. Если ему интересно, то результат обязательно будет даже если у него не так много опыта. Этот подход так же позволяет оценить его реальный уровень и потенциал.
Есть еще одна истина это спрашивать подробно у человека по тем вещам что он сам указал в своем резюме. В 90% случаях очень слабые знания в том что они сами и указали.
Так же если ставка например ведущего инженера-программиста, то требования к его знанию и опыту разумеется серьезные. Ведущий инженер должен соответствовать уровню, что бы небыло перекоса когда старший инженер будет разбираться лучше ведущего и видеть эту несправедливость, что негативно скажется на атмосфере в коллективе и рабочем процессе.
Серьезные ребята обязаны знать базовые вещи.
Еще раз. Они обязаны их понимать. Это означает знать, но в срезе прикладных задач.
Мы при наборе руководствуемся той истиной, что чем человек больше знает, тем ему это направление интереснее. Если ему интересно, то результат обязательно будет даже если у него не так много опыта. Этот подход так же позволяет оценить его реальный уровень и потенциал.Или он просто посидел сутки перед вашим собесом и почитал статьи про базовые вопросы на собесах с ответами на них.
Есть еще одна истина это спрашивать подробно у человека по тем вещам что он сам указал в своем резюме. В 90% случаях очень слабые знания в том что они сами и указали.Само собой. Большая часть откликнувшихся на вакансию будут некомпетентны. Но, если будете задавать не те вопросы, получите искаженный результат.
Так же если ставка например ведущего инженера-программиста, то требования к его знанию и опыту разумеется серьезные. Ведущий инженер должен соответствовать уровню, что бы небыло перекоса когда старший инженер будет разбираться лучше ведущего и видеть эту несправедливость, что негативно скажется на атмосфере в коллективе и рабочем процессе.Перекос в тех или иных моментах может быть и скорее всего будет. Как же без этого? Но по этому поводу в двух словах не ответить, чтобы раскрыть тему.
Серьезные ребята обязаны знать базовые вещи.Если серьезному человеку будет интересно, я не думаю что он будет ежегодно перечитывать базу, а будет изучать что-то новое, при этом забывая неиспользуемое старое.
Есть еще одна истина это спрашивать подробно у человека по тем вещам что он сам указал в своем резюме. В 90% случаях очень слабые знания в том что они сами и указали.Как вы указали, значительная часть будет некомпетентна, но немалая часть компетентных людей отсеется неудачными вопросами.
Если с указанной технологией кандидат последний раз работал несколько лет назад, естественно он плохо ее помнит. Многие ли задают вопрос: «по каким технологиям/областям вы готовы отвечать на вопросы? (хотя звучит странно)» или «что из этого списка вы часто использовали за последние полгода?»?
Мне интересно было бы посоветоваться, что в такой ситуации делать?
Указывать в резюме как много и как давно работал с каждой технологией?
Указать Senior и оставить только штук 5 навыков?
Предупредить перед техническими вопросами: «многое из перечисленного использовал несколько лет назад, а что-то недолго, поэтому естественно, подобное буду помнить довольно плохо»?
Например DRY. Когда я первый раз столкнулся с неоходимость объяснить, я подвис секунд на несколько: как объяснить что вода мокрая, снег холодный, а код не должен дублироваться?
Или, совсем недавно узнал, CQRS. Удивительная вещь!!! Оло, на первом курсе это называется процедурой и функцией! Это вообще какая-то школьная база. Как её обяснить когда объяснение это само определение? И это на собесе на мидла.
KISS — Ну логично, опять же. Не усложняй. Пиши проще, понятнее для большинства. Мне, например, проще .filter().map() а не Array.reduce(). А вам? Нет? Ну так кто прав-то?
L из SOLID — прощай переопределение методов? Ведь если мы мы переопределим A.f(return 1) -> B.f(return «hi») то мы не сможем использовать B вместо A.
GoF'ский Адаптер у меня в голове гвоздями прибит как Конвертер. Как-то раз минут пять доказывал это на интервью.
Вообще хорошее интервью это не когда «расскажи», а «давай поговорим».
А то некоторые скриншоты когда кидают в скайп 12px шрифтом, а ты с телефона должен разглядеть, скомпилировать в голове, ещё и без мата.
Но так походил где-то полгодика по собеседованиям, поднаторел, и в местах посолиднее уже были абсолютно нормальные задачи исключительно по QA и немного по SQL, ну тобишь именно по моей специфике, куда шел.
Кого вы хотите принять на работу?