Комментарии 50
Не увидел какого-то внятного посыла в статье. Что, русские кодеры должны быть менее прямолинейными и "токсичными", а быть более "толерантными" и "гибкими"? ps: про знание английского - это было понятно как раз по тексту, но почему-то это не попало в "Заключение"
Прямо же написано: большое количество русскоязычных кандидатов на собесах в FAANGMANGA проваливается на софт-скиллах. Ещё в одном посте на этой неделе при \том писали, что если вы проваливаетесь именно на софт-скиллах, то вам про это никто не скажет. Так что хотите в MANGA - качайте их.
Прямо же написано: большое количество русскоязычных кандидатов на собесах в
FAANGMANGA проваливается на софт-скиллах
Видимо это мой косяк в софт скиллах, что я не смог донести эту мысль :)
Ещё в одном посте на этой неделе при \том писали, что если вы проваливаетесь именно на софт-скиллах, то вам про это никто не скажет.
Справделивости ради я хочу сказать, что на собеседовании в одну из таких компаний мне дали полный фидбек, с выдержками каждого интервьюера, что было хорошо, а что плохо. Хотя, в основном, так и есть, фидбек вы получите скорей всего "мы хотим предложить Вам оффер" / "К сожалению мы решили не идти с Вами дальше"
Софт-скилы ценятся, пока задачи стандартны.
В ситуации, когда например, нужно спасать вашего родственника - кого вы предпочтёте - хирурга-матершинника, который достаёт с того света людей, или фальшиво-любезного физишиана, прописывающего парацетамол?
Если рынок голосует за софт-скилы - значит, статистически никто не пишет драйверы для Линукса, не запускает Вояджер в космос или не ковыряет движок БД - эти экстремальные хард-скилы тонут в массе формописательства.
Уникальные специалисты есть и набирают их по-своему, но логично, что описанный процесс массового набора не рассчитан на уникальных специалистов.
А "любезных" "спасателей" не бывает, и их не надо искать?
У вас ложная дихотомия. Как будто вы персонажа в РПГ прокачиваете и выбираете кидать ему очки в интеллект или в харизму. Но в жизни оно немного не так не работает. Вот вы пишете
Если рынок голосует за софт-скилы - значит, статистически никто не пишет драйверы для Линукса
Но зачастую весьма резкая манера общения Торвальдса и готовность обосрать низкокачественный PR немало помогла Линуксу и качеству кода в нём. И когда нужно было надавить на Nvidea, Линус им не программный код показал, а средний палец. И эффект от его софт-скиллов был именно потому, что до этого он продемонстрировал хард-скиллы.
Так же и у
хирурга-матершинника, который достаёт с того света людей
мат взялся не на пустом месте, а потому что по его опыту это самый эффективный способ руководить командой и готовить пациентов. То есть снова взаимодействие хард-скиллов (опыт в медицине) и софт-скилов (опыт в общении). А если он будет материть всех подряд по поводу и без, то он потом зае..тся искать себе ассистентов на операцию.
А если он будет материть всех подряд по поводу и без, то он потом зае..тся искать себе ассистентов на операцию.
Мне очень нравится аналогия про ассистентов, если кандидат rock star, но как человек он так себе, то и работать он будет скорей всего в одиночестве, а у компаний типа Google / FB / Amazon / ... видение примерно такое, что два средних девелопера, которые хорошо работают в команде сделают лучше, чем один самый одаренный программист. Имхо, это в большинстве случаев так и есть, но, конечно, есть и гениальные исключения, которые в одиночестве творят магию :). Но за такими идет прямой хайринг и он никак к этой статье не относится.
Пойдёте ли вы к гениальному врачу, если при встрече он вас в жопу послал? А если вопрос вполне рядовой?
Теоретически, любая компания может себе позволить нанять чувака, с которым окружающим некомфортно работать. Будет ли он для этой компании полезен, если из-за него другие разработчики/девопсы/DBA будут разбегаться? Или пусть даже не разбегаются, но бас-фактор становится равен 1, потому что с ним другой такой же сумрачный гений не уживается? Некоторые компании считают, что оно того стоит, некоторые не готовы ставить всё на одного человека.
для этого у нормальной больницы есть любезный администратор и вежливая медсестра. А хирурга вам покажут после операции на 5 минут : "у вас был интересный случай, сломал об отросток два скальпеля, обязательно придите через ____ на доп. обследование, я вас снова с удовольствием посмотрю" (или "банальный пузокардит, ничего интересного. кушайте, отдыхайте, доживёте до правнуков").
Если вы девелоперов (хоть вежливых хоть невежливых) видите на техподдержке - значит шарашкина контора.
Причём тут техподдержка? Вопрос же про работу внутри компании, и проблемы во взаимоотношениях человека со слабыми софт-скиллами и его же коллегами: другими разрабами, PM-ом, тимлидом. Вот вы лично готовы работать в команде с чуваком, который вас постоянно посылает, и вообще за специалиста не считает, но он сам очень крутой спец, на две головы лучше вас?
Платить кто будет за все эти прослойки? Если это бизнес - то фокус см. выше. Будет три слоя софт-скилов, и хорошо, если хирург из госклиники на подработке. Если Вы хотите ехать, а не шашечки - зайдите в эту подпрограмму через боковую точку входа - уже после того, как ENTRY съел бОльшую часть вашего стекового фрейма. ;)
Великолепная формулировка
Как человек, который собеседовался (в том числе и успешно) последние пару лет в несколько европейских/американских компаний могу сказать, что все перечисленные автором пункты кроме первого (английский мои собеседники всё-таки знали) были мною встречены и с другой стороны тоже. То есть и там софт-скиллы сильно хромали.
Например
Предубеждение
Эту хрень я и на наших собесах регулярно встречаю. У рекрутера есть чёткое мнение, как человек должен решать задачу, отвечать на вопрос по системному дизайну или строить ответ по сиcтеме S.T.A.R. При этом, если ваш ответ в эти рамки не вписывается, а для собеседования не по алгоритмам вообще-то и не должен, вас будут настоятельно к нему подталкивать, не стараясь объяснить, чем собственно ваш ответ был плох, а зачастую тупо игнорируя ваше мнение. То есть как раз демонстрируя так себе софт-скилы.
Гордость (самоуверенность)
В России как-то привыкли скромнее описывать собственные компании, и описания в духе какой мы офигенный стартап Рога и Копыта, получивший аж пару миллионов от инвесторов и уже имеющий двух клиентов. Что характерно — самые скромные описания были от соотечественника работающего сейчас в Кремниевой Долине и от рекрутера Facebook.
Ну и наконец, автор пишет:
В заключение могу сказать, что по моему опыту у русскоязычных кандидатов в большинстве случаев действительно сильнее хард скиллы, чем у остальных. Они быстрее решают проблему, чище пишут код (видно, что они действительно его пишут day to day) и чаще более технически подкованы, но берут всё равно не их.
То есть процесс найма в компании построен так, что она не в состоянии нанять компетентных и ценных сотрудников из-за их культурных отличий, также из-за неспособности рекрутеров подстраиваться под таких кандидатов? И при этом проблемы с софт-скилами только у кандидатов?
Ну ладно, вы вот статью на Хабр, хотя бы написали, будем считать, что у одного рекрутера там всё-таки софт-скиллы есть.
P.S.
Со своей стороны могу посоветовать проходить собеседование в иностранные компании не с целью трудоустройства, а например с целью подтянуть иностранный язык. Этим вы сразу убьёте несколько зайцев
уберёте проблему стресса от отказа, в случае отказа просто начинайте искать нового халявного "препода"
будете стараться более грамотно говорить на собеседовании
будете более расслаблены, чем повысите ваши шансы на трудоустройство.
P.P.S.
Лично для меня это было токсичное окружение в российских компаниях и отношениях менеджер-подчиненный. Где сказать, что "твой код г$%#о" это нормально, это значит, что человеку просто надо переписать этот код, прямолинейность вытачивала из нас жестких, но сильных спецов
По-моему сказать человеку, что "твой код г$%#о" так, чтобы его код после этого стал лучше — это проявление весьма недюжинных софт-скиллов.
Всегда прошу кандидатов по-возможности строить ответ по сиcтеме S.T.A.R потому что тогда мне не придется тратить время и пытать его каленым железом, чтобы извлечь из него данные, которые я должен потом отразить в interview feedback.
То есть процесс найма в компании построен так, что она не в состоянии нанять компетентных и ценных сотрудников из-за их культурных отличий
+1 от меня за правильно (IMHO, естественно) сформулированную корневую проблему.
Где сказать, что "твой код г$%#о" это нормально, это значит, что человеку просто надо переписать этот код
Впрочем, это не указывает на то, как именно этот код надо переписать и что именно в нём не понравилось ревьюеру. А если указать причины, то и фекальная словесная конструкция уже избыточна.
Это Ваш второй комментарий, который я не могу обойти, очень хорошие аргументы.
Как человек, который собеседовался последние пару лет в несколько европейских/американских компаний могу сказать, что все перечисленные автором пункты кроме первого ... были мною встречены и с другой стороны тоже.
Не отрицаю, просто у русскоязычных это ярче выражено и встречается уж слишком часто. Низкий процент успешного хайринга подверждает Ваш аргумент, что проблемы встречаются у всех.
У рекрутера есть чёткое мнение, как человек должен решать задачу, отвечать на вопрос по системному дизайну или строить ответ по сиcтеме S.T.A.R.
Зависит от собеседующего, про S.T.A.R. это скорее behavioral questions. На самом деле Вы можете рассказывать как хотите, просто интервьюер потратить больше времени на уточняющие вопросы, технические детали, что Вы лично вынесли из данной ситуации и т.п., так тоже можно, это скорее нейтральная ситуация, отвечая лаконично и по делу Вы заработаете дополнительные баллы, если можно так сказать.
Про решение задач, систем дизайн я бы хотел еще раз подчеркнуть, что речь не идет про найм SWE/SRE/SDE, там всё чуть-чуть иначе и довольно протокольно, мы себе можем позволить немного вольности и мои задачи не имеют единственного верного решения, мы дискутируем и обсуждаем компромиссы, мне важно понять как кандидат мыслит, насколько глубоко я могу с ним копнуть.
То есть процесс найма в компании построен так, что она не в состоянии нанять компетентных и ценных сотрудников из-за их культурных отличий, также из-за неспособности рекрутеров подстраиваться под таких кандидатов? И при этом проблемы с софт-скилами только у кандидатов?
Так и есть, это называлось раньше cultural fit (сейчас так уже не говорят, потому что cultural стало применяться именно к культурным отличиям наций нежели к культуре компании). Как-то на просторах ютуба было интервью с девушкой, получившей офферы от Amazon / Google / Linkedin и еще парочки, которая рассказывала, что на один и тот же вопрос: "Что вы выберете? Сохранить отношения в команде или сдать проект вовремя?" надо отвечать по разному в Google и в Amazon :). Однако, не могу сказать насколько сейчас это актуально...
По-моему сказать человеку, что "твой код г$%#о" так, чтобы его код после этого стал лучше — это проявление весьма недюжинных софт-скиллов.
Именно в этом и суть, и именно так на работе в российских компаниях у нас проходила коммуникация. К сожалению, эту прямолинейность мы несем на интервью в интернациональные компании и встречаем непонимание.
p.s.: Я полностью согласен с Вашим p.s. :)
Вы не думали, что кандидатам, возможно, совершенно не интересен этот сторителлинг.
Если кандидатам не интересен этот сторителлинг, они могут проходить мимо и работать в других компаниях.
А если уж захотели в эту конкретную – то придется рассказать то что им нужно. Более того, сторителлинг не заканчивается после собеседования, все повышения внутри компании тоже нужно подкреплять примерами и историями, показывающими ваш достойный уровень.
Если вам такие процессы не по душе, дело ваше, можно найти и другие места
они, очевидно, и проходят мимо.
Ну и надо сказать, часто процесс найма не имеет ничего общего с реальной работой.
Я амазоновцев на интервью спрашивал, типа когда был последний пример их овнершипа над продуктом, чтобы они выкатили исконно их фичу, не спущенную сверху. Ответом было "я тут еще не очень долго работаю" в 100% случаев ;)
В статье не хватает реального примера истории, которую вы ожидаете от кандидата. В теории оно выглядит как "расскажи про все хорошее в лучшем свете, а плохое рассказывать не надо". Нужен практический пример.
Ещё по своему опыту проведения собеседований в FAANG замечу, что ответы по STAR не какая-то супер сложная штука. Это задача собеседующего разложить ответ кандидата по полочкам STAR. От вас требуется только отвечать на наводящие вопросы.
В статье не хватает реального примера истории, которую вы ожидаете от кандидата
Таких можно очень много найти на просторах интернета :)
В теории оно выглядит как "расскажи про все хорошее в лучшем свете, а плохое рассказывать не надо".
Вам с 99% вероятностью зададут вопрос о Ваших фейлах. Не ошибается лишь тот, кто ничего не делает. Нам важно понять, что Вы вынесли из этого фейла, что сделали, чтобы предотвратить это в будущем.
Вот пример, который в плюс не пойдет :). Один из кандидатов мне рассказывал, как у них раз в квартал падала база из-за того, что пользователи присылали не верифицированные данные и он вычищает их из базы и исправляет их вручную уже на протяжении 5 (!) лет, на вопрос, а не думал ли он изменить процесс, наладить верификацию до загрузки в БД, найти другие способы ответ был - нет, конечно, это не входило в мои обязанности.
Это задача собеседующего разложить ответ кандидата по полочкам STAR
Я уже ответил выше, что да, так тоже можно, но интервьюер потратит Ваше время на то, чтобы разложить это за Вас. Умение складывать слова в предложения, чтобы это звучало последовательно и правдоподобно это то, что потом потребуется в работе, когда Вас попросят отстоять Вашу позицию, спросят экспертного мнения или попросту обьяснить это Вашему менти или любому члену команды.
С одной стороны, рекрутеры пытаются научить кандидатов "хакнуть" систему и пройти все их витиеваетые вопросы... С другой стороны, рекрутеры в упор не слышат фидбек от сильных кандидатов, которые уже вопят им "фуфло все эти ваши вопросы, ими нас поймать можно разве что случайно..."
Как мне кажется, рекрутер должен поверхностно знать больше архитектурных решений и уметь просеивать кандидатов рассматривая именно опыт их прошлых решений, стыкуя его с текущей позицией... Ведь сколько людей - столько ж и дорог... Но нет, мы пока в упор предлагаем решать всем алгоритмические задачки и гонять всех на знания, которые гуглятся за минуту.
С одной стороны, рекрутеры пытаются научить кандидатов "хакнуть" систему и пройти все их витиеваетые вопросы...
Речь не идёт про витиеватые вопросы, речь идёт про навык коммуникации. Если Вы не можете донести до меня своё архитектурное решение, почему Вы тогда сделали это именно так (время, знание технологий, цена, etc) и изменили бы Вы свое решение теперь, то в этом и будет проблема при найме, я просто не могу гарантировать команде, которая Вас нанимает, что Вы сможете интегрироваться в команду и поделиться своим опытом с ними. Как Вы метко подметили "сколько людей - столько ж и дорог" и на очередном митинге Вас спросят, а почему Вы выбираете именно эту дорогу? И Вам надо будет это донести людям, которые, возможно, менее подкованны технически, разложить по полочкам, показать анализ, который Вы провели
Я не являюсь рекрутером, я инженер :)
Но нет, мы пока в упор предлагаем решать всем алгоритмические задачки и гонять всех на знания, которые гуглятся за минуту.
Вы говорите про SWE / SRE / SDE, я несколько раз попрбовал подчеркнуть, что это немного другая история. Я знаю, что большинство пользователей хабра скорей всего подходят под эту категорию и мне было всегда обидно, что статьи на тему интервью на позиции DBE / DE обходят стороной. Попробуйте нагуглить вопросы и задачки, которые дают FAANG компании на эти роли, а потом сходите и расскажите совпало ли ожидаемое с реальным ;)
Мне это даже на teamblind не удалось сделать
С одной стороны требуется
умение доносить экспертное мнение до менеджеров и аргументированное отстаивание своей позиции
А с другой
всегда надо слушать и принимать подсказки, а не продолжать себя топить
Что-то я подозреваю, что когда ищут эксперта, с большой долей вероятности у него больше экспертизы, чем у интервьюера.
Даже нанимая эксперта, все равно от него не ожидают работы оракула "будем делать так, но почему – я рассказывать не буду", а последовательного объяснения своих решений.
Поэтому и интервью – это диалог и обсуждение разных альтернатив, а если кандидат уперся в одно решение и не хочет с него сворачивать, то это красный флаг.
Не увидел я в статье, что кандидат настаивает на своем решении, не объясняя почему. Зато увидел, что интервьюер хочет получить то решение, которое у него (на листочке записано).
Видимо, речь про это
когда Вы идёте не туда со своими размышлениями, интервьюер даёт Вам подсказку, но Вы её игнорируете (в лучшем случае), а в худшем еще и настаиваете на неправильном ответе.
не стоит додумывать чего там не было (про листочки). Давайте все-таки подразумевать хорошие намерения обеих сторон. Например, что в задаче есть несколько правильных решений и несколько тупиковых (которые кажутся верными, но заваливаются на сложных граничных случаях).
У меня в практике такое бывало, кандидат выбирает тупиковое решение, ты ему подсказываешь, намекаешь про граничные случаи, но он все равно идёт напролом со своим решением. Спустя пол-интервью, он таки осознает что его подход не годится, но отведенное время уже вышло, и на нормальное решение его уже нет. ССЗБ, получается.
Часовое интервью, двадцать минут на общие вопросы, сорок на решение задач из которых он двадцать минут тупил. Если он в реальной работе будет двадцать минут тупить, а потом найдёт правильный путь, то вы этого даже не заметите. Точно это он ССЗБ?
В реальном мире у нас и задачи больше и сложнее, чем можно сделать за час на интервью. Поэтому правильная экстраполяция будет такая – получил задачу на неделю, из них 3 дня тупил. А это уже ощутимая разница
У вас есть экспериментальные данные, подтверждающие правильность экстраполяции? Может он потратит день на тупление, а потом за два дня сделает задачу, на которую отвели неделю.
Зачем все это? У меня нет задачи дотянуть этого конкретного кандидата до правильного ответа. При конкурсе несколько десятков человек на одно место это не имеет смысла.
Раз ответа нет, значит ответ - "нет".
Я веду лишь к тому, что вот эти принципы скоринга кандидатов, популярные в компаниях FAANG и мнящих себя не хуже, мало что говорят о реальных качествах кандидатов.
А вам незачем, действительно. Вы же себе работника ищете, чтобы он именно вам подходил.
А у вас есть какие-то экспериментальные данные подтверждающие вот это:
эти принципы скоринга кандидатов, популярные в компаниях FAANG и мнящих себя не хуже, мало что говорят о реальных качествах кандидатов.
Есть. Когда я вижу, что толкового специалиста не берут из-за того, что интервьюеру что-то помстилось, и это неоднократно повторяется.
Наверное, скоринг должен нивелировать личные впечатления. Наверное. Просто я этого не вижу.
Знаете, в обратную сторону тут не работает, получается вы просите "Доказать, что ты не верблюд". Если вы взяли тактику FAANG, то хотелось бы другого обоснования, вместо "А вы сначала докажите, что это плохо"
Просто в ИТ вроде говорят дефицит кадров и вакансии очень долго закрыть не могут, если же у вас наоборот вы можете какие угодно фильтры добавлять, хоть умения играть на виолончели требовать.
сорок на решение задач из которых он двадцать минут тупил.
Вот, чтобы кандидат не тупил 20 минут, то и даются подсказки. А у нас (русскоязычных) еще и заложено, что думать надо максимально молча, чтобы никто не узнал, что мы тупим. Поэтому не всегда понятно - или Вас мысли не туда ведут, или Вы уже близки к решению и просто компонуете всё вместе.
Но подсказка зачастую воспринимается в штыки и кандидат начинает всё равно делать по-своему, что не всегда правильно.
Просто для примера:
"Выведите сумму зарплат сотрудников отдела X из таблички employee, зарплата лежит в колонке salary"
И вот Вам кандидат пишет
select count(salary) from employee
Дадите ему подсказку или просто поставите жирный минус и завалите его полностью?
Лично я, наверное, спрошу, что он этим хотел сказать, может быть задам вопрос про агрегирующие функции, какие ещё бывают. То есть и не подскажу, и возможность поправится дам.
Хотя пример хороший, наглядный. А с where по отделу - это уже высший пилотаж?
Это не является реальными задачами на интервью, так как мы работаем с базами данных, то и вопросы на порядок сложнее, но зачем нам это здесь, это было просто примером, который поймет большинство?
Лично я, наверное, спрошу, что он этим хотел сказать, может быть задам вопрос про агрегирующие функции, какие ещё бывают.
Своим вопросом Вы и даёте тот самый hint (подсказку), что кандидату надо обратить внимание на конкретную часть кода. Возможно, прямой перевод слова hint не несёт того смысла, который закладывается в него.
Сначала я предложу перечитать вопрос, если после прочтения кандидат не увидит ошибки, то скорее всего попытаюсь обратить наводящим вопросом на конкретную часть кода (как Вы, когда это возможно), потом попрошу провести дебагинг того, что он написал и что будет выведено, пожалуй в последнюю очередь я могу явно указать на ошибку в функции (это случается, но не часто)
Давайте все-таки подразумевать хорошие намерения обеих сторон. Например, что в задаче есть несколько правильных решений и несколько тупиковых (которые кажутся верными, но заваливаются на сложных граничных случаях).
Да, всё верно. Иногда всё более тривиально, кандидат мог неправильно прочитать задачу, упустить условие и т.п.
Не могу сказать за всех со 100% вероятностью, но мне кажется, что практически все интервьюеры с хорошими намерениями. Мы также тратим своё время и мне очень хочется, чтобы оно было потрачено с пользой для компании - нанять хорошего специалиста. Фактически каждый интервьюер тратит 3+ часа на одно интервью (подготовка, интервью, написание фидбека, коммитет), а их 4-5 + еще phone screening + рекрутер, который Вас ведет.
Никто не хочет завалить кандидата, это уже саботаж :)
После статьи подумалось: вот поэтому гиганты вроде IBM уходят на второй план и прорывы делают какие-то google, но не Yahoo. Внутри такой "культуры" с бюрократией и рафинированным наборомотбором нет места отмороженным и фанатичным психам которые готовы родить чудо.
Так вот и живем в 21м веке, технари, софт-скиллзы метриками меряем, и по ним на работу берем. Прости, Юра, мы всё прое...
Гордость и предубеждение или собеседование русскоязычных на роль Database Engineer