Comments 96
Когда ко мне, как к нанимающему менеджеру, приходят с просьбой прособеседовать человека на должность, я сначала спрошу: а чем он должен будет заниматься?
Последнее время практикую именно такой подход. Задаю вопросы по опыту кандидата в контексте предстоящих бизнес задач. Ключевые преимущества, на мой взгляд, следующие.
Комфортный диалог
Стресс улетучивается, кандидат открывается как только понимает что он не на экзамене, а на совместном обсуждении причин для сотрудничества.
Вообще получается что модель типичного собеседования “я оцениваю тебя” превращается в “мы обсуждаем что можем сделать вместе”. Это начинает больше походить на диалог потенциальных партнеров, поэтому кандидат проявляет больше заинтересованности и инициативы.
Вы точно поймете уровень кандидата
Прикол в том, что вы уже реально работаете вместе, выполняя первый этап любой задачи – её обсуждение.
Если обсуждение развивается, вопросы кандидата вам кажутся подходящими, предложения не вызывают сомнений – значит вы сработаетесь. Разве не это настоящая цель любого собеседования?
Если интервьюер не может отличить заученные слова кандидата от реального опыта, не может понять корректность и применимость технической экспертизы – то как он у вас работает вне собеседований на реальных задачах? Это уже проблема квалификации интервьюера, а не кандидата.
Кандидат получает ответы на свои вопросы
Вспомните насколько абсурдным иногда бывает техническое интервью: после нескольких часов абстрактных ребусов и задач, кандидату дают всего 5-10 минут на вопросы о реальном положении дел в компании, ещё и ответить внятно не могут некоторые.
Кандидат сможет сразу понять и оценить устройство вашей технической кухни, сможет сопоставить ваши требования и ожидания к собственной экспертизе, если вы ясно обозначите какие задачи хотите решать и почему.
Польза тут ещё в том, что вы уменьшаете риск ухода нового разработчика на период адаптации, потому что сразу решаете проблему несоответствия ожидания и реальности. Во всяком случае, я убежден, что это одна из самых частых причин: когда на техническом собеседовании компания Лев Толстой, а не деле формошлёп простой.
Решает проблему законсервированности текущих решений
Одна из проблем любой команды – это замыкание технической экспертизы на мнение текущих разработчиков. Кроме инертности и устаревания технических решений это приводит ещё и к проблеме найма. Разработчиков со свежим взглядом часто отфильтровывают не актуальными техническими вопросами.
Но если обсуждать реальные задачи, кандидат может на основе своего опыта предложить лучшее решение этих задач уже на этапе собеседования. А вместе с тем и дать импульс текущим разработчикам освежить свое техническое видение.
Я начинающий программист, ищу свою первую работу. Как в итоге мне быть? Получается чтобы найти работу надо сидеть и знать каждую техническую тонкость языка и рекурсировать рекурсию?)
И ещё, в подлинности скриншота не уверен. Неужели человек с большим опытом на Сеньоре реально сидит 2 недели и не понимает чего он делает?
К сожалению эта статья не для начинающих программистов, сейчас рынок устроен так что да, ври про опыт и знай даже не тонкости а просто ~50 однотипных вопросов. Это если хочешь как можно быстрее найти работу и быстро с нее вылететь)
а если хочешь чего-то стабильного то долго ищи и пиши свои пет проекты
Скрин к сожалению правдивый, об этом я и сокрушаюсь)
А что с полями то не так ?
Я не фронт, но из контекста можно сделать вывод, что просят два поля, а чел пишет вместо них json-объект с двумя полями
Ну для пост запроса что то формирует... 2 недели с задачей возится... Здесь дело точно не в запросе, а скорее всего в не правильной постановке задачи или в её отсутствии. Или проект кривой как моя жизнь.
Задачи в паблике надо обсуждать или в джире, а не в личке.
Качество знаний у людей которые обсуждают задачу тоже не факт, что высокие.
А как из себя гераклов в ИТ рисовать все из себя любят дак это часть сферы.
Когда у тебя зп 300+ у тебя вообще не должно в голове возникать вопроса про "правильность постановки" и молчания в 2 недели, ты уже сам знаешь как надо и что надо.
Одно дело знать, другое дело работать в команде. Для маленьких контор и каких нибудь стартапов это нормально когда ты с шашкой наголо на встречу задачам и проблемам.
Другое дело достаточно большая компания, которая расчитывает существовать до конца существования России. В таком варианте важно не только сделать задачу, а сделать её в рамках определенной системы. Либо если система не сформированна, проанализировать то, что он делает и придумать какой то рабочий вариант, который устроит команду и внести изменения в рабочий воркфлоу.
Какой здесь вариант приведен не понятно.
Если первый, там скорее всего 300+ не будет зп или человек знает когда дедлайн и может быть решил уделить больше внимания архитектуре. И делал не этот запрос, а может быть переписывал половину сайта в это время.
Если второй вариант, то это вопросы к руководителю проекта.
И вообще работают достаточно часто по спринтам. Максимально длинный спринт я видел 4 недели + дейлики должны проводиться.
Если на одну задачу в спринте уходит 2 недели.
У РП должны возникнуть вопросы в любом случае.
По этому этот диалог в любом случае странный.
Вот это вы конечно странно начали отстаивать честь рандомного синьора по скриншоту обсуждения его коллегами) почти борьба с соломенным чучелом получилась.
Вот тут на скриншоте буквально начинают возникать вопросы к человеку с большой зп о его проф пригодности, ибо он спрашивает как работают базовые вещи у мидла)
Все в системе, все знают как и что делать, задача не на 2 недели)
тут 0 подводных камней, просто так тоже бывает)
Компания платит 300+, но нормального поставщика найти не может? Да и сам факт, что человеку со старта дали задачу на 2 недели (или на два часа, но не проверяли две недели) говорит об уровне тимлида в команде. Так что не удивительно, что и на уровень сеньора взяли непрофильного специалиста, который, возможно, даже http-протокол не знает.
Как статья противоречит вашему комментарию?
Да, наняли плохого спеца, провели собес по всем правилам и даже http спросили и получили превосходный ответ))
Тут же прям кристальный пример - вызубрил шаблонное интервью - получил работу.
Автор переписки читал тут это все и может сам наверное подробнее рассказать, не буду за него говорить)
Меня удивил срок. Да, взяли плохого спеца. И если бы он просто не тянул, можно было бы и несколько месяцев не понимать это. Но тут намёк, что он вообще ноль. Просто обманул на собеседовании, но совершенно не в теме работы (если я верно понял посыл статьи).
Кроме проблемы собеседований тут есть и проблема онбординга. Человеку дали задачу и бросили на две недели, он же сеньор. На всякий случай было бы интересно узнать другую сторону. Вдруг там вообще не было ни документации, ни доступа к коду интегрируемого сервиса, названия полей говорили коллеги, при этом неправильно и неохотно (с последним я сталкивался), а сам сервис работал крайне нестабильно?
Конечно, сеньор мог бы свалить из такого ада сразу, но вдруг это его первая попытка выйти на уровень сеньора? Неудачная.
А что с полями то не так ?
Это можно максимум за пару часов выяснить методом дебага, гугла и перебора. Что-нибудь да скушается. Можно быть вообще полным 0 в технологии, но всё равно разобраться как правильно.
Полностью согласен с Вашей статьёй и ситуацию вижу так же. Всё ещё усугубляется вот этим
рынок устроен так что да, ври про опыт
В результате, врать вынуждены все. Иначе те, кто не будет врать - оказываются в проигрыше.
Тут может быть 2 варианта.
Код проекта очень замудренный, связанный. И на его изучение и правильную доработку нужно очень много времени. Лично сталкивалась с таким, что на погружение в код чтобы понять что-то нужно было 4 дня. А если что-то там изменить, то нужна была неделя, не меньше.
Поверхностно поставленная задача. Для новичков (новых членов команды) все контракты должны были быть описаны и задача подробно расписана.
А вот честно, шут его знает. Я не начинающий программист, с 20+ годами опыта и тем не менее, имею опыт работы проблемы с поиском работы. В том числе и по описанным в статье причинам. Начинающим я могу только в полной мере посочувствовать.
Ну я со своими 4 годами ангуляра, годом webgl попробовал недавно поискать работу в Минске. На третьем и четвёртом в моей жизни собесе по js спрашивали вот эту всякую чушь. И тут я понял кого индустрия сейчас набирает, и что работать с такими я точно не хочу. Да ещё сидит по 15 человек на rabota.by, смотрят одновременно одну вакансию, потом в фигме штук 100 тестовое верстают.
Только что проверил, 29 человек одновременно пялятся в вакансию https://hh.ru/vacancy/81797571?from=applicant_recommended. Несчастные 1200 евро. Да лучше пойти коров на ферму доить чем страдать вот этой ерундой.
Не знаю как себя нужно не любить чтобы сейчас искать работу в этой области.
Это очередной ответ на вопрос, почему я не собеседую кандидатов, потому, что собеседовать так не могу, а что реально спрашивать у человека, что бы понять кто это реально я не знаю.
Пусть рассказывает что делал.
Судя по тому, как я сам "красочно" рассказываю о том, что делал, сам бы себя на работу не взял )))
Еще нравится вопрос про эпичный провал, фиг знает, что на него отвечать, что такой фейл был я уверен, ну прям точно помню, что как то сильно сел в лужу, но проблема в том, что это было так давно, что подробностей я не помню))) Как собственно и эпичных достижений тоже, все давно слилось просто в поток работы, иногда сложной иногда простой )
Вот про сложную работу и можно поспрашивать. В какую технологию погружался, как она работает.
Вот-вот. Мне кажется, основываясь на том, что бы я спросил самого себя, спрашивать имеет смысл:
Расскажите, с какими сложностями вы столкнулись в предыдущих проектах и каким способом вы их преодолели.
Расскажите, какими решениями из предыдущих проектов вы можете гордиться.
Расскажите о решениях, которые вы вынуждены были использовать в предыдущих проектах и почему они вам не нравились и почему вы, всё таки были вынуждены использовать.
Правда тут возникает проблема, если собеседующий менее опытный, чем кандидат.
Пару раз нарывался на такое в прошлом, в итоге отказ, стойкое ощущение, что либо не поняли о чем я вообще говорю, либо не поверили )))
У меня нет решений, которыми я горжусь. Я не блокбастер снимаю а решаю рутинные продуктовые задачи, которые чрезвычайно важны для бизнеса, но совершенно однотипны с технологической точки зрения.
Если такое спрашивает HR то это вообще мрак. Ощущение что они делают это для отчётности, чтобы передать информацию техническому руководителю (разумеется, исказив до неузнаваемости).
Если правда не знаете, то подумайте что кандидат будет делать у вас? какие задачи решать? буквально его фронт работ на ближайшие 3 месяца
Вам же нужен зачем-то новый человек, да?)
Если он уже решал ваши будущие проблемы, или с ходу придумал как их будет решать и в общении приятный - заканчивайте собес и высылайте оффер. Ваши таски он закроет и будет 3 месяца на испыталку.
Или же соотнесите со своим уровнем спросив о проблеме которую вы с командой решали какое-то время и послушайте что он будет вам говорить. Тут уже легче сопоставить ваши уровни и найти "общее мерило" его знаний.
А не пробовали во время работы записывать задачи? У меня иногда возникают моменты, когда вот реальная задача и её хоть сейчас на собеседование (умеренно простая, короткая, изолированная). Правда, я собеседований не провожу, поэтому не записываю, но уверен, что что-то такое должно работать.
ну вот пройдя ради интереса порядка 30 таких веселых интервью "по списку" с грейдами, я наконец-то сделал выводы и стал спрашивать HR - 1) КТО будет проводить собеседование, 2) СКОЛЬКО обычно собеседование длится и 3) ЧТО у вас соискатели делают на собеседование.
По первому пункту - если слышу туманное "коллеги" - прекращаю разговор. Правильный ответ - ваш будущий руководитель такой-то такой-то.
По второму пункту - если слышу про более полутора часов - прекращаю разговор - или требую оплатить мое время. Правильный ответ - не более часа вашего времени.
По третьему пункту - если там перечень вопросов по грейдам или лайвкодинг - точно так же прекращаю разговор. Если с вами ребята надо попотеть еще, решая задачки - ну платите за это - труд должен быть оплачиваем. Правильный разговор - разговор по прошлым работам и вообще по технике, максимум - ну код показать.
Если не вяжется со всем что описал выше - ну у людей цель - собеседовать кандидатов, сотрудник им не нужен.
Да, как "заваливать" кандидатов я тоже в курсе - простой вопрос - чем арифметическое битовое смещение отличается от логического битого смещения - 100% кандидатов ставит в тупик. И да, это "база". Не врите себе что ее знаете.
сли там перечень вопросов по грейдам или лайвкодинг - точно так же прекращаю разговор.
Удачи с таким подходом завести трактор. Лайвкодинг сейчас просто мейнстрим для тех, кто вывозит.
По прошлым работам тоже можно скрыть некомпетентность, довирая и приукрашивая. Собеседующему трудно понять, насколько всё это правда - если он начнёт слишком душить, то кандидат всегда может сослаться на то, что в памяти не отложилось, а то и в контратаку пойти - мол, чё это вы меня на враньё что ли пытаетесь подловить?
Задачи с литкода, знание теории алгоритмов и т.п. даже поверхностное - это всё-таки знание. То есть чел вероятно даже его применит (написав ужасный нечитаемый кусок кода).
Вы как-то статью и не прочитали походу)
Вы проводили собеседования? Если кандидат юлит это видно ну просто моментально, а если идет в контратаку то это сразу скип.
Задачи с литкода и алгосы это не знания а умения, и они ничего не говорят о кандидате кроме того что он сидел их и зубрил. Если кандидат знает дейкстру, но не ответит мне на то когда применять его а когда тарьяна (и где он вообще применял дейкстру) то это не ценность.
Посыл в том, что ищите человека под ваши задачи, а не человека который вам начистит ведро картохи за пол часа или напишет алгос который вам не нужен.
Тут есть и положительный финансовый момент, человек решивший вашу проблему может стоить сильно дешевле человека знающего все алгоритмы мира.
Никогда в жизни не сталкивался со "сразу скип", даже на позициях где я явно не подходил. Это скорее то как вы хотите чтоб было, это не реальность.
Серьезно?
это не реальность когда я заканчиваю интервью после того как человек мне скажет "чё это вы меня на враньё что ли пытаетесь подловить?"
А когда мне заканчивать интервью? когда он начнет по фене ботать или матом орать?)
Да, я хочу чтобы на интервью мне не задавали таких вопросов и делаю все чтобы у кандидата не возникло таких мыслей (в том числе и не пытаюсь его подловить ни на чем) и это и есть РЕАЛЬНОСТЬ.
Спасибо за статью. Прочитал с интересом.
Сам тут попытался найти работу java джуном. В результате две компании, в которых сказали, что резюме и опыт интересные, но в одну я не успел, там уже успели закрыть вакансию, а во второй стартап и им нужен человек с опытом, который сможет вникнуть в суть максимально быстро. Первая компания в Казахстане, а вторая - стартап в РФ. В обоих случаях резюме смотрели директора.
При этом идти по пути "вызубрить билеты" я и не собирался. Я люблю программировать, я учился этому самостоятельно. Как следствие я сделал не стандартное резюме и неспеша ищу работу, попутно развивая свои проекты.
Касательно культуры собеседований - такая проблема наблюдается не только в IT. Я успел много куда поустраиваться и поработать. От грузчика до зам. директора. Почти везде используется шаблонный метод собеседований. И да, когда я дорос до должностей в обязанности которых входил найм сотрудников, я тоже заметил шаблонность и стал строить собеседования сначала с общих вопросов (для понимания что за человек ко мне пришел), а потом вопросы, которые дадут мне возможность понять знает ли как и/или способен ли обучиться человек выполнению должностных обязанностей.
Иначе говоря мне все равно умеет ли человек чинить компьютер, если это не входит в его обязанности, но если в процессе выяснится, что умеет, то это просто дополнительный козырь в его рукаве)
P.S.
Все равно хочу работать в IT.
Если позволите, я бы указал здесь ссылку на обсуждение и статью по той же самой теме: Статья
Странно, что в комментарии не набежали доброхоты, доказывающие, что именно знание конкретного event loop им всё о кандидате и говорит, ведь это же основы.
Спасибо, статья правдивая но весьма эмоциональная и забавно что всего на пару дней назад написана) не мониторю обычно хабр а читаю кучу гневных тиррад в одной соцсети.
Там в комментариях действительно много интересных людей которые заставляют думать на собеседованиях с помощью однотипных задачек. Но и с тейком про плохой вопрос - "опишите структуру" не вполне согласен. Вот такие вопросы как раз и надо задавать. Бизнесу наплевать на понимание сложных нюансов яп, им нужен результат за время и обеспечить дальнейшую поддержку этого результата. И в этом как раз различие вопросов про "(true + true * 5) - 2" и "опишите структуру хайлоада", второй вопрос тоже заставит подумать, а еще и потенциально принесет прибыль.
Давно уже пытаемся на собесе просто растопить лёд и потом совместно берём задачи из жиры и делаем ее рефаймент, парное программирование или баг разбираем.
Современное состояние рекрутинга - идиоты набирают идиотов.
Современное состояние рекрутинга — идиоты набирают идиотов.
И ведь блестяще справляются с этой непростой задачей!/s
Впрочем, это не только про IT.
идиоты набирают идиотов
И к сожалению, они даже защищают такой подход.
Вот честно говоря, на мой взгляд, вот это вот онлайновое думанье - так себе штука. Было у меня, показывают экран с кодом и спрашивают, что в нём плохо. У меня от стресса глаза по экрану бегают, ни за что зацепиться не могут. Говорю, ну вот это выглядит странно. Ну вот это при каких-то условиях будет странным. А так, вроде, ничего фатального не замечаю. Наконец мне тыкают пальцем и я восклицаю: ну позвольте, в одном контексте - это плохое, а в других контекстах вообще без разницы, тут всё зависит от деталей, которые мне не известны. Т.ч. в таком вот онлайновом думанье есть минимум две проблемы.
У некоторых людей возникает стресс просто от того, что они находятся рядом с незнакомыми людьми. И кажется мне, что это не является чем-то необычным для программистов. Много среди нас разной степени интравертов и даже в чем-то аутистов.
Всё эти задачи очень субъективны, т.к. у спрашивающего в голове какой-то контекст, а у отвечающего - нет.
А на собесе в нормальную команду там все сплошь экстраверты будут сидеть? Да сидят там такие же гики, которые в идеале ищут ответы на многие общие с тобой вопросы, на которых нет однозначных ответов и поговорить на эти темы с человеком, который просто себе их уже задал - это радость, а когда он для себя нашёл какие то ответы - то это праздник и мы сразу это заметим.
Если нет, то это просто не твоя команда. Заползти туда можно, но зачем?
Не стоит этого так сильно бояться, потому что существует также много работадатей, которые объективно оценивают компетентность кандидатов. Как минимум 1 точно есть - автор этой статьи. Да и судя по комментариям тут, многие разделяют это мнение)
Я из таких статей не понимаю вот чего. Общей картины в индустрии. Большие ЗП (даже у джунов) говорят о дефиците кадров или о том, что реально рекрутинг нацелен на поиск одного лучшего из 10? В первом случае - брали ли бы любого желающего, на собесах бы смотрели просто потенциал. Во втором тоже "легко". Лучшие смогут на собесе показать что они лучшие, даже ещё до собеседований. Хедхантерство - это не про проблему собеседований.
Прочитал пункты 1-2-3 из вступления. Уже поюсую. Всё так.
Мда, помню как на первой работе, будучи уже чем-то вроде мидла (четких грейдов там не было, фронтендеров опытнее меня тоже), при поиске человека на позицию джуна, где надо было бы уметь писать просто в меру рабочий говнокод, так жестил при проверке тестового, что теперь аж стыдно. Отчетливо понял я что делал что-то не то, когда начал сам искать новую работу и столкнулся с вариантами тестовых там. Собеседования мне проводить, слава Богу, не довелось...
потрясающие вопросы уровня «Как улучшить SQL запрос если медленно работает»
А что плохого вы увидели в этом вопросе, с учетом того, что вы лид фронтендер (и это как бы вполне может быть за пределами ваших компетенций, и это даже не зазорно не знать всего)?
ну как бы вы сами и ответили на свой вопрос, нет?)
Для лидов фронта это еще мб релевантный вопрос, но он задавался ну уровень мидла)
Ну, так и что плохого для миддла? Как по мне, миддлу уже пора понимать границы своих компетенций. И я бы принял бы ответ типа "посмотреть план запроса, если нихрена не понял, спросить DBA". Это многое бы мне сказало про человека.
Да, для миддла фронта — конечно странно. Тут вообще зачем SQL?
Ну, так и что плохого для миддла?
Да, для миддла фронта — конечно странно. Тут вообще зачем SQL?
???
Так бы и ответил на вопрос, мол посмотреть сложность запроса (и бизнес необходимость для такой сложности), если сам ничего не понял (ибо писать sql запросы не работа даже лида фронтов) поставить задачу на дба, пусть сделают красиво
но мы говорим про мидла и тут мой тейк простой:
В вакансии указано знание sql? тогда вопросы ожидаемы и понятны
Но вакансия не подразумевала подобных вещей. Если у вас есть возможность задать 20 вопросов кандидату, и вы один тратите на познания человека в SQL - 5% от всех вопросов, а на работе он будет с этим сталкиваться 0,01% времени, то у меня бы как у бизнеса были бы к вам вопросы, зачем?
я еще может спросил бы о творчестве Куприна - это бы тоже многое бы мне сказало про человека)
Фронту — вопрос об улучшении SQL-запроса? Серьезно?
Тут можно много написать, и все не так и все не то. Но нужно понимать, айтишники в России живут в том же поле, что и все другие специалисты и к сожалению ситуация такая, что у нас врут все и обо всем. В нашей ситуации ничего другого ожидать и не стоит.
а что такое нормализация и денормализация json? в мире бэкенда в контексте нормализации обычно БД имеют ввиду.
Да примерно то же самое, как и в БД. Допустим, есть json для объекта comment
{
text: '...',
date: 123456789,
user: {
id: 456,
name: '...',
...
}
}Вот этот юзер из объекта извлекается, кладется в отдельный объект (или хэшмэп) users по id, а в comment вместо user: {...} будет user: 456
В ряде случаев так удобнее.
Опять двадцать пять... Снова учат работодателей разглядывать таланты.
В книжке "Are you smart enough to work at Google?" (хорошая книжка, рекомендую) описан косвенный вопрос, ответ на который стремится получить интервьюер: "хочу ли я с этим парнем/девушкой выпить пива после работы?" Так вот мне было бы скучно пить пиво с ботаном, чей профессиональный кругозор ограничивается парой фреймворков. Как изрек Козьма Прутков, специалист подобен флюсу. Возможно, во фронтэнде это приветствуется, чтобы человек знал ровно то, что нужно, и на этом его кругозор был ограничен, но в тех областях, где доводилось работать мне, ограниченность кругозора делала человека профнепригодным.
Знания -- это не все. Более того, важнее не сами знания, а умение их получать, и вот тут Leetcode и алгоритмы как нельзя кстати. Все мы в той или иной мере изучали дискретную математику. Все мы знаем, что на интервью будут гонять именно по этой части. И вот она, возможность продемонстрировать, как ты сумел подготовиться к испытанию с заранее очерченной темой. В конце концов, не надо считать, что работодатель окажется внакладе, не сделав вам оффер. Он найдет, кому его сделать, будет руководствоваться неявными и алогичными критериями, но примет на работу того, кто понравился, а не того, кто "правильно ответил на вопросы".
Опять двадцать пять... я буквально и есть работодатель который разглядывает таланты)
У вас дальше воспаленное творческое проглядывает на которое даже и хз как отвечать.
Попить пива после работы? Ботан но пара фреймворков? Козьма Прутков?
вы вообще как читали то?
я буквально пишу что узкие собесы на одни и те-же вопросы/алгосы это зло которое хакает рынок и спрашивать надо то что лично вашему проекту важно а вы мне говорите что это расширяет гругозор)
Вот именно что все мы знаем что нас будут спрашивать, и включается синдром егэ, где тем кому это не интересно а интересны реальные вещи в проигрыше перед теми кому интересны только эти узкие задачки)
И реальность такова, что на работе работают на фреймворках, задачи решают не с литкода, а на фронте гораздо важнее знать как сделать красиво и удобно для пользователя и не положить браузер чем уметь в алгосы. И если мне человек ответит на важные для работы вещи лучше чем человек с алгоритмами то я его возьму на работу.
И обычно с людьми умеющими в реальные задачи гораздо приятнее пить пиво чем с 123 хардами с литкода)
Мне совершенно все равно, с кем вы предпочтете пить пиво. А также индифферентно, кого вы возьмете на работу. Но зачем вы пытаетесь всех учить, как им нанимать сотрудников?..
Знания алгоритмов нужно, но поверхностное. Чтобы не лепили тройной и тд вложенности циклы и могли на пальцах объяснить почему так делать нельзя.
А то требуют задачки с леткода, а у самих такой код.....
В книжке "Are you smart enough to work at Google?"
Ой не нужно ориентироваться на гугл. Ваша компания не гугл и вряд ли когда нибудь будет. Это типичный карго культ. Ну а уж ссылаться, в качестве аргумента, на какую-то книгу, какого-то гугла... Тоже мне, истина в последней инстанции.
Более того, важнее не сами знания, а умение их получать, и вот тут Leetcode и алгоритмы как нельзя кстати.
Шта? Выдроченный литкод это уже стало "умением получать знания"?
И вот она, возможность продемонстрировать, как ты сумел подготовиться к испытанию с заранее очерченной темой.
Как правило на этом всё и заканчивается. Сидят потом такие макаки, шаг вправо-влево ничего самостоятельно сделать не могут.
Никогда не видел собеседования, которое бы заканчивалось на литкоде.
Собеседование не заканчивается. Работать потом эта публика не умеет, от слова совсем. Литкод уже стал скорее антипаттерном: кандидат плохой специалист, его никуда не берут, поэтому у него куча времени и мотивации выдрочить литкод. Сам литкод решается простым запоминанием, а не пониманием каких-то глубинных принципов.
Повторяю, никогда не видел, чтобы все собеседование только и состояло, что из литкода. Обычно это удел скрининга, позволяющего отсеять тех, кто вообще кода боится. Ну вот в моей недавней практике были два кандидата: первый не знал, что такое указатель в C++, а второй вообще отказался кодировать (типа, он умеет "проблемы решать", а кодируют люди попроще). Я из вежливости потратил час на первого, пытался хоть что-то из него вытянуть, со вторым мы закончили интервью быстрее по обоюдному согласию. И вот зачем оно мне было нужно? Отсеить их простенькой литкодовской задачкой, и тратить время только на тех, с кем есть о чем поговорить.
Отсеить их простенькой литкодовской задачкой, и тратить время только на тех, с кем есть о чем поговорить.
Проблема в том что осеятся и годные спецы. И чем они годнее, тем меньше у них резона заниматься всей это хренью.
Чтобы отсеять, достаточно взять резюме и пообщаться с кандидатом по проектам. В процессе диалога уже сразу становится понятно в теме ли человек. На этом собес можно и заканчивать, на самом-то деле.
Не знаю, может, у вас во фронтенде и есть "годные спецы", не умеющие решить простенькую литкодовскую задачку (в чем я сильно сомневаюсь), но я не разу не видел таких в бэкенде. Зато настрадался от обратного: от говнокодеров с высоким ЧСВ, которые плохо понимают, что и зачем они делают, и лишь увеличивают энтропию. И да, литкод им не по силам, и потому они зовут его хренью.
Есть более-менее общепринятое мнение, что в найме ошибки второго рода гораздо больнее, чем первого. То есть упустить хорошего кандидата более приемлемо, чем взять плохого.
Ни прибавить, ни убавить. Абсолютно все те же мысли после 50+ созвонов
Дело вовсе не в том, что мало кто умеет использовать сложные мыслительные процессы, анализировать, применять научный подход, проверить гипотезы, провести эксперименты, собрать статистику, при этом сделав всё правильно и избежав ошибок. И по результатам улучшить свой процесс найма. Люди не тупые, они умные и всё это в той или иной степени умеют, в т. ч. и ваши собеседующие постоянно применяют это в своей работе, когда программируют. А вот чтобы везде применять - такой привычки попросту нет. Как в анекдоте про прапорщика, который сразу идёт трясти дерево с бананом. Надо нанять человека - так, вот примеры задачек из инета, вот резюме почитать, вот интересный вопрос из моего опыта - идём трясти собеседовать. Про то, чтобы сделать мини-исследование, как вы, многие даже не задумаются, а многие посчитают ненужным. И этот тимлид перед вами, который спрашивает про абстрактные классы - он просто не понимает, что плохо подготовился, плохо изучил кадровые потребности, потратил мало времени, недостаточно продумал процесс собеседования, не прокачал свой навык собеседовать, в конце концов.
Когда ко мне, как к нанимающему менеджеру, приходят с просьбой прособеседовать человека на должность, я сначала спрошу: а чем он должен будет заниматься?
Последнее время практикую именно такой подход. Задаю вопросы по опыту кандидата в контексте предстоящих бизнес задач. Ключевые преимущества, на мой взгляд, следующие.
Комфортный диалог
Стресс улетучивается, кандидат открывается как только понимает что он не на экзамене, а на совместном обсуждении причин для сотрудничества.
Вообще получается что модель типичного собеседования “я оцениваю тебя” превращается в “мы обсуждаем что можем сделать вместе”. Это начинает больше походить на диалог потенциальных партнеров, поэтому кандидат проявляет больше заинтересованности и инициативы.
Вы точно поймете уровень кандидата
Прикол в том, что вы уже реально работаете вместе, выполняя первый этап любой задачи – её обсуждение.
Если обсуждение развивается, вопросы кандидата вам кажутся подходящими, предложения не вызывают сомнений – значит вы сработаетесь. Разве не это настоящая цель любого собеседования?
Если интервьюер не может отличить заученные слова кандидата от реального опыта, не может понять корректность и применимость технической экспертизы – то как он у вас работает вне собеседований на реальных задачах? Это уже проблема квалификации интервьюера, а не кандидата.
Кандидат получает ответы на свои вопросы
Вспомните насколько абсурдным иногда бывает техническое интервью: после нескольких часов абстрактных ребусов и задач, кандидату дают всего 5-10 минут на вопросы о реальном положении дел в компании, ещё и ответить внятно не могут некоторые.
Кандидат сможет сразу понять и оценить устройство вашей технической кухни, сможет сопоставить ваши требования и ожидания к собственной экспертизе, если вы ясно обозначите какие задачи хотите решать и почему.
Польза тут ещё в том, что вы уменьшаете риск ухода нового разработчика на период адаптации, потому что сразу решаете проблему несоответствия ожидания и реальности. Во всяком случае, я убежден, что это одна из самых частых причин: когда на техническом собеседовании компания Лев Толстой, а не деле формошлёп простой.
Решает проблему законсервированности текущих решений
Одна из проблем любой команды – это замыкание технической экспертизы на мнение текущих разработчиков. Кроме инертности и устаревания технических решений это приводит ещё и к проблеме найма. Разработчиков со свежим взглядом часто отфильтровывают не актуальными техническими вопросами.
Но если обсуждать реальные задачи, кандидат может на основе своего опыта предложить лучшее решение этих задач уже на этапе собеседования. А вместе с тем и дать импульс текущим разработчикам освежить свое техническое видение.
Спасибо, нечего и добавить, все так.
Выскажусь в поддержку "системы".
Паззлы, квизы и прочие олимпиадные задачки на собеседованиях имеют смысл (при определенных условиях!), потому что есть положительная корреляция между умением решать такие задачки и общими программистскими навыками. И такая система удобна всем: и кандидату, так как можно просто потренироваться (все такие задачки -- однотипные и в них быстро можно увидеть систему), и интервьюеру, так как можно просто дать человеку задачу и наблюдать за её решением. И хайринг-менеджеру, так как понятны критерии, по которым интервьюер потом выдает рекомендацию. Они так же хорошо сочетаются с "повесточкой", так как минимизируют риски обвинения в той или иной форме предвзятости.
"Поговорить с кандидатом о его опыте" (как альтернатива "квизам") -- звучит хорошо, но не масштабируется, так как предполагает наличие у интервьюера нетривиальных психологических навыков и хорошей интуиции. И тут тоже легко обмануть систему, так как вопросы тут тоже задают типовые и под них можно подготовить типовые ответы.
По моему опыту, лучшем критерием оценки является опыт работы, отраженный в резюме, предполагая, что каких-то особых и редких навыков не потребуется. Поэтому, всё, что нужно проверить -- это то, что кандидат не "врет" в своем резюме. Компании врут о реальных задачах, которые будут решать программисты, а программисты врут своем реальном полученном опыте за тот или иной ременной промежуток. У нас тут это взаимное, да)
В остальном, найм в IT "почти слепой" и связано это с тем, что сейчас у большинства программистов квалификация избыточная для той работы, которую они реально делают. Поэтому надо создать искусственные проблемы, чтобы смена быстро надоевшей работы не казалась таким уж простым делом. Программист должен изрядно побегать и пострадать за новую работу. Работа, которая легко достается, не ценится. Всем удачи в поисках! Джунам -- терпения и всё будет хорошо!
Я много нанимал людей и устраивался на работу сам. В целом со статьей согласен, но на всякий случай продублирую, что все сильно зависит от размера компании. Одно дело, когда тебе надо закрыть 2-3-10 позиций и лид может поговорить с каждым кандидатом "по душам" и другое дело, когда тебе надо закрыть 100 позиций и у тебя тысячи кандидатов.
Для меня вопросы на собеседовании являются лакмусовой бумажкой того, какая команда сидит на той стороне, что за компания и какой там менеджмент. Особенно устраиваясь на более менеджерские позиции это становится критически важно.
Если меня с более чем 10 летним подтвержденным бэкграундом на позицию CTO просят разливать воду по ведрам неподходящего размера, или объяснять отличия абстрактного класса от интерфейса, мы скорее всего заведомо не подходим друг другу.
сам собеседую людей и пробовал ходить на собесы этой зимой. Итог - собесы тупо русская рулетка. Иногда такие вопросы задают, что сидишь и думаешь: "что ты понять-то пытаешься этим вопросом?".
Для себя выделил следующие моменты:
лайвкодинг. мне вообще по барабану, решит кандидат задачу или нет, я смотрю как он мыслит и рассуждает. Умение писать код на собесе никак не кооррелирует с реальной работой.
теория. заученные ответы слушать уже надоело. отвечают правильно, но попросишь привести пример - тишина. Поэтому я задаю вопросы в стиле, а как бы ты сделал это или почему так делать плохо.
в целом стараюсь создать непринужденную атмосферу, чтобы было всем комфортно общаться. Иногда приходится объяснять кандидатам, что это не экзамен.
Рынок опытных кандидатов, которые уже решали какие-то реальные бизнес-задачи. Их бэкграунд-чек несложно проверить звонком/сообщением на прошлую работу
Со всем, что вы описали, согласен. Кроме звонков на прошлую работу.
А если кандидат не хочет говорить, что увольняется, пока не получит оффер? А вы так раз- и слили его.
Но ладно, допустим, кандидат сам разрешил и дал контакты. Что вы сможете проверить? То, что он там работтал? Ну, об этом и так в трудовой написано. А уровень его квалификации все равно не узнаете.
Да и вообще, когда я нанимаю - хочу понять, подходит ли человек, чтобы тянуть со мной проект. Закроет ли текущую потребность. Мнение его бывшего начальника мне ответа на эти вопросы не даст.
Когда нанимаюсь, стараюсь показать, что хочу, умею, и могу решить их бизнес-проблемы.
Прогресса в собеседованиях айти на должность разработчика не будет, еще 10 лет назад брали людей без всяких проблем, они до сих пор делают отличные проекты, сейчас тенденция деградации айти разработчиков, когда кидаешь им статью действительно важную о том как проводить собеседование, они забивают на нее болт, и продолжают заниматься своей неэффективный и абсудрной логикой, одним словом зомби, не понимающие вещей, даже когда обьясняешь как ребенку, принцип такой "1. работодатель всегда прав, 2. если работодатель не прав , читай пункт 1" это огромнейший абсурд что это проявляется на таком мелком этапе как собеседование, но это факт
Их вопросы всегда были про то, как я буду решать их проблемы.
Боже, где найти такие интервью?)
Недавно собеседовался на лидовую позицию, спрашивал у будущего моего руководителя, какие задачи стоят перед командой сейчас и какие главные проблемы на пути этих задач. Не прямо, но около того. Получил ответ - "Это не публичная информация".
Какого черта мы нанимаем, или осмысленность собеседований в IT