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

Предисловие:
К собесу надо готовиться. Для чего? Почему? чтобы что? Если человек может подготовиться к собесу, то его практические навыки нафиг не нужны на этой работе и можно нанимать в принципе любого, кто прослушал курс Х или же сам его изучил.

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

Дизайн интервью
Этот кейс более приближен к реальности, но когда дают запроектировать фейсбук или ютуб за 3 часа, то какой смысл давать такое, если человек не будет писать этот фейсбук, а даже если и будет, то будет писать 3-4 сервиса.

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

И вот тут у меня закрадывается сомнение: сложность разработки по сути миф, достаточно взять любого человека, который может просто писать код. У больших IT компаний денег столько, что можно нанимать в принципе кого угодно кто проходит стартовый фильтр. Получается так, что ФААНГ действуют как картель, компанию с сильными спецами и готовым хорошим решением дешевле купить, чем писать такое у себя с нуля.

Мои собесы
За всю жизнь было собесов штук 20 наверное, года 1,5 назад собесился в амазон и завалил первую или вторую задачу литкода, до этого литкод не решал вообще никогда, хотя при этом писал фрейморки, продукты, плюс минус разбираюсь в инфраструктуре как в виндовой, так и в линуксовой, немного сетей и т.д. Наводил порядок в нескольких проектах(успещная борьба с лютым легаси и тех долгом + кривыми процессами), что менеджмент просто забывал о том, что такой проект есть.

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

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

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

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

Сформировать область пересечения интересов.

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

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

так же и с алгозадачами, например поиск подстроки палиндрома в строке и оптимальный алгоритм был предложен Гленном Манакером в 1975 году, уже тогда готовились к собесам
И вот когда дают такое на собесе и ожидают, что?
Если человек придумает такое решение, то наверное он гений или точно не ординарный человек и ему наверное можно давать какие-то другие сложные задачи, а не перекладывать жсоны в рест пользуясь ассойиативными контейнерами. А если человек заучил и повторил решение, то какую проблему он сможет решить?

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

Здравствуйте, diez_p, Вы писали:

_>Я не совсем понимаю что компании проверяют,

Часть интервью — это получение знаний друг о друге. Но всё в мире относительно, и кандидаты на собеседовании не исключение. Интервьюер всегда их сравнивает с другими — даже если проводит собеседование впервые, он сравнивает с собой и другими людьми, которых видел/общался. Так что многое на интервью ради сравнения, а не ради выяснения чего-то. Интервьюер задает какие-то задачи/вопросы на размышление, смотрит, как кандидат решает, как размышляет, сравнивает с другими — делает выводы о его относительном уровне.
Бывает даже не важно, решает кандидат задачу или нет — задача вообще может не иметь решения или иметь множество разных решений — акцент именно на том, как именно человек размышляет в сравнении с другими кандидатами.

То же по психологии и поведению.

Так же и в обратную сторону — кандидат сравнивает компании с другими — с теми, где еще собеседовался, где работал, а новичок так вообще с некими воображаемыми компаниями, про которые где-то что-то слышал.

_>Идеальный собес
_>1) Понять сильные и слабые стороны кандидата, как технические, так и психологические
_>2) Определить как и что из этого можно использовать у себя на проектах
_>3) Понять подходит ли компания человеку, его ожиданиям, целям в развитии и т.д.

Это не идеальное собеседование, а задачи собеседования.

_>И вот еще мысль была, почему-то все хотят стандартизировать процесс найма
...так давайте поучимся у него.

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

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

_>Вместо этого собес формализуют в этапах, чтобы чуть ли не обезьяна могла прособесить по методичке, но раз можно прособесить по методичке, то опять таки нанимаем по шаблону и что-то может в шаблон и не пролезет
Это нужно по причинам:
1. Когда человек только начинает собеседовать — ему нужна база, с чего начать. Дальше получит опыт и сам выработает свой подход.
2. Ресурсы "хороших интервьюеров" ограничены, так что да — нужны и те, кто по методичке — т.к. решить задачу хоть как-то лучше, чем не решить никак.

Здравствуйте, diez_p, Вы писали:

_>По другую сторону баррикад
_>Сейчас сам являюсь интервьювером по этим же самым алгозадачам, и вот если человек готовился и решал — то он их возможно решит, при этом бывают норм кандидаты(15 лет опыта во всяких ынтерпрайзах), где основная сложность не в алгоритме, а в понимании того, как весь этот зоопарк работает, то его даже не рассматривают. При этом позиция писать плюс минус такой же ыинтерпрайз с перекладыванием жсонов, в базенках там поковыряться, с людьми пообщаться. На возражения, что задачи не нужны, руководство упорствует.

Задачи не нужны, но показывают что человек по крайней мере что-то о них слышал, и имеет хоть какое представление об алгоритмической сложности, параллельной обработке и прочем.
По опыту даже при перекладывании жсонов в ентерпрайзе можно сделать одно и то же с разницей в производительности в десятки или сотни раз.
Живой пример из недавнего — есть ынтерпрайз система, один процесс постепенно обрабатывает записи в базе и обновляет их статус, второй ловит события обновлений в базе и обновляет общую статистику успешных/провальных/в процессе чтобы показать в интерфейсе.
Логически это всё вполне правильно, но поскольку первый процесс распараллелен он делает работу относительно быстро. А вот второй был написан так что он принимал сообщения по одному, конвертировал жсон из формата события, читал идентификатор записи и какой статус сменился на какой, потом делал +1 и -1 к нужным полям в таблице статистики. Обработка очереди всех обновлений статуса занимала на многие часы дольше чем собственно полезная работа, а юзеры видели интерфейс и думали что работа ещё идёт.
Теперь второй принимает сразу по тысяче сообшений, не тратит время на конвертирование а читает нужные данные прямо так, подсчитывает сколько статусов перешло в какие в этой тысяче и потом делает одно обновление сводной статистики, это ускорило его примерно в 400 раз.

Здравствуйте, Pyromancer, Вы писали:

P>Здравствуйте, diez_p, Вы писали:

_>>По другую сторону баррикад
P>Теперь второй принимает сразу по тысяче сообшений, не тратит время на конвертирование а читает нужные данные прямо так, подсчитывает сколько статусов перешло в какие в этой тысяче и потом делает одно обновление сводной статистики, это ускорило его примерно в 400 раз.

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

Здравствуйте, diez_p, Вы писали:

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

Потому, что требованиям удовлетворяло? Удовлетворяло! Code review проходило? Проходило! Тесты прошли? Тоже прошли!

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

Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, diez_p, Вы писали:

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

Pzz>Потому, что требованиям удовлетворяло? Удовлетворяло! Code review проходило? Проходило! Тесты прошли? Тоже прошли!

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

Pzz>Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!

Да, пока объемы данных были маленькие было неочевидно — юзеры видят в интерфейсе что работа идёт, прогрессбар двигается, есть несколько минут выпить кофейку, жалоб нет. Проходит почти год с начала использования, входных данных вкидывают больше в тысячу раз чем было, уже не "кофейку выпить" а "запустить и проверить завтра", и начинают жаловаться что что-то оно долго.
Больше половины проблемы была даже не в батчинге а в десериализаторе, чтобы потом прочесть 3 значения из многокилобайтного объекта. Там разработчик и не подозревал насколько медленную операцию применил: десериализатор из стандартной библиотеки, так что поискав примеры в интернете любой подумает "все так делают".

Здравствуйте, Pyromancer, Вы писали:


P>Больше половины проблемы была даже не в батчинге а в десериализаторе, чтобы потом прочесть 3 значения из многокилобайтного объекта. Там разработчик и не подозревал насколько медленную операцию применил: десериализатор из стандартной библиотеки, так что поискав примеры в интернете любой подумает "все так делают".

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

_>входной порог на собес
_В_ собес https://ru.wiktionary.org/wiki/собес ходят обивать пороги чтобы исхлопотать пенсию.

On Jul 16, 2024, 10:46 AM, diez_p <81585@users.rsdn.org> wrote:

DP>И вот когда дают такое на собесе и ожидают, что?

Задачи — это всего лишь следствие конкуренции на рынке труда. Не ищите здесь никакой рациональной подоплеки. И тем более, недоумевать по поводу того, что на работе "формошлеперство", а на собеседование тебя тягают от дизайна архитектуры до задач и обратно. Когда инженеров разработки была нехватка, то готовы были брать любого с улицы без собесов, который прочитает "We are hiring" в ASCII на рекламном щите или знает ответ на "как сдвинуть гору Фудзи". Сейчас конвеер. Тебя выжимают 2-4 года, затем твое место занимает такой же клон тебя 2-4 года давности. Клон с такими же ожиданиями и иллюзиями. И все по кругу.

DP>А если человек заучил и повторил решение, то какую проблему он сможет решить?

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

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

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

Здравствуйте, Pzz, Вы писали:
Pzz>Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!

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

По фаанг могу ошибаться, но у меня сложилось такое впечатление, что там всё настолько отличается от остальных компаний, что опыт очень часто иррелевантен. Ну есть у тебя опыт работы с git, а в гугле там своя VCS. Есть у тебя опыт работы со спрингом, а в гугле ты его использовать не будешь, ты будешь первые полгода изучать их внутренние библиотеки.

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

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

Здравствуйте, diez_p, Вы писали:

Pzz>>Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!

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

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

Здравствуйте, r0nd, Вы писали:

R>Задачи — это всего лишь следствие конкуренции на рынке труда.

100% согласен.

R>Имхо, самая важная черта инженеров разработки найти оптимальное решение в состоянии стресса. Поэтому на собесе главное отсеять явный неликвид (типа алкаши или нарков) и нанять того, кто похож на человека находящего оптимальное решение в состоянии стресса.

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

Здравствуйте, diez_p, Вы писали:

_>Есть набор компаний, у которых входной порог на собес — решение алгозадач, далее идет дизайн секция, на которой за 3часа делают фейцбух, ютуп итп

Я уже как-то писал здесь об этом. Нужно балансировать текущую работу с подготовкой к собеседованиям всё время, а не за месяц до.

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

если бы разработчика можно было так же легко уволить/разойтись
как и нанят
то все эти собесы уменьшились бы на 95%

а поскольку этого нет
то зарплатодатель
уменьшает свои риски методом отбора

эффективный ли этот отбор?
решает уже сам работодатель своим кошельком

On Jul 17, 2024, 12:51 AM, Ip Man <133900@users.rsdn.org> wrote:

IM>А с какого хрена "инженеры разработки" должны находиться в стрессе? Надеюсь, что зарплата стоит того, ибо стресс — прямая дорога к проблемам со здоровьем и ранней смерти.

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

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

Здравствуйте, diez_p, Вы писали:

_>Здравствуйте, diez_p, Вы писали:
_>И есть еще один тонкий момент, даже психологическая ловушка.
_>Мне всегда было интересно, как работает мозг всяких коши, дирихле, риманов и лебегов, ну или перельмана.
_>Т.е. эти крайне сообразительные граждане решали какую-то задачу, которая не была решена, сидели думали, тратили время и по итогу получали какое-то решение, которое остается потом в книжках на века. Позже большинство только пытается понять и применить их решение. И вот в этот момент появляется психологическая ловушка, что если я знаю интегрирование дифференцирование и прочее, то я хоть как-то становлюсь ближе к этим гражданам, но нет. Чтобы встать с ними на одну ступень, надо решить какую-то похожую проблему.

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


_>так же и с алгозадачами, например поиск подстроки палиндрома в строке и оптимальный алгоритм был предложен Гленном Манакером в 1975 году, уже тогда готовились к собесам
_>И вот когда дают такое на собесе и ожидают, что?
_>Если человек придумает такое решение, то наверное он гений или точно не ординарный человек и ему наверное можно давать какие-то другие сложные задачи, а не перекладывать жсоны в рест пользуясь ассойиативными контейнерами. А если человек заучил и повторил решение, то какую проблему он сможет решить?

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

Здравствуйте, diez_p, Вы писали:

Pzz>>Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!
_>я про другое говорил, что первый знал, что проблема есть, т.е. юзеры уже страдают, почему бы не переделать на нормальную реализацию?

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

Здравствуйте, diez_p, Вы писали:

_>Дизайн интервью
_>Этот кейс более приближен к реальности, но когда дают запроектировать фейсбук или ютуб за 3 часа, то какой смысл давать такое, если человек не будет писать этот фейсбук, а даже если и будет, то будет писать 3-4 сервиса.

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