Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Я несколько раз сталкивался с подобными требованиями. Связано было с заковыристой предметной областью.
SVZ>Системные аналитики не в состоянии в разумные сроки расписать требования к задаче (да и разработчик не в состоянии всё это потом прочесть и удержать в голове), поэтому часть требований остаётся недокументированными в расчете на то, что разработчик понимает, о чём идёт речь.

Э... А как это оправдывает то, что на собеседование тратиться всего час (включая и вопросы от HR)?

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

S>А то код, видите ли, просят написать

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

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

Условно: опытный программист наверняка развернет вам на собеседовании двусвязный список. Сложного в этом ничего нет. Но в условиях стресса самого собеседования и непривычных условий (то же online IDE далеко не для всех привычный инструмент) выглядеть это будет коряво. И тут возникает вопрос: а насколько произведенное впечатление будет соответствовать потенциальным возможностям соискателя?

Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее? Например, поспрашивайте, видит ли соискатель место для таких структур данных? Не лучше ли использовать vector? Или deque? Если list таки лучше vector, то в каких условиях? Применял ли соискатель списки? Каким образом он принимал решения об их применении?

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

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

S>Э... А как это оправдывает то, что на собеседование тратиться всего час (включая и вопросы от HR)?

Когда я набирал, то часа было достаточно, чтобы оценить, что человек знает.
Ну и не исключено, что "час" это словесный оборот, на деле может оказаться и два-три часа

Здравствуйте, Stanislav V. Zudin, Вы писали:

S>>Э... А как это оправдывает то, что на собеседование тратиться всего час (включая и вопросы от HR)?

SVZ>Когда я набирал, то часа было достаточно, чтобы оценить, что человек знает.

Знания-то ладно, особенно если область специфическая.
Но ведь есть и еще одна, не менее важная сторона: захочется ли с таким человеком работать.

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

SVZ>Ну и не исключено, что "час" это словесный оборот, на деле может оказаться и два-три часа

Ну пока что есть точная цитата: "У нас сейчас на собес разработчика дается 1 час на все — общее интервью с вопросами об опыте, вопросами о проекте и компании, техническая часть. HR тоже свои вопросы задает." Здесь неоткуда взяться двум-трем часам

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

S>Знания-то ладно, особенно если область специфическая.

Это так.

S>Но ведь есть и еще одна, не менее важная сторона: захочется ли с таким человеком работать.

S>За час запросто можно понять, что с человеком работать не хочется. С этим соглашусь (хотя, опять же, а как защититься от того, что первое впечатление было неправильным?)

ИМХО первого впечатления вполне достаточно. Не зацепило и ладно, каждый найдёт себе работу/работника по вкусу.

SVZ>>Ну и не исключено, что "час" это словесный оборот, на деле может оказаться и два-три часа

S>Ну пока что есть точная цитата: "У нас сейчас на собес разработчика дается 1 час на все — общее интервью с вопросами об опыте, вопросами о проекте и компании, техническая часть. HR тоже свои вопросы задает." Здесь неоткуда взяться двум-трем часам

Видимо полагаются на чутье. Если результат их устраивает, значит всё правильно делают

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

SVZ>>Неа, не в этом дело. Вот получается на выходе талмуд в полторы тыщщи страниц. И как такой объём переваривать?

C>А как переваривать тот же объем информации, да еще и без доков? Бред какой-то.

Если ты уже в предметной области, то половина информации, считай, уже в голове.

SVZ>>В качестве примера возьми последний стандарт с++ и напиши по нему с нуля оптимизирующий компилятор. Архитектуру процессора предлагается изучить дополнительно
SVZ>>Если никогда не занимался подобными задачами осилишь?

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

Ну давай возьмём пример попроще. Прочитать/записать какой-нибудь dxf, odb++, docx. Это по силам?
Документация на ODB++ всего 500 с копейками страниц. Написать парсер с преобразованием сырых данных в нечто высокоуровневое, пригодное для работы редактора, тянет на 10 чел/мес — работа на одного, максимум на троих.
Правда, если ты не знаком с проектированием и производством печатных плат, то даже не найдёшь ошибку — ни в коде, ни в данных.

Но это всё лирика.

Получается, есть два подхода:
1. Берём программиста, знакомого с предметной областью, и он всё делает. Возможно, не в одиночку.
2. Берём команду программистов общего назначения и в придачу к ним "няньку", которая будет писать ТЗ и разжевывать, что именно им надо делать.

Довелось поработать и по первому варианту, и по второму. Ты, насколько я понимаю, привык ко второму варианту.

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

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

S>Некоторые видят проблему в том, что написание кода на интервью (а это наверняка какая-то несложная алгоритмическая задачка) сильно не похоже на написание кода в реальном проекте (даже если в реальном проекте нужно делать что-то алгоритмически сложное). Соответственно, проверяется не тот навык.
S>Да, корреляция, в принципе, будет сильная вот в каком плане: хороший программист и в условиях интервью сможет более-менее что-то нормальное выдать. Но этот процесс может выглядеть... непрезентабельно, скажем так. И выглядеть этот условный хороший программист на собеседовании будет хуже, чем тот, кто вымуштрован на решение подобных простеньких задачек.
S>Условно: опытный программист наверняка развернет вам на собеседовании двусвязный список. Сложного в этом ничего нет. Но в условиях стресса самого собеседования и непривычных условий (то же online IDE далеко не для всех привычный инструмент) выглядеть это будет коряво. И тут возникает вопрос: а насколько произведенное впечатление будет соответствовать потенциальным возможностям соискателя?

Мы же выше это уже обсудили -- все это так, но крупные компании идут на это, т.к. для них лучше не нанять хорошего
программиста, чем нанять плохого. Увы, компромиссы. Для менее крупных компаний -- тестовое на дом, с обсуждением,
кажется ок.



S>Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее? Например, поспрашивайте, видит ли соискатель место для таких структур данных? Не лучше ли использовать vector? Или deque? Если list таки лучше vector, то в каких условиях? Применял ли соискатель списки? Каким образом он принимал решения об их применении?

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

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

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

S>>За час запросто можно понять, что с человеком работать не хочется. С этим соглашусь (хотя, опять же, а как защититься от того, что первое впечатление было неправильным?)

SVZ>ИМХО первого впечатления вполне достаточно. Не зацепило и ладно, каждый найдёт себе работу/работника по вкусу.

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

SVZ>Видимо полагаются на чутье. Если результат их устраивает, значит всё правильно делают

Вот и интересно узнать в каких условиях это работает. И работает ли.

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

S>Мы же выше это уже обсудили -- все это так, но крупные компании идут на это, т.к. для них лучше не нанять хорошего
S>программиста, чем нанять плохого.

Так ведь решение около-олипиадных задачек не показатель "хорошести" для программиста. Вот в чем дело.

S>Для менее крупных компаний -- тестовое на дом, с обсуждением,
S>кажется ок.

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

S>У такого способа есть проблема, что про структуры
S>данных и алгоритмы можно реально выучить, не скомпилировав при это ни одной программы.

Зазубрить можно описания структур данных и оценки сложности тех или иных операций. Но зазубрить цепочку рассуждений... Не верится. Вы вот сами попробуйте ответить на общие вопросы вроде "Сохраняет ли сейчас актуальность такая структура данных, как связанный список? Почему вы так думаете? Согласны ли с тем, что vector всегда предпочтительнее? Если да, то почему? Если нет, то можете привести пример, где список предпочтительнее?"

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

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

S>>>За час запросто можно понять, что с человеком работать не хочется. С этим соглашусь (хотя, опять же, а как защититься от того, что первое впечатление было неправильным?)

SVZ>>ИМХО первого впечатления вполне достаточно. Не зацепило и ладно, каждый найдёт себе работу/работника по вкусу.

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

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

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

Мы рассказывали, что мы делаем, кандидат рассказывал, что и как он делал. Обсуждали наши предстоящие задачи, на которые и искали кандидата.
Прикидывали, что для этого потребуется. Кандидат сам предлагал варианты решения.
Как раз часа — полтора достаточно, чтобы всё обсудить и сформировать впечатление.
Предполагается, что кандидат про виртуальный д-тор слышал и знает, как его применять. Это выясняется невзначай по ходу разговора.
Скажем так, ошибки из-за собственно с++ у нас возникали на порядки реже (за последние 10 лет раза три и то из-за невнимательности), чем проколы в алгоритмах.

SVZ>>Видимо полагаются на чутье. Если результат их устраивает, значит всё правильно делают
S>Вот и интересно узнать в каких условиях это работает. И работает ли.

+1.

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

SVZ>Ты так говоришь, будто впечатление создаётся одномоментно.

Говорю потому, что первое впечатление может (и бывает) обманчивым. И чем длиннее общение, тем меньшее влияние оказывает именно первое впечатление. Лучше потратить лишние 30 минут на собеседовании, чем узнать, что с человеком не сработаешься уже на испытательном сроке.

SVZ>Как раз часа — полтора достаточно, чтобы всё обсудить и сформировать впечатление.

Ну вот полтора часа общения -- это да, это оптимальный срок. Больше -- уже можно начать уставать (да и выкраивать это время сложнее).
Меньше как-то не то. Разве что собеседуется молодой программист, с небольшим опытом.

Опять же, собеседование же не только для тех, кто нанимает. Но и соискатель так же должен иметь возможность задать свои вопросы чтобы составить впечатление для себя. В полтора часа уложиться еще можно, в час -- сложнее. ИМХО.

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

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

Ну вот бигтех так решил. К тому же это все-таки не олимпиадные задачи, а вполне обычные. Речь
идет о том, чтобы прорешать порядка 100 задач литкоде.

S>>Для менее крупных компаний -- тестовое на дом, с обсуждением,
S>>кажется ок.
S>Это сильно зависит от рынка, имхо. В крупном городе с большим количеством вакансий тестовое на дом -- это отпугивание большого количества соискателей. В небольшом городе, где всего 3-4 вменяемых работодателей, это может и сработать. Но опять таки, зависит от состояния рынка. Тем более, что он сейчас еще более глобальный, чем года три назад.

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

S>>У такого способа есть проблема, что про структуры
S>>данных и алгоритмы можно реально выучить, не скомпилировав при это ни одной программы.
S>Зазубрить можно описания структур данных и оценки сложности тех или иных операций. Но зазубрить цепочку рассуждений... Не верится. Вы вот сами попробуйте ответить на общие вопросы вроде "Сохраняет ли сейчас актуальность такая структура данных, как связанный список? Почему вы так думаете? Согласны ли с тем, что vector всегда предпочтительнее? Если да, то почему? Если нет, то можете привести пример, где список предпочтительнее?"

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

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

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

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

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

S>К тому же это все-таки не олимпиадные задачи, а вполне обычные.

Вполне обычные для студентов первого курса. Когда университет оставлен за спиной десяток (а то и несколько десятков) лет назад, то все эти задачки они как будто из другой вселенной. Да, вполне по силам, но непривычно, по крайней мере.

S>Речь идет о том, чтобы прорешать порядка 100 задач литкоде.

Допустим, по полчаса на задачу. Это уже 50 часов. Больше полной 40-часовой рабочей недели. Не лучше ли потратить их на что-то другое?

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

S>В чем проблема провести один день, вечер, пару часов, решая задачу для фирмы, куда очень хочешь попасть?

Как минимум, такой фирмы (куда очень хочешь попасть) может и не быть. Далеко за примерами ходить не нужно: если бы у меня сейчас спросили, куда бы хотел, то не смог бы ни одного названия сказать.

Еще вполне может оказаться, что тестовое не на один вечер.

S>Блин, неугодишь: алгоритмы -- плохо, тестовые -- плохо.

Да, жизнь, сука, суровая штука

S>Надо знать для каждой структуру сложность операций, и в зависимости от задачи и компромисса выбирать.

Ну вот такие рассуждения вполне могут выдать и сферического теоретика. Ибо, условно, вставка в list -- это O(1), но если мы говорим о C++, то это O(1) может запросто умножиться на стоимость динамической аллокации и все, вставка в середину вектора (в котором capacity > size) запросто может оказаться дешевле.

S>Если много операций вставки, то сс лучше, если много поиска -- то массив.

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

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

S>Мы же выше это уже обсудили -- все это так, но крупные компании идут на это, т.к. для них лучше не нанять хорошего
S>программиста, чем нанять плохого.

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

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

S>Зазубрить можно описания структур данных и оценки сложности тех или иных операций. Но зазубрить цепочку рассуждений... Не верится.

Типичные задачи зубрят только в путь. Особо упертые — месяцами.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Если ты уже в предметной области, то половина информации, считай, уже в голове.

Так выглядит разумнее А то формулировка была странная.

SVZ>Ну давай возьмём пример попроще. Прочитать/записать какой-нибудь dxf, odb++, docx. Это по силам?
SVZ>Документация на ODB++ всего 500 с копейками страниц. Написать парсер с преобразованием сырых данных в нечто высокоуровневое, пригодное для работы редактора, тянет на 10 чел/мес — работа на одного, максимум на троих.
SVZ>Правда, если ты не знаком с проектированием и производством печатных плат, то даже не найдёшь ошибку — ни в коде, ни в данных.

Так прочитать/записать, или провалидировать? Это разные вещи.

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

S>Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее?

Правильный ответ — "связные списки не нужны практически никогда"?

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

S>>Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее?

C>Правильный ответ — "связные списки не нужны практически никогда"?

В вопросах на "порассуждать" нет правильных ответов (с) Однако, как-то так, да

Правда, в случае C/C++/Rust для списков (особенно интрузивных) применимость может быть найдена, и как раз об этом было бы интересно побеседовать.

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

S>Правда, в случае C/C++/Rust для списков (особенно интрузивных) применимость может быть найдена, и как раз об этом было бы интересно побеседовать.

Вместо rope? А зачем?

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

SVZ>>Ну давай возьмём пример попроще. Прочитать/записать какой-нибудь dxf, odb++, docx. Это по силам?
SVZ>>Документация на ODB++ всего 500 с копейками страниц. Написать парсер с преобразованием сырых данных в нечто высокоуровневое, пригодное для работы редактора, тянет на 10 чел/мес — работа на одного, максимум на троих.
SVZ>>Правда, если ты не знаком с проектированием и производством печатных плат, то даже не найдёшь ошибку — ни в коде, ни в данных.

C>Так прочитать/записать, или провалидировать? Это разные вещи.

Под "прочитать" я подразумеваю получить на выходе данные, пригодные для работы.
Т.е. тут и преобразование данных из одного вида в другой, и валидация, и восстановление недостающих/кривых данных.
А просто парсер накарябать — это задача уровня курсовика для студента.