Почему нет смысла готовиться к собеседованию

Дефицит специалистов становится все заметнее. В связи с этим и внимание к теме поиска и найма сотрудников значительно выросло. Стало появляться много публикаций на эту тему и обсуждений в социальных сетях. Часто упоминается такое понятие, как «подготовка к собеседованию». О нем бы я хотел поговорить подробнее. Точнее, высказать довольно неожиданную и, скорее всего, непопулярную мысль о том, что подготовка к собеседованию не нужна.

Так вышло, что разработкой и различными ІТ-проектами я занимаюсь уже более десяти лет. За это время мне пришлось поработать на разных позициях и в разном формате. Я был и разработчиком, и тимлидом, и архитектором, и консультантом. Выступал как в роли наемного сотрудника, так и собственника. Я проходил собеседования и сам собеседовал других инженеров, я помогал подбирать команды для клиентов и искал людей к себе на проекты.

Сразу уточню, что говорить я буду о собеседованиях и найме исключительно технических специалистов. Более того, речь идет о найме специалистов с опытом, а не тех, кто хочет получить свою первую работу.

Опыт, который всегда с тобой

Для многих инженеров, с которыми я общался, собеседованию практически всегда предшествует этап подготовки, когда специалист за день-два старается вспомнить все то, что он успешно забыл на текущем месте работы, выучить определения, которыми он не пользовался с момента прошлого собеседования, и зазубрить ответы на вопросы о том, почему люки круглые и зачем курица перешла дорогу. Ближайшей аналогией такого процесса можно назвать подготовку спортсмена к соревнованиям, когда он старается прийти в свою лучшую форму. И как спортсмен на соревнованиях, так и специалист на собеседовании, хочет показать свой лучший результат. Казалось бы, правильная и благородная цель!

Вот только как ни один спортсмен не может находиться на пике своей формы постоянно, так и технический специалист. Можно долго тренироваться и в один прекрасный день пробежать стометровку за десять секунд, но перемещаться каждый день с такой скорость никто не сможет. Поэтому, если смотреть с точки зрения интервьюера, я считаю, что подготовка к собеседованию не имеет смысла.

Когда я собеседую человека, мне хочется видеть его не подготовленным и зазубрившим наизусть ответы на типичные вопросы. Я хочу понимать то, как кандидат мыслит, какой у него реальный опыт.

Если же смотреть с точки зрения кандидата, то я тоже не вижу смысла в подготовке. Мои знания и опыт всегда со мной. Я готов рассказать о них, поделиться примерами своих решений. Но если для интервьюера важнее то, помню я или нет определение трех его любимых аббревиатур, то ему нужен не я, ему нужен другой специалист.

Диалог или экзамен?

Кстати, сама идея того, что к собеседованию необходимо готовиться, что-то заучивать, повторять, связана еще и с тем, что часто технические собеседования проходят в формате своеобразного экзамена. Часто интервьюер считает, что он подловил кандидата на незнании чего-то или на неправильном ответе. Я сейчас не хочу углубляться в причины этого (они могут быть разными), хочу лишь отметить тот факт, что подобный формат собеседования я также не считаю правильным.

Исходя из вышеперечисленного, хочу высказать мнение, что лучшим форматом собеседования я считаю беседу. Это не просто однокоренные слова, в моем понимании собеседование должно быть именно беседой двух равных людей. В отличие от собеседования, проходящего в формате «экзамена», у собеседования в формате диалога есть несколько преимуществ.

Любое собеседование является для человека стрессом. Даже опытный и толковый специалист может не очень уютно себя чувствовать в момент прохождения интервью. Когда кандидата заваливают шаблонными вопросами из базовой (или пусть даже не очень базовой) теории, а он волнуется и находится в напряжении, то даже ответы на вопросы, которые он точно знает — может банально забыть. При этом в другой, более спокойной обстановке такой человек вполне мог бы продемонстрировать отличный уровень своих знаний.

Еще один момент, который может сыграть злую шутку уже с интервьюером — кандидат может оказаться гораздо компетентнее того, кто его собеседует. И в этом случае некомфортно себя будет чувствовать уже интервьюер. Ведь изначальный формат предполагает то, что он априори владеет вопросом лучше. Это, в свою очередь, может привести к тому, что интервьюер попытается доказать самому себе, что он не хуже, а то и лучше, и в итоге собеседование превратиться и вовсе в своеобразное соревнование «кто здесь умнее».

Не нужно строить деревянные самолеты

Ситуация, которую мне иногда приходилось наблюдать — когда интервьюер, не очень понимая, как и для чего он собеседует человека, пытался копировать подходы крупных компаний, задавая вопросы про количество шариков в автобусе, форму люков и так далее. Зачастую такой подход похож на карго-культ, когда островитяне из кокосов и пальм строили взлетно-посадочные полосы и делали самолеты, ожидая, что на их «аэродромы» начнут приземляться настоящие самолеты.

С одной стороны, мне понятны мотивы интервьюеров, которые так делают — не имея собственного опыта, они стараются применить опыт чужой. И в первую очередь смотрят на то, как это делают лидеры рынка — Microsoft, Apple, Google и другие. Вот только повторение чужих действий без понимания того, почему и для чего эти действия были совершены — это уже признак магического мышления, которое, как это ни печально, все же свойственно даже инженерам.

Если у вас нет опыта проведения собеседований — не стоит пытаться копировать опыт крупных компаний. Скорее всего, он вам будет просто вреден, так как причины, по которым в этих компаниях собеседования происходят именно так, вам не известны. Результат тоже будет абсолютно другим. А ваша компания может упустить толкового специалиста. Если не знаете, как проводить собеседование, если у вас нет в этом опыта, но так сложилось, что вы должны провести интервью — просто начните общаться.

Дайте возможность кандидату рассказать свою историю

Когда собеседование изначально построено как диалог двух равных специалистов, которые присматриваются друг к другу, а их основная цель — оценить возможность плодотворного сотрудничество в будущем — то атмосфера будет совершенно другая. При этом кандидат сможет максимально раскрыть себя как специалиста.

Тут может возникнуть вопрос, если не проводить экзамен, не задавать кандидату вопросы из списка, то как понять, кто перед тобой? Лично мое мнение, что лучший способ — это пройтись вместе с кандидатом по его карьерной истории. Я уверен, что хороший специалист (причем даже независимо от сферы своей деятельности) без всякой подготовки сможет интересно и подробно рассказать о том, чем он занимался, с какими проблемами во время своей работы сталкивался, как их решал и, главное, почему был выбран тот или иной путь решения. Это позволит понять ход мысли человека, оценить, с чем реально он работал и насколько его предыдущий опыт пересекается с тем, с чем ему придется иметь дело в новой компании.

В ходе беседы всегда можно задавать уточняющие вопросы и давать новые вводные, меняя условия задачи и предлагая кандидату подумать над тем, выбрал бы он то же самое решение или другое, исходя из предложенных интервьюером вариаций. Это, в свою очередь, поможет оценить подходы кандидата к решению задач.

Почему это важно? Возьмем простой и слегка утрированный пример. Кандидат может не помнить расшифровки аббревиатуры SOLID, но при этом во время обсуждения того, каким образом он бы спроектировал классы для описания бизнес-логики, он мог бы продемонстрировать прекрасные навыки проектирования, определения базовых сущностей предметной области и выделения абстракций.

Нет смысла просить разработчика в деталях рассказать о том, как работает сборщик мусора, тем более, если на вашем проекте эти знания не нужны на столь высоком уровне. Лучше опишите несколько проблем и посмотрите, какой вариант решения предложит кандидат. К подобным вопросам нельзя подготовиться за день-два. Подготовкой для ответа на подобные вопросы является весь карьерный путь человека.

Главное в собеседовании — нанять хорошего специалиста, а не специалиста проходить собеседования. Зачастую — это разные люди.

👍ПодобаєтьсяСподобалось40
До обраногоВ обраному12
LinkedIn

Найкращі коментарі пропустити

готовиться к собеседованию, определенно, надо, но не перед самим собеседованием, а все время

Очень здравое видение, спасибо.

Еще (как-то писала уже об этом) помимо беседы, имхо лучшая проверка знания специалиста по какой-то технологии — это не лайв кодинг, когда от стресса кандидат забывает как зовут родную маму... И не тестовое, когда за кандидата его может сделать кто угодно и еще время на проверку надо убить. А прямо на собеседовании дать человеку кусок кода из проекта, чтоб он рассказал, как это работает, зачем это надо, и (задача со звездочкой), как это можно улучшить\оптимизировать\исправить. Удивляюсь, почему это не распространено (всего один раз за карьеру такое давали), но это ж убивает прямо нескольких зайцев:

1. Кандидат успокаивается и ощущает себя равноправным участником переговоров, а не под лампой у товарища майора, как на лайв кодинге.

2. Вы сразу видите, как он мыслит и сразу понимаете, насколько глубоко он знает предметную область. Причем, даже если конкретный фреймворк для него новый, то, если у него есть опыт с подобными решениями, но на других технологиях\языках, все равно будет понятно, как он въезжает.

3. Станет ясно, насколько его видение совпадает с видением команды на проекте (если собеседуете middle+ и выше) .

4. Кандидат может сам подсказать интересные идеи интервьюеру, которые можно использовать, даже если не сложится сотрудничество.

5. Появляется чуть более ясное понимание об общей адекватности персонажа :)

Будь-ласка, не готуйтесь, та закрийте собі дорогу в купу компаній які наслідують карго-культ та задрочують кандидатів дурнуватими питаннями по алгоритмам.

Готуватися не потрібно лише тим хто не ставить собі задачу збільшити шанси знайти роботу.

Для всіх інших готуватися треба, а поради ваші шкідливі.

Согласен с автором. Более того, как соискатель, когда я ощущаю, что собеседующий специалист упарывается в «точность знаний в терминах» over «представление, как это работает на пальцах», то для меня это звоночек, что я ошибся дверью.

Почему есть смысл готовиться к собеседованиям: потому что в 80% вас будут собеседовать люди, которые ожидают от вас ответов из «100500 вопросов для собеседования», причем ответы будут сравниваться не по понимаю, а лексикографически.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ну в Украине на интервью (да и не только) действительно карго-культ, автор это точно подметил, насчет остального можно местами подискутировать, но лень

Кажется, я тебя в твиттере видел, классный аккаунт!

Нету на рынке ни какого аврала. Пока требования к уборщице на складе: до 30 лет, английский б2, 10+ лет опыта уборщицой в английском посольстве или 10 лет опыта главным технологом на производстве пылесосов(опыт оператора снегоуборочной машины приветствуется).
Это все фикция.
15 лет назад, я пришол на собес в СЦ, и тыкнув пальцем в ящик с коробками комплектухи предложил вместо вопросов из темника собрать комп.
Сейчас, без ЦЦНП и МСМВП и резюме не шли, а на проверку, пара комутаторов старше секретарши директора и пяток тазиков с 2008, и одинесом.

Замечания автору:
Разберется ли человек как приготовить(повторить) борщ, если до этого он его только ел? Или обязателен опыт в пузатой хате посудомойщиком?😃
Как вы считаете, если у трактора снять отвал и ковш и прицепить прицеп на штатное место — повезет? Или если до этого не возил, значит не стоит и пробовать?🙈

Как относитесь к выражению: Любой иногородний по умолчанию очень высокой квалификации. (тут перефразируем: иногородний => знающий *заморский* язык)?

Неверная аналогия — верный путь к заблуждению.

«Если все пройдет круто, то я чертов гений.
А если плохо, то..
..я же не готовился» © Марк Мэрон

Уже полгода в мыслях крутилась идея написать статью на эту тему. Автору лайк за попытку изменить подход в индустрии к собеседованиям. Если интервьюверы перестанут задрачивать кандидатов, то и сам процесс в итоге станет более приятным и непринужденным.

А че к интервью готовиться, если компании в стартер паке даже символичное весло не выдают.
dou.ua/...​me-and-farewell-packages

Не згоден з автором, знову ж виходячи зі свого досвіду. Справа не в SOLID, і в ООП. Перш за все підготовка до співбесіди це:

1) Прочитати про компанію, куди ви хочете піти і про проект. Якщо ви це не робите, це відразу дзвіночок для рекрутера, а чи варто вас брати, якщо вам взагалі все одно куди йти, і ні проект, ні компанія для вас значення не має
2) Переглянути своє резюме, освіжити інформацію про своїх роботодавців і проекти/технології (особливо старi). Щоб не було такого, що вас запитують про якийсь проект, а говорите, що не пам’ятаєте, що це було.
3) Продумати, які питання ви хочете задати інтерв’юеру, що вам цікаво дізнатися про майбутню роботу. Якщо у вас немає ніяких питань, то це знову ж привід задуматися, наскільки серйозні ваші наміри.

дзвіночок для рекрутера,

вы, похоже, LinkedIn-ом не пользуетесь. Скоро рекрутеры начнут похищать миддл+ разработчиков на улице, всучивать им +500 ЗП без вопросов и привязывать к весло-месту... А не звоночки отмечать для себя.

Да уж, плач стоит по всем направлениям

А как зафиксировали? А то я парень стеснительный, не готов (не хочу) офферами размахивать, а райз хочется.

1) Прочитати про компанію, куди ви хочете піти і про проект. Якщо ви це не робите, це відразу дзвіночок для рекрутера, а чи варто вас брати, якщо вам взагалі все одно куди йти, і ні проект, ні компанія для вас значення не має

 Та куча вакансий \ линкедин спама в стиле «требуеться работник работать работу». А если контора аутсорс — то что там читать вообще ? Отзывы на доу?

3) Продумати, які питання ви хочете задати інтерв’юеру, що вам цікаво дізнатися про майбутню роботу.

 эт полезно, не забыть спросить про отпуск, про удаленку, про больничные, про бонусы, и про переработки. Причем надо спрашивать все это не у ХР и не у менеджера, а у технического собеседующего, чтобы понимать насколько тебе врет ХР.

В статье под подготовкой к собеседованию понимается как раз подготовка к техническим вопросам. Об это четко написано.

Речь об украинских аутсорс компаниях ?
Если джун-мидл, то подготавливаться определенно нужно, ибо шансы у джуна и так малы.
А если синьйор ? Я б не парился.

Кстати моя старая-же фраза:
Когда я приходил на собесы подготовленный, и отвечал уверенно то получал почемуто отказы.
Почти все мои оферы, я получал приходия на собес чутли не с бодуна, и местами неся какуюто ахинею.

switch (position) {
case «programmist»: daem_pisat_kod()
case «pizdabol»: vedem_besedu()
}

Все больше интервьюеров начинают выполнять этот простой алгоритм. Кандидату можно не готовиться к интервью, если он/она готовы к такому развитию событий.

Why bother to be a 110%,
85% is good enough.

Для таких интервьюиверов, которые устраивают «экзамен» нужно также готовить ответные вопросы.
Ведь как никак условно «мне» придется с ним работать и нужно удостовериться, что он знает основы основ, алгоритмы.

Это приведёт либо к увеличению продолжительности, либо к отказу потому что долгих кандидатов не все жалуют. А из якобы полезного можно узнать что интервьюер шарит или не шарит, что ровным счётом ничего не говорит об остальной компании

Так есть время для встречных вопросов. Чего бы его не использовать?

Готовиться надо, особенно кандидату. Когда-то я интервьюировала людей в люксофт к своему кастомеру, на позицию миддла требовали основы SQL, а в рамках интервью проверяли эту самую базу, хоть на проекте он нужен на уровне SELECT *, что можно нагуглить за 5 минут. Цель тут не проверить знания, а отсеять ленивых, которые видя требования на позицию, забьют болт и не удосужатся потратить на изучение/повторение азов хоть полчаса.

Цель тут не проверить знания, а отсеять ленивых

Вот уже по этой фразе понятно, что с подходом к найму все плохо. Есть даже шутка такая, что инженер должен быть ленивым — тогда он всегда будет искать способы автоматизации рутины и повышения эффективности своей работы. А в каждой штука, как известно, есть доля практики.

То, что на кандидату на позицию задают вопросы, которые практически не имеют отношения к тому, с чем придется иметь дело на проекте — это уже второй маркер того, что все плохо.

Почему нет смысла готовиться к собеседованию

Епам нервно закурил в стороне

Почему на собеседованиях никто не дает коротенький тест на IQ, минут на 20?
Как показывает жизнь, практически всегда человек с более высоким IQ (например 120-130) сможет намного быстрее разобраться в чем-то новом для него, чем человек среднего ума.
И такой кандидат, даже если чего-то не знает (на момент собеседования) сможет в этом разобраться (если это концепция) или просто загуглить/запомнить (если это определение термина/факт).

1. IQ тест задрочити ще легше, ніж літкод. Літкод і є таким-собі IQ тестом.
2. IQ тест може показаті інтелект не в тому, в чому треба.
3. Вміння розбиратись у новому — не є тим, що треба. Десь цього треба більше, десь менше, для когось цього треба більше, для когось менше. Інші фактори можуть грати набагато більшу роль.
4. Є фактор стресу співбесіди, що інтелект падає по різному. Я от вважаю, що треба наливати кандидатам десь 200-400 грам на початку співбесіди (на вагу треба розраховувати). Стресу не буде, побазікати за життя буде легше, інтелект буде приблизно однаково падати в усіх. Нажаль, важко налити по зуму.

Я от вважаю, що треба наливати кандидатам десь 200-400 грам на початку співбесіди (на вагу треба розраховувати). Стресу не буде, побазікати за життя буде легше, інтелект буде приблизно однаково падати в усіх. Нажаль, важко налити по зуму.

Мабуть вам буде цікаво глянути фільм Ще по одній. Там декілька друзів, що працюють в одній школі викладачами різних предметів, вирішили перевірити гіпотезу: «Людині не вистачає алкоголю в крові, він повинен бути на рівні 0.5 проміле».

Взагалі то не важко спрогнозувати результат, але схоже ви думаєте по-іншому.

Ее, мені ліньки буде дивитись. Я не за те, що кодити треба забуханим. Я за те, що на співбесіді цей метод вигляда не гірше за інші і може мати перелічені переваги! І мені здається ви не це адресували. Але зауваження по суті вітаються!

в далекому 2004 саме так на роботу й приймали в одну харківську геймдев контору, приходиш, наливають, спілкуються, й одразу видно — мудак не мудак. досвіду тоді небагато було у всіх, та й всіх хто хоч щось знав було теж небагато, а от людей гарних було мало.
досі вважаю що то був найкращий коллектив, шкода що контора та не "взлетіла)

Раньше в компании, где я работал, перед всякими собесами был тест на IQ на 20 минут. Щас уже всё. Некогда тестировать на IQ.

Парадокс теста на IQ состоит в том, что человек с высоким IQ не будет тратить время на прохождение этого теста.

Хз, мне было всегда лестно читать в результатах что я гений, но для работы в айти.... Где средний iq около 50... оч странно...

Где средний iq около 50... оч странно...

Вважається, що IQ нижче 70 балів — це розумова відсталість.

знаю таких которые дают:) и мне кажется, что это очень правильно

Тому що ІТ — це все-таки робота з людьми, і тут потрібен ще й емоційний інтелект (soft skills), а не тільки високий IQ

Если в данный момент времени компании для найма сотрудников выдвигают формальные критерии знания терминов, принципов работы GC и умения решать алгоритмические задачки; и по данным формальным критериям решают брать или не брать, какую ЗП предлагать, то сори, я буду готовиться как только могу. Я хочу работать в классных компаниях и за хорошую ЗП.

К сожалению это никак не коррелирует

Не згоден, що готуватись до співбесіди не потрібно, але згоден, що інтерв’юеру потрібно бути більш лояльним до незнання так званих академічних термінів.

В далекому 2008 році, коли я тільки «увійшов в ІТ», оці усі терміни про інкапсуляцію, про SOLID, KISS, DRY і т.д. я не просто зазубрив, а я розумів їх. Але на протязі 13 років своєї кар’єри я їх позабував, бо ними досить рідко оперують на практиці, тобто в технічних завданнях чи документаціях.

Звичайно ж, це не означає, що наприклад SOLID чи KISS стали неактуальними, просто для мене ці принципи вже стали практичними правилами, які я постійно впроваджую. З іншого боку, я вже досить давно проходив співбесіду і усі ці академічні терміни от прямо зараз не готовий розшифровувати.

В далекому 2008 році, коли я тільки «увійшов в ІТ», оці усі терміни про інкапсуляцію, про SOLID, KISS, DRY і т.д. я не просто зазубрив, а я розумів їх. Але на протязі 13 років своєї кар’єри я їх позабував, бо ними досить рідко оперують на практиці, тобто в технічних завданнях чи документаціях.

а я за 11 не позабывал ничего, тут отношение важно, а не время

Абсолютно усе забувається, що не використовується, не залежно від «відношення до цього» (як ви кажете). Якщо ви не забули ці терміни, значить ви когось вчите, або ж періодично читаєте теоретичну літературу (яку, як правило, читають джуни).

нет и нет, я просто разработкой занимаюсь, она на всем этом построена, хз как можно забыть то, на чем вся работа основана

Наведіть конкретний приклад, пліз. Де ви читаєте ТЗ чи певну документацію із цими термінами? Дуже рідко ці терміни справді зустрічаються, але щоб... Хоча можливо в .NET це не те саме, що у TypeScript or JavaScript, or PHP світі.

самих терминов нет, но эти принципы основа построения приложения

Принципи так, терміни — не завжди. Я он проходжуся по черговій компетенс-моделі і там є купа термінів, які я не знаю (всілякі антипаттерни і т.п.). Якщо загуглити — очевидні речі, але тут залежить що хоче почути людина, яка проводить інтерв’ю

Сьогодні кум розказав як його, спеціаліста senior SQL адміна, рівня ентерпрайз заставили на інтерв’ю виконувати якісь задачки і він з 5 тільки три встиг зробити під наглядом інтерв’ ювера.
А я кажу — на твоєму рівні треба добре подумати, гарно все обмислити, підготувати рішення, 7 раз перепровірити, два протестувати і тоді запустити виконання.
Це не так треба оцінювати. Причому він саме з тих, хто перепровірить кілька разів перш ніж запустити виконання скриптів, чи зміни вносити.
Тому погоджусь з автором

Насправді правда десь посередині :)

Але нажаль дуже часто люди коли читають такі статті відчувають «о! Це супер-вірно! Я теж так думаю!» тільки тому, що це... легше. Легше думати «любить мене таким яким я є» ніж взяти свою дупу і вийти з зони комфорту.

В жодній компанії, а тим більше в жодному проекті немає повного спектру технологій (і це нормально!). І ймовірність того, що в іншій компанії будуть потрібні точно ті знання, які використовувались останні 10-15 років дуже мала... (Окрім випадків коли приходять люди і говорять «тааак, тут все фігня, потрібно все переписати і я знаю як!)

Готуватись потрібно. Я знаю деяких моїх колег в Гуглі, які готувались до співбесіди при переведенні з однієї команди в іншу. Не тому, що вони глупі або диктатори в новій команді, а тому що просто там трохи інші специфіка, а нам платять гроші не за те, що ми вчимося, а за те що ми робимо ефективно свою роботу.

А сказати «нічого не потрібно робити» дуже легко.

Легше думати «любить мене таким яким я є» ніж взяти свою дупу і вийти з зони комфорту.

Співбесіда — аж ніяк не зона комфорту.

Перестать готовиться к собеседованию надо тогда когда они эти собеседования Вам начинают сниться.Вам еще не снились собеседования?А экзамены?Если нет тогда продолжайте готовьтесь!)))

Готуватись треба якшо хочеш збільшити вибірку компаній і, відповідно, шанс отримати вигіднішу фінансову пропозицію.

Можна не готуватися якщо для вас важливо знати, що інтервювер відбирає по принципу «нам треба кандидата, з яким прикольно буде працювати». Це дуже класний підхід, але компаній, де є така філософія відбору дуже небагато, тому це більше валідно для пасивного пошуку роботи.

проект из Швейцарии предложили вакансию. зп 20к евро в месяц

Для проектов онсайт — это нормальный средний рейт (1к/день), как для Швейцарии.

Для удалёнки, таки редкостъ (пока).

Вакансію в студію! Можна в приват)
Обіцяю пляшку Dom Perignon якщо наймуть))

Где искать такие предложения?

Будь-ласка, не готуйтесь, та закрийте собі дорогу в купу компаній які наслідують карго-культ та задрочують кандидатів дурнуватими питаннями по алгоритмам.

Готуватися не потрібно лише тим хто не ставить собі задачу збільшити шанси знайти роботу.

Для всіх інших готуватися треба, а поради ваші шкідливі.

Жизненный опыт говорит, что если в компании наследуют карго-культ и задрачивают кандидатов, то внутри такой компании полный п...ц извините меня за мой френцузский. В лучшие места в которых я работал я попадал по собеседованию без подготовки. Это был просто «матч фром ферст аттемпт». Там же где надо было готовиться к передовым практикам собеседований — внутри был полнейший ад и содомия. Как по мне, собеседование с подготовкой это как знакомство на карнавале, все расфуфыренные, разрисованные макияжем, в красивых костюмах взятых на прокат. А потом когда костюмы и макияж снят... ))) Ахтунг))

никогда не готовился.
как кандидат читаю про компанию и ее бизнес перед собесом, как интервьюер читаю резюме и стараюсь понять что за кандидат и как построить собес для него

І як успіхи? Скільки офферів вже отримали?

Да у меня вообще в те редкие случаи когда я ищу работу и хожу по рынку ( не часто это происходит) где — то 70% собесов заканчиваются оферами.

Ніколи не готуюсь до співбесід.
Вважаю це поганим тоном.
Щось на зразок того, як обманювати працедавця.

Ніколи не готуюсь до співбесід.
Вважаю це поганим тоном.
Щось на зразок того, як обманювати працедавця.

Ну тогда, отправляясь на свидание с дамой, следить, чтоб носки и трусы были приличными и без дырок, а также контролировать, побрит ли, пострижен и не воняешь, тоже не надо :)

А уж со стороны девушек все усилия по улучшению внешности (макияж, одежда, скрывающая недостатки) — вовсе преступление!

P.S. Честно говоря, я к собесам специально тоже практически никогда не готовилась. Просто лень, и перед смертью не надышишься.

а если носки с трусами приличные каждый день, как и ежедневные гигиенические процедуры? :-)

Литкод задачки ежедневно, без специальной цели к собеседованию, тоже некоторые решают :)

к сожалению их слишком мало что бы ежедневно решать

Щось на зразок того, як обманювати працедавця.

Только если говорить, что с чем-то работал или что-то делал, чего на самом деле не было. Иначе в чём обман-то? Или на работе ничего не гуглим и доки не читаем, всё сходу пишем?) Но Вы вряд ли это считаете «обманом работодателя»).

готовиться к собеседованию, определенно, надо, но не перед самим собеседованием, а все время

и это приводит к постоянному напряжению и выгоранию

Я тогда, получается, исключение

Якщо для вас постійне навчання — це стрес, то можливо, що ІТ — це не для вас

Вроде логично, но я бы все-таки посоветовал уделить алгоритмам и структурам данных хотя бы пару часов (а лучше дней) перед важным собеседованием. В повседневной работе это редко используется поэтому легко подзабыть. Это из моего опыта работы в двух FAANG-ах, YMMV.
.

Маю три контраргументи чому готуватись потрібно які випливають з вашої статті:
1.

Часто интервьюер считает, что он подловил кандидата на незнании чего-то или на неправильном ответе. Я сейчас не хочу углубляться в причины этого (они могут быть разными), хочу лишь отметить тот факт, что подобный формат собеседования я также не считаю правильным.

Так в тому ж і вся «прєлєсть», що переважна більшість компанія, я б навіть сказав майже всі, проводять такий формат співбесід.
Більше того компанії типу Епама чи СС мають ексель табличку з питаннями які інтерв’юєр заповнює в процесі співбесіди. Чистої води екзамен.
2. Дуже багато технічних спеціалістів не можуть оцінити рівень кандидати по його кар’єрній розповіді, та й це об’єктивно важче і більше шансу на помилку. Окрім того, рідко інженер працює один, як правило, це команда. А по розповіді визначити саме його вклад в командну роботу дуже важко.
А оцінити знання патернів, досвід з багатопоточністю, знання ООП і коли який механізм застосувати — це вже набагато легше оцінити і дати заключення.
3. Дуже мало кандидатів можуть чітко і зрозуміло описати свою кар’єру і свої досягнення.
Причини різні: Від банальної поганої вимови через яку людина соромиться говорити, надмірного вживання слів-паразитів(короче, тута, дааа, блін, йопта і т.д.) і до психологічних аспектів типу синдрома самозванця.
Навіть досвідчений інтерв’юєр почне нервуватися якщо кандидат буде часто запинатися, невнятно говорити і це нервування не дозволить об’єктивно оцінити кандидата.

Моя позиця така: Чи потрібно задавати технічні питання? — Так. Чи варто питати про попередній досвід, досягнення і т.д? — Так. Але це повинна бути збалансована бесіда, в ідеалі 50/50, коли людина описала якийсь цікавий досвід і ви по ньому задали 2-3 релевантних технічних запитання і пішли далі.

Отже, чи варто готуватись до співбесід? — Однозначно так. Варто освіжити в пам’яті основні аспекти вашого стеку, варто проговорити основні досягнення у вашій кар’єрі. Ідеально, вміти це розказати як вашою рідною мовою так і англійською, тому що з великою ймовірністю, у вас буде співбесіда із англомовним замовником.

Відокремлено стоїть тема вирішення задачок на інтерв’ю.
Вирішення задач — це скілл, який до того ж досить швидко встрачається. Так. ви будете пам’ятати, що у хеш-таблиці константна складність операцій, у BST логарифмічна, а у ліста лінійна, але вирішення конкретних задачок забудеться досить швидко.
Якщо компанія куди ви йдете практикує такі задачі( а це майже всі каліфорнійські + частина європейських) то готуватись однозначно варто, до того ж витратити на підготовку не години, а дні чи навіть тижні.

я б навіть сказав майже всі,

На щастя, це не так)
Я, до речі, суб’єктивно помітив деяку кореляцію між віком інтерв’юера і трешем на співбесіді. Вчорашні студенти 20ти річні синьйори справді влаштовують екзамен. Спеціаліст з 10+ річним досвідом більше питає по суті проекта і дивиться на те, як кандидат підходить до вирішення проблем.

Вчорашні студенти 20ти річні синьйори справді влаштовують екзамен

лол-точно

Ну хз-хз, декілька разів зустрічав немолодих пердунів 50+ які приходять і очікують, що будеш шарити все з чим він зустрічався за 30 років і періодично видають фрази в стилі «Як таке можна не знати!!».
Самоствердження в чистому вигляді.

Є адекватні молодчики, а є старічки, які так і не набрались мудрості за все життя.

Вчорашні студенти 20ти річні синьйори справді влаштовують екзамен

вот не всегда, есть еще такая категория как — вчерашние преподаватели

Більше того компанії типу Епама чи СС мають ексель табличку з питаннями які інтерв’юєр заповнює в процесі співбесіди. Чистої води екзамен.

Вот поэтому большинство топовых специалистов, с которыми я общаюсь, даже не рассматривают предложения от Епам — они просто уходят в спам.

Окрім того, рідко інженер працює один, як правило, це команда. А по розповіді визначити саме його вклад в командну роботу дуже важко.

А не нужно оценивать именно его вклад. Нужно оценивать то, понимает ли человек, почему то, или иное решение было принято. Какие у решения достоинства и недостатки, может ли он подобрать оптимальное решение, если в ходе беседы будут изменены условия. Это главное. А не то, кто конкретно в команде написал ту, или иную строку кода. Если даже он посмотрел, как что-то сделал его коллега, понял это, изучил и сможет применить в дальнейшем — то это уже отлично.

Дуже мало кандидатів можуть чітко і зрозуміло описати свою кар’єру і свої досягнення.

Как раз таки даже закоренелому интроверту куда проще рассказать о том, чем он конкретно занимался на своем проекте, чем пытаться вспомнить перечень порождающих паттернов. При этом информация о том, чем он занимался и что умеет будет полезна. А то, помнит он названия паттернов, или нет — не говорит вообще ничего о его профессиональных навыках.

Когда будут собеседовать кандидата, то интервьюверы скорей всего будут идти по матрице, матрица состоит из тематических блоков, оватывающих фундаментальные основы той или иной области. Умея отвечать на вопросы из competency matrix кандидат демонстрирует наличие фундаментальных знаний в этой области. Это значительно отличается от кусочно-дробного знания, полученного на предыдущих проектах.
Поэтому готовиться надо.

матрица состоит из тематических блоков, оватывающих фундаментальные основы той или иной области
...
Поэтому готовиться надо.

Уж к чему, к чему — а к экзамену на понимание фундаментальных основ, готовиться перед собеседованием точно не нужно. Т.к. это понимание не появится за пару дней (или даже недель) подготовки, если его нет.

Где я написал что на подготовку уйдет пару дней?

Обычно, «подготовка к собеседованию» — это то, что делается между получением приглашения на собеседование и собеседованием. Сейчас непременно хотят собеседовать, как можно быстрее (т.е. времени такого пару дней). Но даже в спокойные вермена — максимум времени будет, недели 2.

к экзамену на понимание фундаментальных основ, готовиться перед собеседованием точно не нужно

А полуостров Индостан-то и не знает такой истины в граните :)

Почему есть смысл готовиться к собеседованиям: потому что в 80% вас будут собеседовать люди, которые ожидают от вас ответов из «100500 вопросов для собеседования», причем ответы будут сравниваться не по понимаю, а лексикографически.

Якщо робота не треба, то можна встати і вийти)
Більше того, можна навіть не приходити %)))

Я прошу стільки, щоб стало треба. Інакше нафіга ходити?

Если человек не умеет проводить собеседования, это еще не значит что он плохой спец/коллега/тимлид. Аналогично как если человек не умеет их проходить.

чудова стаття. дякую. збігається з моїм власним уявленням процесу співбесіди.

Со многим согласен, но с основным посылом — нет). Пример:
1. Я работал с Кубером (любой другой список технологий) и хочу поработать ещё, но могу забыть детали. При этом часто забываю нюансы способов, как «подружить» нод с подом, хотя сам же своими руками это делал.
2. Собеседующий спрашивает этот вопрос -> я круто отвечаю на него и другие подобные, с которыми сталкивался в реальности, потому что не поленился их повторить -> ... -> мне дают оффер (реальный случай... хотя в итоге я принял другой оффер, но тем не менее :) ). Спросить нюансы реального использования — это же и есть самый верный способ проверить, с чем работал человек, и обсудить это. Без нюансов можно просто прочитать статью и нарассказывать про космические корабли на просторах вселенной, что сразу будет видно. И именно нюансы забываются со временем.

И ведь это всего один такой вопрос, а ведь их же много. Дали бы мне оффер, если бы я на всё забил и отвечал в духе «можно taints + tolerations, можно labels + node selectors, а как оно там в деталях, я уже не помню» на все подобные вопросы, вопрос открытый. Поэтому не совсем понимаю, зачем самого себя подставлять и уменьшать шансы. Другое дело, если соискателю всё равно, куда идти, или компания непритязательна к тех стеку (у нас второго практически не бывает).

«Нет смысла просить разработчика в деталях рассказать о том, как работает сборщик мусора» — не согласен. Если человек не интересуется как это всё работает под капотом, что такое jit и оптимизации компилятора, то высока вероятность, что он просто пишет код и не стремится к саморазвитию, да и скорее всего просто мразь.

да и скорее всего просто мразь

Серйозна заява, але шось в цьому все ж є.

да и скорее всего просто мразь.

Anton Bocharov, CIO, co-Founder в IntelSoft Technologies
Дякую за камінгаут, додав до свого списку.

записываешь людей, которые могут что-то немножко грубое сказать?

Да, с такими людьми неприятно общаться

Вова, оглянись назад, ты себе позволял более жесткие выражения в сторону других

он просто пишет код и не стремится к саморазвитию

Тебе работать, или саморазвиваться?

просто мразь.

А за такие фразочки можно и пойти умыться после разбитого носа

А есть упоротые на саморазвитии кедры, которые тычут это всем, как главный недостаток. Потому что не знают, что у людей в свободное время бывают и другие интересы, кроме как код задротить.

Степа, в твоих словах говорит обида, но мы оба знаем, что я прав. Развивайся, читай, смотри исходники мастеров на гите, да прибудет с тобой любовь, брат

Вова, хватит в интернетах руками махать да носы разбивать, диванный вояка. Ты глубже копни, и поймёшь глубокую истину написанного мною — она не должна быть сладкой. Я провел сотни собеседований и знаю о чем пишу

Да нафиг мне твоя глубина, если скорее всего это глубина заблуждений. На работу люди приходят работать — менять труд на деньги. Саморазвитие тут при чем?

я бы не называл саморазвитием знание основ того с чем работаешь...

По твоему получается, что простой таксист должен знать как чинить двигатель. Только нафига, если для этого есть слесарь, а он лучше вместо починки возьмёт ещё пару заказов?

и кто же этот слесарь, который должен знать как сборщик мусора работает?

Тот, чья специализация — высоконагруженные приложения, очевидно.

у тебя слишком мелкая градация для программистов

У меня вообще бинарная: платят, или нет?

платят, если знаешь про сборку мусора

Угу, конечно. Например, когда нужно писать бизнесс-логику быстро

работает себе и работает. вот когда будет просадка по перфомансу, и будет ясно что дело именно в латентности GC (а не в кривой схеме БД или переусложненных запросах SQL), тогда и нужно копать. проблемы надо решать по мере их поступления, тем более когда используется аджайл где главное фичу выкатить удовлетворяющую MVP

проблемы надо решать по мере их поступления

на опыты в поликлинику бы сдавал всех тех, кто умышленно допускает проблемы и потом пытается их решить. Задача руководителя проекта не допускать проблемы. А там где качество не надо, а только скорость вообще не вижу смысла проводить собеседования, чем меньше человек знает, тем быстрее он копрокодит

на опыты в поликлинику бы сдавал всех тех, кто умышленно допускает проблемы и потом пытается их решить.

Ну вот я решал реальные проблемы, где требовалось понимание GC. Поэтому мне интересно, какие проблемы можно решить заранее, зная, как он работает? Желательно пример из жизни (и я не про мелочи вроде правильного использования IDisposable, естественно). А именно «мы сделали вот так, потому что знали, как работает GC, и это решило проблему X, которая бы возникла в будущем, если бы это писал кто-то другой, не знающий GC под капотом, а не мы».

Если человек не интересуется как это всё работает под капотом, что такое jit и оптимизации компилятора, то высока вероятность, что он просто пишет код и не стремится к саморазвитию, да и скорее всего просто мразь.

Читал об этом до того как вообще получил оффер на трейни, после этого оно мне нафиг не нужно было и забылось. Или такой вариант для Вас отстутствует?

Дима, ты абсолютно прав и неправ одновременно. Ты туда не лезешь, так как оно работает, его создали мастера и ты им веришь. Но разве ты не хочешь достичь того же уровня мастерства и начать хотя бы с понимания того как всё устроено?
Иначе ты просто пользователь...

каждый программист пользователь чего-нибудь, нет смысла изобретать заново операционные системы, языки программирования и стандартные библиотеки (если это не твоя непосредственная профессия — написание ОС и языков)

Изобретать заново точно не стоит, а вот понимать как оно работает порой просто необходимо. Я не пишу механизм индексирования в sql, но должен понимать принцип работы. Так же и со сборкой мусора

эта фигня тоже все время меняется. в Java 11 появился ZGC а они все еще про mark-and-sweep спрашивают

Кстати, заметил такую закономерность: если тебя спросили про сборщик мусора, то вопросов про алгоритмы и структуры данных не жди.
Почему так?

Вот держи.
Как посчитать x^y, где y положительное целое число. Какова сложность алгоритма в о-нотации?

Как посчитать x^y, где y положительное целое число. Какова сложность алгоритма в о-нотации?

Соответствующая функция — есть практически в любом API и гуглится в 2 счёта.

Если такой функции нет — в 99.99% решений достаточно умножить число x в цикле (y — 1) раз.

Соответственно, зачем такие странные вопросы? Что они должны сказать о соискателе?

Скорее, такие вопросы — многое говорят квалифицированому соискателю o таком странном интервьювере и этой загадочной конторе.

ну любой нормальный мидл и выше знает на это ответ, целесообразность, действительно, под вопросом, кроме технического образования о человеке это ничего не говорит. я такое встречал когда позиция интервьюера была ниже, чем потенциального кандидата, просто от не знания что спрашивать вылетают странные свежепогугленные вопросы, которые мало что показывают. в целом правильные вопросы должны что-то прояснять

Открою секрет — навыки алгоритмизации не зависят от синьёрити. Тут не нужен многолетний опыт и знание фреймворков — это проверка на образное мышление и способность применять нестандартные подходы.
Если ты думаешь, что эта задача решается проходом цикла n-1, то собеседование ты провалил.
:)

Ты удивишься, но практически для всего есть готовые решения и библиотеки.
Оставим лирику и вернёмся к задаче

достаточно умножить число x в цикле (y — 1) раз

отлично, вот мы подходим к алгоритмизации. Это что называется — решение в лоб.
Можно ли оптимизировать количество шагов? Например в 2 раза?)

Что-то подобное встречал на литкоде
Можно рекурсивно, сложность O(2^lgy) что лучше O(y), правда стек забивает

Тут нужно вспомнить математику за 10-й класс
если y = a*b, то x^y = (x^a) ^ b
Если степень y — чётное число, его можно представить как кратное 2,
тогда x ^ y = (x ^ 2) ^ (y/2)
Таким образом мы в 2 раза уменьшим количество итераций.
(для нечётного просто делаем тоже самое с y-1 и ещё раз домножаем на х)
сложность такого подхода O(log y)

так и итеравтивно легко кодиться, так что со стеклом все впорядке.

Я писал про рекурсивный вариант, но я там в расчетах сложности ошибку сделал, а так при О(logy) можно забить на стековерфлоу
При итеративном варианте стек не забивается

Можно ли оптимизировать количество шагов? Например в 2 раза?)

Можно. Но зачем? В 99.99% — в твоих задачах это не нужно.

А тех, кто на проекте изобретает ненужые велосипеды (включая и с подобными оптимизациями), вместо использования стандартных решений — хорошо бы с проектов просто гнать.
Т.к. от их недоделанных и недотестированных велосипедов (а как правило, они именно такие) — больше проблем, чем пользы.

Видимо нужно пояснить для особо одарённых — это алгоритмическая задача на нестандартное мышление, в чистом виде у неё нет практического применения (равно как и задача с шариками и автобус у гугла).

В 99.99% — в твоих задачах это не нужно.

Статистика опять с потолка?
Ты написал самый примитивный вариант решения задачи брутфорсом и защищаешь его.
Включи воображение — а если при каждой итерации у нас будет обращение к диску, оптимизировать тоже «нинужна»?
Скорее всего ты пилишь какой-то унылый легаси код на своей невесёлой работке, где всем на всё плевать. Удачи тебе)

Ты написал самый примитивный вариант решения задачи брутфорсом и защищаешь его.

Я защищаю не это решение, а «cоответствующая функция — есть практически в любом API и гуглится в 2 счёта.»

Если какой-то оригинал использует на проекте, вместо стандартной функции API, свою велосипедую реализацию — гнать с проекта. За самые примитивные собственные брут-форс реализации, гнать тоже.

Ну, на самом деле для программиста ничего нестандартного тут нет, метод используется во многих случаях, далеко не только в функции возведения в степень, это базовые вещи. Другое дело, когда на интервью спрашивают узкоспециализированные вопросы, и не на предмет посмотреть как думает человек, а на предмет скорее завалить кандидата. Вопрос о сборщике мусора — он как раз из этой категории. Если ты сам писал сборщик мусора, сможешь ответить, если же нет, то наверное нет. Такого рода вопросы правильно задавать «как бы вы написали сборщик мусора» и дать человеку какое-то время подумать, минут десять. Вот такой подход я поддерживаю, а завалить человека при желании можно всегда.

алгоритмическая задача на нестандартное мышление, в чистом виде у неё нет практического применения (равно как и задача с шариками и автобус у гугла)

Це значить, що ви, як інтерв’ювер не змогли знайти відповідну задачу. Гугол відмовився від автобуса із кульками вже. Конкретно ця задача є особливо нікчемною навіть серед літкодівських. Якщо Х є числом із плаваючою комою, то, скоріше за все, стандартна функція, що працює через логарифм та експоненту є не тільки більш швидкою але і більш точною, тому що менше операцій робиться. Якщо Х є цілим фіксованого розміру — то проблем із швидкістю у «брутфорса» не буде, тому що кількість операцій множення буде обмеженою, щоб воно не вилізло за макс. значення. Задача може мати сенс тільки для bigint X. І от тільки якщо ви наймаєте працювати із якоюсь кріптографією, де бувають такі обчислення — її можна давати.

Быстрое возведение в степень, работает за lgy.... Так что не все так однозначно...

это ж то, которое еще называют бинарным и требует памяти на мемоизацию?
ох, как бы я офигел, встретив это в реальном коде

Очень хорошая статья, спасибо

Более того, речь идет о найме специалистов с опытом

От синьора, баблоносными заказчиками ожидаются хорошие рекомендации с прошлых проектов. Т.к. брать чела и платить ему до 1к/день просто по резюме — это получить кота в мешке. Даже если этот кот вызубрил наизусть весь API.

Если нет рекомендаций, тестовые задачи могут помочь в оценке — но выявят лишь умение чела решать примитивные/локальные проблемы. Но не помогут понять, чего от чела ожидать на сложном проекте, где придётся постоянно решать такие проблемы в течении полугода/года.

Собеседование типа экзамена, для синьоров действительно не имеет смысла.

Стоп — а зазубрить 5 букв солида и чем интерфейс от абстрактного класса отличается? Без этого никуда!

Тільки заради подібного іноді готуюся

YAGNI дуже добре підходить для розробки не дуже великих продуктів по Agile, але не всі продукти такі.

А Солід досить часто конфліктує сам із собою на практиці.

В принципе, SOLID не входит в противоречие с YAGNI/KISS — т.к. SOLID не регламентирует необходимости в овер-инжиниринге.

С другой стороны, при разрастании проекта — чел оказывается в ситуации, когда ему приходится достигать SOLID (например, «S» для избежания нарушений DRY) . Но делать это приходится уже на крупном продакшн коде, разрывая его с ошмётками мяса и большим оверхедом на тестирование именно этого рефакторинга.
А всё из-за того, что не придерживался SOLID изначально.

например, «S» для избежания нарушений DRY

как связаны single responsibility и повторение кода? Иди читай теорию, ошмётки мяса у него летают )))

как связаны single responsibility и повторение кода?

Связаны достаточно очевидно. Если какая-то функция или там класс, содержит внутри себя реализацию нескольких responsibilities, а в другом коде нужна лишь 1 из них — варианта у тебя 2:

— копи-пэйст кодa реализации responsibility (нарушение DRY)
— выделение реализации responsibility в отдельную функцию/класс — и использование в обоих местах

Чтобы реиспользовать в первоначальном месте — понадобится рефакторинг существующего кода, со всем вытекающим оверхедом.

В общем, продолжай писать собственные «велосипедные» реализации x^y — возможно, это твой потолок.

А если у меня хороший, правильный метод с одной responsibility, но в другом месте мне надо чтоб он работал чуть иначе — та же проблема. Можно копипастить, а можно рефакторить (через наследования, добавление параметров и тд)
В итоге, «для избежания нарушений DRY» нужно иметь мозг, а не «s» из солида
Поэтому, не позорься, мой юный друг, а читай книги, читай Фаулера, Макконела и других.
И тогда ты будешь знать, что целью single responsibility является «причина для изменений» и она должна быть только одна)

А если у меня хороший, правильный метод с одной responsibility, но в другом месте мне надо чтоб он работал чуть иначе — та же проблема. Можно копипастить, а можно рефакторить (через наследования, добавление параметров и тд)

Я привёл пример с тем, как при неправильном применении YAGNI/KISS — приходится с дополнительными издержками возвращаться к SOLID, при пренебрежении «S».
И разжевал этот пример для тебя — т.к. ты демонстрируешь явное непонимание элементарных вещей.

Это хорошо, что ты имеешь представление об иных проблемах в коде. Подучи, что означают остальные буквы в SOLID, посмотри на паттерны проектирования и (главное!) перестаь говнокодить велосипеды на своих проектах, вместо использования стандартных функций. И может даже станeшь неплохим миддлом.

Я не знаю твоего имени, но хочу попросить у тебя прощения...
Прости меня за то, что так сильно ущемил твоё эго этой простенькой алгоритмической задачкой, которая всё не даёт тебе покоя (даже в ветке про solid).
Вероятно ты действительно никогда не писал ни своих библиотек, ни алгоритмов и как я предположил — просто тихонько пилишь старенький легаси проект, поддерживая чужой код, и тебе за это платят. Это же отлично! Главное что ты доволен.
Я не учёл, что далеко не всем это нужно, да и не всем дано.
Мой опыт проведения собеседований (как на прошлых работах, так и сейчас уже в свою компанию) убеждает меня, что креативное, образное мышление это маст-хэв на новых проектах, однако на поддержке старого кода люди с таким мышлением быстро выгорают.
И ты со своей стороны прав — тебе не нужно много думать, не нужно ничего оптимизировать... Надо будет — напишешь ещё один вариант брутфоса. Будет работать медленно, но выполнит свою задачу. Главное, чтоб заказчик был доволен)
Вот честно, не хотел, извини ;)

Прости меня за то, что так сильно ущемил твоё эго этой простенькой алгоритмической задачкой, которая всё не даёт тебе покоя (даже в ветке про solid).

Ты влез в ветку про СОЛИД с какой-то ахинеей, типа «как связаны single responsibility и повторение кода? Иди читай теорию». При этом, проблемы у меня. :)
Детсад, да и только.

П.С. Что касается твоих задачек — ещё раз: за велосипеденье функций API на проекте — отправлять в детсад. Т.к. от таких велосипедистов и вашего недо-кода — на реальном проекте пользы 0, зато вреда полно.

Прости, ты глупый?
1. Тебе на пальцах объяснили, single responsibility создан не для защиты от копипасты, а для уменьшения количества потенциальных изменений. A class should have only one reason to change. Robert C. Martin. Что ж так туго доходят такие простые вещи)
2. Ну и в 20-й раз (давай может тебе татуху на лоб с этим текстом?) — задачка, которая тебя так задела, это тест на образное мышление, не для применения в коде))
Разговор себя исчерпал, не вижу смысла дальше отвечать 👋

Похоже, у тебя проблемы с пониманием прочитанного.
1. Я ничего не писал о том, для чего нужен «single responsibility principle». Лишъ о том, как пренебрежение «S» из SOLID (из-за злоупотребления YAGNI/KISS) — ведёт к последующим проблемам, например с DRY.
2. Я тебе и задал вопрос: нафига такие задачки — если они не имеют ничего общего с тем, что нужно в реальном проекте? Вместо ответа, ты упорно несёшь какую-то ахинею, про «образное мышление» или «креативное мышление».

паттерн стратегия или template method

ни ягни, ни солид не конфликтуют с солидом. делай просто != делай абы как

У мене одна рекрутерка намагалася витягнути щорічний звіт починаючи з першого рядка коду, який я продав за гроші. А я їх уже і не пам’ятаю. Як згадаю — аж здригнуся.

— А чому пішли з останнього місця роботи?
— ...
— Ні, ну, а все ж таки?

Не подобається ІТ і її правила? Завжди є робота на найближчій заправці

Очень здравое видение, спасибо.

Еще (как-то писала уже об этом) помимо беседы, имхо лучшая проверка знания специалиста по какой-то технологии — это не лайв кодинг, когда от стресса кандидат забывает как зовут родную маму... И не тестовое, когда за кандидата его может сделать кто угодно и еще время на проверку надо убить. А прямо на собеседовании дать человеку кусок кода из проекта, чтоб он рассказал, как это работает, зачем это надо, и (задача со звездочкой), как это можно улучшить\оптимизировать\исправить. Удивляюсь, почему это не распространено (всего один раз за карьеру такое давали), но это ж убивает прямо нескольких зайцев:

1. Кандидат успокаивается и ощущает себя равноправным участником переговоров, а не под лампой у товарища майора, как на лайв кодинге.

2. Вы сразу видите, как он мыслит и сразу понимаете, насколько глубоко он знает предметную область. Причем, даже если конкретный фреймворк для него новый, то, если у него есть опыт с подобными решениями, но на других технологиях\языках, все равно будет понятно, как он въезжает.

3. Станет ясно, насколько его видение совпадает с видением команды на проекте (если собеседуете middle+ и выше) .

4. Кандидат может сам подсказать интересные идеи интервьюеру, которые можно использовать, даже если не сложится сотрудничество.

5. Появляется чуть более ясное понимание об общей адекватности персонажа :)

А прямо на собеседовании дать человеку кусок кода из проекта, чтоб он рассказал, как это работает, зачем это надо

Есть проект, скажем, на 10 млн строк. И туда ищут чела, это дописывать...

Какой код и этого проекта нужно дать на разбор челу (в рамках получасовой части интервью) — и чем это будет отличаться от экзамена?

Что чел об этом куске кода (скажем, 500 строк) должен сказать? Что вообще по этому коду можно сказать о том, как улучшить\оптимизировать\исправить проект?

Более того, если чел прямо на собеседовании начнёт критиковать существующий код (т.к. критика это часть предложений по улучшению\оптимизации\исправлению) — как к этому отнесутся люди на собеседовании, писавшие этот код?

Как вообще можно ожидать от опытного чела суждений, по какому-то выдранному из проекта куску? Это, примерно, как судить о книге в несколько сто страниц — по отдельной, выбранной оттуда цитате на треть страницы.

Есть проект, скажем, на 10 млн строк. И туда ищут чела, это дописывать...

Какой код и этого проекта нужно дать на разбор челу (в рамках получасовой части интервью) — и чем это будет отличаться от экзамена?

10 миллионов строк в одном файле, что ли? Выбрать модуль\несколько модулей и дать посмотреть. Оно ж все равно разбито на логические блоки, выполняющие конкретные задачи. От экзамена это отличается тем, что кандидат волен выражать свои мысли по этому куску кода свободно, а не озвучивать зазубренную инфу.

Что чел об этом куске кода (скажем, 500 строк) должен сказать? Что вообще по этому коду можно сказать о том, как улучшить\оптимизировать\исправить проект?

Дофига всего. Начиная от неймингов и код стайла, заканчивая использованием библиотек и алгоритмов, наличием оптимизаций, код дизайном, уместностью решений.

Более того, если чел прямо на собеседовании начнёт критиковать существующий код (т.к. критика это часть предложений по улучшению\оптимизации\исправлению) — как к этому отнесутся люди на собеседовании, писавшие этот код?

Если люди, писавшие код, отнесутся к конструктивной критике плохо, то кандидату стоит бежать оттуда, роняя тапки.

Дофига всего. Начиная от неймингов и код стайла, заканчивая использованием библиотек и алгоритмов, наличием оптимизаций, код дизайном, уместностью решений.

Ок, допустим увидит чел в предоставленных исходниках публичные «property-injections» повсюду и расскажет что такие инъектирования антипаттерн, нарушение нескольких принципов Солид, нарушение инкапсуляции, итп раскритикует. А у вас на этом построен весь проект и переделка в «красиво» займёт NNNNN человеко-дней.
И тому подобной критики может масса (вплоть, до bloated комментами кода).

В итоге, это будет быстро-вынесенное суждение — которое вашему проекту никак не поможет, но будет чем-то типа той же экзаменационной задачки.

Впрочем, реально-опытный чел — вообще не поймёт, каких здравых/взвешенных суждений от него ожидают услышать, по какому-то отдельно-выдернотому из крупного проекта кусочку?

Ок, допустим увидит чел в предоставленных исходниках публичные «property-injections» повсюду и расскажет что такие инъектирования антипаттерн, нарушение нескольких принципов Солид, нарушение инкапсуляции, итп раскритикует

Ну и отлично. Получится конструктивная критика, а в ответ он может услышать причины, почему так вышло. Интервьюер будет знать, что человек видит недостатки и поле для возможных улучшений.

А у вас на этом построен весь проект и переделка в «красиво» займёт NNNNN человеко-дней.
И тому подобной критики может масса (вплоть, до bloated комментами кода).

Тоже неплохо — интервьюер донесет до кандидата инфу о том, что переделывать в ближайшее время это никто не будет, и кандидат будет знать, с чем придется работать и хочет ли он этого. Заодно и собеседующим будет понятно, готов ли человек вписаться в проект с такой кодовой базой. Потенциальный сотрудник не будет шокирован, придя на работу, и не уволится через три месяца с воплями «мне обещали интересный проект, а там такооооое».

реально-опытный чел — вообще не поймёт, каких здравых/взвешенных суждений от него ожидают услышать, по какому-то отдельно-выдернотому из крупного проекта кусочку

Ожидают суждений по качеству этого конкретного кусочка, вопросов, как этот кусочек взаимодействует с остальными, все ли написано в таком духе, вопросов о дальнейшем развитии и возможности рефакторинга этого кусочка и ему подобных (в случае надобности), и роли кандидата в этом деле.

Вставлю свои 5 копеек.А Вы никогда не думали что некоторый «неправильный» код пишется специально?И он очень часто именно приносить прибыль как разработчику так и компании.И вот ситуация когда кандидать на такой код говорит,мол все это «г..но» и так писать нельзя.Как поступать?Отсюда вывод — диалог и опыт вот 2 критерия при собеседовании.Не надо делать поспешных суждений,надо давать людям работу,пусть работают.И главное как говорил классик — не ешьте на ночь сырых помидоров)))

Как вообще можно ожидать от опытного чела суждений, по какому-то выдранному из проекта куску? Это, примерно, как судить о книге в несколько сто страниц — по отдельной, выбранной оттуда цитате на треть страницы.

когда интернетов особо не было и получить ревью было не откуда именно так и делали, кто родился в ссср в школе по литературе это должен был проходить, как и практические задания по странице большой книги дать своё мнение с детальным описанием почему так решил

Это я к чему... Примеры с умом надо давать, а не сочинять чепуху на ходу

Направленность советской школы была нацелена, на воспитание «советского человека». Произведения/отрывки и сочинения по ним — тоже.

В общем, аналогия так себе...

Кстати, я очень похожее делал. Я писал код и спрашивал, что будет результатом выполнения.

Кстати, я очень похожее делал. Я писал код и спрашивал, что будет результатом выполнения.

Ну тут, главное, не скатиться в абсурд, когда код написан так, чтоб специально запутать человека и в реальности так никогда никто не напишет, а что-то максимально приближенное к тому, с чем действительно придется работать.

Не, задротством никто не занимается. Для Salesforce я пользуюсь очень простой код с логикой типа
account.CountrField__c = account.CountrField__c + 1;
запускаю код и спрашиваю, что будет в итоге в account.CountrField__c. Задача на понимание работы Salesforce, а не курение бизнес логики приложения. Мне нравится. Я не жалею ни об одном найме с таким интервью.

живой код вряд ли покажут постороннему (NDA). к тому же часто реальные проекты весьма огромны и чтоб вникнуть «что делает этот кусок» нужно просмотреть кучу связанных модулей в разных местах и потратить пару дней. для собеса тогда нужно выдумать отдельный тренировочный проект, и чтоб он более-менее был похож на реальную задачу. это может быть довольно трудоемко — поэтому большинство интервьюверов дают литкод или физбазз :-)

Реальные проекты как правила состоят из кучи как-то слепленного говна, накопленгого лет за 15 разработки. И конечно в реальных проектах никакого солида нет и никогда не было.

то есть вот это

А прямо на собеседовании дать человеку кусок кода из проекта, чтоб он рассказал, как это работает, зачем это надо

совсем не то же самое что и

это не лайв кодинг, когда от стресса кандидат забывает как зовут родную маму...

, да?)) Ну-ну

Нет, не то же. Если кандидат утверждает, что работал с данной технологией, то он будет хотя бы примерно понимать, что там написано. Навык читать код — это одно, самому на лету под взором интервьера придумывать алгоритм для олимпиадной задачки — другое.

Дуже толково. Перед співбесідою гуглю лише не знайомі абревіатури в вакансії, якщо вони є. І дуже часто це якісь концепції 10 річної давнини, які зараз назвали і упакували по модному. Напр. на співбесіді в Гугл, коли ще займася інформаційною безпекою «направлені атаки» чомусь називали modern attacks, а я цього не знав. Які вони нафіг modern? Вони існували від самого початку... От через таке буває сумно, тому все ж таки трохи готуватися треба.
Інша проблема, що зробити завдання де проявиться сами мислення кандидата не так легко, як пройтися по переліку питань. З іншого боку і на простих питання можна іти вглиб і побачити розуміння, а не щось зазубрене. Особисто я рішення приймаю на 70% за софт скілами. Технічні навички легко при бажанні підтягуються, а змінити характер людини проти її волі не можливо.

если для интервьюера важнее то, помню я или нет определение трех его любимых аббревиатур, то ему нужен не я, ему нужен другой специалист.

Не факт. Може не вміє співбесідувати просто. Хто їм треба — треба кандидату взнавати окремо =) Може і я, може це і ідеальна позиція для мене, тільки не візьмуть, тому що я забув деякі визначення.

К подобным вопросам нельзя подготовиться за день-два.

До літкод задачок — теж не можна підготуватись за день-два. І є от питання, чи не легше, насправді, підготуватись до «розмови за життя», яка пропонується у статті? Принципово — це можливо робити і таке роблять. Через це — не можна брати на основі того, що кандидат каже, що робив. System design питання «як би ти зробив/задизайнив Х» — гарні, може і не погано тільки на їх основі наймати. Але не треба дуже давати бонусні бали за твердження, що саме так і робив.

Загалом стаття гарна. На співбесіді треба взнати, чи підходить кандидат на конкретну позицію і чи буде із ним норм. працювати. Саме цим і треба там займатись.

Тут есть принципиальная разница собеседуете ли вы человека в компанию или на проект!
Если у вас, например, продуктовая компания и вы хотите найти толкового специалиста, который будет с вами много лет и внесет свой вклад в продукт — то все правильно, вам нужно понять как человек мыслит, а не знает ли он на-зубок Ангуляр или Реакт.
Но если у вас аутсорс или тем более аутстаф и вы ищете человека что бы срочно «заткнуть» вакансию — то вам нужен кто-то, кого сразу можно будет посадит педалить! Времени «подучить», «вспомнить», «вникнуть» скорее всего уже нет. Из-за кадрового голода и так клиенту обещали набрать команду еще вчера. И все сроки как обычно горят. Поэтому на собеседовании предпочтение будет тому, кто вызубрил технологии написанные в вакансии! То, что он умеет думать и знает Ангуляр и Реакт не поможет ему завтра начать педалить на каком-нибудь Вуе.

еще бывает какой-нить экзотический фреймворк (например sencha) который мало кто знает в силу слабой распространенности. поэтому берут любого кто знает хоть какой-то из*-js , и пусть на лету вникает и педалит

Когда собеседование изначально построено как диалог двух равных специалистов, которые присматриваются друг к другу, а их основная цель — оценить возможность плодотворного сотрудничество в будущем — то атмосфера будет совершенно другая

 Да не, ерунда какая-то ))

Согласен с автором. Более того, как соискатель, когда я ощущаю, что собеседующий специалист упарывается в «точность знаний в терминах» over «представление, как это работает на пальцах», то для меня это звоночек, что я ошибся дверью.

Підписатись на коментарі