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

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

по моему ощущению — не соглашусь

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

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

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


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

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

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

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

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

_>Если человек придумает такое решение, то наверное он гений или точно не ординарный человек

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

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

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

Или например, писал программист на питоне, а им понадобился программист на C++. Ничего страшного — этого переучим!

vsb>Поэтому они в первую очередь смотрят на "живость ума", а не на то, какие ты проекты поднимал.

К этим собеседованиям готовятся, потому что иначе хрен пройдешь. И эта подготовка работает. Все готовятся, без исключений. Если говорят, что не готовятся — пи*дят. (Кстати, к вопросу о живости ума, ты сообщение ТСа вообще прочитал?)
Более того, даже многие хрюши говорят что надо готовиться, и это уже совсем за гранью бреда.
Хотя на самом деле, корреляция действительно есть. Но не с живостью ума, а с готовностью выполнять любые указания, независимо от того, насколько они нелепы. Именно это они и тестируют.

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

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

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

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

P>Живой пример из недавнего

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

P>Обработка очереди всех обновлений статуса занимала на многие часы дольше чем собственно полезная работа

Интеграционных тестов не было? Тестеров не было?

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

Pzz>оба открещиваются

Точно?

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

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

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

_> Т.е. человек, который банально поднатаскался с не очень релевантным опытом может вполне пройти собес.

Верно. Проверяется не набор знаний, а то, может ли человек что-то изучить (подготовиться). Потому что 99% времени его работы в конторе будет как раз изучение каких-то существующих легаси систем. Где-то допилить, где-то переделать, где-то скопировать.

Почему так? Да потому, что если человек смог по-быстрому научиться, — это ценный кадр.

_> до этого литкод не решал вообще никогда, хотя при этом писал фрейморки, продукты, плюс минус разбираюсь в инфраструктуре как в виндовой, так и в линуксовой, немного сетей и т.д. Наводил порядок в нескольких проектах

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

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

Проблема (1) в том, что формат собеседования редко когда помогает выявить эти самые сильные и слабые стороны. Человек, как правило, вообще не раскрывается в первые недели, а то и месяцы, работы с ним.

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

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

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

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

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

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



Человек общается сам с собой и процессе общения меняет точку зрения. Шизофрения это всегда нескучно

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

R>Сейчас конвеер. Тебя выжимают 2-4 года, затем твое место занимает такой же клон тебя 2-4 года давности. Клон с такими же ожиданиями и иллюзиями. И все по кругу.
Видимо мне надо куда-то двигаться в более инженерную или научную сферу. Либо действительно дефицита в IT кадрах нет в принципе и сито в виде алгозадач вполне себе устраивает и работает.

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

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

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

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

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

C>

C>Человек общается сам с собой и процессе общения меняет точку зрения. Шизофрения это всегда нескучно

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

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

P>Если требуется взять на работу три человека, а желающих выстроилось аж три тысячи, то как поступить работодателю?

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

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

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

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

Вроде глупо конечно, а как отбирать если много желающих?

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

P>разработчик и не подозревал насколько медленную операцию применил: десериализатор из стандартной библиотеки, так что поискав примеры в интернете любой подумает "все так делают".

С++ ?

Какая хреновая стандартная библиотека.

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

M>Еще появляется риск, что профессиональные навыки и умения проходить собеседования — это разные вещи.

Это не риск, это гарантировано.

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

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

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

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

Если же релиз это подвиг, то что-то не так. И в состоянии нехватки времени пишут так себе код. Тесты, естественно, в этот момент никто не добавляет. Хорошо, если потом это всё разгребут.

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

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

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

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

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

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

И как теперь это исправить? Наверное надо взять ещё одного человека, который знает что-то про сложность задач и слышал, что алгоритм с квадратичной сложностью работает медленнее, чем с линейной. Что-то мне кажется не поможет. Надо взять человека, который будет упорно разбираться что происходит и попутно пытаясь хоть как-то ускорить программу. Причём почти наверняка вариант написать заново не подходит, т.к. часть багов стало фичами и много программ от них зависят. Естественно это всё незадокументированно. А люди, которые это писали, либо уволились, либо у них амнезия и ничего полезного рассказать не могут.