По примерным прикидкам за 10+ лет работы в Miro провел порядка 500 интервью. Настало время поделиться сакральным опытом «как за час проверить, что чел шарит, и при этом не превратить интервью в душный допрос».
Все написанное ниже является персональным мнением и никак не отражает существующий процесс собеседования в Миро.
Копаем вглубь
Никаких гипотетических или абстрактных вопросов типа:
— что бы ты сделал, если бы…
— как выглядит идеальный…
— назови 5 лучших качеств команды
— и прочие «кем ты себя видишь через 5 лет»
Единственное, что мы отсюда узнаем насколько реалистичные ответы чел умеет генерировать на ходу. ЧатГПТ так тоже может.
Есть только один способ достоверно проверить, что кандидат может делать — спросить что и как он уже делал. Поэтому большую часть интервью отстраиваем от копания в прошлом опыте.
Варианты вступления.
— в двух словах расскажи про свой самый интересный (самый сложный) проект? В чем суть проекта? Размер команды? Твоя роль? Твой основной вклад? Срок проекта? И т.д…
За 3 минуты узнаем общий контекст, а потом проваливаемся в детали, цепляясь за шероховатости.
Люди охотно делятся историями про проекты, которыми они гордятся больше всего. Можно сразу понять синьорность кандидата по структурированности ответа и как он определяет проблему.
Джуниор:
— Мы переехали с кастомного велосипеда на реакт
— Зачем?
— Реакт популярный / на нем легче писать / он работает быстрее
Мидл:
— Наш кастомный велосипед жутко тормозил и не поддерживал типизацию из-за чего мы тратили кучу времени на фикс багов. В итоге мы решили переехать на реакт. Приложение стало загружаться быстрее и количество багов уменьшилось.
Синьор:
— Чтобы улучшить тайм ту маркет… бла бла бла ????
Убеждаемся, что кандидат четко понимает какую задачу он решал, знает в каких попугаях меряли успех. Чем четче в терминах бизнеса сформулирована проблема, тем лучше. Ред флаг, если кандидат выдает кашу вместо постановки.
Спрашиваем, что пошло не так и что бы сейчас сделал иначе. Саморефлексия — полезный навык.
Кандидат должен все помнить, даже если проект был 5 лет назад. В конце концов мы именно потому спрашиваем про «самый-самый» проект.
А если не помнит детали — значит не было самоотдачи или «я просто исполнял приказ». Тут в любом случае глубины нет — для нас ред флаг.
Если чел шарит — это сразу чувствуется и беседа получается живой. Особенно классно, если ты не разбираешься в доменной области или использованных технологиях — можно узнать что-то новое. Потому что классный кандидат способен быстро и доступно объяснить суть тому, кто не шарит.
Промежуточное итого:
— Спрашиваем про прошлое, а не будущее
— Копаем вглубь, а не вширь
Чекаем харды за 15 минут
Допустим, на предыдущем этапе все понравилось:
— Релевантный опыт есть;
— Здравый смысл присутствует;
— Мысли излагаются внятно;
— А главное, мы поняли грейд кандидата и на какую роль он лучше подойдет;
В теории, уже на основе того, как кандидат рассказал про свой опыт, собес можно закруглять. Но, к сожалению, встречаются ребята с подвешенным языком и никудышными техническими скилами.
Потому надо проверить, что человек умеет работать свою работу качественно и быстро.
И тут программисты дружно договорились устраивать друг другу на собесах кромешный ад, дабы потешить свое ЧСВ максимально дорогим для компании образом.
Для этого в бой идут:
— Абстрактные алгоритмические задачи, когда мы ищем чела, который должен быстро формочки на реакте клепать;
— Проектирование высоконагруженных систем, которых у вас нет;
— Многоступенчатый отбор из часового лайвкодинга, потом часового системного дизайна с двумя-тремя интервьюерами на каждом этапе для рядовой позиции мидла или джуна;
— И прочие способы сжечь бабло, так и не выяснив умеет ли кандидат работать работу;
Надо не выпендриваться, а давать типовую задачу, с которой реально придется сталкиваться, но решаемую за 5-15 минут.
Если нанимаем обычного фронтендера, то и просим обычную форму заверстать. Потом валидацию и аксесабилити прикрутить. Смотрим насколько реюзабельно все спроектировано.
И, если кандидат ее сделает, задать пару вопросов в глубину про понимание инструмента (языка, фреймворка). Потому что без глубины нет смысла ожидать скорости или качества. Любая проблема заставит буксовать на месте часами.
А если чел шарит, то это сразу видно, и 15 минут на проверку техники более чем достаточно. А если не шарит, то и 2 часа не нужны.
В каких попугаях оценивать
В итоге получаем следующую структуру интервью:
— 10 минут на интро о себе и продажу команды;
— 30 минут общаемся про опыт кандидата;
— 15 минут про технику;
— 5 минут на вопросы кандидата, или дольше, если кандидат интересный;
Осталось рассмотреть, как сравнивать кандидатов между собой.
Сразу оговорюсь, что я не заполняю реальное саммари в указанных ниже попугаях. Но, если разбирать на основе чего формируется саммари, то я оцениваю кандидатов по трем основным навыкам.
Харды и наличие релевантного опыта (хорошо, если человек повидал некоторого дерьма).
Коммуникация. Умение общаться, быстро и структурировано объяснить суть вопроса.
Проактивность в обучении и страсть к делу.
За каждый навык даем до трех баллов:
0 — все плохо
1 — с пивом покатит
2 — хорошо
3 — прекрасно
Есть хоть один ноль – сразу до свидания.
Если везде единицы, кандидат слаб по всем фронтам — тоже не интересно. (Отталкиваемся от того, что каждый следующий игрок должен усилять, а не разбавлять команду)
А дальше, в зависимости от пропорций, можно решать, какая роль человеку подходит больше всего.
Харды: 2
Коммуникация: 1-2
Обучаемость: 1-2
Рядовой разработчик, который может просто работать работу. Берем.
Харды: 1-2
Коммуникация: 1
Обучаемость: 3
Идеальный джун. Берем, если готовы вкладывать.
Харды: 1
Коммуникация: 3
Обучаемость: 1-2
Менеджер, берем.
Харды: 3
Коммуникация: 2-3
Обучаемость: 1-2
Техлид. Берем.
При этом следовать любой формальной системе в слепую при работе с людьми не лучший выбор. Формально чел может набрать много баллов, но так же несколько плохо формализируемых тревожных звоночков.
В таком случае лучше довериться гатфилингу и сказать нет, чем рисковать с наймом. Или попросить кого-то еще провести доп. интервью, чтобы убедиться, что не показалось. Мы же не безликий станок нанимаем, а живого человека, с которым каждый день взаимодействовать будем.
Справедливости ради, описанный подход годится для тех, кто проводит интервью регулярно, нужна набитая рука, чтобы принимать решение на ходу. Если интервьюить раз в месяц — будет сложно откалиброваться, и тогда лучше позвать больше людей на интервью или сделать больше этапов, чтобы собрать больше мнений. Дороже, но тоже работает.
Разумеется, невозможно написать статью на хабр, не оставив ссылку на свой тг-канал. Подписывайтесь, я там нерегулярно выгружаю разный бред из головы — очень интересно ????
Комментарии (36)
panzerfaust
00.00.0000 00:00+22И тут программисты дружно договорились устраивать друг другу на собесах кромешный ад, дабы потешить свое ЧСВ максимально дорогим для компании образом.
Что характерно, именно на собесе в Миро я ощутил этот вайб. Про HR-этап не скажу ничего плохого. Потом был мутный дядечка из Германии, который все пытал меня, что я буду делать, если коллега ведет себя неадекватно. Я не знаю, дядя, я ж не в психлечебнице работаю. Для рядовых конфликтов я всегда находил компромисс через разговор - но дядю такой ответ не устроил. А потом был как раз часовой лайвкодинг, где 2 сотрудника просто молча смотрели на мои страдания.
Francyz
00.00.0000 00:00-3Никаких гипотетических или абстрактных вопросов типа...
Для этого в бой идут:— Абстрактные алгоритмические...
Ясно-понятно.
sepetov
00.00.0000 00:00Так автор же и говорит, что это плохо. В обоих случаях он приводит их как антипаттерн при проведении собеседования:
Никаких гипотетических или абстрактных вопросов типа
...
Надо не выпендриваться, а давать типовую задачу, с которой реально придется сталкиваться
Если вакансия не подразумевает знание распространённых алгоритмов или формализации (формошлёп, crud-писатель, например), то это правильный же подход?
Tretiner
00.00.0000 00:00-1— И прочие способы сжечь бабло, так и не выяснив умеет ли кандидат работать работу;
В этом же списке:
Lexicon
00.00.0000 00:00+1Наверное самое приятное пока, что видел на хабре из собес-сценариев
К оценке однако есть вопросы, что делать, если человек 3/3/3, - это оверквал?
Почему есть крайне узкий предел по хард скиллам? 1-2 это джун, окей, но между техлидами разница просто космическая, берете ли вы первого проходящего?Отличаются ли задачки для джунов и для синьоров? Если да, то как вам удается не превышать 15 минут, если нет, то влияют ли они на оценку синьоров?
pltnkv Автор
00.00.0000 00:00Это скорее описание ментальной модели, которую я использую при определении подходящей роли для человека. В реальной скорекарде нет шкал "Харды", "Коммуникация", "Обучаемость", потому что это очень утрированная оценка.
> Отличаются ли задачки для джунов и для синьоров?
Задачи не отличаются от грейда, иначе сложно сравнивать. В том числе грейд определяется на основании качества ответов на одинаковые задачи.
> Если да, то как вам удается не превышать 15 минут
А мы и превышаем, потому что текущий процесс собеседования отличается от описанного.
Но даже в те моменты, когда мне я интервьюировал по описанному подходу часто вываливался за рамки часа.
- С сильными кандидатами потому что есть что обсудить.
- Со слабыми потому, что медленно отвечают, но прерывать на середине некорректно.
Т.е. в статье целевой формат, в реальности лучше закладывать полтора часа на интервью, если идти по подобному процессу.
auddu_k
00.00.0000 00:00+1К стати интересно, почему "прерывать на середине не корректно", если результат уже понятен и оценка уровня проведена? Почему "корректным" будет тратить общее время?
selkwind
00.00.0000 00:00значит не было самоотдачи или «я просто исполнял приказ». Тут в любом случае глубины нет — для нас ред флаг.
Т.е. работал в поддержке 3 уровня десяток лет, беря таски из джиры - все, на помойку?
Sild
00.00.0000 00:00+1Работать 10 лет беря таски из джиры и все - в джуны. Если инструментарий совпадает, то можно попробовать в мидлы, но есть риски.
Areso
00.00.0000 00:00+5Надо не выпендриваться, а давать типовую задачу, с которой реально придется сталкиваться, но решаемую за 5-15 минут.
Если нанимаем обычного фронтендера, то и просим обычную форму завестать. Потом валидацию и аксесабилити прикрутить.
Я вот не фронтендер, но скажите, реально ли проверяется навык фронтендера (вроде как программиста) вёрсткой форм?
Второе, реально ли сверстать условную форму оплаты картой +опции доступности, а так же написать валидацию (какую? хорошая валидация -- отдельный навык) и всё это за 15 минут?
sovaz1997
00.00.0000 00:00+1Нет
Скорее нет, только если человек делал много форм с хорошей валидацией
barloc
00.00.0000 00:00+4Все написанное ниже является персональным мнением и ни как не отражает существующий процесс собеседования в Миро.
Для меня очень непонятная приписка от человека, который провел 500 собеседований в миро. Сколько там у вас раньше было - 4 интервью? Плюс звонки по рекомендациям, которые указал кандидат.
Я бы понял приписку, что провел 500 интервью. А когда человек активно собеседует и совсем не так, как пишет и никак не может повлиять на их проведение - ну такое.
cadovvl
00.00.0000 00:00+8Ну епрст, опять двадцать пять. Ну давайте ваш собес
Чем четче в терминах бизнеса сформулирована проблема, тем лучше.
А если это опен сорс, или аутсорс, где бизнес - ровно сделать ТЗ от и до? А если я в крупной компании, где бизнес - вообще не моя сторона? Я в лучшем случае знаю, сколько стоит наше облако. До нашего подразделения задачи доходять типа "Отказоустойчивость надо повысить до трех девяток для таких пользователей, и до четырех для таких. Срок - три месяца". И вот я понятия не имею, как они высчитали, что именно такой порог им нужен для бизнеса, а дальше импакт/затраты не срастутся. Это не значит, что я говно специалист - вполне вероятно компания просто так организована.
Кандидат должен все помнить, даже если проект был 5 лет назад
Да ладно? Я вот открываю свои коммиты двухмесячной давности, и попадаю в одну из двух ситуаций: "какой м**ак это написал?" и "круто, хочу уметь так писать", только потом понимаю, что код мой. Потому что перед тем, как написать что-то сложное, я глубоко погружаюсь в контекст. Мы тут внутренний алгоритм сжатия два года назад замутили (объяснить, с точки зрения бизнеса, зачем?), так у меня на столе была бааааальшая такая стопка статей и пара книг. Я половины названий-то не вспомню, не то что пересказать. Но как же хорошо, что я написал документацию, в которой описал как все работает, чем руководствовались, какие идеи отбросили и почему.
Я такого рода написанные мной доки/заметки перечитываю, для повышения таксказать квалификации. Сделано очень круто, а детали забываются. Если у вас один "самый-самый" проект, который настолько крутой что вы только его помните - мне вас жаль. У меня каждый второй проект - это эпическая история, и я физически не могу помнить каждый в деталях.Надо не выпендриваться, а давать типовую задачу, с которой реально придется сталкиваться, но решаемую за 5-15 минут.
Что очень хорошо говорит о вашем месте работы. Если у вас есть реальные "типовые" продуктовые задачи, которые решаются за 15 минут... Ну, вы в зоне GPT-риска.
90% задач у меня начинаются, внезапно, со сбора данных.
Для новых фич - анализ потенциальной нагрузки, особенностей данных, гарантий предоставляемых внутренними сервисами, и декларированных новыми внедряемыми. Ну и как верифицировать успех, как не сломать существующие потоки.
Для нефункциональных изменений: сбор внутренней телеметрии, внедрение новой, попытка понять где что не так работает, какие данные нам нужны для локализации проблемы. После чего поиск решения: спрашиваем коллег и гугл кто как такое решал, как решается в других продуктах-командах, собираем tradeoff для разных решений, выставляем ответственному за продукт на выбор, он говорит что-то из серии "сотня машин для Metric Space Index не проблема, а вот ответ должен укладываться в 80ms, такчто третий вариант кажется лучше всего".
И вот это 40% времени. Дальше код, редко простой и на 15 минут. Обычно сложно распиливаемый проект на месяц. Потом - долгая процедура тестирования верификации и деплоя, которая еще 30% времени.
И что удивительно: "типовых" задач не появляется. Все типовое делается один раз так, чтобы второй раз эту же задачу не решать.А самое главное, если у вас такие есть: откуда такое пренебрежение алгоритмическими задачами на собеседовании? Тоже условно типовые задачи с некоторой вариативностью, заодно логику проверить.
Проактивность в обучении и страсть к делу
Это вы вообще прекрасно оцените за час собеса. Знаете поговорку "У меня нет приступов лени. У меня приступы активности, а лень у меня - постоянная". Чел просто один раз выспался перед собесом и заварил литр крепкого кофе. Даааа, активность и страсть к делу. Особенно прекрасно оценить "обучаемость" за час собеса. Не за 11 лет, а за час.
Вцелом, вывод: результат собеседования, это субъективная оценка кандидата собеседующим.
Вы просто пытались рассказать, почему ваша субъективная оценка может оказаться релевантной некоторым кандидатам, и некоторым местам работы. Меня вы, скорее всего, не возьмете, а если возьмете, то я к вам не пойду: не хочу решать типовые задачи на 15 минут.
sshikov
00.00.0000 00:00+1Да я бы даже так сказал — ну вот у меня есть типовые задачи, допустим. Но у меня нет типовых кандидатов. То есть, кандидатов, которые знают мой стек от и до — их можно искать днем с огнем, и не найти. Поэтому все кандидаты, с высокой квалификацией, но чуть в другой, более типичной области, мои типовые задачи по 15 минут будут вероятно решать 150.
не хочу решать типовые задачи на 15 минут.
Очень похоже )
VladimirFarshatov
00.00.0000 00:00Это всегда так 150 вместо 15, пока не втянешься.
Не, я видел в свое время одного, который, как сказывали, пришел в легаси и за 8 часов первого же дня работы закрыл то ли 6 то ли 16 баг-тикетов.. вот так вот сходу, впервые воткнувшись в багтрекер и код. Сдается мне, что вопрос был не в его квалификации (кстати, джун-мидл на тот момент) а просто в качестве этого легаси. ;)
Нормально, ни один человек не в состоянии быть в глубоком погружении во всем стеке, применяемом во всех местах одновременно. Но .. только так можно ожидать, что сеньор придет и сразу начнет работать на полную катушку. Даже одни и теже инструменты зачастую применяются "ровно наоборот", особенно новомодные.
Зато периодически можно услышать "нам нужен специалист, который сразу втянется в нашу работу" .. это, простите, "как"? Кмк, только тот, кто уволился не позднее недели назад, я так думаю. От одного до трех месяцев он только будет постигать ваше легаси (от его размера), а ещё доходить своим умом КАК такое удалось и почему оно по сию всё ещё такое.. в общем-то поэтому "за одного битого, двух не битых дают, да и то .. не берут" (с)..
sshikov
00.00.0000 00:00за 8 часов первого же дня работы закрыл то ли 6 то ли 16 баг-тикетов…
Я тоже такого видел. Я типа тимлид, щас я вам тикеты позакрываю… потом пришлось его изменения откатывать, потому что формулировку тестировщика, что "вот это вот по умолчанию должно быть равно тому-то" интерпретировал неверно. Всегда есть вещи, которые по незнанию можно интерпретировать двояко, и то что постоянным членам команды понятно без слов, для стороннего потребует либо лекцию, либо чтение документации.Но — при этом сеньор таки как правило обнаружит возможность такой двоякой интерпретации, и задаст вопрос — а джун на этом же месте просто реализует неверную интерпретацию.
А насчет задач — ну у нас все же очень специфический стек. Скажем, много вы знаете людей, знакомых с Oozie? Я думаю что конторы в России, где таки люди есть, можно пересчитать по пальцам. А это инструмент, хоть и второстепенный.
AleksandrRd
00.00.0000 00:00+3Харды: 3
Коммуникация: 2-3
Обучаемость: 1-2
Техлид. Берем.
ТехЛид с обучаемостью 1-2 это как?
Как тогда он заработал свои Хард Скилы на максимум?
Или заработал и уже остыл, дальше будет почивать на лаврах уже достигнутого результата и препятствовать техническому движению вперед ...
larasage
00.00.0000 00:00Думаю, что все люди разные - по обе стороны. И как не меняй алгоритм - всё равно будут вываливаться исключения. Как с сильной недооценкой кандидата, так и переоценкой. Это не значит, что не надо искать алгоритм. Надо, но везде он будет хоть немного (а иногда и принципиально) другим. И всем к этому надо относится несколько спокойней.
sved
00.00.0000 00:00+3— в двух словах расскажи про свой самый интересный (самый сложный) проект?
Меня всегда вгоняли в ступор такие вопросы.
Что если у меня вообще не было интересных проектов? Я, например, всю жизнь хотел заниматься биоинформатикой, геоинформационщиной и прочей алгоритимстикой. Разве я виноват что на рынке мало подобных предложений? Надо признать, что большинство задач не являются сколько-либо интересными.
Что касается сложности проекта, то что это проверяет? Что является предпочтительным ответом? Сложность это хорошо или плохо?
Чем опытнее кандидат, тем менее сложными кажутся ему его проекты и тем менее сложными он их делает. Обычно сложности возникают из-за технических просчётов, багов в выбранных библиотеках и неясной аналитики.
KongEnGe
00.00.0000 00:00+1Как правило, самые интересные проекты связаны с личным архитекторством велосипедостроения: не взлетит, так шишек "как не надо" понабиваешь на будущее. Но вот для собеса в качестве примера оно такое себе.
А так, конечно, если мы посмотрим на ситуацию со стороны нанимающего, то тому хотелось бы, чтобы кандидат проманифестировал личным интересом к текущим задачам конторы или хотя бы к персональному опыту из прошлого самого интервьюера -- чтобы перевести беседу в "недушное" обсуждение славных прошлых деньков. Поэтому такое направление для разговора всяко получше люков, продаж ручек и сортировок красно-черных деревьев в вакууме, но тоже не всегда к конструктиву приводит.
sshmakov
00.00.0000 00:00+2Как вы проверяете обучаемость? О самом интересном ни слова не нашел.
VladimirFarshatov
00.00.0000 00:00Хороший вопрос. В свои 60+, стараюсь читать, искать, узнавать что-то новое .. вот Хабр - каждый день мин. 1-1.5 часа. Тут выше писал, что "Go освоил за неделю" .. хм.. это я поторопился, однако. :) Третий год работы, вроде "вдоль и поперек", но .. второй вечер не могу понять КАК в моем, в общем-то тривиальном куске кода бенчмарк показывает аж целых 3 аллокации, когда в похожем коде из стандартной библиотеки только .. одну. Ну ок, одну делает Sprintf() - одинаково, что там что тут, ещё одну я делаю сам сознательно требуя от кода реентерабельности для горутин. Где третья, Карл?!? :)
Все глаза уже поломал..
auddu_k
00.00.0000 00:00+2Годная статья, спасибо ????
Но вопрос про оценку обучаемости, действительно трепещет :-)
VladimirFarshatov
Хорошая статья. Мало таких собеседователей, но Вы не указали на ограничения по возрасту кандидатов, а оно есть и после 40 превращается в ключевое. ;)
И что, с того что у меня работа в ИТ аж с 1979года? Харды? Да какие угодно, но все "примерно по среднему", ибо "помнить всё" - не реально, память давным давно ушла в своп и не вернулась. Последние лет 15 вообще не запоминаю что делал и как, ибо это всё ровно одно и тоже. Всё что надо было накодить украдено до Вас, впрочем, по большей части и до нас тоже или как раз нашим поколением погромистов. ;)
Примеров? Да сколько угодно, начиная с писания на Си диспетчера задач с хоаровским взаимодействием процессов, по типу Ада (семантический компилятор с неё тоже был в загашнике когда-то) .. это ровно то, что теперь внезапно называется "каналы и горутины в языке Golang" .. почто у меня Си-шная прога могла в слайс каналов в селекте, а Го .. никак по сию пору? ;) 1994 год или около него +- .. точно уже не помню. ;)
Что было самое интересное? Не .. не это, как ни странно. Самым своим чудом считаю Ассемблер-Реассемблер для Д3-28, который занимал весь целых 8 килобайт, и единая таблица мнемоник применялась в нем трижды: как таблица текстов мнемоник, как набор кодов программы реассемблирования мнемоники и как часть кода ассемблера для получения кодов команд из мнемоники.. 4 килобайта, примерно половина всего могла применяться в трех ипостасях. Да, я понимаю что теперь это "фу-фу-фу", ибо нарушает тот же "SOLID", и др. "принципы" придуманные нашим же поколением (помню те конференции, где это ещё начиналось) для "бестолковых джунов", как решение вопроса "Как быстрее ввести в профессию новичков и избежать переделок за ними?" .. заставь дурака Богу молиться он и лоб пробьет.. ;)
Обучаемость? По сию пору стараюсь держать на самом высоком уровне. Освоение Парадокса в 2009-м - неделя до первого применения, пара месяцев до полноценного сеньора; Го - неделя до начала работы на нем в позиции мидла... и чО? (спрошу по современному) ;)
.. и Вы всерьез считаете что это я бахвалюсь типо "один такой"? :) Да любой погромист возрастом 50+ не ушедший с профессии в рукомахательство расскажет Вам с 10+ таких историй.. ЛЮБОЙ.
Толку? Одно время собеседовался "из принципа" повесив резюме .. как-то ХР-ы забывают что собеседование это "палка о двух концах": не только Вы смотрите кандидата, но и кандидат смотрит на Ваших "тимлидов", зачастую молодых и малообразованных. Несколько раз натыкался на дурацкий вопрос: "Расскажите нам как делается сортировка вставками?" ЧО?!? Оно Вам зачем? Давным давно сей алгоритм включен во многие библиотеки и знать как оно делается современному даже сеньору .. незачем. В общих чертах может и расскажу, но в деталях .. увольте, хотя Кнут долго в моей жизни лежал на столе.. хотя о чем я? Половина тимлидов не то, что не читали ни Ахо с Ульманом ни Кнута .. они и само слово на слух воспринимают неправильно! ;)
В целом (и по частям как Петербуржец) - плюсую. Хорошая статья. Когда-то, будучи "дирехтуром" сам так принимал народ..
shamash
Душно
Anvano
С возрастными кандидатами бывает такая проблема, что они считают ниже своего достоинства "опуститься" на уровень собеседующего и поговорить с ним на одном языке.
При этом мне самому ближе к пятому десятку и я собеседовал достаточно людей 50-60 (на позицию разработчика под БД Oracle, если что).
Были отдельные кадры, от которых прямо сквозило при общении "да вы вообще всё делаете не так, я один тут дартаньян с опытом 20 лет". Зачем мне такой сеньор в команде, вот честно?
Наряду с этим - встречались и прекрасные варианты, и у меня даже работал такой человек с возрастом в районе 60 (правда умер от ковида, но это отдельная грустная история)
Если человек весь из себя такой опытный - то он первым должен понимать, что собеседующий видит его впервые в жизни. Собеседующий не может с одного взгляда оценить его как профессионала и "подпрыгнуть" на его уровень общения. Собеседующему, хочешь не хочешь, а приходится начинать интервью с чего-то "среднего по больнице". Резюме конечно есть, но не всегда люди умеют адекватно его составлять.
Я научился составлять резюме только после того как сам начал собеседовать людей и начал понимать, что реально должно быть написано в резюме с точки зрения нанимателя.
VladimirFarshatov
Небольшая правка: не опуститься до уровня, а подняться. Мне, примеру сложны все новоанглицизмы.
Areek
Удалено.
karon
На днях было собеседование с человеком 52 года. Мне 32) Увидев меня у него прям лицо поменялось. На попытки вопросов и рассказать, про проекты отвечал сквозь зубы, ответами из серии: "Работу делал, у нас там свой фреймворк, который лучше чем ваш стек".
HR потом сказала, что на первом созвоне, рассказывал спокойно, и без каких либо проблем
venanen
Поддерживаю, и даже считаю отсутствие таких наклонностей признаком адекватности. Если человек стал техлидом, имеет отличные харды и софты, и при этом видя джуна или его ошибки - то будучи нормальным человеком просто его поправит, объяснит и все. Часто же приходится видеть обратное - люди в такой ситуации, как сказал мой бывший коллега, "Смотрят как на пыль". Как будто это не просто человек без большого опыта, а какой-то ущербный. Снобизм для меня - одна из худших черт характера.
С другой стороны, любой разработчик знает, что есть профессионалы уровнем выше, и если я встречаю а собесе, или просто в жизни человека, который действительно имеет бОльший опыт, нежели чем я - я всегда с удовольствием послушаю критику и советы.
BlueBeard
"аналогичный случай был в городе пизе"