Привет Хабр, меня зовут Герман, и я лид разработки, вышедший из фронтов. Сегодня очень хочу обсудить тему культуры собеседований, а точнее тот хаос, что творится на этом поприще и узнать, что об этом думает комьюнити in situ.
Набрел я на такие мысли, когда стал лидом и пришлось много собеседовать людей. Плюсом сюда идет то, что я ради эксперимента и сам проходил собеседования на разные вакансии от мидла до лида (про джуновский уровень - это отдельная песня). Собирал фидбек от коллег и друзей, расспросил, как собеседуют их. И спустя год я обнаружил несколько вещей:
От компании к компании сильно различается уровень собеседований — на одну и ту же вакансию с одинаковой зарплатой.
Зачастую абсолютное непонимание у собеседующих того, что необходимо спрашивать на определенную должность.
Засилье лайфкодинга уровня leetcode easy в ущерб реальным знаниям.
Все эти факторы приводят к тому, что собеседования в 2023 году — это русская рулетка, которая стреляет в ногу как работодателям, так и рынку кандидатов.
Давайте подробнее разберем все это безобразие, и я постараюсь объяснить, почему компаниям/лидам/менеджерам стоит пересмотреть свой подход к найму.
Влияние бигтеха на рынок
В сети ходят легенды о собеседованиях в бигтех компании, на ютубе сотни видосов, как решать задачки всех уровней, для того чтобы попасть на работу в одну из них. И вот я тоже решил сходить на подобный собес синьорного уровня.
7 задач, 3 часа: 3 задачи по js (замыкания, функциональщина, промисы) и 4 алгоритмических (графы, линкед листы, скользящие окна).
Я понимаю, зачем это бигтеху. Лидеры рынка могут позволить себе выбирать, плюс многие из них успешно продают курсы для того, чтобы ты прошел их собеседования. Чего я не понимаю, так это зачем компаниям поменьше перенимать опыт собеседования лидеров рынка? Если и к вам, и к бигтеху попасть одинаково потно, то зачем выбирать вас? Что ВЫ поймете после того, как кандидат нарешал вам уйму задачек/алгосов, но у вас цели переписать легаси код и перейти на PWA стек?
И в итоге на своих публичных собеседованиях бигтех менеджеры на вопрос из зала «А зачем на фронта так много алгоритмов?» отвечают: «А вдруг вам придется огромные JSON нормализировать и денормализовать на клиенте?». Я надеюсь, что это последнее, чем придется заниматься фронту на клиенте. Но суть в том, что других внятных объяснений подобных форматов собеседований у них для нас нет.
Но люди принимают практики больших компаний и, в большинстве случаев, собесы сразу начинаются с окна редактора кода, и после пару слов приветствий идет штурм leetcode based задачек.
И вот тут-то и кроется все коварство данного подхода.
Просмотрев сотни и сотни резюме, держа руку на пульсе «тенденций попадания на первую работу в IT», я своими глазами наблюдаю следующую картину. Молодые люди с накрученным опытом в резюме активно спамят джун+/миддл вакансии в надежде попасть на любителя алгоритмов. И тогда собеседования - это просто своеобразный экзамен с билетами, которые можно зазубрить. И согласно базовой теории игр это выигрышная стратегия. И эти люди находят работу!
Как я лидом устраивался
Мое самое большое удивление за всю мою карьеру, что на джуна и лида многие спрашивают одно и тоже (и в весьма крупных конторах).
Типичный диалог с техническим специалистом:
— Какие бывают значения у свойства position?
— А вот var, let и const чем отличаются?
— Абстрактный класс от интерфейса чем отличается?
— А я простите на какую позицию собеседуюсь?
— Техлид, а что?
И, когда ты идеально отвечаешь на все, то остается немой вопрос: а как люди будут принимать решения, какого кандидата взять? А почему этот человек вообще собеседует меня на такую должность? И чем мне придется там заниматься? К сожалению, это не единичный случай, но, слава богу, нечастый.
Есть и другие крайности, когда HR проводит с тобой 2 собеса (знакомство и скрининг анкетой) и потом по результатам того, что CTO прочитал твою анкету и что-то не понял, HR попросил написать эссе на тему отличия Express от Nest. А ты действующий лид, и все это выглядит как какая-то нездоровая шутка и огромная трата времени.
— Вы мидл? Объясните разницу Jit компиляции в SpiderMonkey и JavaScriptCore
Наверное второй по холиварности тезис при обсуждении собеседований и знаний, которых на них проверяют (после алгоритмов). Избыточность вопросов и требований к экспертности кандидатов на должность, которая этого не требует.
Сколько моих мидлов повалилось на подобных собесах, после которых мы сидели и разбирали эти потрясающие вопросы уровня «Разница работы евент лупа в браузере и в ноде», «Как улучшить SQL запрос если медленно работает» и так далее..
Я понимаю, чего хотят добиться собеседующие, если бы были другие вопросы, но часто собеседование состоит только из того, что собеседующий выстрадал на своем опыте и требует от своих подчиненных. И все мы понимаем, что уровень реальных рабочих задач не такой. Во всяком случае в вакансии о таких вещах не написано ни слова.
Обратная сторона подобных собесов — это вопросы на БАЗУ.
Процитирую Вадима Макеева: у нас есть 2 джава скрипта, один на котором мы пишем, а второй с собеседований.
И черт возьми, вот ЭТУ статью на хабре люди читают только для того, чтобы решать задачи с собесов на выводы консоль логов через промисы. Никто в продакшн коде не будет писать Promise.all с 0. Фибоначчи не фигурирует в топе вопросов на хабркуа или стаковерфлоу.
Если ваш кандидат нереально круто и быстро ответил на вопросы по БАЗЕ, это не значит что он семи пядей во лбу, это значит, что ваше собеседование у него уже десятое.
А что же тогда спросить?
Если у вас есть такой вопрос в голове, то задумайтесь — а нужен ли вам новый человек в команду? Когда ко мне, как к нанимающему менеджеру, приходят с просьбой прособеседовать человека на должность, я сначала спрошу: а чем он должен будет заниматься?
Кратко отмечу, что вопросы для человека, который будет поддерживать легаси и архитектора систем не будут даже пересекаться. Мне правда неинтересно, знает ли крепкий мидл, как разворачивать деревья или как работает ивент луп в деталях, бизнес будет ему платить не за это. То же самое и с синиор+ уровнем, мне неинтересно, насколько у него зеленый гитхаб или сколько лычек в литкоде. Если он не может за час рассказать вкратце, как бы он развернул полноценный PWA и не понял, нужен ли нам SSR для проекта или нет.
Итого
Находясь в профессии какое-то время, мы часто слышим что-то в стиле «кандидатов мало, а достойных еще меньше» или «нормальную работу хрен найдешь». И причиной этому я вижу исключительно в отсутствии культуры собеседований или понимании того ЗАЧЕМ они действительно нужны.
И из-за этого мы имеем два рынка:
Рынок вакансий, которому нужны просто смышленые сотрудники с опытом для конкретных бизнес задач, или джуны у которых есть смекалка не только зубрить БАЗУ, но и делать самую важную джуновскую работу — спрашивать и не бояться. Но большая часть собеседований на эти вакансии проверяет совсем не эти навыки.
Рынок опытных кандидатов, которые уже решали какие-то реальные бизнес-задачи. Их бэкграунд-чек несложно проверить звонком/сообщением на прошлую работу. Но их не спрашивают об опыте, их спрашивают что-то, что придет в голову собеседующему.
И в генеральном случае два этих рынка редко пересекаются. Успех среди кандидатов имеют люди, зубрящие собесы и системно хакающие рынок.
Уважаемые наниматели, лиды, менеджеры! Для вас всегда есть подходящий кандидат (и много, а не 1 из 100), просто спросите его о чем-нибудь другом, о чем-то, что важно вашему бизнесу, а не вашему идеально настроенному линтеру.
P.S. Парадоксально, но самые лучшие собесы у меня были с гендиректорами или управляющими менеджерами, которые не сталкиваются с кодом. Их вопросы всегда были про то, как я буду решать их проблемы.
Комментарии (92)
Suffix0
21.06.2023 13:46+1Я начинающий программист, ищу свою первую работу. Как в итоге мне быть? Получается чтобы найти работу надо сидеть и знать каждую техническую тонкость языка и рекурсировать рекурсию?)
И ещё, в подлинности скриншота не уверен. Неужели человек с большим опытом на Сеньоре реально сидит 2 недели и не понимает чего он делает?
lilkan Автор
21.06.2023 13:46К сожалению эта статья не для начинающих программистов, сейчас рынок устроен так что да, ври про опыт и знай даже не тонкости а просто ~50 однотипных вопросов. Это если хочешь как можно быстрее найти работу и быстро с нее вылететь)
а если хочешь чего-то стабильного то долго ищи и пиши свои пет проектыСкрин к сожалению правдивый, об этом я и сокрушаюсь)
19Zb84
21.06.2023 13:46+2А что с полями то не так ?
mirraim
21.06.2023 13:46Я не фронт, но из контекста можно сделать вывод, что просят два поля, а чел пишет вместо них json-объект с двумя полями
19Zb84
21.06.2023 13:46Ну для пост запроса что то формирует... 2 недели с задачей возится... Здесь дело точно не в запросе, а скорее всего в не правильной постановке задачи или в её отсутствии. Или проект кривой как моя жизнь.
Задачи в паблике надо обсуждать или в джире, а не в личке.
Качество знаний у людей которые обсуждают задачу тоже не факт, что высокие.
А как из себя гераклов в ИТ рисовать все из себя любят дак это часть сферы.lilkan Автор
21.06.2023 13:46+1Когда у тебя зп 300+ у тебя вообще не должно в голове возникать вопроса про "правильность постановки" и молчания в 2 недели, ты уже сам знаешь как надо и что надо.
19Zb84
21.06.2023 13:46Одно дело знать, другое дело работать в команде. Для маленьких контор и каких нибудь стартапов это нормально когда ты с шашкой наголо на встречу задачам и проблемам.
Другое дело достаточно большая компания, которая расчитывает существовать до конца существования России. В таком варианте важно не только сделать задачу, а сделать её в рамках определенной системы. Либо если система не сформированна, проанализировать то, что он делает и придумать какой то рабочий вариант, который устроит команду и внести изменения в рабочий воркфлоу.
Какой здесь вариант приведен не понятно.
Если первый, там скорее всего 300+ не будет зп или человек знает когда дедлайн и может быть решил уделить больше внимания архитектуре. И делал не этот запрос, а может быть переписывал половину сайта в это время.
Если второй вариант, то это вопросы к руководителю проекта.
И вообще работают достаточно часто по спринтам. Максимально длинный спринт я видел 4 недели + дейлики должны проводиться.
Если на одну задачу в спринте уходит 2 недели.
У РП должны возникнуть вопросы в любом случае.
По этому этот диалог в любом случае странный.lilkan Автор
21.06.2023 13:46Вот это вы конечно странно начали отстаивать честь рандомного синьора по скриншоту обсуждения его коллегами) почти борьба с соломенным чучелом получилась.
Вот тут на скриншоте буквально начинают возникать вопросы к человеку с большой зп о его проф пригодности, ибо он спрашивает как работают базовые вещи у мидла)
Все в системе, все знают как и что делать, задача не на 2 недели)
тут 0 подводных камней, просто так тоже бывает)19Zb84
21.06.2023 13:46Ну или так )
Про большую зп в статье вообще ничего не сказанно.
Это тут предположение такое было.
Я с такими фронтами не сталкивался тогда и не могу говорить о том, чего не видел.
Если только сам таким был...Да и то не факт. Первое, что я научился делать это запросы к бэку.
Hardcoin
21.06.2023 13:46+1Компания платит 300+, но нормального поставщика найти не может? Да и сам факт, что человеку со старта дали задачу на 2 недели (или на два часа, но не проверяли две недели) говорит об уровне тимлида в команде. Так что не удивительно, что и на уровень сеньора взяли непрофильного специалиста, который, возможно, даже http-протокол не знает.
lilkan Автор
21.06.2023 13:46Как статья противоречит вашему комментарию?
Да, наняли плохого спеца, провели собес по всем правилам и даже http спросили и получили превосходный ответ))
Тут же прям кристальный пример - вызубрил шаблонное интервью - получил работу.
Автор переписки читал тут это все и может сам наверное подробнее рассказать, не буду за него говорить)Hardcoin
21.06.2023 13:46+1Меня удивил срок. Да, взяли плохого спеца. И если бы он просто не тянул, можно было бы и несколько месяцев не понимать это. Но тут намёк, что он вообще ноль. Просто обманул на собеседовании, но совершенно не в теме работы (если я верно понял посыл статьи).
Кроме проблемы собеседований тут есть и проблема онбординга. Человеку дали задачу и бросили на две недели, он же сеньор. На всякий случай было бы интересно узнать другую сторону. Вдруг там вообще не было ни документации, ни доступа к коду интегрируемого сервиса, названия полей говорили коллеги, при этом неправильно и неохотно (с последним я сталкивался), а сам сервис работал крайне нестабильно?
Конечно, сеньор мог бы свалить из такого ада сразу, но вдруг это его первая попытка выйти на уровень сеньора? Неудачная.
lilkan Автор
21.06.2023 13:46Все так и ваши тейки вполне вписываются в реальность процессов уже после устройства.
Просто стараюсь думать в стройной картине мира, где все стороны отдавали на каждом этапе себе отчет в том что делают. И стараюсь не опускаться на уровень домыслов)
Leetc0deMonkey
21.06.2023 13:46+1А что с полями то не так ?
Это можно максимум за пару часов выяснить методом дебага, гугла и перебора. Что-нибудь да скушается. Можно быть вообще полным 0 в технологии, но всё равно разобраться как правильно.
dsh2dsh
21.06.2023 13:46+1Полностью согласен с Вашей статьёй и ситуацию вижу так же. Всё ещё усугубляется вот этим
рынок устроен так что да, ври про опыт
В результате, врать вынуждены все. Иначе те, кто не будет врать - оказываются в проигрыше.
lilkan Автор
21.06.2023 13:46+1Да, к ситуации где врать - вынужденная мера, приводят ужасные собесы. Менять надо подход к найму в целом, тогда и врать не придется.
kimisa
21.06.2023 13:46+1Тут может быть 2 варианта.
Код проекта очень замудренный, связанный. И на его изучение и правильную доработку нужно очень много времени. Лично сталкивалась с таким, что на погружение в код чтобы понять что-то нужно было 4 дня. А если что-то там изменить, то нужна была неделя, не меньше.
Поверхностно поставленная задача. Для новичков (новых членов команды) все контракты должны были быть описаны и задача подробно расписана.
dsh2dsh
21.06.2023 13:46А вот честно, шут его знает. Я не начинающий программист, с 20+ годами опыта и тем не менее, имею опыт работы проблемы с поиском работы. В том числе и по описанным в статье причинам. Начинающим я могу только в полной мере посочувствовать.
Lex20
21.06.2023 13:46+2Ну я со своими 4 годами ангуляра, годом webgl попробовал недавно поискать работу в Минске. На третьем и четвёртом в моей жизни собесе по js спрашивали вот эту всякую чушь. И тут я понял кого индустрия сейчас набирает, и что работать с такими я точно не хочу. Да ещё сидит по 15 человек на rabota.by, смотрят одновременно одну вакансию, потом в фигме штук 100 тестовое верстают.
Только что проверил, 29 человек одновременно пялятся в вакансию https://hh.ru/vacancy/81797571?from=applicant_recommended. Несчастные 1200 евро. Да лучше пойти коров на ферму доить чем страдать вот этой ерундой.
Не знаю как себя нужно не любить чтобы сейчас искать работу в этой области.
Viacheslav01
21.06.2023 13:46+2Это очередной ответ на вопрос, почему я не собеседую кандидатов, потому, что собеседовать так не могу, а что реально спрашивать у человека, что бы понять кто это реально я не знаю.
Koyanisqatsi
21.06.2023 13:46+1Пусть рассказывает что делал.
Viacheslav01
21.06.2023 13:46+1Судя по тому, как я сам "красочно" рассказываю о том, что делал, сам бы себя на работу не взял )))
Еще нравится вопрос про эпичный провал, фиг знает, что на него отвечать, что такой фейл был я уверен, ну прям точно помню, что как то сильно сел в лужу, но проблема в том, что это было так давно, что подробностей я не помню))) Как собственно и эпичных достижений тоже, все давно слилось просто в поток работы, иногда сложной иногда простой )
Farongy
21.06.2023 13:46Вот про сложную работу и можно поспрашивать. В какую технологию погружался, как она работает.
dsh2dsh
21.06.2023 13:46Вот-вот. Мне кажется, основываясь на том, что бы я спросил самого себя, спрашивать имеет смысл:
Расскажите, с какими сложностями вы столкнулись в предыдущих проектах и каким способом вы их преодолели.
Расскажите, какими решениями из предыдущих проектов вы можете гордиться.
Расскажите о решениях, которые вы вынуждены были использовать в предыдущих проектах и почему они вам не нравились и почему вы, всё таки были вынуждены использовать.
Правда тут возникает проблема, если собеседующий менее опытный, чем кандидат.
Viacheslav01
21.06.2023 13:46Пару раз нарывался на такое в прошлом, в итоге отказ, стойкое ощущение, что либо не поняли о чем я вообще говорю, либо не поверили )))
muturgan
21.06.2023 13:46+2У меня нет решений, которыми я горжусь. Я не блокбастер снимаю а решаю рутинные продуктовые задачи, которые чрезвычайно важны для бизнеса, но совершенно однотипны с технологической точки зрения.
dsh2dsh
21.06.2023 13:46+1И это тоже валидный ответ, на мой взгляд. У кого-то нет таких решений, а у кого-то есть. Всё нормально. Так что Ваш ответ на этот вопрос ничего плохого бы мне не сказал о Вас.
berendiaev
21.06.2023 13:46Если такое спрашивает HR то это вообще мрак. Ощущение что они делают это для отчётности, чтобы передать информацию техническому руководителю (разумеется, исказив до неузнаваемости).
lilkan Автор
21.06.2023 13:46+2Если правда не знаете, то подумайте что кандидат будет делать у вас? какие задачи решать? буквально его фронт работ на ближайшие 3 месяца
Вам же нужен зачем-то новый человек, да?)
Если он уже решал ваши будущие проблемы, или с ходу придумал как их будет решать и в общении приятный - заканчивайте собес и высылайте оффер. Ваши таски он закроет и будет 3 месяца на испыталку.
Или же соотнесите со своим уровнем спросив о проблеме которую вы с командой решали какое-то время и послушайте что он будет вам говорить. Тут уже легче сопоставить ваши уровни и найти "общее мерило" его знаний.
Norgorn
21.06.2023 13:46+1А не пробовали во время работы записывать задачи? У меня иногда возникают моменты, когда вот реальная задача и её хоть сейчас на собеседование (умеренно простая, короткая, изолированная). Правда, я собеседований не провожу, поэтому не записываю, но уверен, что что-то такое должно работать.
IRS
21.06.2023 13:46+2ну вот пройдя ради интереса порядка 30 таких веселых интервью "по списку" с грейдами, я наконец-то сделал выводы и стал спрашивать HR - 1) КТО будет проводить собеседование, 2) СКОЛЬКО обычно собеседование длится и 3) ЧТО у вас соискатели делают на собеседование.
По первому пункту - если слышу туманное "коллеги" - прекращаю разговор. Правильный ответ - ваш будущий руководитель такой-то такой-то.
По второму пункту - если слышу про более полутора часов - прекращаю разговор - или требую оплатить мое время. Правильный ответ - не более часа вашего времени.
По третьему пункту - если там перечень вопросов по грейдам или лайвкодинг - точно так же прекращаю разговор. Если с вами ребята надо попотеть еще, решая задачки - ну платите за это - труд должен быть оплачиваем. Правильный разговор - разговор по прошлым работам и вообще по технике, максимум - ну код показать.
Если не вяжется со всем что описал выше - ну у людей цель - собеседовать кандидатов, сотрудник им не нужен.
Да, как "заваливать" кандидатов я тоже в курсе - простой вопрос - чем арифметическое битовое смещение отличается от логического битого смещения - 100% кандидатов ставит в тупик. И да, это "база". Не врите себе что ее знаете.
senglory
21.06.2023 13:46+3сли там перечень вопросов по грейдам или лайвкодинг - точно так же прекращаю разговор.
Удачи с таким подходом завести трактор. Лайвкодинг сейчас просто мейнстрим для тех, кто вывозит.
IRS
21.06.2023 13:46+1а кто вам сказал, что все мечтают "завести трактор" и свалить за границу? особенно если это будет псевдоиностранная компания с родными рязанскими рожами, которая почему-то не желает нанимать специалистов там на местном рынке? :).
Я ведь правильно понял ваш жаргон? :)
berendiaev
21.06.2023 13:46По прошлым работам тоже можно скрыть некомпетентность, довирая и приукрашивая. Собеседующему трудно понять, насколько всё это правда - если он начнёт слишком душить, то кандидат всегда может сослаться на то, что в памяти не отложилось, а то и в контратаку пойти - мол, чё это вы меня на враньё что ли пытаетесь подловить?
Задачи с литкода, знание теории алгоритмов и т.п. даже поверхностное - это всё-таки знание. То есть чел вероятно даже его применит (написав ужасный нечитаемый кусок кода).
lilkan Автор
21.06.2023 13:46+1Вы как-то статью и не прочитали походу)
Вы проводили собеседования? Если кандидат юлит это видно ну просто моментально, а если идет в контратаку то это сразу скип.
Задачи с литкода и алгосы это не знания а умения, и они ничего не говорят о кандидате кроме того что он сидел их и зубрил. Если кандидат знает дейкстру, но не ответит мне на то когда применять его а когда тарьяна (и где он вообще применял дейкстру) то это не ценность.
Посыл в том, что ищите человека под ваши задачи, а не человека который вам начистит ведро картохи за пол часа или напишет алгос который вам не нужен.
Тут есть и положительный финансовый момент, человек решивший вашу проблему может стоить сильно дешевле человека знающего все алгоритмы мира.berendiaev
21.06.2023 13:46Никогда в жизни не сталкивался со "сразу скип", даже на позициях где я явно не подходил. Это скорее то как вы хотите чтоб было, это не реальность.
lilkan Автор
21.06.2023 13:46Серьезно?
это не реальность когда я заканчиваю интервью после того как человек мне скажет "чё это вы меня на враньё что ли пытаетесь подловить?"
А когда мне заканчивать интервью? когда он начнет по фене ботать или матом орать?)
Да, я хочу чтобы на интервью мне не задавали таких вопросов и делаю все чтобы у кандидата не возникло таких мыслей (в том числе и не пытаюсь его подловить ни на чем) и это и есть РЕАЛЬНОСТЬ.
ZooMMaX
21.06.2023 13:46Спасибо за статью. Прочитал с интересом.
Сам тут попытался найти работу java джуном. В результате две компании, в которых сказали, что резюме и опыт интересные, но в одну я не успел, там уже успели закрыть вакансию, а во второй стартап и им нужен человек с опытом, который сможет вникнуть в суть максимально быстро. Первая компания в Казахстане, а вторая - стартап в РФ. В обоих случаях резюме смотрели директора.
При этом идти по пути "вызубрить билеты" я и не собирался. Я люблю программировать, я учился этому самостоятельно. Как следствие я сделал не стандартное резюме и неспеша ищу работу, попутно развивая свои проекты.
Касательно культуры собеседований - такая проблема наблюдается не только в IT. Я успел много куда поустраиваться и поработать. От грузчика до зам. директора. Почти везде используется шаблонный метод собеседований. И да, когда я дорос до должностей в обязанности которых входил найм сотрудников, я тоже заметил шаблонность и стал строить собеседования сначала с общих вопросов (для понимания что за человек ко мне пришел), а потом вопросы, которые дадут мне возможность понять знает ли как и/или способен ли обучиться человек выполнению должностных обязанностей.
Иначе говоря мне все равно умеет ли человек чинить компьютер, если это не входит в его обязанности, но если в процессе выяснится, что умеет, то это просто дополнительный козырь в его рукаве)
P.S.
Все равно хочу работать в IT.
dsh2dsh
21.06.2023 13:46Если позволите, я бы указал здесь ссылку на обсуждение и статью по той же самой теме: Статья
Странно, что в комментарии не набежали доброхоты, доказывающие, что именно знание конкретного event loop им всё о кандидате и говорит, ведь это же основы.
lilkan Автор
21.06.2023 13:46Спасибо, статья правдивая но весьма эмоциональная и забавно что всего на пару дней назад написана) не мониторю обычно хабр а читаю кучу гневных тиррад в одной соцсети.
Там в комментариях действительно много интересных людей которые заставляют думать на собеседованиях с помощью однотипных задачек. Но и с тейком про плохой вопрос - "опишите структуру" не вполне согласен. Вот такие вопросы как раз и надо задавать. Бизнесу наплевать на понимание сложных нюансов яп, им нужен результат за время и обеспечить дальнейшую поддержку этого результата. И в этом как раз различие вопросов про "(true + true * 5) - 2" и "опишите структуру хайлоада", второй вопрос тоже заставит подумать, а еще и потенциально принесет прибыль.
webaib1
21.06.2023 13:46+7Давно уже пытаемся на собесе просто растопить лёд и потом совместно берём задачи из жиры и делаем ее рефаймент, парное программирование или баг разбираем.
Современное состояние рекрутинга - идиоты набирают идиотов.
exTvr
21.06.2023 13:46+1Современное состояние рекрутинга — идиоты набирают идиотов.
И ведь блестяще справляются с этой непростой задачей!/s
Впрочем, это не только про IT.
lilkan Автор
21.06.2023 13:46+2идиоты набирают идиотов
И к сожалению, они даже защищают такой подход.
dsh2dsh
21.06.2023 13:46+6Вот честно говоря, на мой взгляд, вот это вот онлайновое думанье - так себе штука. Было у меня, показывают экран с кодом и спрашивают, что в нём плохо. У меня от стресса глаза по экрану бегают, ни за что зацепиться не могут. Говорю, ну вот это выглядит странно. Ну вот это при каких-то условиях будет странным. А так, вроде, ничего фатального не замечаю. Наконец мне тыкают пальцем и я восклицаю: ну позвольте, в одном контексте - это плохое, а в других контекстах вообще без разницы, тут всё зависит от деталей, которые мне не известны. Т.ч. в таком вот онлайновом думанье есть минимум две проблемы.
У некоторых людей возникает стресс просто от того, что они находятся рядом с незнакомыми людьми. И кажется мне, что это не является чем-то необычным для программистов. Много среди нас разной степени интравертов и даже в чем-то аутистов.
Всё эти задачи очень субъективны, т.к. у спрашивающего в голове какой-то контекст, а у отвечающего - нет.
webaib1
21.06.2023 13:46-1А на собесе в нормальную команду там все сплошь экстраверты будут сидеть? Да сидят там такие же гики, которые в идеале ищут ответы на многие общие с тобой вопросы, на которых нет однозначных ответов и поговорить на эти темы с человеком, который просто себе их уже задал - это радость, а когда он для себя нашёл какие то ответы - то это праздник и мы сразу это заметим.
Если нет, то это просто не твоя команда. Заползти туда можно, но зачем?
Tvinsen_NSK
21.06.2023 13:46+1У меня с каждой такой статьёй всё сильнее портится настроение и усиливается желание не пытаться поменять работу, а терпеть, лишь бы не начинать собеседоваться...
rosby
21.06.2023 13:46Не стоит этого так сильно бояться, потому что существует также много работадатей, которые объективно оценивают компетентность кандидатов. Как минимум 1 точно есть - автор этой статьи. Да и судя по комментариям тут, многие разделяют это мнение)
AlanRow
21.06.2023 13:46Мда, помню как на первой работе, будучи уже чем-то вроде мидла (четких грейдов там не было, фронтендеров опытнее меня тоже), при поиске человека на позицию джуна, где надо было бы уметь писать просто в меру рабочий говнокод, так жестил при проверке тестового, что теперь аж стыдно. Отчетливо понял я что делал что-то не то, когда начал сам искать новую работу и столкнулся с вариантами тестовых там. Собеседования мне проводить, слава Богу, не довелось...
sshikov
21.06.2023 13:46потрясающие вопросы уровня «Как улучшить SQL запрос если медленно работает»
А что плохого вы увидели в этом вопросе, с учетом того, что вы лид фронтендер (и это как бы вполне может быть за пределами ваших компетенций, и это даже не зазорно не знать всего)?
lilkan Автор
21.06.2023 13:46+1ну как бы вы сами и ответили на свой вопрос, нет?)
Для лидов фронта это еще мб релевантный вопрос, но он задавался ну уровень мидла)sshikov
21.06.2023 13:46Ну, так и что плохого для миддла? Как по мне, миддлу уже пора понимать границы своих компетенций. И я бы принял бы ответ типа "посмотреть план запроса, если нихрена не понял, спросить DBA". Это многое бы мне сказало про человека.
Да, для миддла фронта — конечно странно. Тут вообще зачем SQL?
lilkan Автор
21.06.2023 13:46Ну, так и что плохого для миддла?
Да, для миддла фронта — конечно странно. Тут вообще зачем SQL?
???
Так бы и ответил на вопрос, мол посмотреть сложность запроса (и бизнес необходимость для такой сложности), если сам ничего не понял (ибо писать sql запросы не работа даже лида фронтов) поставить задачу на дба, пусть сделают красиво
но мы говорим про мидла и тут мой тейк простой:
В вакансии указано знание sql? тогда вопросы ожидаемы и понятны
Но вакансия не подразумевала подобных вещей. Если у вас есть возможность задать 20 вопросов кандидату, и вы один тратите на познания человека в SQL - 5% от всех вопросов, а на работе он будет с этим сталкиваться 0,01% времени, то у меня бы как у бизнеса были бы к вам вопросы, зачем?
я еще может спросил бы о творчестве Куприна - это бы тоже многое бы мне сказало про человека)
dkuzminov
21.06.2023 13:46+1я еще может спросил бы о творчестве Куприна
Так и спросите. Это многое расскажет кандидату о собеседующем.
koly86
21.06.2023 13:46Тут можно много написать, и все не так и все не то. Но нужно понимать, айтишники в России живут в том же поле, что и все другие специалисты и к сожалению ситуация такая, что у нас врут все и обо всем. В нашей ситуации ничего другого ожидать и не стоит.
serjeant
21.06.2023 13:46а что такое нормализация и денормализация json? в мире бэкенда в контексте нормализации обычно БД имеют ввиду.
Alexandroppolus
21.06.2023 13:46Да примерно то же самое, как и в БД. Допустим, есть json для объекта comment
{ text: '...', date: 123456789, user: { id: 456, name: '...', ... } }Вот этот юзер из объекта извлекается, кладется в отдельный объект (или хэшмэп) users по id, а в comment вместо user: {...} будет user: 456
В ряде случаев так удобнее.
dkuzminov
21.06.2023 13:46-4Опять двадцать пять... Снова учат работодателей разглядывать таланты.
В книжке "Are you smart enough to work at Google?" (хорошая книжка, рекомендую) описан косвенный вопрос, ответ на который стремится получить интервьюер: "хочу ли я с этим парнем/девушкой выпить пива после работы?" Так вот мне было бы скучно пить пиво с ботаном, чей профессиональный кругозор ограничивается парой фреймворков. Как изрек Козьма Прутков, специалист подобен флюсу. Возможно, во фронтэнде это приветствуется, чтобы человек знал ровно то, что нужно, и на этом его кругозор был ограничен, но в тех областях, где доводилось работать мне, ограниченность кругозора делала человека профнепригодным.
Знания -- это не все. Более того, важнее не сами знания, а умение их получать, и вот тут Leetcode и алгоритмы как нельзя кстати. Все мы в той или иной мере изучали дискретную математику. Все мы знаем, что на интервью будут гонять именно по этой части. И вот она, возможность продемонстрировать, как ты сумел подготовиться к испытанию с заранее очерченной темой. В конце концов, не надо считать, что работодатель окажется внакладе, не сделав вам оффер. Он найдет, кому его сделать, будет руководствоваться неявными и алогичными критериями, но примет на работу того, кто понравился, а не того, кто "правильно ответил на вопросы".
lilkan Автор
21.06.2023 13:46+4Опять двадцать пять... я буквально и есть работодатель который разглядывает таланты)
У вас дальше воспаленное творческое проглядывает на которое даже и хз как отвечать.
Попить пива после работы? Ботан но пара фреймворков? Козьма Прутков?
вы вообще как читали то?
я буквально пишу что узкие собесы на одни и те-же вопросы/алгосы это зло которое хакает рынок и спрашивать надо то что лично вашему проекту важно а вы мне говорите что это расширяет гругозор)
Вот именно что все мы знаем что нас будут спрашивать, и включается синдром егэ, где тем кому это не интересно а интересны реальные вещи в проигрыше перед теми кому интересны только эти узкие задачки)
И реальность такова, что на работе работают на фреймворках, задачи решают не с литкода, а на фронте гораздо важнее знать как сделать красиво и удобно для пользователя и не положить браузер чем уметь в алгосы. И если мне человек ответит на важные для работы вещи лучше чем человек с алгоритмами то я его возьму на работу.
И обычно с людьми умеющими в реальные задачи гораздо приятнее пить пиво чем с 123 хардами с литкода)dkuzminov
21.06.2023 13:46-3Мне совершенно все равно, с кем вы предпочтете пить пиво. А также индифферентно, кого вы возьмете на работу. Но зачем вы пытаетесь всех учить, как им нанимать сотрудников?..
lilkan Автор
21.06.2023 13:46+4Слышали про слово - мнение?)
Зачем Резерфорд сомневался в теории Томсона? Зачем люди сомневались в Эфире? Ну и так далее.
Если вам так "все равно" и "индифферентно" то прошу не переводить свои силы на столь расточительные занятия, спасибо.
kimisa
21.06.2023 13:46Знания алгоритмов нужно, но поверхностное. Чтобы не лепили тройной и тд вложенности циклы и могли на пальцах объяснить почему так делать нельзя.
А то требуют задачки с леткода, а у самих такой код.....
dsh2dsh
21.06.2023 13:46-1В книжке "Are you smart enough to work at Google?"
Ой не нужно ориентироваться на гугл. Ваша компания не гугл и вряд ли когда нибудь будет. Это типичный карго культ. Ну а уж ссылаться, в качестве аргумента, на какую-то книгу, какого-то гугла... Тоже мне, истина в последней инстанции.
dkuzminov
21.06.2023 13:46Я делал референс не на Google, а на книжку, и там не только про него (если не вообще не про него). Вы бы хоть прочитали вначале, прежде чем комментить.
Leetc0deMonkey
21.06.2023 13:46Более того, важнее не сами знания, а умение их получать, и вот тут Leetcode и алгоритмы как нельзя кстати.
Шта? Выдроченный литкод это уже стало "умением получать знания"?
И вот она, возможность продемонстрировать, как ты сумел подготовиться к испытанию с заранее очерченной темой.
Как правило на этом всё и заканчивается. Сидят потом такие макаки, шаг вправо-влево ничего самостоятельно сделать не могут.
dkuzminov
21.06.2023 13:46Никогда не видел собеседования, которое бы заканчивалось на литкоде.
Leetc0deMonkey
21.06.2023 13:46Собеседование не заканчивается. Работать потом эта публика не умеет, от слова совсем. Литкод уже стал скорее антипаттерном: кандидат плохой специалист, его никуда не берут, поэтому у него куча времени и мотивации выдрочить литкод. Сам литкод решается простым запоминанием, а не пониманием каких-то глубинных принципов.
dkuzminov
21.06.2023 13:46-2Повторяю, никогда не видел, чтобы все собеседование только и состояло, что из литкода. Обычно это удел скрининга, позволяющего отсеять тех, кто вообще кода боится. Ну вот в моей недавней практике были два кандидата: первый не знал, что такое указатель в C++, а второй вообще отказался кодировать (типа, он умеет "проблемы решать", а кодируют люди попроще). Я из вежливости потратил час на первого, пытался хоть что-то из него вытянуть, со вторым мы закончили интервью быстрее по обоюдному согласию. И вот зачем оно мне было нужно? Отсеить их простенькой литкодовской задачкой, и тратить время только на тех, с кем есть о чем поговорить.
Leetc0deMonkey
21.06.2023 13:46Отсеить их простенькой литкодовской задачкой, и тратить время только на тех, с кем есть о чем поговорить.
Проблема в том что осеятся и годные спецы. И чем они годнее, тем меньше у них резона заниматься всей это хренью.
Чтобы отсеять, достаточно взять резюме и пообщаться с кандидатом по проектам. В процессе диалога уже сразу становится понятно в теме ли человек. На этом собес можно и заканчивать, на самом-то деле.dkuzminov
21.06.2023 13:46-1Не знаю, может, у вас во фронтенде и есть "годные спецы", не умеющие решить простенькую литкодовскую задачку (в чем я сильно сомневаюсь), но я не разу не видел таких в бэкенде. Зато настрадался от обратного: от говнокодеров с высоким ЧСВ, которые плохо понимают, что и зачем они делают, и лишь увеличивают энтропию. И да, литкод им не по силам, и потому они зовут его хренью.
Leetc0deMonkey
21.06.2023 13:46но я не разу не видел таких в бэкенде.
Так они к вам не приходят, вот вы их и не видите.
dom1n1k
21.06.2023 13:46+1Есть более-менее общепринятое мнение, что в найме ошибки второго рода гораздо больнее, чем первого. То есть упустить хорошего кандидата более приемлемо, чем взять плохого.
ruslan-smirnov
21.06.2023 13:46Ни прибавить, ни убавить. Абсолютно все те же мысли после 50+ созвонов
Femistoklov
21.06.2023 13:46Дело вовсе не в том, что мало кто умеет использовать сложные мыслительные процессы, анализировать, применять научный подход, проверить гипотезы, провести эксперименты, собрать статистику, при этом сделав всё правильно и избежав ошибок. И по результатам улучшить свой процесс найма. Люди не тупые, они умные и всё это в той или иной степени умеют, в т. ч. и ваши собеседующие постоянно применяют это в своей работе, когда программируют. А вот чтобы везде применять - такой привычки попросту нет. Как в анекдоте про прапорщика, который сразу идёт трясти дерево с бананом. Надо нанять человека - так, вот примеры задачек из инета, вот резюме почитать, вот интересный вопрос из моего опыта - идём
трястисобеседовать. Про то, чтобы сделать мини-исследование, как вы, многие даже не задумаются, а многие посчитают ненужным. И этот тимлид перед вами, который спрашивает про абстрактные классы - он просто не понимает, что плохо подготовился, плохо изучил кадровые потребности, потратил мало времени, недостаточно продумал процесс собеседования, не прокачал свой навык собеседовать, в конце концов.lilkan Автор
21.06.2023 13:46Все так, статья про то и есть, что лучше бы людям подсобраться. Иначе чет не очень предчувствия у меня(
Str5Uts
21.06.2023 13:46Надо проводить собеседование так, чтобы сначала отфильтровать неадекватных кандидатов — т.е. там где враньё в резюме, обман в опыте, заученные правильные ответы из опыта предыдущих интервью.
Лично мой способ:
-
Я прошу напротив каждой из технологий в его резюме и которые релевантны для нашей позиции поставить оценку её знания по 5-ти бальной системе.
-
Даю листок с кодом (~ 50 строк простого кода) из нашего реального проекта, в который умышленно добавлены штук десять плохих ошибок (не синтаксических или типа пропущена запятая) и прошу рассказать что с этим кодом не так. Разработчик читает код сильно чаще чем пишет, атк что чтение чужого кода очень важный навык.
-
Для всех найденых ошибок прошу объяснить — почему это плохо так делать и как это исправить.
-
Разговариваем по трём технологиям из резюме которые получили наивысшие оценки.
Работает замечательно, сразу видно всё как на ладони.
Может быть есть разработчики которые хороши, но плохо проходят интервью с подобным подходом, но это ок. Есть много компаний с другими подходами в собеседовании и они в конце концов найдут себе позицию.
Ещё кстати совет, перед тем как проводить интервью, надо просмотреть видео от каналов типа "компани экспер".
Будет видно кто начинает тебе задвигать по методике.
dom1n1k
21.06.2023 13:46+1Уметь находить ошибки в чужом коде и не допускать их в своем — сильно разный уровень квалификации. Первому можно научиться по книжке, а для второго необходим ещё и опыт.
Str5Uts
21.06.2023 13:46Для целей интервью — чтение и объяснение его гораздо луче, потому что за 30 минут ты не напишешь много кода и многие не любят это делать в стрессовом состоянии — прочитать же, на порядок легче и таким образом можно анализировать гораздо более сложный код.
-
lebedec
21.06.2023 13:46+5Когда ко мне, как к нанимающему менеджеру, приходят с просьбой прособеседовать человека на должность, я сначала спрошу: а чем он должен будет заниматься?
Последнее время практикую именно такой подход. Задаю вопросы по опыту кандидата в контексте предстоящих бизнес задач. Ключевые преимущества, на мой взгляд, следующие.
Комфортный диалог
Стресс улетучивается, кандидат открывается как только понимает что он не на экзамене, а на совместном обсуждении причин для сотрудничества.
Вообще получается что модель типичного собеседования “я оцениваю тебя” превращается в “мы обсуждаем что можем сделать вместе”. Это начинает больше походить на диалог потенциальных партнеров, поэтому кандидат проявляет больше заинтересованности и инициативы.
Вы точно поймете уровень кандидата
Прикол в том, что вы уже реально работаете вместе, выполняя первый этап любой задачи – её обсуждение.
Если обсуждение развивается, вопросы кандидата вам кажутся подходящими, предложения не вызывают сомнений – значит вы сработаетесь. Разве не это настоящая цель любого собеседования?
Если интервьюер не может отличить заученные слова кандидата от реального опыта, не может понять корректность и применимость технической экспертизы – то как он у вас работает вне собеседований на реальных задачах? Это уже проблема квалификации интервьюера, а не кандидата.
Кандидат получает ответы на свои вопросы
Вспомните насколько абсурдным иногда бывает техническое интервью: после нескольких часов абстрактных ребусов и задач, кандидату дают всего 5-10 минут на вопросы о реальном положении дел в компании, ещё и ответить внятно не могут некоторые.
Кандидат сможет сразу понять и оценить устройство вашей технической кухни, сможет сопоставить ваши требования и ожидания к собственной экспертизе, если вы ясно обозначите какие задачи хотите решать и почему.
Польза тут ещё в том, что вы уменьшаете риск ухода нового разработчика на период адаптации, потому что сразу решаете проблему несоответствия ожидания и реальности. Во всяком случае, я убежден, что это одна из самых частых причин: когда на техническом собеседовании компания Лев Толстой, а не деле формошлёп простой.
Решает проблему законсервированности текущих решений
Одна из проблем любой команды – это замыкание технической экспертизы на мнение текущих разработчиков. Кроме инертности и устаревания технических решений это приводит ещё и к проблеме найма. Разработчиков со свежим взглядом часто отфильтровывают не актуальными техническими вопросами.
Но если обсуждать реальные задачи, кандидат может на основе своего опыта предложить лучшее решение этих задач уже на этапе собеседования. А вместе с тем и дать импульс текущим разработчикам освежить свое техническое видение.
Psychiatrist
21.06.2023 13:46+1Выскажусь в поддержку "системы".
Паззлы, квизы и прочие олимпиадные задачки на собеседованиях имеют смысл (при определенных условиях!), потому что есть положительная корреляция между умением решать такие задачки и общими программистскими навыками. И такая система удобна всем: и кандидату, так как можно просто потренироваться (все такие задачки -- однотипные и в них быстро можно увидеть систему), и интервьюеру, так как можно просто дать человеку задачу и наблюдать за её решением. И хайринг-менеджеру, так как понятны критерии, по которым интервьюер потом выдает рекомендацию. Они так же хорошо сочетаются с "повесточкой", так как минимизируют риски обвинения в той или иной форме предвзятости.
"Поговорить с кандидатом о его опыте" (как альтернатива "квизам") -- звучит хорошо, но не масштабируется, так как предполагает наличие у интервьюера нетривиальных психологических навыков и хорошей интуиции. И тут тоже легко обмануть систему, так как вопросы тут тоже задают типовые и под них можно подготовить типовые ответы.
По моему опыту, лучшем критерием оценки является опыт работы, отраженный в резюме, предполагая, что каких-то особых и редких навыков не потребуется. Поэтому, всё, что нужно проверить -- это то, что кандидат не "врет" в своем резюме. Компании врут о реальных задачах, которые будут решать программисты, а программисты врут своем реальном полученном опыте за тот или иной ременной промежуток. У нас тут это взаимное, да)
В остальном, найм в IT "почти слепой" и связано это с тем, что сейчас у большинства программистов квалификация избыточная для той работы, которую они реально делают. Поэтому надо создать искусственные проблемы, чтобы смена быстро надоевшей работы не казалась таким уж простым делом. Программист должен изрядно побегать и пострадать за новую работу. Работа, которая легко достается, не ценится. Всем удачи в поисках! Джунам -- терпения и всё будет хорошо!
hlogeon
21.06.2023 13:46Я много нанимал людей и устраивался на работу сам. В целом со статьей согласен, но на всякий случай продублирую, что все сильно зависит от размера компании. Одно дело, когда тебе надо закрыть 2-3-10 позиций и лид может поговорить с каждым кандидатом "по душам" и другое дело, когда тебе надо закрыть 100 позиций и у тебя тысячи кандидатов.
Для меня вопросы на собеседовании являются лакмусовой бумажкой того, какая команда сидит на той стороне, что за компания и какой там менеджмент. Особенно устраиваясь на более менеджерские позиции это становится критически важно.
Если меня с более чем 10 летним подтвержденным бэкграундом на позицию CTO просят разливать воду по ведрам неподходящего размера, или объяснять отличия абстрактного класса от интерфейса, мы скорее всего заведомо не подходим друг другу.
Kostas2509
21.06.2023 13:46сам собеседую людей и пробовал ходить на собесы этой зимой. Итог - собесы тупо русская рулетка. Иногда такие вопросы задают, что сидишь и думаешь: "что ты понять-то пытаешься этим вопросом?".
Для себя выделил следующие моменты:
лайвкодинг. мне вообще по барабану, решит кандидат задачу или нет, я смотрю как он мыслит и рассуждает. Умение писать код на собесе никак не кооррелирует с реальной работой.
-
теория. заученные ответы слушать уже надоело. отвечают правильно, но попросишь привести пример - тишина. Поэтому я задаю вопросы в стиле, а как бы ты сделал это или почему так делать плохо.
в целом стараюсь создать непринужденную атмосферу, чтобы было всем комфортно общаться. Иногда приходится объяснять кандидатам, что это не экзамен.
Gradiens
21.06.2023 13:46Рынок опытных кандидатов, которые уже решали какие-то реальные бизнес-задачи. Их бэкграунд-чек несложно проверить звонком/сообщением на прошлую работу
Со всем, что вы описали, согласен. Кроме звонков на прошлую работу.
А если кандидат не хочет говорить, что увольняется, пока не получит оффер? А вы так раз- и слили его.
Но ладно, допустим, кандидат сам разрешил и дал контакты. Что вы сможете проверить? То, что он там работтал? Ну, об этом и так в трудовой написано. А уровень его квалификации все равно не узнаете.
Да и вообще, когда я нанимаю - хочу понять, подходит ли человек, чтобы тянуть со мной проект. Закроет ли текущую потребность. Мнение его бывшего начальника мне ответа на эти вопросы не даст.
Когда нанимаюсь, стараюсь показать, что хочу, умею, и могу решить их бизнес-проблемы.
lebedec
Последнее время практикую именно такой подход. Задаю вопросы по опыту кандидата в контексте предстоящих бизнес задач. Ключевые преимущества, на мой взгляд, следующие.
Комфортный диалог
Стресс улетучивается, кандидат открывается как только понимает что он не на экзамене, а на совместном обсуждении причин для сотрудничества.
Вообще получается что модель типичного собеседования “я оцениваю тебя” превращается в “мы обсуждаем что можем сделать вместе”. Это начинает больше походить на диалог потенциальных партнеров, поэтому кандидат проявляет больше заинтересованности и инициативы.
Вы точно поймете уровень кандидата
Прикол в том, что вы уже реально работаете вместе, выполняя первый этап любой задачи – её обсуждение.
Если обсуждение развивается, вопросы кандидата вам кажутся подходящими, предложения не вызывают сомнений – значит вы сработаетесь. Разве не это настоящая цель любого собеседования?
Если интервьюер не может отличить заученные слова кандидата от реального опыта, не может понять корректность и применимость технической экспертизы – то как он у вас работает вне собеседований на реальных задачах? Это уже проблема квалификации интервьюера, а не кандидата.
Кандидат получает ответы на свои вопросы
Вспомните насколько абсурдным иногда бывает техническое интервью: после нескольких часов абстрактных ребусов и задач, кандидату дают всего 5-10 минут на вопросы о реальном положении дел в компании, ещё и ответить внятно не могут некоторые.
Кандидат сможет сразу понять и оценить устройство вашей технической кухни, сможет сопоставить ваши требования и ожидания к собственной экспертизе, если вы ясно обозначите какие задачи хотите решать и почему.
Польза тут ещё в том, что вы уменьшаете риск ухода нового разработчика на период адаптации, потому что сразу решаете проблему несоответствия ожидания и реальности. Во всяком случае, я убежден, что это одна из самых частых причин: когда на техническом собеседовании компания Лев Толстой, а не деле формошлёп простой.
Решает проблему законсервированности текущих решений
Одна из проблем любой команды – это замыкание технической экспертизы на мнение текущих разработчиков. Кроме инертности и устаревания технических решений это приводит ещё и к проблеме найма. Разработчиков со свежим взглядом часто отфильтровывают не актуальными техническими вопросами.
Но если обсуждать реальные задачи, кандидат может на основе своего опыта предложить лучшее решение этих задач уже на этапе собеседования. А вместе с тем и дать импульс текущим разработчикам освежить свое техническое видение.