Здравствуйте, Baiker, Вы писали:
B>Получается, что мы, ветераны отрасли, даже и показать-то ничего не можем, кроме целлюлита. B>Как быть, кого бить, что делать?
Попросить и сделать тестовое задание. Или online coding, где можно что-то обсудить.
Здравствуйте, Codealot, Вы писали:
C>Профессионализм в программировании, и профессионализм в пролезании в любую дырку без мыла — не одно и то же.
спору нет, но я вообще не это подразумевал.
я вот что имел ввиду: по-моему, если мы ведём речь о действительно высококлассном профессионале, то всё происходит наоборот.
то есть не он ищет работу, а работа ищет его.
Здравствуйте, mike_rs, Вы писали:
_>если же где-то собеседующие вообще не относятся к команде, куда идет набор — то оттуда надо бежать сразу.
В крупных (и даже в некоторых средних компаниях) используются формализованные процессы найма, в которых расписаны количество и типы собеседований. Собеседований может быть несколько, только часть из них будет проводится представителями команды, для которой открыта вакансия. Так, собеседования на уровень знания конкретного ЯП (или технологии) может проводить человек (или несколько человек) совсем из другой команды, просто потому, что за ним (ними) закреплена подобная роль. Аналогично и по собеседованиям на знания алгоритмов/структур данных, подходов к проектированию и т.д., и т.п.
И ничего с этим поделать нельзя, процесс есть процесс.
Бежать ли от компаний масштаба Яндекса, Касперского, Сбера, VK и пр. "гигантов" каждый решает для себя. Но многие специально ищут работу только в крупных компаниях, т.к. там есть свои плюшки, которых нет у мелких работодателей.
Здравствуйте, ути-пути, Вы писали:
vsb>>1. Опыт работы в крутых компаниях типа яндекса.
УП>В смысле, умение гонять туда-сюда json?
Ну как минимум — туда ещё попасть надо. Я слыхал, что там адские собеседования, по несколько часов мучают людей. Это как в МГУ и подобными университетами. В целом там не учат ничему такому, чему не учат в других университетах. Но жесточайший фильтр на входе даёт высокое качество студентов, и даёт возможность отчислять тех, кто учится плохо. В итоге средний выпускник таких университетов гораздо лучше среднего выпускника обычных университетов. Так и с яндексом.
А json-ы везде гонять надо.
Да и кроме json-ов, очевидно, там хватает алгоритмо-ёмких приложений. У них же куда ни плюнь — везде хайлоад.
Здравствуйте, Sharov, Вы писали:
S>>>Или online coding, где можно что-то обсудить. S>>ИМХО, это одна из худших вещей, практикующихся на собеседованиях
S>1)Почему?
Некоторым людям (включая меня) нужно прежде подумать, возможно, разрисовав несколько листочков каракулями или сделав несколько черновых набросков, а лишь затем начать писать код. Когда интервью идет он-лайн да еще и время его ограничено, то как-то сидеть и молчать перед веб-камерой пока на тебя недоуменно смотрят с другой стороны... Ну такое себе.
Некоторые люди сильно стрессуют на интервью. Этот стресс сказывается на способности писать код (особенно если человек привык это делать в какой-то определенной IDE, а не в той он-лайн системе, которую используют на собеседовании). А осознание того, что ты не можешь хорошо себя показать именно в написании кода (т.е. в основной деятельности) стресс только усиливается и эта спираль давления еще больше раскручивается в худшую сторону.
Хотя, может для проверки джунов в написании сортировки пузырьком и нормально, не смотря на вышеперечисленные недостатки.
S>2)Чем те же code review на собесах плохи?
Тут нужно определиться: соискателю нужно на интервью код писать в online IDE или же посмотреть на уже написанный кем-то код и высказать свое "фи"?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Baiker, Вы писали:
B>>Как программисту доказать, что он — профи высшего класса?
IT>Программист должен уметь программировать, а не доказывать уровень своей компетентности. Выяснять уровень компетентности — это задача работодателя.
IT>Если ты "профи высшего класса" и тебе задают только дебильные вопросы на интервью, то ты там не хочешь работать и доказывать никтому ничего не надо.
IT>Нормальный работодатель может выстроить всё интервью вокруг одной задачи. Сначала попросить тебя написать простое решение, потом начать усложнять условия и всё с тобой в конце концов станет ясно.
Это хороший сценарий из нулевых годов. У работодателя есть бизнес-идея и свободная ниша, он подбирает
"профи высшего класса" который перельет первое во второе.
А теперь один из современных сценариев. Работодатель это подросший "профи" из нулевых. И тут перед ним
появляется некий "профи высшего класса"... дальше уже все понятно.
Здравствуйте, mike_rs, Вы писали:
_>ты сколько собеседований провел?
Я думаю, побольше тебя.
_>цель собеседования — понять, подходит ли в вашу команду на конкретную должность именно этот кандидат. При этом собеседующий точно знает какие навыки нужны работнику на том месте, куда его планируют взять и выясняет, сможет ли кандидат потянуть эту лямку
Это в теории. А на практике, сначала кандидата долго выспрашивают про знание X, а потом внезапно оказывается, что на самом деле в основном нужно знание Y, которое к X вообще никак не относится. Примеров такого я видел немало.
А часто и вовсе спрашивают какой-нибудь Z, например алгоритмические задачи, которые ни к X ни к Y никакого отношения не имеют.
_>и насколько он вообще адекватен в общении.
А на всех предыдущих собеседованиях этого выяснить не смогли. Только на данном конкретном собеседовании сидят умные люди, а во всех остальных компаниях не знают, с какой стороны надевать на вилку еду.
Вот ты и подтверждаешь ровно то, что я только что написал.
_>если же где-то собеседующие вообще не относятся к команде, куда идет набор — то оттуда надо бежать сразу.
То есть, практически из любой компании крупнее чем "десяток студентов в подвале" придется бежать.
Здравствуйте, LuciferSaratov, Вы писали:
LS>я вот что имел ввиду: по-моему, если мы ведём речь о действительно высококлассном профессионале, то всё происходит наоборот. LS>то есть не он ищет работу, а работа ищет его.
Если только ты достаточно крут, чтобы быть знаменитым. Но, опять же, пиар — это отдельный талант.
Здравствуйте, Codealot, Вы писали:
C>Это в теории. А на практике, сначала кандидата долго выспрашивают про знание X, а потом внезапно оказывается, что на самом деле в основном нужно знание Y, которое к X вообще никак не относится. Примеров такого я видел немало. C>А часто и вовсе спрашивают какой-нибудь Z, например алгоритмические задачи, которые ни к X ни к Y никакого отношения не имеют.
зачем ты это делаешь?
C>А на всех предыдущих собеседованиях этого выяснить не смогли. Только на данном конкретном собеседовании сидят умные люди, а во всех остальных компаниях не знают, с какой стороны надевать на вилку еду.
на каких предыдущих? у HR-а что ли? речь о техническом собеседовании в команду, если что
C>Вот ты и подтверждаешь ровно то, что я только что написал.
абсолютно нет
C>То есть, практически из любой компании крупнее чем "десяток студентов в подвале" придется бежать.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>>>Или online coding, где можно что-то обсудить. S>>>ИМХО, это одна из худших вещей, практикующихся на собеседованиях S>>1)Почему? S>Некоторым людям (включая меня) нужно прежде подумать, возможно, разрисовав несколько листочков каракулями или сделав несколько черновых набросков, а лишь затем начать писать код. Когда интервью идет он-лайн да еще и время его ограничено, то как-то сидеть и молчать перед веб-камерой пока на тебя недоуменно смотрят с другой стороны... Ну такое себе. S>Некоторые люди сильно стрессуют на интервью. Этот стресс сказывается на способности писать код (особенно если человек привык это делать в какой-то определенной IDE, а не в той он-лайн системе, которую используют на собеседовании). А осознание того, что ты не можешь хорошо себя показать именно в написании кода (т.е. в основной деятельности) стресс только усиливается и эта спираль давления еще больше раскручивается в худшую сторону.
Увы, это так. А что особого стресовать на алгоритмических задачах -- размышляй в слух, особого
знания языка они не требуют. Тут надо тупо практиковаться, т.е. набивать руку на самих задачах+
проходить mock-интервью. Сейчас полно таких услуг. Лично я считаю, что средней сложности алг.
задачки вполне посильно писать и онлайн, т.е. если человек неплохо подкован в алгоритмах, то
особых проблем не будет. Но идеально это все же тестовое задание, приближенное к реальности, и его последующее
обсуждение. Вероятно, это подход не очень масштабируется для FAANG конвейера. Все-таки надо вникать в решение
соискателя, что может потребовать сущ. больше времени.
S>Хотя, может для проверки джунов в написании сортировки пузырьком и нормально, не смотря на вышеперечисленные недостатки. S>>2)Чем те же code review на собесах плохи? S>Тут нужно определиться: соискателю нужно на интервью код писать в online IDE или же посмотреть на уже написанный кем-то код и высказать свое "фи"?
И то, и то -- сказать фи и исправить на "как надо". Объеменой писанины не требуется, т.е. даже не надо,
чтобы код компилировался.
Здравствуйте, mike_rs, Вы писали:
_>зачем ты это делаешь?
А что, есть выбор? Во всех мало-мальски крупных компаниях это делается именно так, да и многие мелкие пытаются это копировать.
_>на каких предыдущих? у HR-а что ли? речь о техническом собеседовании в команду, если что
Речь о всех собеседованиях в предыдущие компании. Там что, не могли выяснить, насколько человек вообще адекватен в общении, и только тебе лично это под силу? А может, ЧСВ надо немного успокоить?
Здравствуйте, Sharov, Вы писали:
S>Лично я считаю, что средней сложности алг. S>задачки вполне посильно писать и онлайн, т.е. если человек неплохо подкован в алгоритмах, то S>особых проблем не будет.
Нанятый после online-coding-а специалист у вас на работе будет:
a) решать алгоритмические задачи и
b) будет вслух рассуждать при их решении?
Если хотя бы по одному из этих пунктов получается "нет", то с высокой долей вероятности на собеседовании вы будете проверять не тот целевой признак.
S>Но идеально это все же тестовое задание, приближенное к реальности, и его последующее S>обсуждение.
Это очень и очень далеко от online-coding-а на собеседовании. И да, если это делается нормально со стороны работодателя, то это очень затратно для самого работодателя.
S>И то, и то -- сказать фи и исправить на "как надо". Объеменой писанины не требуется, т.е. даже не надо, S>чтобы код компилировался.
Мне тут давеча интересная статья на глаза попалась: Захватывающая ловля багов, которые портили работу Unbound. И в контексте разговора про "исправить на "как надо"" хочется спросить: а что же там люди, имея исходники на руках, не посмотрели, не разобрались по коду, не сделали как надо? Вместо этого они долго ловили моменты возникновения проблем и использовали специализированные инструменты чтобы понять что и как происходит.
В том-то и дело, что если соискателю предлагать простые задачки, которые можно проверить в условиях стресса и ограниченного времени, вроде вот такой:
void f() {
int * buf = new int[40960];
...
delete buf;
}
то это опять-таки будет проверка не того целевого признака. Т.к. в реальности придется разбираться с проблемами как из упомянутой статьи. И умение быстро вылавливать "типовых блох" в тривиальном коде здесь не поможет.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Лично я считаю, что средней сложности алг. S>>задачки вполне посильно писать и онлайн, т.е. если человек неплохо подкован в алгоритмах, то S>>особых проблем не будет.
S>Нанятый после online-coding-а специалист у вас на работе будет:
S>a) решать алгоритмические задачи и S>b) будет вслух рассуждать при их решении?
S>Если хотя бы по одному из этих пунктов получается "нет", то с высокой долей вероятности на собеседовании вы будете проверять не тот целевой признак.
лет 15 назад я тоже скептически относился к алгоритмическим задачам на собеседованиях.
Сейчас мнение поменялось на ровно противоположное.
умение решить такие задачи — базовый навык программиста.
Тоже самое как повара могут проверить на умение шинковки например, или столяра как он гвоздь забъет и не будет ли вбивать шурупы. Хотя и в том и в другом случае это не целевой навык, повара берут готовить блюда, а столяра делать мебель.
Что касается "посидеть — подумать" — по моему опыту это вполне коррелирует с общей производительностью человека в дальнейшем. если есть два равных человека — один быстрый как пчела другому надо посидеть подумать — я выберу первого. не один раз приходилось расставаться с людьми за низкую производительность, когда на собеседовании убедили себя что он не медленный а обстоятельный
