Pull to refresh

Comments 392

Я так и не понял является ли автор профессиональным программистом или профессиональным музыкантом. Кажется ни тем ни другим. При приеме на работу в оркестре музыкантов обычно тестируют по сборникам оркестровых сложностей по виду его инструмента. И все кто хочет играть в оркестре с этим сборником так или иначе работают. Что касается гамм — именно так на русском звучит слово scales — то если музыкант всю жизнь их не играет он рискует потерять скилы еслии это конечно не супергений которому это не нужно.


Что касается знания алгоритмов наверное при приеме на работу в ibm или ms это важно. Для 100500 вебстудии выглядит как лишнее. Хотя сам писал сортировку quicksort при приеме на работу.

Когда-то решал очень сложные тройные интегралы, сейчас квадратное уравнение с трудом решу. Почему так? Да потому что последний раз хоть какое-то уравнение решал 15 лет назад. Я даже задачку по геометрии 7 класса не решу. Это значит что у меня плохое образование? Нет это значит, что давно этого не делал и все забыл. То же самое с алгоритмами и даже синтаксисом языка. Помнишь только то, что делал последние 2-3 года. Зато помню как работает ядро postgress, оно кстати вообще на C написано, потому что буквально пол года назад писал к нему плагин. Помню как отлаживать в windbg, по когда у меня спросили какая функция будет вызвана в простой задачке на с++ я растерялся, действительно сложно удерживать в голове пару десятков правил которые подолгу не нужны и по большому счету применимы в выдуманном коде, причем в таком за написание которого реально уволят, т.к. он нарушает все правила и постулаты «хорошего» кода.
Но на практике есть огромная разница между состояниями «знал и разбирался, но уже подзабыл» и «никогда и не знал, но в случае надобности обещаю быстро нагуглить, чесслово!»

В первом случае действительно могут быть проблемы написать код сходу, но немного времени и справочных материалов — и всё отлично получится. А во втором даже с гуглежом реализация скорее всего получится кривая, потому что у человека нет понимания. Часто, кстати, даже нет понимания что конкретено нужно гуглить.
Но на практике есть огромная разница между состояниями «знал и разбирался, но уже подзабыл» и «никогда и не знал, но в случае надобности обещаю быстро нагуглить, чесслово!»

Да, и не всегда эта разница в пользу первых. Первые — это не только те, которые «если что, быстренько вспомнят», но и те, которые если что, схватятся за устаревшие в данный момент вещи, потому что когда они разбирались — это всё еще было актуально, но сейчас уже нет.

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

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

… на то и фундаментальные, что изучаются один раз и не забываются. Там не такой большой объем информации.
Разница только в том, кто что считает «фундаментальным». Некоторые и алгоритмы сортировки называют фундаментальными. Но да кто ж им доктор.

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

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

Никто ж не просит идеальную реализацию вспомнить. Я помню как один из кандидатов вообще «сортировку слиянием в стиле QuickSort» изобразил… сливая каждый раз в новый массив. И что? Это плохая сотрировка? Да — потому что память транжирит. Кандидат «всё понял», напрягся, сделал «merge-in-place» (хотя изначальная задача этого, в общем-то, не требовала), получил от меня хорошую оценку — видно сразу и чего человек помнит и чего он умеет.

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

Не вижу никакой связи, если смотреть по результатам (а по чему еще смотреть, по способности нагнать словесной пурги?).
Ну, например, по количеству времени, которое уйдёт у меня на то, чтобы «причесать» то, что кандидат, если его примут на работу, сотворит.

И этот показатель для меня важнее чем умение что-то там сотворить «на скорость» исходя из «новых принципов» (которые новые только потому что историю забыли).
Вот последнее чего от вас хочет интервьюер

Это вы щас с барского плеча за всех интервьюеров сказали?
Это то чего меня на тренингах по проведению интервью учили.

Идеальная память в современном мире не нужна — у нас есть компьютеры и Гугл. А вот умение писать код — очень даже нужно. И особенно — у сеньоров.

И да — вот именно это подобные задачи и призваны проверять.
Замечательные тренинги. Осталось разобраться, почему (по моему скромному опыту) более половины интервью — это что угодно, но только не попытки понять, может ли кандидат писать код.
Ну потому что «умение писать код» — это требование досаточное только для NewGrad'а. Уже от Junior'а — требуют больше.

Я вот вижу, что с навыком чтения тоже часто очень плохо. Требовать от программистов требуют очень многого, но вот оценивать конкретно способность писать полезный код — проверяют очень мало.
Самое частое явление — попытки «проверять» через игру в экзамен по заковыристым практикам; на втором месте — через игру в реализацию стандартных библиотек (от разворотов строк до сортировок до чёрно-красных деревьев).
Желание проверить на чём-то ближе к делу — где-то в конце списка. Хотя казалось бы. Впрочем, даже вот вы, начитавшийся семинаров и (наверное) наслушавшийся прочих умных книжек — усиленно топите за сортировки. Хотя конечно может быть у вас там такая область, что сортировки страсть как нужны и важны. Но я в этом заочно сомневаюсь.

ЗЫ: Я по важным семинарам не ходил, но мое, успешно поработавшее на очень малом количестве случаев, мнение — очень простое. Проверять нужно способность кандидата писать код, именно типичный для предметной области. Проверять это можно не лично, а заочным тестовым заданием. Проверить потом тот факт, что кандидат написал код сам, а не организовал помощь зала — можно банальным FizzBuzz и подобными заданиями. Убедительно выстроить обманную схему, при которой кандидат очно будет настолько же уверенно (или неуверенно) писать простенький алгоритм на 10-15 минут, насколько уверенно (или неуверенно) вылядит его решение заочного задания — весьма сложно. И в любом случае, если вы не гугл или MS — вопрос обмана для вас стоит далеко не на первом по важности месте. А вот вопрос найма кого-нибудь вменяемого, да желательно не очень задорого, на рынке, на котором работников гораздо меньше, чем работы — будет очень важным.
Желание проверить на чём-то ближе к делу — где-то в конце списка.
А зачем вам проверять на чём-то «ближе к делу»? Нет, ну серьёзно: если вы повара там нанимаете или плотники — вы будете просить прям на собеседовании сварить обед на 10 персон или табуретку сваять?

А вот попросить что-то простое, техническое… можно запросто. Если человек, условного говоря, не знает какой рукой за какую ручку рубанок брать — это будет видно сразу.

Вот и сортировки эти и разворачивания списков — это вот такое, простое и техничное средство отсеять тех, кто не знает чем if от while отличается.

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

Однако на практике — это не самый лучший подход. Гораздо проще и надёжнее начинать искать людей тогда, когда имеющиеся ещё не загружены на 120%… и потихотьку, без суеты и штупмовщины — найти того, кто вам нужен.

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

А если нет спешки — то и ситуации с «рынком, на котором работников гораздо меньше, чем работы» — не будет.

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

Вы вообще-то сами говорили о ситуации с «рынком, на котором работников гораздо меньше, чем работы»… зачем кто-то будет делать какое-то тестовое задание забесплатно, если есть полно предложений, где этого можно не делать?

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

Причём чем на более высокую позицию ищут людей — тем больше отсев.
Вот и сортировки эти и разворачивания списков — это вот такое, простое и техничное средство отсеять тех, кто не знает чем if от while отличается.


Вы ошибаетесь, сортировки списков — это простое и техническое средство отсеять тех, кто перед собеседованием не тренировался специально сортировать эти списки.

Вы вообще-то сами говорили о ситуации с «рынком, на котором работников гораздо меньше, чем работы»… зачем кто-то будет делать какое-то тестовое задание забесплатно, если есть полно предложений, где этого можно не делать?


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

Так замечательно же получилось в итоге? Вы устроились куда хотели, не напрягаясь.

сортировки списков — это простое и техническое средство отсеять тех, кто перед собеседованием не тренировался специально сортировать эти списки.

Вот не соглашусь. Я последний раз работал со списками 20 лет назад в универе. Когда стал решать задачки на списки, оказалось что почти все я прекрасно помню. Да, я не помню специфических алгоритмов, типа поиска цикла с О(1) ограничением по памяти, но в целом все довольно хорошо.


То же касается основных алгоритмов сортировок. Достаточно принцип помнить.


И, да, на работе я руками списки не вращаю и сортировок не пишу.

Нет, ну серьёзно: если вы повара там нанимаете или плотники — вы будете просить прям на собеседовании сварить обед на 10 персон или табуретку сваять?

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

Однако на практике — это не самый лучший подход. Гораздо проще и надёжнее начинать искать людей тогда, когда имеющиеся ещё не загружены на 120%… и потихотьку, без суеты и штупмовщины — найти того, кто вам нужен.

Вы же понимаете, что ваше «на практике» — оно никак не относится к эффективности найма? Вы просто говорите «а мне норм неэффективно нанимать, потому что я нанимаю заранее и всю свою кривизну процесса найма уже оплатил» (зарплатой людей, которые еще пока не особо нужны). А гуглу норм неэффективно нанимать, потому что у них всё равно будет очередь за дверями, даже если они будут нанимать очень плохо. Это просто перенос проблемы в другое место, туда, где её можно залить деньгами или репутацией, и сделать вид, что никакой проблемы нет.

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

Сами придумали про 2 дня, сами дальше пофантазировали.
Тестовое заочное задание — оно не для задач на 2 дня. Оно для задач, которые требуют больше 15 минут, потому что на формат очного собеседования на часик протяженные задачи ложатся не очень хорошо — там и без этого есть о чём побеседовать с человеком. Задачу на полчаса или час — тоже лучше давать заочно.

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

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

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


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

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

Для таких случаев надо вообще не с тестового начинать, как вы сами же и пишете. А с «а что мы такого вообще можем предложить, чтоб на нас обратили внимание?».

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

Идеальная память в современном мире не нужна — у нас есть компьютеры и Гугл.

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


Одно дело каждую функцию "ну должна же такая быть в библиотеке" искать по 30 секунд в Гугле. И другое — сразу писать, не отвлекаясь на поиск, а думать о той части кода, которого в библиотеке точно нет и которую, тебе, собственно, и написать надо.

Затраты времени на «написать код» в любом случае и рядом не стоят с затратами времени на, собственно, решение задачи. Даже если вы не по 30 секунд на функцию будете в справочник лезть, а по 5 минут.

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

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

Потому что ты помнишь, где и какое решение уже есть.

Набор стандартных функций очень многих языков примерно одинаков. Это никак не меняет того факта, что я не помню, какие именно там в каждом есть функции, и как их вообще применять. Да что там, я на JS, на котором я пишу постоянно и всегда — пишу с открытым MDN, потому что вместо заучивания функций я лучше чем-нибудь более полезным займусь, а документация и гугл никуда не денутся (а если и денутся — у меня будут проблемы совсем иного масштаба нежели «теперь доку посмотреть негде»).
Если они забываются — то зачем они, вообще, учились?

Чтобы сформировать связи.


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

Ну если вам потребуется «полчаса-час, чтобы вспомнить» без посторонней помощи, то с подсказками вы сможете что-то сможете придумать и быстрее, скорее всего.
Я помню как один из кандидатов вообще «сортировку слиянием в стиле QuickSort» изобразил… сливая каждый раз в новый массив. И что?

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


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

Я помню как один из кандидатов вообще «сортировку слиянием в стиле QuickSort» изобразил… сливая каждый раз в новый массив. И что?
Простите, а когда это для QuickSort нужен был новый (дополнительный) массив? Он там не нужен. И что это за такой стиль QuickSort?
Интересно что цитату вы провели, а вот прочитать её «не осилили». Ну так прочитайте ещё раз — там есть ответы на все ваши вопросы.

Есть мнение, что кто-то сам не так уж хорошо в алгоритмах разбирается, чтобы кого-то «собеседовать».
Есть мнение, что умение читать и понимать прочитанное — тоже входит в необходимые умения для Senior Software Engineer. Хотя формально в требованиях к вакансии — этого и нет.

Уважаемый, я хотел указать на 2 момента:


  1. в QuickSort дополнительный массив не нужен
  2. использование дополнительного массива не называется "стилем QuickSort".

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


Поэтому возвращаю вам назад претензии о чтении и понимании прочитанного.

Я согласен с тем, что спрашивать на собеседования про алгоритмы сортировки это моветон, хотя есть много интересных задач, которые очень быстро и легко решаются, например при использовании того же mergesort/heapsort.

Да и в целом, как можно доверять человеку, который, например не знает отличия list от set или, например, не может инвертнуть простое сапомисное дерево из нод c value, left, right. Ну и понятия не имеет, что такое сложность алгоритма.
Есть мнение, что такие вопросы можно решить показывая код, и прося определить сложность выполнения этого алгоритма.
Умение читать код — тоже полезно, но оно, к сожалению, отличается от умения его писать.
Я высшую математику знал на достаточно хорошем уровне. Сейчас с ходу не найду какую нибудь даже производную. Видно я уже не годен для IT, пора на пенсию.
Я высшую математику знал на достаточно хорошем уровне.
Вы её знали? Или зазубрили?

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

Потом погуглите — проверьте.

Если вы математику действительно знали (умели отвечать на вопрос "почему синус 30 градусов равен ½", например), то проблем быть не должно: за паутинку в уголке потяните — вся сеть и вытянется…
Думаю, что больше, подходит «знал». Первый три курса (вышки) из четырех разбирал материал с удовольствием. На четвертом – уже была работа, поэтому учил по минимуму.
Тогда вот попробуйте взять производную какой-нибудь сложной функции — и засеките время.

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

А вот в то, что ничего не получится… ну не верю.

Вот то, что вы учили на четвёртом курсе — могли и забыть. А первые один-два — наверняка остались в памяти, нужно только «чуток поскоблить».
Ну да — и сложные случаи для решения которых нужно вывести теоремы нетривиально следующие из определений и утверждений? Или это уже для интегралов, а с производными все просто? Что-то я забыл матан совсем. Впрочем за 15 лет немудрено.
Чему равна производная логарифма и степенной функции, а также произведения, отношения и аргумента функции я все-равно не помню и знания того что это предел разностного отношения мне не помогут. Там ведь идут теоремы формулировок которых я не помню, а вывести и доказать их самому когда даже не помнишь о чем теорема-то должна быть — увольте.
Так что без предварительного освежения курса мат анализа (или хотя-бы чтения правил дифференцирования) — никак.
Вы сами давно изучали матан? И если да, то освежали ли после обучния раз предполагаете, что человек вспомнит через десятки лет? Или вы знакомы с хаброжителем prishelec и речь идет о нескольких годах?
Или это уже для интегралов а с производными все просто — что-то я забыл матан совсем?
Я не знаю что вы имеете в виду, так что ответить не могу.

Чему равна производная логарифма и степенной функции я все-равно не помню и знания того что это предел разностного отношения мне не помогут.
Как это не помогут? Ну вы же когда изучали всё это выводили их из этого отношения как-то? Неужели сейчас тупее стали? Или нет? Или не выводили? И все эти школьные (a+b)³=a³+3a²b+3ab²+b³ — прошли мимо вас? А как же Треугольник Паскаля?

Вы точно не можете этого вспомнить? А может быть не хотите?

Там ведь идут теоремы формулировок которых я не помню, а вывести и доказать их самому когда даже не помнишь о чем теорема-то должна быть — увольте.
Уволить — это завсегда не проблема. Но и вспомнить формулировки — тоже. Если хотеть. Если не хотеть, и придумывать отмазки… дело другое, для этого даже и 15 лет ждать не нужно, забыть что угодно можно и за год — если не хотеть помнить.
И все эти школьные (a+b)³=a³+3a²b+3ab²+b³ — прошли мимо вас? А как же Треугольник Паскаля?

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

А чего мне помнить то, что я не использую даже опосредованно?
И да — как уже говорил в соседнем топике — «шли бы вы в баню» (с)
А чего мне помнить то, что я не использую даже опосредованно?
Ну вот мы, наконец, и добрались до сути проблемы: дело не в том — можете вы это вспомнить или нет, а в том — что вы не хотите.

Что собствеенно и обнуляет все жалобы на алгоритмические задачи на собеседовании: типа — на собеседовании я про это говорить не хочу, но в реальной-то работе полезу в справочники и всё сделаю «как надо».

Нет, не полезете. Сотворите какашку — а кому-то её придётся исправлять. Хотели бы вспомнить — вспомнили бы.

И все эти школьные (a+b)³=a³+3a²b+3ab²+b³ — прошли мимо вас? А как же Треугольник Паскаля?
Сравнили жопу с пальцем элементарные вещи и матан
Ну то есть про Треугольник Паскаля мы помним. А если теперь взять опредение и подставить?
d xⁿ/d x = ((x + Δx)ⁿ — xⁿ)/Δx
d xⁿ/d x = ((xⁿ + n * xⁿ⁻¹ * Δx + (n * (n-1))/2 * xⁿ⁻² * Δx² +… ) — xⁿ)/Δx
d xⁿ/d x = n * xⁿ⁻¹ + (n * (n-1))/2 * xⁿ⁻² * Δx +…

Ну надо же: в пару простых шагов «элементарные вещи» превращаются в матан… увидительно? Нет! Базовый матан — штука несложная. И её точно так же можно вспомнить на собеседовании… если захотеть. Вот какие-нибудь интегралы по поверхности — уже нет. Как и timsort. А базовые факты… ну их можно забыть и не суметь вспомнить только если не хотеть их вспоминать.

И да — как уже говорил в соседнем топике — «шли бы вы в баню» (с)Скоро вся страна с Мягковым в баню пойдёт… несколько дней осталось.

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

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

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

И от логической важности это не зависит.
Оп-па. Это что-то новенькое.

Советую вам прочитать книжку «Программистский камень» — там подробно описано про разницу между паковщиками и картостроителями.

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

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

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

У меня вообще память отвратительная, потому «дыры в карте» возникают постоянно… ну как возникают — так и залатываются, соседние-то участки уцелели, то есть «недостающий участок» достроить — не проблема, дело-то житейское.

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

Ну ёлки ж палки — производные же непосредственно связаны с пресловутым «O большим», а через N log N и вот это вот всё — с кучей вещей, которыми вы оперируете каждый день.

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

Потому что «вы не рефлексируете, вы распространяете»? Ну вы прекрасно сможете сделать это где-нибудь в другом месте… Я ж не против…

P.S. На самом деле «Программистский камень» — книжка старая. Хорошая, но старая. Со временем выяснилось что все мы — немного паковщики, и все мы — немного картостроители. Просто карты мы строим в тех областях, где нам интересно. А там где неинтересно — пакуем факты. И если у вас нет карты вокруг алгоритмических, программистких задач… значит они вам неинтересны… в этом нет ничего ужасного — мало ли кому что интересно, а что неинтересно… но зачем же нам мучить и вас и всех окружающих? Лучше взять на работу человека, которому программирование интересно… то есть «человека с ментальной картой». Вот и всё.
Советую вам прочитать книжку «Программистский камень»

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


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

Логика оперирует фактами, которые надо знать. То есть помнить. А если они не используются, то см. выше.


Только дни, которые сильно влияют на мою «картину мира».

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


соседние-то участки уцелели, то есть «недостающий участок» достроить — не проблема, дело-то житейское.

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


Ненормально, что вы не можете эту «дыру» в вашей картине мира «заштопать».

Я вам об этом и говорю. Для других людей это нормально.


производные же непосредственно связаны с пресловутым «O большим», а через N log N и вот это вот всё — с кучей вещей, которыми вы оперируете каждый день.

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


Почему когда оно оттуда пропало — вас это ни разу не обеспокоило?

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


Лучше взять на работу человека, которому программирование интересно…

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

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

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

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

Можете относиться к этому как к «бзику» — не вопрос. И искать работу сеньора. Без проблем. Но… где-нибудь не у нас.

Так разговор вроде не про вашу компанию был) Я заметил, что вы часто так делаете в таких обсуждениях — начинаете разговор на общие темы типа "сеньор должен", а потом съезжаете "а это у нас в компании так". Да с этим никто и не спорил, делайте как хотите, факты и их причины от этого не меняются. Пишите тогда сразу в начале "У нас в компании сеньор должен", вам и возражать никто не будет.

И если у вас нет карты вокруг алгоритмических, программистких задач… значит они вам неинтересны…

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

Ну вы же когда изучали всё это выводили их из этого отношения как-то?

Выводили же, как правило, не самостоятельно, а переписывая с доски. И с неочевидніми преобразованиями. Вот при виде a^2+2ab+b^2 может и шевельнулось бы что-то в памяти, типа вроде была какая-то формула, которую можно погуглить, а при a³+3a²b+3ab²+b³ уже нет.

И с неочевидніми преобразованиями

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

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

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

Теперь представьте что это сказал хирург. Раз Вы пришли на собеседование по математике будьте добры решать соответствующие задачи.


А иначе если 15 лет назад решали задачи которые нужны сейчас под проект о чем написано в вакансии, а Вы не подготовились, тогда извините Вы не подходите на проект.

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

А мне однажды предложили в качестве домашнего задания написать потокобезопасный менеджер памяти для объектов фиксированного размера (С++), с тестами (google test) и бенчмарками (google benchmark), и чтобы было production-ready. Сложность задания они оценили "часов пять-шесть".


Я до этого никаких менеджеров памяти не писал, как-то хватало стандартных, у нас не геймдев, но решил развлечься. На выходных почитал теорию, размахнулся и накидал lock-free реализацию, С++17, оформил всё по канону, тесты к ней, комментарии, документация, только бенчмарки не сделал из-за проблем прикручивания google benchmark к visual studio (мы в конторе не использовали его, я честно написал что опыта с ним не имею). Реализация наверняка имела неотловленные тестами баги, но выглядела неплохо, как по мне. Явно не на "часов шесть".


Ответ интевьюера был коротким: "not sophisticated enough". И всё. Я так и не понял, что это было — то ли я действительно слишком туп был для них, то ли интервьюер не разобрался, то ли ещё что-то.

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

Тоже "задание часов на шесть"? :)

Они оценили это на 2-3 недели, и да, я его сделал. И да, было интересно разобраться в области, которая совершенно не моя.

Надеюсь, эту работу оценили не отпиской из 3-х слов.

Как итог — съездил еще в другой город

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


  • слишком просто, не хватает абстракций
  • слишком сложно, зачем столько абстракций?
  • вы использовали менеджер зависимостей X, а мы используем Y (это во времена golang, когда еще не было go mod)
  • странное у вас форматирование, мы придерживаемся другого стандарта (это в случае PHP, где я использую PSR-*)
  • ой, вы использовали подход X, а мы от вас ожидали подход Y. Оно, конечно, работает, но это не то, что нам было нужно (задание, понятное дело, этот момент не уточняло).
  • "ой, а вот в этом месте у вас недочёт"

У некоторых собеседователей просто есть психологическая проблема — они ищут подобного себе, но если человек чуток слабже, чем они, то это всё, зашквар, не брать. А если человек чуть-чуть (или очень) сильнее, чем они, то ищется формальный повод, чтобы ткнуть носом и сказать — иди, учись еще, студент. Такое себе самоутверждение.

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


А ещё бывает конфликт интересов бизнеса и личных — это не психологическая проблема, а этическая.

А мне однажды предложили в качестве домашнего задания написать потокобезопасный менеджер памяти для объектов фиксированного размера (С++), с тестами (google test) и бенчмарками (google benchmark), и чтобы было production-ready. Сложность задания они оценили «часов пять-шесть».
А там точно должны были использоваться lock-free структуры или просто на обычных mutex'ах сгодилось бы?

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

Ответ интевьюера был коротким: «not sophisticated enough».
Я думаю это был сарказм… но сарказм плохо работает в письменном виде.

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

Мммм. Я обычно спрашиваю такие вещи. Все таки писать lock-free там где и мутекса хватит, это очень хреново.

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


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

Да, если размер мапы не меняется, то lock-free для нее реализуется и работает не слишком сложно. Думаю, уже это намек, что следует использовать алгоритмы без блокировок.
Тут я с вами полностью согласен. ИМХО, хамство — давать сложное тестовое и не давать на него развернутого фидбека.

Там не мапа, там memory pool для объектов одинакового размера (arena), реализованный как список чанков, где каждый chunk хранит элементы и снабжён кольцевым индексом свободных ячеек (free list). Собственно этот кольцевой буфер и является lock-free. Если чанк заполняется, в список чанков добавляется новый; операция добавления чанка защищена обычным мьютексом, но она редкая. Ну и плюс я добавил всякие дополнительные фишки вроде отсутствие требования иметь дефолтный конструктор (многие виденные мной примеры реализации требовали, чтобы элементы размещаемые в пуле были default_constructible), статические проверки и проч.


Собственно, репозиторий тут, а весь код тут, один заголовочный файл; можно критиковать :)

В принципе, код мне нравится, но мне кажется в нем есть ошибки (если это я ошибаюсь, то было бы хорошо, если объясните, что не так).
Дальше буду писать без «мне кажется»

            if (!next) {
                std::lock_guard<std::mutex> _(expansion);
                if (!next) next = std::make_unique<MemoryPool>();
            }

Мьютекс должен быть симметричный. То есть, если создаем объект под мьютексом, то и читать должны под мьютексом.
Также, сам код
            if (!next) {
                std::lock_guard<std::mutex> _(expansion);
                if (!next) next = std::make_unique<MemoryPool>();
            }
            return next->allocate(); 

неверен по той же причине

2)
elem->~ElemT();

Если элемент не сконструироваля, то деструктор у него вызывать нельзя

3)
                while(!freeList.at(pos).compare_exchange_weak(index, TAKEN, std::memory_order_relaxed)){ []{}; };

                // take the spot
                elem = &arena[index];


Нужна проверка перед elem = &arena[index]; что index <> TAKEN.
Можете попробовать прокрутить в голове алгоритм с двумя потоками и ChunkSize == 1
если создаем объект под мьютексом, то и читать должны под мьютексом

В имеете в виду, что next->allocate() нужно целиком занести под мьютекс? В чём именно тут может быть гонка? Я так думаю, что next всегда либо null, либо какой-то указатель (всегда один и тот же, инициализация происходит лишь однажды), поэтому любой тред либо заходит под double-lock (и значит имеет null), либо успешно прочитал ненулевое значение и может свободно им пользоваться без лока (allocate() является lock-free).


Если элемент не сконструировался, то деструктор у него вызывать нельзя

alloc() использует placement new и вызывает конструктор. Если конструктор инициализировал половину членов класса (которые могли в куче что-то насоздавать), а потом бросил исключение, кто будет за ним чистить?


Нужна проверка перед elem = &arena[index]; что index <> TAKEN.

Спасибо, тут подумаю. И спасибо за ревью :)

1) Кроме указателя еще существуют и данные. И они могут «добежать» позже самого указателя

Сорри, не вкуриваю, куда данные могут добежать? Поле next указывает на следующий чанк, которого либо ещё нет (тогда next==nullptr, и если места в пуле не осталось, то нам нужно создать новый чанк и слинковать с предыдущим), либо он уже создался и — что важно — он останется неизменным до конца жизни всего пула. Т.е. защищать нам нужно только момент создания и линковки нового чанка. Как только next присвоено какое-то ненулевое значение, защита больше не нужна, потому что next больше никогда не изменится.

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

Разве count.load() в самом начале allocate() не создаёт необходимый барьер?

Где count.load и где оперирование указателем? Точно также можно сказать «создание потока создает необходимый барьер», но это не значит, что теперь все программы можно писать без мьютексов?

Я подумал, что под абстрактным "полем x" вы подразумевали оставшиеся поля класса, вроде count.


Если вы имели в виду поле next, то вы считаете что, в отсутствие барьера, next->... может выполниться раньше, чем двойная проверка if (!next) {..} и получить разыменование нулевого указателя?

Нет, дело во внутренних полях класса.

Благодарю, интересная статья.

Если элемент не сконструировался, то деструктор у него вызывать нельзя

Впрочем да, вы всё же правы, это надо пофиксить.

Меня изначально предупреждали, что собеседование займет порядка трех часов и будет одна долгая задача, и желательно подготовиться к этому, а если я не люблю маки, то лучше взять собой ноут со своей любимой осью и настроеным рабочим окружением, что бы не тратить время. Какая именно будет задача — не сказали.
Уже сотню раз мусолили эту тему же: если в профессиональные обязанности будет входить хотя бы раз в неделю построение красно-чёрных деревьев и написание быстрой сортировки — их стоит спрашивать у кандидата.
Если не входит — лучше спросить то, что входит.
Иначе получится тот самый
остров с ядовитым газом, воздушным шаром и вентилятором
Тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: «УТЕЧКА ЯДОВИТОГО ГАЗА!!!».
— Как так-то? Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что-то в проекте менял?
— Немного, швабры вынес…
— Швабры потолок держали!
— Что??? Что извините???
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и уелетайте!

Классная история.
Реформаторский зуд лечится резкими обжигающими ударами по рукам

В данном случае бить по рукам следовало того, кто это всё изначально соорудил.

Не более, чем того, кто вместо достраивания всё сломал.

Чтобы можно было говорить про "сломал", оно должно было работать в прошлом.


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

Чтобы можно было говорить про «сломал», оно должно было работать в прошлом.

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

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


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

Доки.
Зачастую швабры в таких количествах и 120тонные вентиляторы немного документируются.
К тому же, в приличном обществе, перед уборкой костылей делают форк и прогоняют регресс-тесты, а не коммитятся на прод.

Исходя из восклицания "Ты хотя бы записку на двери повесил бы, что швабры для держания потолка!" я заключаю, что записки не было.


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

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

Когда нет контактов предыдущего разработчика — это ещё полбеды. А когда нет контактов предыдущего заказчика… Вот есть большой кусок кода, он что-то делает с данными, откуда-то берёт, обрабатывает, куда-то результаты складывает, но никто ни из разработки, ни из бизнеса не знает что делает и зачем. С неделю (40 часов) "собираешь требования" — обходишь всех хоть как-то причастных по известным тебе бизнес-процессам, вроде получаешь картинку, что препредыдущему начальнику какого-то отдела были нужны какие-то ежедневные показатели работников для мотивации, которые никто не использует давно. Выпиливаешь, всё хорошо месяц, другой, полгода, а в январе прибегают начальники почти всех отделов и говорят, что у них годовой отчёт полную билеберду показывает.


Оказывается, где-то вне рамок системы были какие-то скрипты, у каждого отдела свой, причём с игнорированием ошибок, которые использовали эти показатели для расчёта своих раз в год, причём с игнорированием ошибок. А за это время система уже сменила версию языка, фреймворк, переехала с MySQL частично на PostgreSQL, а частично на MongoDB…

А вот за это и отвечает этап сбора требований: Ничего не понятно?
Всех обошёл, все подписали, что хотят и что кроме этого — ничего не хотят, теперь делаем.
А как возникли претензии «а чегойто у нас неправильно работает?! Срочно чините, пришли тут всякие и всё переломали!» показываешь бумажку/письмо и предлагаешь уточнять ТЗ с последующим допилом. Со временем из непонятной и неподдерживаемой кучки скриптов может получиться хорошая и рабочая документированная система.
Это если интересно работать именно в этой компании, если не интересно — после слов «вот тут какой-то код, доков нет, требований нет, заказчиков нет, разработчиков тоже нет, зависимости… а шойто такое?! короче, сделай так, чтоб лифт ходил не только вверх-вниз, а ещё и влево-вправо, тыжпрофессионал» улыбаешься и уходишь подальше.
Возможно, я не прав, но я дорожу своим психическим здоровьем.

Речь не про "делаем", речь про "чистим конюшни".

У любой чистки есть цель: можно просто выкинуть мм… мусор из конюшни на задний двор (там никто не ходит и не видно), а можно увезти мусор с пользой на поля, ещё и стоила переделать, и дырявую крышу подлатать, зависит от того, будем этой конюшней дальше пользоваться или на снос её.
К тому же, во многих местах работают процессы риск-менеджмента, с оповещением всех потенциально затронутых изменениями в системе и перед разбором непонятных скриптов заводится новый риск.
Ну а если риски не оцениваются и никому ничего не нужно и некогда, но сделайте — я уже писал своё отношение.
PS Ведь в компании, про которую рассказываете, после форс-мажора поменяли процессы и завели что-то подобное?
Когда случилась утечка, он догадался позвонить прошлому прорабу, а перед демонтажом 120-тонного вентилятора — не догадался. Кто-то не очень сообразителен.
если в профессиональные обязанности будет входить хотя бы раз в неделю построение красно-чёрных деревьев и написание быстрой сортировки — их стоит спрашивать у кандидата

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

Люди, которые только и умеют брать инструмент и его использовать, умеют только брать инструменты, которые за них давно уже выбрали и использовать их, причем иногда так, что хочется плакать.
Одно из другого совершенно не вытекает. Чтоб «неплохо понимать», что у тебя там происходит на всех двадцати (или около того) уровнях абстракций от высокоуровневого DSL до машинного кода — нужно перелопатить огромное количество документации и кода. По-другому оно не работает. Человек, который «неплохо понимает» это всё — или уже потратил кучу времени, или принял (на веру) выводы тех, кто это сделал за него.

От знания алгоритмов и структур данных знания конкретного технологического стека магическим образом не прирастают.
Ох, из последнего, с чем пришлось столкнуться, была задача — для каждого пользователя необходимо сделать троттлинг по запросам, например не чаще двух запросов в секунду от одного пользователя. Первоначальная реализация была через таблицу в обычной базе данных, работала плохо и очень часто неправильно, с последующими костылями стала работать лучше, но скорость оставляла желать лучшего. Реализация c редисом была лучше, но так же имела свои минусы. По итогу я плюнул и написал свою реализацию, которая работает уже как полгода, выдерживает примерно 100-1500 запросов в секунду (при нагрузочном тесте использовались показатели примерно в 10 раз выше).
Не готов комментировать конкретно ваш случай, я по другим вещам — но хочу заметить, что вот это вот «плюнул на всё и написал велосипед и он пашет» — оно обычно (не всегда, и я не берусь сказать, как у вас было) свидетельствует о том, что в алгоритмы человек смог, а вот знаний о инструментах у него маловато. И в итоге он пишет свои инструменты вместо того, чтоб заставить чужие работать надлежащим образом. И далеко не всегда это оправдано.

Несколько лет назад у меня был прекрасный пример перед глазами с самописной БД. Самописная она была, разумеется, от того, что сумрачные гении времен начала нулевых сказали «third-party RDBMS это фу-фу, они или платные или кривые, мы щас быстренько сваяем!». И сваяли, и это жило в проде примерно 7 лет, пока продукт применялся к нуждам пары (больших) клиентов. Но годы прошли, появились конкуренты, большие клиенты задумали свалить, и встал вопрос о развитии продукта. Немедленно выяснилось, что самописную БД развивать невозможно вообще — большинство людей совершенно не желает к ней прикасаться, а те сумрачные гении, которые желают — жрут много денег и их силы всё равно крайне ограничены, так что говорить о feature parity с популярными продуктами просто фантастично, а фич для развития требовалось много — БД наконец-то надо было использовать в режимах отличных от тривиальных вставок и выборок, а оно такого не могло от слова «совсем».

Это конечно было не единственным фактором, в итоге похоронившим продукт — но одним из важнейших.
Мне кажется, масштабы задач очень разные — написать троттлинг vs написать свой RDBMS. Второе — очевидная глупость. Первое — вполне может оказаться обоснованным. Возможно, что там объем кода получился даже меньшим, чем объем конфигурации существующих инструментов.
Второе — очевидная глупость.

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

Мне кажется, масштабы задач очень разные

Это вам так кажется. Просто я описал свой случай с точки зрения последующего провала, а ashofthedream — c точки зрения текущего выигрыша. На самом деле в моем случае тоже никто не писал RDBMS — решали задачу «нам надо что-то для быстрой индексируемой записи с гарантиями большого потока информации и последующей выборки по индексам». Это уже сильно потом стало ясно, что тут нужен серьезный объем фич RDBMS, и на разных этапах жизни продукта некоторые самые «больные» фичи худо-бедно пытались добавлять.

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

По идее redis должен справляться с таким потоком. Если по хорошему о защищать нужно скорее конфигам nginx. Если на уровне приложения то получится немасштабируемо. Нельзя будет запустить два экземпляры приложения

слишком сложно конфигами нжинкса дать одному пользователю допустим 2 запроса, а другому — 10.

На редис там и так хорошая нагрузка была, поэтому было принято решение использовать что-то еще
100-1500 запросов в секунду этофигня для редиса. Хотя конечно зависит от железа на котором запущено. Но у меня была ошибка однажды изза которой количесвто запросов в редис было 60к с пиками по 80к. Проц был загружен процентов на 10-20. Заметил случайно когда полез полюбоватся статистикой по редису
В чем сложность? На первый взгляд — несколько строчек в конфигурации. (Лично такое делал)
Видимо сложность вот в чем: есть у нас абстрактный пользователь, у него дефолтные 2 запроса в секунду, дальше он зарегался у нас и вошел, окей, мы теперь говорим ему, что у него 5 запросов в секунду. Но при этом, если у этих пользователей набирается, ну представим себе что 20к запросов в сутки, мы говорим им пока. Но пользователь он допустим бабки еще кидает, то у него будет 10 запросов в секунду, но максимум 100к, а если кидает прям хорошо бабок, то и лимиты повыше.

И еще такой момент, к некоторым апи отдельные тротлеры привязаны, например у нас глобально — 10rps для пользователя, есть /api/a и есть /api/b где отдельный троттлер на 5rps, но всего у нас для пользователя 10rps. Ну то есть в некоторых случаях мы должны проверить аж три раза что пользователь может это сделать — глобально, в целом и частный случай.

Так вот, как это быстро сделать при помощи конфигов нжинса, когда есть пяток способов изменить стейт у пользователя?
У нас было только два стейта и мы тупо вешали пользователю зашифрованную куку, по которой nginx определял его категорию.
Но, не факт, конечно, что такое решение подошло бы в вашем случае.
насколько мне известно, изначально примерно так и было настроено, что-то вроде реквест лимита и по куке определялось какой лимит у пользователя, но с появлением дополнительных требований, решили это перенести уже в код, а там и свое решение подтянулось
UFO just landed and posted this here
Я всегда считал, что знание технологического стека дело вторичное, если кандитат знает его то это идет в плюс, если не знает, ничего страшного, минусом я это не считаю.

Смотря кто вам нужен. Если просто «толковый человек, а там разберется» — то одно. Если кто-то, кто за два дня войдет в курс дела и будет уже закрывать простые задачи, а через месяц будет шарить во всем проекте и сможет проектировать его дальше — то знание стека таки нужно, иначе «просто толковый человек» месяц будет только курить документацию и набивать базовые шишки, а правильно проектировать дальше — и вообще фиг знает когда сможет (сможет-то скорее всего быстро, но если напроектирует что-то не так, расплачиваться за это будет контора, а не он).
UFO just landed and posted this here
Ну да, есть еще такие штуки, как «близкий опыт», и тому подобное. Если человек всю жизнь (такие уже есть) писал на Typescript, то полагать, что он не сможет в Javascript — нет смысла. Сможет конечно. С другой стороны я на фронтэнде видел людей, которые как программисты хороши, но вот билд настроить и вебпак (или другой бандлер) поконфигурировать — им обязательно нужна помощь зала, потому что собственного опыта у них как-то вот не было совсем.

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

С четвертой стороны, я конечно не могу похвастаться огромным опытом, но еще ни разу не видел такого фронтэнда, где программистам не надо было бы быть чуточку девопсами. Create-react-app это лишь отправная точка, а потом всё равно какое-нибудь «доработать напильником» возникает.

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

Ответ не так однозначен. Хороший работник может получиться из кандидата, который ПОСЛЕ приема на работу освоит теорию и будет строить вам ваши деревья. То есть при собеседовании он может и ответить на специальные вопросы.

Хороший работник может получиться из кандидата, который ПОСЛЕ приема на работу освоит теорию и будет строить вам ваши деревья.
Не может. Потому что они нигде не фигурируют как что-то явно упоминаемое.

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

Обычно предволагается, чтобы вы это сделали уже один раз, давным-давно, во время обучения.

А вот фреймворки появляются всё время новые, тут ожидать что вы их точно знаете зачастую бессмысленно — особенно если у фирмы есть есть свои «фирменные» надстройки над ними.

Ну так пусть фигурируют. У вас задача не схитрить, а получить человека в команду.

Ну так пусть фигурируют.
Вы это сейчас… всерьёз? Предлагаете всей, ну вот просто всей компании буквально всё бросить и начать описывать базовые вещи из курсов Computer Science в коде и в документации ради того, чтобы получить ещё одного человека в команду?

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

Если для того, чтобы его можно было взять на работу, остальная команда должна будет тратить лишние 10 или 100 человеко-лет каждый год (да, у нас большая команда) на то, чтобы везде-везде, где это релевантно прописать то, что человек, разбирающийся в CS и так знает… — то нафиг нам такой человек нужен?

Попробуйте не утрировать и взглянуть на вопрос здраво.

Я и смотрю на вопрос здраво. Мне не нужен кандидат, который между ArrayList'ом и LinkedList'ом делает выбор на основании того, что ArrayList в алфавитном порядке первым стоит.

Это понятно. Но если он в течении первого дня разницу уразумеет и, соотв, начнет использовать их как следует? Ну разве это не хорошо?

Нет. Потому что если человек — таки сеньор, то есть у него было несколько лет опыта — он про всё это так и не удосужился узнать, то он либо никогда не изучал Computer Science, либо изучил — но всё забыл.

В обоих случаях — доверять его решениям нельзя… а зачем нам нужен сеньор, решениям которого нельзя доверять?

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

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

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

Это Java. Да, представьте себе, там в стандартной библиотеке есть ArrayList. И да, в природе существуют программитсты, которые, когда им нужен List — выбирают ArrayList потому что он в документации первый в списке реализаций интерфейса (там перед ним ещё Collection и Set, но они не годятся — это тоже абстрактные интерфейсы, а не классы).

А чётакова? Предварительная же оптимизация — это ж корень всех зол, сам Кнут сказал! Потом в профайлере всё увидим.

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

А если он начнёт гуглить перед выбором различия?
То это значит, что он врёт либо про то, что он сеньор, либо про то, что он с Java работал. Это стандартная библиотека — причём та её часть, которая ещё из прошлого века идёт. Можно немного поработать с Java джуниором и с ней не столкнуться, но избежать её и стать сеньором — вряд ли получится.
О, вы та самая компания, которая знает, где LinkedList быстрее ArrayList-a? Расскажите пожалуйста. Мне кажется, с точки зрения явы там должно быть вообще все равно.
(Не все равно может быть разве только в случае занимаемой памяти, ArrayList может выделить сильно больше того, что необходимо)
Мне кажется, с точки зрения явы там должно быть вообще все равно.
Вам кажется? Или вы пробовали померить? Ну там взять listIterator и начать этот список модифицировать? Добавляя/удаляя элементы в серединке?

И да, во многих случаях ArrayList будет быстрее — несмотря на то, что алгоритмы там получаются O(N²) вместо O(N) у LinkedList. Просто константа сильно меньше.

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

А в проде — у вас сервера «ложиться» будут под нагрузкой. Более того: они могут продолжать «ложиться» даже притом, что даже на боевых данных профайлер будет показывать, что ArrayList быстрее!

Абстракции — текут. И кто-то должен с этими протечками что-то да делать.

Ну и? От кого вы ожидаете, что он устранит протечки? От сеньора или джуниора?

P.S. Кстати упомянутый вами факт, касающийся того, что если ArrayList, в какой-то момент, стал большим, то он по прежнему будет занимать кучу памяти даже если из него почти все элементы удалить — из той же оперы. Ещё одна «протечка» из абстракции, да.
Тоесть у вас есть реально подтвержденное поведение? Какой размер массива был? Какой тип вычислений? Я подозреваю, там еще может быть связано со сборщиком мусора, возможно удалять небольшие куски памяти ему проще, чем большие. Но было бы интересно получить этому подтверждение.

> Ну и? От кого вы ожидаете, что он устранит протечки? От сеньора или джуниора?
От любого наверно. То есть по вашему, синьер должен уметь устранять только протечки ArrayList-а? Никаких других протечек устранять он уметь больше не должен? Я о том, что не лучше ли выработать повторяемые методики поиска утечек, чем устранять эти самые утечки «методом тыка»?

Я вот в яве почти не работал, но в C++ я бы ни за что не догадался бы взять std::list в качестве коллекции. За 10 лет он мне потребовался всего один-единственный раз: когда нужно было гарантировать, что элементы, добавленные в список, никуда не денутся со своего места при любых манипуляциях с этим списком.
Тоесть у вас есть реально подтвержденное поведение? Какой размер массива был? Какой тип вычислений?
Вы сейчас притворятесь идиотом или правда не понимаете, что пишите чушь? Операция вставки элемента в LinkedList не зависит от его размера. Операция вставки в ArrayList, куда-нибудь поближе к началу, занимает время, пропорциональное его размеру (там «внутре» вызвается System.arraycopy).

Извините — но это типичный O(N²) против O(N). Вопрос только в том — насколько велики ваши списки.

И да, LinkedList тоже можно сделать медленным, если использовать не итераторы, а индексы… это ещё один быстрый способ получить вердикт «no hire».

То есть по вашему, синьер должен уметь устранять только протечки ArrayList-а?
Нет — по моему если «синьер» не понимаете какие протечки бывают даже у такой простой строктуры, как ArrayList, то говорить о чём-либо ещё просто бессмысленно.

Потому что у ArrayList несмотря на одинаковый набор операций (общий интерфейс List) — ну вот совершенно разные своства. У обоих есть операции, которые у другой строктуры медленные. Самой же гениальной операцией, конечно, является add(index, element)любое её использования в любой из этих двух структур — это ошибка с 99% вероятностью.

В C++, кстати, это операции вообще нет — ни в std::list, ни в std::vector.

Я о том, что не лучше ли выработать повторяемые методики поиска утечек, чем устранять эти самые утечки «методом тыка»?
Самый эффективный метод их устранения — это их устранение без запуска кода, просто глядя на него. И да — он работает не всегда, но очень хочется, чтобы «синьер» большинство протечек устранял бы именно так.

Я вот в яве почти не работал, но в C++ я бы ни за что не догадался бы взять std::list в качестве коллекции.
Всё зависит от задачи. И да, ArrayList чаще бывает полезен, чем LinkedList — но понимать-то его ограничения нужно? Зачем вообще в языке появился LinkedList если он никому ни для чего не нужен?
От количества данных зависит конечно. Но вставка чегото «поближе к началу» это уже довольно странная операция на мой взгляд. Если вставлять совсем в начало, то есть ArrayDeque
Да много чего есть. «Вставка вначало» — это, как правило, обработка типа «читаем строчки, иногда вместо одной вставляем две, а иногда, лишнее — удаляем». Ну или что-то более сложное (скажем ищем «парную строку» и удаляем сразу блок).

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

И вот тут так может получиться, что даже если на бенчмарках всё работает быстрее на ArrayList — но лучше всё-таки LinkedList. Ибо тот вызов, который случается раз в год вам будет, по итогу, каждый год устраивать аврал, когда вся ваша конструкция будет «вставать раком» и watchdog будет вам ваш сервис прибивать.

Но если подумать — можно и с ArrayList'ом обойтись. Скажем если «перекачивать» данные из одного такого в другой (и добавлять всегда в конец). Но для этого нужно знать, что добавление в конец в ArrayList — быстрое, а в другие места — медленное.

А для этого, прежде всего, нужно понимать чем отличается ArrayList от LinkedList и какие в них есть подводные камни.

P.S. Кстати хорошие синьоры часто пишут ArrayList (как вы верно заметили — он бывает полезнее в реальности), но говорят (голосом) «я сейчас всё допишу и посмотрю — не стоит ли тут LinkedList использовать». Это принимается… как приглашение обсудить всё это, когда код будет написан.
Для удаления в том же c++ существуют идиомы erase-remove. Для вставки тоже наверно можно чтото придумать. По моему, «портить» код LinkedList-ом только для того, чтобы чтото откудато удалить, это нехорошо. Лучше использовать другой подход

Зависит конечно от частоты операций. Но я например не представляю, как делать предложенные Вами операции «по одиночке». То есть, как я понимаю, эти операции выполняются сразу пачкой, например «удалить все дубликаты строк». Тогда идиомой erase-remove это решается эффективнее, чем листами. А если нужно удалять по одному элементу… То как еще найти этот элемент? То есть представьте, что Вам нужно что-то удалить из середины списка. Но для этого же до этой середины еще нужно както дойти в случае листа. Получается тот самый «квадрат» (точнее линейный поиск в случае одного запроса), которого Вы так боялись
Получается тот самый «квадрат» (точнее линейный поиск в случае одного запроса), которого Вы так боялись
Если вы каждый раз проходите с начала — да. Но если вы обрабатываете элементы последовательно (то есть найдя один «нужный» элемент ищите другие в остатке, а не сканируя список с начала) — нет.

И да, конечно, работа с ArrayList/LinkedList — это где-то близко к вершине айсберга… но если вы не знаете даже этого, то каков шанс, что вы не запутаетесь в дебрях этого айсберга.
Ну тогда получается, что это «потоковый» алгоритм, который проходит сразу все элементы. Тогда думаю, будет лучше использовать аналоги идиомы erase/remove. Или, как Вы сами предложили, перекладывать элементы в другой массив.

> И да, конечно, работа с ArrayList/LinkedList — это где-то близко к вершине айсберга… но если вы не знаете даже этого, то каков шанс, что вы не запутаетесь в дебрях этого айсберга.

Ага, это я понимаю. просто думал, у Вас есть какойто интересный пример работы с LinkedList
То это значит, что он врёт либо про то, что он сеньор, либо про то, что он с Java работал.

А если не врёт? Если он сеньор, с Java работал, но всего лишь месяц. Рекрутеры уговорили прийти на собеседование, потому что они решили, что подходящий кандидат, потому что где-то в резюме слово Java встретилось.

Меня так звали 1с8 разрабатывать, сеньором, из-за того, что среди прочего в резюме была строка «поддержка интеграции с 1с».
Даже собеседование с тестами прошёл (интернет — сила!), правда, потом представил себе, что придётся и дальше писать на ломаном русском ежедневно — извинился и ушёл.
Если он сеньор, с Java работал, но всего лишь месяц.
Но тогда у него об этом в резюме будет написано.

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

Не факт, будет, например, написано 2013-текущее время, проектирование и имплементация (с привлечением команды) микросервисной архитектуры высоконагруженного финансового CRM/ERP-like приложения. Стэк: PHP (Symfony/Doctrine2), Java (Spring/Hibernate), Go, TS(Node.js, React), C#(.Net Core), MySQL, PostgreSQL, RabbitMQ, Kafka, AWS (S3,DynamoDB), Docker, Docker Swarm, Kubernetes

Ну в этом случае придётся смириться с тем, что могут начаться вопросы по Java, придётся остановить интервьюера и объяснить свою ситуацию.

Не знаю даже что лучше делать в таких случаях: упоминать Java в Resume или нет.

Наверное лучше упомянуть: больше шансов проскочить черещ HR, а с инженером-интервьюером как-нибудь договоритесь.

Главное не пытаться делать вид, что у вас шесть лет опыта работы на Java, а сразу заявить, что вы больше работали с той частью, что на PHP (или C#).

P.S. У меня у самого похожая ситуация, на самом деле: работать с Android и совсем избежать Java не получится, но количество кода на Java и C++, которое я пишу… разница где-то между 10x и 100x в пользу C++…

Что вопросы по Java будут в такой ситуации ожидаемо. Тут нюанс в другом: интервьюер может свято верить, что есть такая фундаментальная структура данных как массивный список со всеми вытекающими.

Статья «прекрасна»: утверждение, что профессиональному программисту не нужно уметь написать алгоритм сортировки, «доказывается» через недоказанное утверждение, что профессиональному музыканту не нужно уметь играть гаммы. И это несмотря на то, что как правило, и правда не надо. С другой стороны, если это правда Senior, он знает алгоритм сортировки слиянием. А, зная алгоритм, не проблема его и с нуля накодить.
Тут как бы вся статья о том, что «не надо учить» и «не надо уметь» — это две большие разницы.
Вы пишите на русском языке без ошибок. А сможете слету рассказать правила правописания и синтаксиса, изучаемые в школе? Или пару теорем доказать? Вот так и гаммами. Думаю, что если виртуозного музыканта попросят сыграть гамму на собеседовании, он просто развернется и уйдет.
В каких случаях пишется разделительный мягкий знак?))

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

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

Ответ рекрутера: не отличает разделительный "ь" от глагольного окончания "-т[ь]ся" :)

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

Того, что, на мой взгляд, в профессиональной деятельности и правда не надо кодить алгоритмы сортировки и вовсе никто не заметил. А может за это и минусы? :-[ ]

P.S. «Вы пишите на русском языке без ошибок» — я стараюсь, но после Вашей просьбы буду стараться еще больше
Насчет русского языка — это была не просьба, а утверждение :)
тогда в слове «пишите» есть одна ошибка
тогда это просьба, а не утверждение
зная алгоритм, не проблема его и с нуля накодить
— нормальный senior не станет кодить с нуля, а вкрячит библиотечный метод или фреймворк который все это делает, тем он и отличается от junior-а.

утверждение, что профессиональному программисту не нужно уметь написать алгоритм сортировки
— я увидел в статье иной посыл: есть навыки на «кончиках пальцев» и сортировка к ним не относится. Нужно иметь знания о ней, но кодить ее по алгоритму это не нормально, когда есть 100500 библиотечных методов занимающихся этим. Адекватный вопрос для соискателя на должность senior — какие есть методы сортировки в стандартных библиотеках и какие алгоритмы сортировки они реализуют, ну и что вы примените для сортировки… чего то там типичного, заодно проверить понимание equls, hashCode
— нормальный senior не станет кодить с нуля, а вкрячит библиотечный метод или фреймворк который все это делает, тем он и отличается от junior-а.


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

Занимательный факт, большинство людей, которые считают, что не нужно ничего знать самому, нужно только взять библиотеку и впихнуть, работают с этим стандартным флоу и считают, что остальные области не существуют как факт. А все то, чем они пользуются пишет какой-то мегамозг, потому что ему больше нечем заняться
Я надеюсь, что сами вы пишете только на ассемблере, причём сразу в машинных кодах.
Всё прочее было бы просто возмутительно с точки зрения вашего подхода.
В небольшом городке прихожане после воскресной проповеди подошли к священнику. Один из них набрался храбрости и задал вопрос, вертевшийся на языке у всех: «Вы призываете к скромности и бескорыстию — а ваш дом самый богатый в городе. Вы проповедуете умеренность и воздержание — и неоднократно выходите навеселе из трактира. Вы восхваляете смирение плоти — но много раз вас замечали выходящим из дома весёлых девиц. Как всё это совместить ?».

Священник ответил: «Дети мои, всё очень просто — делайте то, что я говорю, но не делайте того, что я делаю».
Зачем же на ассмеблере-то писать? Для генерации ассеблера есть компиляторы. Но да, за ними иногда присматривать нужно.

Такой вот пример:
  uint32_t big_indian_read_foo(const void* p) {
    unsigned const char* ptr = static_cast<unsigned const char*>(p);
    return (ptr[0] << 24U) + (ptr[1] << 16U) + (ptr[2] << 8U) + ptr[3]; 
  }
  uint32_t big_indian_read_bar(const void* p) {
    unsigned const char* ptr = static_cast<unsigned const char*>(p);
    return (ptr[0] << 24U) | (ptr[1] << 16U) | (ptr[2] << 8U) | ptr[3]; 
  }
Казолось бы: не должно быть никакой разницы? Ан нет — вторая функция заметно быстрее… и понятно почему.

Да, конечно, не всегда нужно в такие дебри залезать. Если я пишу вспомогательную утилиту на Python… в код я не полезу — ибо раз Python, значит скорость меня не слишком волнует по определению… но уметь это делать и, главное, делать в случаях, когда это полезно… таки нужно.
и понятно почему
Просто повезло, что у этого процессора есть XCHG/BSWAP.
Дык вопрос же не в этом, а в том — умеет ли компилятор это выражение «свернуть». Инструкции-то есть на всех распросранённых архитектурах: MIPS, ARM, POWER… вот только если использовать сложение — то это только clang умеет… а битовые операции — гораздо больше компиляторов «сворачивают».

big_indian просто получилось или таки с намеком?

Где-то посередине. То есть с одной стороны — это «слегка индусский» код. С другой — в большинстве случаев оно работает-то нормально.

Напрашивается идея: использовать htonl… но MSVC в это случае… вызовет htonl!

Впрочем другие компиляторы htonl нормально отрабатывают… и можно надеяться, что когда-нибудь… в светлом будущем… и MSVC поправят, так что — да замечание про то, что лучше бы использовать htonl тоже будет неплохим… но идеальным, конечно, будет напоминание про _loadbe_i32 — которое работает с MSVC, но… не работает с GCC.

P.S. Вообще же удивительно — сколько всякого интересного можно получить из кандидата при обсуждении даже такой, казалось бы, вполне тривиальной задачи. Ну вот такой язык C++ — куда ни глянь, всюду овраги, буераки да капканы…
А что вообще делает эта функция? Что означают все эти интереснейшие вычисления?
И является ли именно эта функция узким местом, которое надо оптимизировать? Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?
Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?
Вообще-то в имени функции был намёк.

И является ли именно эта функция узким местом, которое надо оптимизировать?
С большой вероятностью. Если бы вы обратили на дальнейшую дискуссию, то заметили бы флажок компилятору -mmovbe. То есть это AMD и Intel не поленились и ради этой функции аж специальную инструкцию замутили — в добавление к той, что всегда была.

А что вообще делает эта функция? Что означают все эти интереснейшие вычисления?
А это — уже вопрос к интервьюируемому, разве нет?
Очевидно делает преобразование из одного endian в другой endian. Я тут сразу вижу намёк на код на каком-то микроконтроллере, может даже на xmega или типа того (судя по ссылке всё-таки нет).
Иногда приходится задумываться даже о таких вещах. Например мы буквально сегодня задвинули в мастер рабочую версию бутлоадера для нашей железяки на микроконтроллере xmega128. Проблема была в том, что нужен был USB-стек, но он с трудом влезал в 8К памяти. Мне пришлось весьма сильно помочь молодому программисту с экономией памяти. Выгадывали буквально по 10 байт за раз. Программа, естественно, на голом С, ибо С++ туда ну совсем никак не лез. В итоге получилось 7800 байт, но был момент, когда программа весила 9000+. Наверное странно в 2019 году читать о нехватке памяти размером 8 килобайт. Вот таков он, суровый мир железячного программирования.
У нас другая сторона той же медали. Никаких микроконтроллеров, у нас очень «большое» (и дорогое) железо.

Но когда речь заходит о десятках миллионов запросов в секунду… такие мелочи начинают играть роль.

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

P.S. Кстати не первый раз замечаю что наши проблемы — очень близки проблемам эмбеддеров. А разгадка простая — даже если у вас железо очень суровое и памяти «дофига» и ядер и всего-всего «дофига»… добавьте туда миллион запросов… и, вдруг, на один запрос — у вас ресусов ну вот ни разу не дофига… а почти столько, сколько в микроконтроллерах.
Я когда-то начинал ещё на Спектруме, снимал защиты с Bill Gilbert и Co, делал читы для игр, затем делал демо. В итоге многие приёмы мне потом пригодились на контроллерах и DSP. Когда памяти и герцев мало, а нужно что-то делать 100 000 раз в секунду. Или отладка с помощью одного светодиода, потому что JTAG не предусмотрен.
С другой стороны, если это правда Senior, он знает алгоритм сортировки слиянием


Он забыл уже. Это для его работы и не важно.

Зато сеньор делает то, то много полезнее для решения прикладных задач на фирме — корректно архитектуру проектирует.

А алгоритмы сортировки — это те знания, которыми может похвастать джун, который еще не умеет грамотно архитектурные вещи делать.

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

Сеньор, что пишет алгорим сортировки самостоятельно… гм. Ну разве что чтобы отвлечься от рутины. Если понадобится что-то вычурное, то полагаю, сеньор знает о существовании тома третьего «Сортировка и поиск» книги Дональда Кнута «Искусство программирования»

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


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


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

Плюс ко всему синапсы человеческого мозга образуются случайно, можно годами усилено что-то зубрить или решать, а в долгосрочную память отложится, например, долгожданная встреча с друзьями. Человеческое мышление это не просто передача сложнозакодированного с помощью комбинаций из 25ти медиаторов сигнала. Все запоминание и мышление является морфогенетическим процессом. Те самые синапсы всю жизнь образуются и разрываются. Если вы хотите что-то запомнить навсегда необходимо перевести тот или иной процесс или информацию в синаптическую связь; а если гонять по старой связи как перед экзаменами или собеседованиями, то такая информация быстро забывается. То есть нужно время, чтобы образовались синапсы, а они в свою очередь образуются с конечной скоростью. Если верить книгам, то каждый день один нейрон образует по 2-3 синапса и столько же разрывает.

Практический опыт практическому опыту рознь, все дело в том, что тот или иной человек запоминает, и это происходит вне зависимости от него самого, синапсы образуются случайно. То есть наше запоминание это образование связей, по которым бегает сигнал и если мозг отключается больше, чем на 5-6 минут (при травме например), начинается разрыв этих самых связей и человек не может вспомнить как его зовут. Следовательно, образование новых связей и есть решение тех или иных задач. Бывает ломаешь голову над задачей, спустя какое-то время приходит решение, надо было лишь понять. Так вот это самое «лишь понять» это когда образуются новые связи. И связывают они между собой настолько отдаленные участки мозга, в которых хранится настолько разная и далекая информация (зрительные образы, слуховые, двигательно-моторные), что происходит это самое понимание. Но просто так это понимание не придет, нужно жить с некоторой мыслью какое-то время, чтобы дождаться образования новых синаптических связей и таким образом запустить механизм синтеза и увидеть, например, новую закономерность так, где вы ее не видели. Весь вопрос как долго человек может жить с той или иной мыслью, да и нужна ли она вообще…
По мне так удачное прохождение веселых задачек на онлайн ресурсах типа Codility или Codesignal гарантируют только одно — человек умеет решать веселые задачки. Если в это состоит бизнес компании, то такой подход оправдывает себя. Если нет, то это ИМХО потеря времени как соискателем, так и работодателем. Более резонно дать какую-то задачу из тех, что реально решаются в компании. Причем если мы говорим о сеньерах, задачи тут нужны абстрактые — кодить сеньер умеет полюбому :)
кодить сеньер умеет полюбому

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

Не можешь вспомнить — выведи. Забыл как переменные в том алгоритме, который вам показали 20 лет назад на доске показали, назывались — дай им другое название.

Блин, почему все утверждают, что «реальную» практическую задачу они решат, а сортировку — ну никак не смогут написать? А они, вообще, пробовали? Или они, на самом деле, кода какого-либо уже лет пять не писали? Так тогда они и не «синьоры» никакие, нафиг они на эту позицию идут? PM — может быть, но никак не TLM…

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

Ну блин, он про эту сортировку знает куда больше, чем про реальное задание, которое ему может достаться — что может ему помешать «сложить кубики», чтобы сделать работающее решение? Он уже не помнит как работает for? Или if?

Как раз если вы помните всё это — то да, написание сортировки ничего не даст. Как меня на собеседовании пропросили написать сортировку «кучей», но остановили, когда я нарисовал дерево этой самой кучи… потому что по нему видно было, что проблем не будет — задали сразу другой вопрос.

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

Одно дело налить чайку, покурить и спокойно вспомнить. Другое дело что надо вспомнить когда в углу тикает таймер. И ты понимаешь что у тебя впереди еще две задачи висят. У меня лично ступор. Что показывает этот тест на время? По-моему ничего. Мне что каждый день на работе необходимо будет вспоминать на время какие-то алгоритмы? Кто это вообще придумал. Кто вообще в здравом уме может держать в голове пару популярных фреймворков на изусть, пару баз данных, пару облачных сервисов, докеры, кубернейтсы, фронтэнд, бэкэнд. А тут сортиовка слиянием на время. Вы прикалываетесь? Может еще красно черное дерево повернуть или нейронную сеть накидать с нуля за 20 минут?

Другое дело что надо вспомнить когда в углу тикает таймер.
А что — в реальной работе «таймер» никогда не тикает? Никогда ничего не делается «к демонстрации» или «к конференции»? Ну… вы счастливый человек… может быть и найдёте работу, где такого никогда не случается… но не у наc.

Мне что каждый день на работе необходимо будет вспоминать на время какие-то алгоритмы?
Опять, блин, это слово у вас. Нет — вспоминать не нужно. Нужно решать задачи. И да — часто на время, к определённому сроку и нет — никто не будет вам из-за этого давать «карт-бланш» и разрешать «задивать» код, который даже вы сами не понимаете как работает.

А тут сортиовка слиянием на время. Вы прикалываетесь? Может еще красно черное дерево повернуть или нейронную сеть накидать с нуля за 20 минут?
А почему бы и нет, собственно? Кто вам может помешать? Задачи простые, уточняющие вопросы вам никто задавать не запрещает… в чём проблема-то?

Ещё раз повторю: никто не требует от вас заучивать те же красно-чёрные деревья, как учат наизусть стихи — наизусть. И даже если вы перепутаете роль красных вершин и чёрных в том самом красно-чёрном дереве… я не обижусь… да, блин, если даже вы вместо красно-чёрного дерева соорудите AVL-дерево… я думаю тоже сойдёт.

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

P.S. Про нейронку, впрочем, я бы стал спрашивать только если бы у человека что-то было в резюме, с ними связанное. Можно проработать довольно долгое время и никогда, ни разу, с нейросетями в принципе не столкнуться — несмотря на весь хайп вокруг них. Но если вы говорите, что вы с ними работали… тогда да, конечно.
Никогда ничего не делается «к демонстрации» или «к конференции»?
К демонстрации или конференции, особенно если нет времени, всё делается по принципу «фигак, фигак, и в продакшен». Там никто не упарывается по алгоритмами и оптимизации, от кода требуется только чтобы он запустился и хоть как-то отработал пару часов.
UFO just landed and posted this here
Сколько вы из этого времени будете писать сортировку?
Минут 20, я думаю.

Ну напишет человек сортировку. А дальше что? Времени ни на что другое не останется уже.
Ну и отлично. Я напишу как кандидат умеет писать код, кто-то другой — поговорит с ним на тему того, как проектировать сложные системы, ещё кто-то — как налаживать работу команды.

Почему вы считаете, что один интервьюер должен с одного интервью о кандидате узнать прям сразу всё?

Другое дело что подобные задачи на собеседовании вообще спорный вопрос.
Нет, практика показывает, что это необходимый вопрос — если вы хотите нанять «синьора», который ещё и код писать может.

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

Они не проверяют (и не должны проверять!) вашу память. Они проверяют — умеете ли вы писать код.

P.S. Впрочем обычно всё-таки рекомендуется давать что-то «по мотивам»: задачу примерно такого же уровня сложности, но вот уж не совсем такую, чтобы человек её когда-то на доске видел. Но это, в общем, только чтобы психологически меньше на человека давило.
UFO just landed and posted this here
Всё, после этого скорее всего другой интервьюер ничего не узнает, потому что на следующий этап чувака уже не позовут. Вот в чем проблема.
А где вы видите проблему? Кандидат спокойно пойдёт на другое интервью в другой фирме — и там уже всё будет хорошо. Если это была случайность. А мы возьмём на работу кого-то ещё. Не вижу трагедии.

Вы так рассуждаете, как будто «проваленное» интервью — это прям конец, всё, катастрофа.

В том, что такие задачи используются как первый (и поэтому единственный критерий)
Это нормально. Так как наша задача — не забрать всех способных кандидатов, а максимально снизить вероятность того, что на работу возьмут человека, который не справится с задачами.

В других фирмах требования могут быть иными, никто ж не спорит…

Собственно если вам нужен именно Senior-чувак, а не олимпиадник — то проводить отбор по критерию где лучше справится олимпиадник странно.
Ещё раз: «Senor-чувак» — это всё равно, в первую очередь, человек умеющий писать код. И, как вы верно заметили, олимпиадники такими задачками отсеиваются плохо, а сеньоры, незаметно для себя, переставшие быть программистами и ставшие менеджерами и алминистраторами — хорошо… так что как раз для них — эти задачки и хороши.

Для скайп-скрининга она слишком долгая, многие вещи не проверяет
Ну дыг для этого есть уже основное интервью с личным общением…

Ваше же предложение обладает одним, но очень существенным недостатком: написание таких утилит ещё хуже вкладывается в то самое пресловутое Skype-интервью, чем написание сортировки. А давать это как домашнее задание… ну если вы индусов, которые чужое решение будут предалагать не видели — то это ваше счастье.
UFO just landed and posted this here
именно вспомнить, за 20 минут написать не помня хорошо детали алгоритма и не заглядывая в гугл — весьма сложно
Если вспомнить, то это не 20 минут будет, а 5. Нет — речь идёт именно о том, чтобы написать.

Кодинга там нет вообще, бесполезно проверять как человек пишет код по скайпу.
Это, как бы, ваше мнение. У нас в компании считают иначе. Так что в добавление к Skype шарится ещё и Google Doc — и да, там смотрится как этот код появляется. И мы не одни такие.

Этот самый код, собственно, и является основным результатом собеседования — замечания интервьюера к нему… вещь немного вторичная.

Как я уже говорил, на скайпе/телефоне кодинга нет.
И, как я говорил, именно и в первую очередь там кодинг там и есть.

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

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

Да, ситуация немного пожёще, чем в реальной работе, ну так и задача — на порядок, а то и на несколько, проще.
khim, вы тут полсотни комментариев написали, но я так и не увидел четкой вашей позиции по поводу статьи(может быть просто пропустил, не заметил). А вопрос то простой на самом деле. Вы либо не признаете статью и говорите, что написание сортировок дает очень высокие шансы(например, 90%) выявить сеньора и поэтому в вашей фирме такие собеседования и вы считаете их идеальными. Либо вы соглашаетесь со статьей и говорите, что да, такие собеседования могут отсеять высокий процент(например, 50%) стоящих кандидатов-сеньоров, но вам важнее нанять нормального сеньора, нежели ошибиться с выбором, если вы будете проводить собеседования другого типа. В этом случае вы признаете проблему поднятую в статье.
Моя позиция простая и её тут многие увидели — странно, что вам она оказалась незаметна.

Умение писать код (и, соотвественно, умение решать простенькие алгоритмические задачки) — это неотъемлемая часть понятия «Software Engineer».

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

То есть аналогия тут не с «профессиональным музыкантом, не раз блестяще выступавшем на сцене», а, скорее, c «профессиональным музыкантом, не раз блестяще выступавшем на сцене… однако возможно последний раз — лет десять назад» (а после этого занимавщийся в основном организацией концертов для своего оркестра).

И вот если бы расклад был с музыкантами именно таким, как с программистами — я бы обязательно прогонял их через «гаммы».

А поскольку ситуация с «горе-сеньорами» — именно такова, то да, у нас все интервью начинаются с написания простенькой программы какой-нибудь (обычно всё-таки не совсем из учебника, но что-нибудь связанное с ним и несложное). Ну чтобы понять — код-то соискатель в принципе писать умеет или нет?

А уже потом, когда мы выяснили, что перед нами программист (Software Engineer) — можно выяснять, какого класса он программист: джуниор там или сеньор.
UFO just landed and posted this here
Так что в добавление к Skype шарится ещё и Google Doc


Как по мне, писать код в Google Doc плохая идея.
Чем collabedit.com не устраивает?
Если воспринимать ту же сортировку слиянием как реальную задачу

То любой программист сначала поищет доступную информацию.

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

Mergesort появилась в 1945 году, quicksort в 1960, а timsort в 2002. Лучшие ученые по компьютерным наукам не могли придумать quicksort 15 лет, до timsort за 42 года никто не догадался, почему вдруг обычный человек должен уметь это сделать за полчаса во время собеседования?

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

Mergesort появилась в 1945 году, quicksort в 1960, а timsort в 2002.
Однако основная идея первого и второго — занимает по паре строк, а вот третьего — страница, а то и две, текста. Потому первые два легко можно написать во время собеседования, а вот timsort — я бы на собеседовании не давал.

Лучшие ученые по компьютерным наукам не могли придумать quicksort 15 лет,
Потому что для этого требуется понятие рекурсии. В ранних компьютерных системах рекурсивные алгоритмы были невозможны, так как в них не было стека. На машине без стека реализовать QuickSort действительно тяжело, на машине со стеком — он тривиален.

Но никто и не предлагает ведь писать QuickSort на языках без стека и рекурсии.
А то, что для изобретения нуля, отрицательных, а затем и комплексных чисел потребовались столетия — вас не смущает?

Не смущает. Для них точно такая же логика — если человек их не знает или забыл, странно требовать от него их переизобрести за несколько минут.


Однако основная идея первого и второго — занимает по паре строк
Потому первые два легко можно написать во время собеседования

Если человек эту идею не знает, то нельзя. Независимо от того, Senior он или нет.


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

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


Но никто и не предлагает ведь писать QuickSort на языках без стека и рекурсии

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

Если человек эту идею не знает, то нельзя.
Ну идею и досказать можно, если человек забыл. Всёж-таки там ещё и интервьюер есть. Человек же не в в сурдокамере интервью проходит.

Я сильно сомневаюсь, что Хоар придумал быструю сортировку через 10 минут после появления первой в мире машины со стеком.
Конечно нет. Вначале был изобретён QuickSort и некоторые другие алгоритмы — а уже потом, через несколько лет, появились PDP-8 и HP 2100 с аппаратным стеком для их поддержки. После чего то, что требовало от Хоара изобретательности и находчивости — стало рутиной.

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

"Скажите мне, как оно работает, а я вам код напишу"?) Ну так даже джуниор может, по готовому ТЗ писать. Можно тогда и сразу в интернете описание искать.


Конечно нет. Вначале был изобретён QuickSort и некоторые другие алгоритмы

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


А почему оно ни с чем не ассоциируется, извините? Как так получилось?

По условиям примера. Человек не знает, что такое MergeSort, и вы говорите, что он должен ее придумать. Не вспомнить, а придумать. Если бы ассоциировалось, это и было бы "вспомнить".

Изначально вы сказали, что QuickSort не могли придумать потому что машин с рекурсивными алгоритмами не было, я исходил из этой информации.
А читать мы умеем? Вот то, что я сказал:
На машине без стека реализовать QuickSort действительно тяжело, на машине со стеком — он тривиален.
Я сказал, что его тяжело реализовать, а не что он был придуман потому что появились машины со стеком. Это, как бы, совершенно разные вещи.

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

Софт всегда идёт на полшага впереди железа. Вначале придумываются некоторые алгоритмы, которые можно ускорить добавив соответствующий аппаратный блок, а потом уж этот блок «запекается в кремнии».

Кто-то мог догадаться и раньше Хоара, но почему-то не догадался.
А почему не догадался? Потому что Шелл был идиотом? Нет, конечно. Просто пытался сделать сортировку из того, что у него было: циклы, проверки… нерекурсивные процедуры…

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

Да, на машине без стека и рекурсии — это был гениальный прорыв, откровение… но сегодня мы уже полвека работаем с подобными машинами, у нас почти все структуры данных в округе (HTML/XML, JSON и прочие всякие DOM-деревья и CSS) рекурсивны, а принцип разделяй и властвуй вбит в подкорку каждого, уважающего себя, программиста! В этом мире QuickSort ну никак не должен быть проблемой.

Человек не знает, что такое MergeSort, и вы говорите, что он должен ее придумать. Не вспомнить, а придумать.
Но ведь придумывает-то он его не в вакууме! Он же, по условию задачи, программист-разработчик! Он, извините, программы пишет. Сегодня. Его не заморозили и не перенесли из середины 50х в наш мир. А тут ещё и название вполне «говорящее».

QuickSort же — это приложение одного из базовых (на сегодня базовых) методов к одной из простейших задач — сортировке. Условно говоря — это не изобретения концепции отрицательных чисел, а попытка придумать какой будет результат у умножения -1 на -1. Ну если вы забыли, вдруг. Это всё выводится из базовых свойств умножения. И вот точно также QuickSort выводится из приципа разделяй и властвуй… а уж если вы этого принципа не знаете… какой из вас сеньор?
Вот то, что я сказал

Я знаю, что вы сказали, я неправильно это понял.


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

Затем, чтобы в стек данные ложить? Адрес возврата например?


мы уже полвека работаем с подобными машинами, у нас почти все структуры данных в округе рекурсивны
В этом мире QuickSort ну никак не должен быть проблемой

Если человек не знает, что алгоритм сортировки с названием "абырвалг" — рекурсивный, он никак не сможет об этом догадаться. И даже если он спросит "рекурсивный он или нет?", то из знания только этого факта конкретный алгоритм вывести нельзя. Mergesort например тоже рекурсивный, только характеристики у него другие, и под "абырвалг" может скрываться и то и другое.


И вот точно также QuickSort выводится из приципа разделяй и властвуй

Рекурсивная форма MergeSort тоже выводится из этого принципа, только это другой алгоритм.


а уж если вы этого принципа не знаете… какой из вас сеньор?

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


QuickSort же — это приложение одного из базовых (на сегодня базовых) методов к одной из простейших задач — сортировке. Условно говоря — это не изобретения концепции отрицательных чисел

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

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

Mergesort например тоже рекурсивный, только характеристики у него другие, и под «абырвалг» может скрываться и то и другое.
Нет. Классический merge sort — ни разу не рекурсивный. Там два вложенных цикла и 4 ленты.

Потому он и появился гораздо раньше, чем QuickSort.

И вот точно также QuickSort выводится из приципа разделяй и властвуй.
Рекурсивная форма MergeSort тоже выводится из этого принципа, только это другой алгоритм.
Ну и нормально. Если вы его сделаете и доведёте до состояния, когда ему дополнительная память будет не нужна — я это тоже приму.

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

а уж если вы этого принципа не знаете… какой из вас сеньор?
Знание принципа никак не означает умения выдать любой алгоритм с его участием за несколько минут.
А «любой» и не нужен. Нужен работающий. Ну плюс с типичным временем O(N log N), памятью O(log N), вот это вот всё.

После того, как будет написан работающий код — можно будет и этот код и алгоритм обсудить… поговорить про память, константу и всё такое прочее.

То есть такие же условия, как и при изобретении этих алгоритмов в первый раз.
Странно — а многие тут начинают вопить, что допуск к компьютеру (то есть возможность один раз положить в него стопку перфокарт и получить результат) раз в неделю с 2 до 3 часов ночи — это негуманно.

</sarcasm>

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

Только у них ещё и опыта работы не было и Computer Science тогда был в зачаточном состоянии…

Если человек не знал или забыл, в обоих случаях это работает одинаково, и на переизобретение с нуля требуется время. Время и условия, которые выходят за рамки собеседования.
Странно — а вот тут человек утверждает, кто это время — это «полчаса-час» даже без подсказок (если изначально теория за три месяца училась).

И мой опыт скорее с ним согласуется. И собеседование на этом строится.

Если же вы подходите к обучению по принципу «всё выучил, потом всё сдал, в голове ничего не осталось» и на повторное изучение чего-то, что вы изучали три месяца десять лет назад вам нужно не «полчаса-час», а снова три месяца… то тут уже неважно на какую позицию вы претендуете… потому что у вас будет абсолютно бесполезно спрашивать — почему вы приняли то или иное решение пять лет назад… а это бывает нужно. Особенно если вы были «сеньором» и ваши решения были реально существенными.
В том-то и дело, что все эти базовые алгоритмы люди придумывали без всякого Гугла и интерактивных сред — вот примерно в тех же условиях, в которых вы находитесь во время собеседования.

Когда это время собеседования занимает месяцы и годы?
Какой из алгортимов люди изобрели во время собеседования при устройстве на работу? Я о таких не слышал.


а многие тут начинают вопить, что допуск к компьютеру раз в неделю с 2 до 3 часов ночи — это негуманно

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


Странно — а вот тут человек утверждает, кто это время — это «полчаса-час» даже без подсказок (если изначально теория за три месяца училась).

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


на повторное изучение чего-то, что вы изучали три месяца десять лет назад вам нужно не «полчаса-час», а снова три месяца

Между "полчаса-час" и "три месяца" есть куча промежуточных вариантов. Более вероятных.
Да даже и час на собеседовании обычно не ждут.
Да и час на собеседовании отличается от часа в спокойной рабочей обстановке.

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

Да даже и час на собеседовании обычно не ждут.
Да и час на собеседовании отличается от часа в спокойной рабочей обстановке.
Всё так. Потому я вполне готов принять и не вполне правильное решение и даже обсуждать его.

Но от отказа от его порождения — я принять не готов, извините.

Вот этот коммент в топ надо или отдельным постом. А то псевдосиньоры выше такую дичь несут…

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

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

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

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


Люди довольно массово считают, что собеседующий (HR, техлид, сеньор, ...) заинтересован в найме кандидата. Во многих случаях картина приоритетов и желаний другая:


1) Получить премию и зарплату
2) Порадовать себя (поделать что-то приятное, у некоторых — написать что-то крутое)
3) Сходить в отпуск
4) Поесть на обеде за счёт компании
5) Отдохнуть, так как объелся
6) Уйти домой пораньше

n) Нанять кандидата

n + много) Провести собеседование хорошо, чтобы кандидату было хорошо

n + крайне много) Написать тому, кто не подошёл, обьяснить причины и дать советы при наличии просьбы об этом.


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


Недавно столкнулся с известной конторой, руководство которой заявляет, что им крайне нужны ещё разработчики. Контора не самая плохая, поэтому каким-то чудом сотрудники им посоветовали несколько неплохих программистов, которые ищут работу, дали их контакты. HR отдел не смог заставить себя написать им на почту (!), когда об этом узнали разработчики, то они сходили к руководству, которое просто погрозило пальцем, но не заставило написать потенциальным кандидатам (!). И все, трём отдельным группам людей найм новых сотрудников вообще не нужен. Но эта компания публично вешает кучу вакансий, постоянно ноет, что нужны новые люди, а никто не хочет идти, дефицит.


И второй момент: многие почему-то считают, что то, что хороший кандидат пролетает, должно расстраивать собеседующих. На куче рядовых позиций, где велико число потенциальных кандидатов, спокойно можно отсеивать кучу людей по любым признакам. Как минимум, так действуют многие компании. А вот когда компания начинает тонуть из-за нехватки людей, то нанимающие либо получают очень болезненный мотивирующий удар по голове от руководства (если оно видит проблему и решает заканчивать эти игры) и начинают нанимать вдумчиво, либо просто бегают, увеличивают количество обрабатываемых резюме, не меняя подходы. И начинают орать "На рынке дикий дефицит!!! Остались только некомпетентные, они даже красно-черный хешмап развернуть и отсортировать не могут!!!!11 Сеньоры устраиваются только по знакомству, их не выцепить на рынке1111111 Мы дико стараемся, премию нам, срочно премию!!!!"

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

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

Если люди нужны — их нанимают, а если не нужны — ноют, что люди нужны, да вот никто не идёт или слишком дорого, или цвет волос не тот.

Если процесс найма /когда люди нужны/ тормозит HR-служба, то после этого HR-служба просто исчезает в полном составе или отодвигается в сторону, а нужные люди нанимаются и работают на благо компании. Если же люди не нужны, то см. выше. Нытьё, вакансии, «заявления руководства».
Очень много компаний это уже корпорации, которые too big to fail.

Лично мне глаза открыл один из комментариев к очередной гневной статье про собеседование в вроде бы Amazon: 15 минут по скайпу, хрипящая связь, странная задача за 5 минут до конца собеседования, а потом «ваше время вышло» и HR отключается.
Так вот, в комментарии бывший сотрудник HR объяснил — в гугле на каждую открытую вакансию поступает в среднем 1500 резюме, из которых по формальным признакам отбирают примерно 200, а уже из них проводится 20 собеседований. Благодаря развитой сети филиалов, программам релокации и общей престижности за вакантное место конкурируют фактически все разработчики всей планеты. Миллиард индусов, китайцы, граждане ЕС, канадцы, местные — все. И поэтому «гугл» может себе позволить перебирать харчами, нанимая по желанию левой пятки только женщин C++ сеньоров ради гендерного равенства, или рыжих, ирландцев, геев, да хоть сеньораС#-CPL-подводного военного ныряльщика-негра-альбиноса.
Плюс эффект масштаба, тот же гугл нанимал по ~13тыс человек в год, то есть это около пары миллионов поступивших резюме, глаз и рука замучаных кадровиков замыливается и отдельные личности превращаются в цифры и галочки CRM.
Заголовок спойлера
гугл тут это пример, подобная ситуация в любой крупной корпорации
а уж если нанимает не сама корпорация, а «кадровое агенство», то всё ещё в десять раз хуже
Только соискателю как-то не легче от понимания почему вопрос «работы всей его жизни» решается на 60% рандомом. Ему важно, только то, что это рандом.
И уж совсем не вызывает понимания, когда от таких же проблем страдают «молодые динамично развивающиеся компании», в которых генеральный имеет возможность без напряга лично отсобеседовать каждого желающего.
Культ Карго?
«Начнём делать как Гугл — станем новым Гугл!»
Ну или величие ударяет в голову, в стиле «да кто они такие, чтоб Я лично их собеседовал, за воротами очередь, а в hh/superjob тыщщи вакансий!»
Я знал, для чего нужна сортировка слиянием, я знал, как найти её код. Я лишь не мог вспомнить его.

По-моему невозможно знать, для чего нужна сортировка слиянием, не зная реализации её и некоторых ближайших сортировок
так не нужно реализацию знать, нужно знать общую идею. А как назвать переменные и в каком порядке пусть цикл — детали реализации.
так никто и не требует доскональное знание реализации, но зная общую идею написать (не мега оптимально, но все же вы сможете) вы сможете. Ну и не зная реализации merge невозможно догадаться до того, что она лучше работает при стабильной сортировке и хуже при обычной
полностью согласен с автором для примера можно взять студента отличника который работал со мной и я ему помогал с элементарными вещами в минуты отчаянья и для него было как магия.
говорил он мне следующее что он все работы делал в институте сам а тут банальный баг пофиксить не может и большая часть того что он знает ему не нужна т.к. она реализована в библиотеках и наврятли он сделает лучше.
Странный пост, конечно.
Мне всегда казалось, что если ты уже состоявшийся синьер (с трудом представляю что это, наверно матерый прогер который может сам ставить себе задачи, сам придумывать решения, сам реализовывать, да еще обладать чувством прекрасного), то на собеседовании ты можешь лениво говорить: «я это не знаю», «я это не пробовал». «Ну если вы настаиваете я могу попробовать придумать сортировку пузырьком, но это вряд ли будет быстро».

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

Хотя, если таки посты есть, значит они кому-то интересны?

Избитая тема.


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


Если кандидат заявляет, что он умелец в реализации алгоритмов/участник ACM/ещё как-то связан с этим, то тоже стоит проверить.


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


Главная цель собеседования — понять, подходит ли человек для работы в вашей команде или компании и на какую должность(ну или соответствует ли позиции, если нужна только конкретная). А специфика у всех своя.


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


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

История из жизни:

— Необходимо знание векторной математики.
— Подучил, пришел на собеседование.
— Час гоняли по задачкам с векторами и кватернионами.
Итог: за три года работы в студии векторная математика понадобилась всего два раза в задачах на пол часа — час. Причем пример решения гуглился первой же ссылкой.
Вот-вот. У меня был период в жизни, когда я хорошо умел решать всякие задачки по высшей математике, потому что изучал всё это. Теперь я решить никакие более-менее сложные задачи не смогу без учебников и гуглежа, даже если на карту поставят мою жизнь. Значит ли это, что я полный дебил? Ну, не исключено. Но более вероятно, что за 10 лет работы я тупо ни единого раза не применял те знания, и они успешно отошли в туман.

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

Думаю, дело ещё и в том, что вам вспомнить это можно будет за на порядок-два меньшее время, чем не изучавшему человеку — изучить с нуля.

Знание базовых вещей решает. Я по факту не вижу ни чего плохо в том что у меня спросят про сортировку. Но не понимаю зачем я должен буду решать по ней задачки и писать код без справочного материала . Я конечно не сеньор, но уже на моем уровне багаж знаний просто огромен, у сеньоров еще больше я так полагаю, когда это все подробно помнить? Знаешь какая сортировка лучше другой, чем отличаются и какую в какой задачи применить, отлично. А саму сортировку написать можно и с материалом, ведь если знаешь, то сможешь и нагуглить быстро, а если не знаешь, то и гуглить будешь дольше — если вообще нагуглишь)
Не читал статью, но по заголовку все логично. Senior должен прежде всего уметь проектировать систему. Если честно, слабо представляю как можно наложить на эту задачу классические задачки по программированию
Senior должен прежде всего уметь проектировать систему.
Полное название должности, всё-таки, «Senion Software Engineer». Так вот если кандидат — вообще не «Software Engineer»… то уже неважно: Senior он или Junior.
Так вот если кандидат — вообще не «Software Engineer»… то уже неважно: Senior он или Junior.
Должен ли инженер-строитель уметь самолично укладывать кирпичи, чтобы быть хорошим инженером?
Должен ли инженер-машиностроитель уметь лично управлять токарным станком?
Должен технолог производства уметь воспроизводить все этапы ручным оборудованием?
и т.д.

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

И таких навыков у software engineer'а — тоже вагон. Он не должен уметь превращать программу на C в машинный код (для этого существует компилятор), он не должен уметь расставлять пробелы (для этого существует автоформаттеры) и прочее.

Да, в общем-то, даже следить за своим сервисом он не всегда должен (для этого админы есть).

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

Я не говорю, что каждая ваша строка кода будет превращаться в подобный квест (так вы 100 строк программы будете писать год), но если вдруг это потребовалось… да вы должны это уметь. А кто, собственно? Junior или NewGrad? Ну вот кто? Кроме вас?
Но написание кода — никогда не бывает рутиной.
Честно, я вам завидую, если для вас написание ЛЮБОГО кода не является рутиной.
Писать код — это ооооочень широкое понятие, и в любом случае написание кода — это и есть рутина.
ИМХО, работа software engineer'а, особенно уровня Senion — не писать код, а решать проблемы. Писание кода — это инструмент, причём далеко не единственный.
но если вдруг это потребовалось… да вы должны это уметь. А кто, собственно? Junior или NewGrad? Ну вот кто? Кроме вас?
Вопрос в том, должен ли я это уметь постоянно, или быстро этому научиться по мере надобности. Я тоже умею играть в эту игру, и могу насочинять вам пару тысяч навыков, которые неплохо бы иметь в любой профессии «ну просто на всякий случай, кто если не вы». И поддержание которых в актуальном состоянии сожрёт всё ваше время, не занятое сном.

Дело тут не в том, что кому-то лень, мозгов не хватает, ЧСВ жмёт и т.д., хотя и не без этого. Ресурсы мозга ограничены. Как не упарывайся, а запомнить больше, чем в него помещается, невозможно. Чем больше знаний вы держите и постоянно обновляете просто про запас, «потому что кто, если не вы», тем меньше места остаётся под всё остальное, в т.ч. под то, что нужно прямо здесь и сейчас.

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

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

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


А можно точный и поимённый список, без чего инженер — не инженер?

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

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

Ну всё, как в обычной работе — только задача «плёвая».

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

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

Вот, совершенно практическая, недавно возникшая задача: мы пишем систему, где нельзя использовать стандартные функции работы с памятью (почему и как отдельный вопрос… но вот так вот, нельзя) и нам нужно экономить стек. Что будет эффективнее — написать свою сортировку или как-то ограничить qsort? Или как-то убедить сортировки из стандартной библиотеки C++ не использовать память?

Как вы вообще будете делать выбор если для вас задача написания своей сортировки — проблема?

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


И проблема для меня написать сортировку по конкретному алгоритму, который вы называете, а я не знаю. Вот пузырьковую знаю, могу написать на трёх языках нескольких версий каждого на бумажке. А остальные только с алгоритмом перед глазами. Хотя лет 27 назад писал на лабах три минимум с бенчмарками на разных данных, но даже названий не помню каких. Из теории помню вроде только что есть теорема, по которой сортировка на случайных данных не может быть проще чем O(N*log(N)) и алгоритм пузырьковой за минуту вспомню.

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

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

Аааа! Держите меня! Какая вышка? Какие разделы?

Задачка. Детская. Может класс 6й-7й. Отсортировать 5 монет по весу за 7 взвешиваний на весах. Доказать, что за 6 взвешиваний гарантировано это сделать невозможно.

Дерево решений.
2⁷=128>120=5!
2⁶=64<120=5!
Меняем 5 монет на N элементов, получаем сложность сортировки O(N log N). Всё! Вот совсем всё!

Причём тут вообще вышка?

Ну почему люди так любят всё усложнять и так не любят думать?
Меняем 5 монет на N элементов, получаем сложность сортировки O(N log N).

Вот про это я и говорю. В дереве решений у вас факториал, а в выводе уже логарифмы. Откуда?

Как вы вообще будете делать выбор если для вас задача написания своей сортировки — проблема?

Так и будем — возьмем на исследование по задаче день или два, проверим сколько стека занимает qsort, проверим можно ли убедить сортировки из стандартной библиотеки C++ не использовать память, поищем алгоритмы сортировки в интернете и выберем подходящий. В крайнем случае свой напишем, пусть и не за 10 минут, а за день. Вместо сортировки может быть какое-нибудь шифрование или драйвер ввода-вывода. Ничем не отличается от любой другой задачи. И как и любую другую задачу, совершенно необязательно знать ее во время собеседования.