Комментарии 392
Я так и не понял является ли автор профессиональным программистом или профессиональным музыкантом. Кажется ни тем ни другим. При приеме на работу в оркестре музыкантов обычно тестируют по сборникам оркестровых сложностей по виду его инструмента. И все кто хочет играть в оркестре с этим сборником так или иначе работают. Что касается гамм — именно так на русском звучит слово scales — то если музыкант всю жизнь их не играет он рискует потерять скилы еслии это конечно не супергений которому это не нужно.
Что касается знания алгоритмов наверное при приеме на работу в ibm или ms это важно. Для 100500 вебстудии выглядит как лишнее. Хотя сам писал сортировку quicksort при приеме на работу.
В первом случае действительно могут быть проблемы написать код сходу, но немного времени и справочных материалов — и всё отлично получится. А во втором даже с гуглежом реализация скорее всего получится кривая, потому что у человека нет понимания. Часто, кстати, даже нет понимания что конкретено нужно гуглить.
Но на практике есть огромная разница между состояниями «знал и разбирался, но уже подзабыл» и «никогда и не знал, но в случае надобности обещаю быстро нагуглить, чесслово!»
Да, и не всегда эта разница в пользу первых. Первые — это не только те, которые «если что, быстренько вспомнят», но и те, которые если что, схватятся за устаревшие в данный момент вещи, потому что когда они разбирались — это всё еще было актуально, но сейчас уже нет.
Единственный принципиально важный тут навык — это общая способность человека учиться. Те, кто могут — учатся быстро и продуктивно, те кто не могут — или нагуглят не то, или возьмут устаревшее, и так далее. Впрочем, побочка тут тоже есть — те, кто эффективно учатся — как правило менее приспособлены к тому, чтоб пилить что-то годами на неизменном стеке.
А фразу про «общую способность учиться» я слышал много раз. С одной стороны с ней трудно не согласиться. Но с другой, часто за это умение выдают способность прыгать по верхам и жонглировать модными базз-вордами.
Фундаментальные вещи
… на то и фундаментальные, что изучаются один раз и не забываются. Там не такой большой объем информации.
Разница только в том, кто что считает «фундаментальным». Некоторые и алгоритмы сортировки называют фундаментальными. Но да кто ж им доктор.
Но с другой, часто за это умение выдают способность прыгать по верхам и жонглировать модными базз-вордами.
Не вижу никакой связи, если смотреть по результатам (а по чему еще смотреть, по способности нагнать словесной пурги?).
… на то и фундаментальные, что изучаются один раз и не забываются.Если они забываются — то зачем они, вообще, учились? А если в готове от выученного что-то осталось — то нет проблем на основании того, что там осталось изобразить какую-то реализацию… нет никаких.
Никто ж не просит идеальную реализацию вспомнить. Я помню как один из кандидатов вообще «сортировку слиянием в стиле QuickSort» изобразил… сливая каждый раз в новый массив. И что? Это плохая сотрировка? Да — потому что память транжирит. Кандидат «всё понял», напрягся, сделал «merge-in-place» (хотя изначальная задача этого, в общем-то, не требовала), получил от меня хорошую оценку — видно сразу и чего человек помнит и чего он умеет.
Вот последнее чего от вас хочет интервьюер — умения воспроизвести в точности то, что вы когда-то, лет 20 назад один раз на доске увидели… Вот это — точно бессмысленное умение.
Не вижу никакой связи, если смотреть по результатам (а по чему еще смотреть, по способности нагнать словесной пурги?).Ну, например, по количеству времени, которое уйдёт у меня на то, чтобы «причесать» то, что кандидат, если его примут на работу, сотворит.
И этот показатель для меня важнее чем умение что-то там сотворить «на скорость» исходя из «новых принципов» (которые новые только потому что историю забыли).
Вот последнее чего от вас хочет интервьюер
Это вы щас с барского плеча за всех интервьюеров сказали?
Идеальная память в современном мире не нужна — у нас есть компьютеры и Гугл. А вот умение писать код — очень даже нужно. И особенно — у сеньоров.
И да — вот именно это подобные задачи и призваны проверять.
Самое частое явление — попытки «проверять» через игру в экзамен по заковыристым практикам; на втором месте — через игру в реализацию стандартных библиотек (от разворотов строк до сортировок до чёрно-красных деревьев).
Желание проверить на чём-то ближе к делу — где-то в конце списка. Хотя казалось бы. Впрочем, даже вот вы, начитавшийся семинаров и (наверное) наслушавшийся прочих умных книжек — усиленно топите за сортировки. Хотя конечно может быть у вас там такая область, что сортировки страсть как нужны и важны. Но я в этом заочно сомневаюсь.
ЗЫ: Я по важным семинарам не ходил, но мое, успешно поработавшее на очень малом количестве случаев, мнение — очень простое. Проверять нужно способность кандидата писать код, именно типичный для предметной области. Проверять это можно не лично, а заочным тестовым заданием. Проверить потом тот факт, что кандидат написал код сам, а не организовал помощь зала — можно банальным 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 секунд в Гугле. И другое — сразу писать, не отвлекаясь на поиск, а думать о той части кода, которого в библиотеке точно нет и которую, тебе, собственно, и написать надо.
Если работник у вас в основном пишет код — скорее всего на этого работника приходится еще два работника, которые собственно решают задачи, и выдают ему подробнейшее ТЗ, которое он потом просто транспилирует в код.
Затраты времени на «написать код» в любом случае и рядом не стоят с затратами времени на, собственно, решение задачи.
А в этом случае знание наизусть помогают задачу не решать, а взять готовое решение. Потому что ты помнишь, где и какое решение уже есть.
Потому что ты помнишь, где и какое решение уже есть.
Набор стандартных функций очень многих языков примерно одинаков. Это никак не меняет того факта, что я не помню, какие именно там в каждом есть функции, и как их вообще применять. Да что там, я на JS, на котором я пишу постоянно и всегда — пишу с открытым MDN, потому что вместо заучивания функций я лучше чем-нибудь более полезным займусь, а документация и гугл никуда не денутся (а если и денутся — у меня будут проблемы совсем иного масштаба нежели «теперь доку посмотреть негде»).
Я помню как один из кандидатов вообще «сортировку слиянием в стиле QuickSort» изобразил… сливая каждый раз в новый массив. И что?
Простите, а когда это для QuickSort нужен был новый (дополнительный) массив? Он там не нужен. И что это за такой стиль QuickSort?
Есть мнение, что кто-то сам не так уж хорошо в алгоритмах разбирается, чтобы кого-то "собеседовать". Это как раз тот случай, когда не надо "спрашивать про алгоритмы".
Интересно что цитату вы провели, а вот прочитать её «не осилили». Ну так прочитайте ещё раз — там есть ответы на все ваши вопросы.Я помню как один из кандидатов вообще «сортировку слиянием в стиле QuickSort» изобразил… сливая каждый раз в новый массив. И что?Простите, а когда это для QuickSort нужен был новый (дополнительный) массив? Он там не нужен. И что это за такой стиль QuickSort?
Есть мнение, что кто-то сам не так уж хорошо в алгоритмах разбирается, чтобы кого-то «собеседовать».Есть мнение, что умение читать и понимать прочитанное — тоже входит в необходимые умения для Senior Software Engineer. Хотя формально в требованиях к вакансии — этого и нет.
Уважаемый, я хотел указать на 2 момента:
- в QuickSort дополнительный массив не нужен
- использование дополнительного массива не называется "стилем QuickSort".
О том, что ваш соискатель использовал в другом алгоритме не самое лучшее решение я ни слова не сказал.
Поэтому возвращаю вам назад претензии о чтении и понимании прочитанного.
Да и в целом, как можно доверять человеку, который, например не знает отличия list от set или, например, не может инвертнуть простое сапомисное дерево из нод c value, left, right. Ну и понятия не имеет, что такое сложность алгоритма.
Я высшую математику знал на достаточно хорошем уровне.Вы её знали? Или зазубрили?
Сейчас с ходу не найду какую нибудь даже производнуюА вы уверены? Попробуйте. Возьмите листочек бумажки, попробуйте вспомнить — почему оно всё так, прикиньте как могли бы выглядеть производные суммы, произведения, всяких синусов-косинусов.
Потом погуглите — проверьте.
Если вы математику действительно знали (умели отвечать на вопрос "почему синус 30 градусов равен ½", например), то проблем быть не должно: за паутинку в уголке потяните — вся сеть и вытянется…
Легко могу поверить в то, что времени потребуется раза два-три-четыре больше, чем в лучшие времена.
А вот в то, что ничего не получится… ну не верю.
Вот то, что вы учили на четвёртом курсе — могли и забыть. А первые один-два — наверняка остались в памяти, нужно только «чуток поскоблить».
Чему равна производная логарифма и степенной функции, а также произведения, отношения и аргумента функции я все-равно не помню и знания того что это предел разностного отношения мне не помогут. Там ведь идут теоремы формулировок которых я не помню, а вывести и доказать их самому когда даже не помнишь о чем теорема-то должна быть — увольте.
Так что без предварительного освежения курса мат анализа (или хотя-бы чтения правил дифференцирования) — никак.
Вы сами давно изучали матан? И если да, то освежали ли после обучния раз предполагаете, что человек вспомнит через десятки лет? Или вы знакомы с хаброжителем 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 лет назад решали задачи которые нужны сейчас под проект о чем написано в вакансии, а Вы не подготовились, тогда извините Вы не подходите на проект.
А мне однажды предложили в качестве домашнего задания написать потокобезопасный менеджер памяти для объектов фиксированного размера (С++), с тестами (google test) и бенчмарками (google benchmark), и чтобы было production-ready. Сложность задания они оценили "часов пять-шесть".
Я до этого никаких менеджеров памяти не писал, как-то хватало стандартных, у нас не геймдев, но решил развлечься. На выходных почитал теорию, размахнулся и накидал lock-free реализацию, С++17, оформил всё по канону, тесты к ней, комментарии, документация, только бенчмарки не сделал из-за проблем прикручивания google benchmark к visual studio (мы в конторе не использовали его, я честно написал что опыта с ним не имею). Реализация наверняка имела неотловленные тестами баги, но выглядела неплохо, как по мне. Явно не на "часов шесть".
Ответ интевьюера был коротким: "not sophisticated enough". И всё. Я так и не понял, что это было — то ли я действительно слишком туп был для них, то ли интервьюер не разобрался, то ли ещё что-то.
Мой опыт показывает, что если компания действительно ищет человека, то она обычно не имеет мозг сложными заданиями. А со сложным заданием вас с вероятностью 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 не выглядело для меня абсолютно необоснованным. Там нужно быть аккуратным, но там нет никакой особой магии.
Кроме того, как я полагаю, в отсутствие прямых указаний, выбор той или иной реализации отдаётся на откуп кандидату, и если нет грубых дисквалифицирующих косяков, а только вопросы к дизайну, то это следует обсуждать как часть интервью. Я вполне способен признать, что у я допустил ошибку, и я бы рад узнать, какую именно, чтобы её впредь не допускать. Но отписка вроде той, что я получил, без малейшей попытки сделать ревью и указать на проблему — это просто плевок. Если же отписка была саркастической, т.е. "простовато" на самом деле означало "переусложнено", то это вдвойне плохо.
Тут я с вами полностью согласен. ИМХО, хамство — давать сложное тестовое и не давать на него развернутого фидбека.
Там не мапа, там 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.
Спасибо, тут подумаю. И спасибо за ревью :)
Сорри, не вкуриваю, куда данные могут добежать? Поле next указывает на следующий чанк, которого либо ещё нет (тогда next==nullptr, и если места в пуле не осталось, то нам нужно создать новый чанк и слинковать с предыдущим), либо он уже создался и — что важно — он останется неизменным до конца жизни всего пула. Т.е. защищать нам нужно только момент создания и линковки нового чанка. Как только next присвоено какое-то ненулевое значение, защита больше не нужна, потому что next больше никогда не изменится.
В данном случае может получиться так. Пусть в классе есть какое-то поле x.
Мы создаем экземпляр этого класса, инициализируем это поле, и берем указатель на этот класс. Но вот только указатель уходит в memory, а инициализированное поле пока остается в регистре ядра.
Разве count.load() в самом начале allocate() не создаёт необходимый барьер?
Я подумал, что под абстрактным "полем x" вы подразумевали оставшиеся поля класса, вроде count.
Если вы имели в виду поле next, то вы считаете что, в отсутствие барьера, next->... может выполниться раньше, чем двойная проверка if (!next) {..} и получить разыменование нулевого указателя?
shipilev.net/blog/2014/safe-public-construction
Здесь правда про яву, но думаю, в C++ будет также
Если элемент не сконструировался, то деструктор у него вызывать нельзя
Впрочем да, вы всё же правы, это надо пофиксить.
Если не входит — лучше спросить то, что входит.
Иначе получится тот самый
— Как так-то? Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что-то в проекте менял?
— Немного, швабры вынес…
— Швабры потолок держали!
— Что??? Что извините???
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и
Классная история.
Реформаторский зуд лечится резкими обжигающими ударами по рукам
В данном случае бить по рукам следовало того, кто это всё изначально соорудил.
Чтобы можно было говорить про "сломал", оно должно было работать в прошлом.
Предположим, что главный герой этой истории всё сделал аккуратно и ничего не сломал. Что было бы дальше? Дальше уборщица вытащила бы одну из швабр, началась бы утечка, после чего все задохнулись бы в процессе поиска противогазов. Назначение вентилятора так и осталось бы нераскрытым, а для воздушного шара не нашлось бы пилота (и это в лучшем случае, в худшем он бы просто не взлетел без ТО).
Чтобы можно было говорить про «сломал», оно должно было работать в прошлом.
Оно работало. Не как лаборатория, но работало.
Но я даже не об этом, а о том, что у перестраивателя вышла лаборатория для тех, кто способен дышать ядовитым газом. Что абсолютно точно так же не то, о чём его просили.
А что можно было увидеть в этом случае? Если до швабр, которые подпирают потолок, ещё можно при наличии опыта как-то догадаться, то назначение вентилятора и воздушный шар заранее расшифровке не поддаётся.
Можно, конечно же, было позвонить знакомому заранее — но я за 10 лет работы по специальности ни разу не видел такой роскоши как контакты предыдущего разработчика.
Зачастую швабры в таких количествах и 120тонные вентиляторы немного документируются.
К тому же, в приличном обществе, перед уборкой костылей делают форк и прогоняют регресс-тесты, а не коммитятся на прод.
Исходя из восклицания "Ты хотя бы записку на двери повесил бы, что швабры для держания потолка!" я заключаю, что записки не было.
Ну и в моей практике самые головоломные костыли как раз и не документируются. Видимо, потому что костыли пишутся в спешке, когда на документацию времени уже нет.
С кодом — тем более: прежде чем разбирать страшную фекалопалочную конструкцию — нужно понять, что она делает, а в идеале — собрать на этот кусок требования и написать тесты.
Когда нет контактов предыдущего разработчика — это ещё полбеды. А когда нет контактов предыдущего заказчика… Вот есть большой кусок кода, он что-то делает с данными, откуда-то берёт, обрабатывает, куда-то результаты складывает, но никто ни из разработки, ни из бизнеса не знает что делает и зачем. С неделю (40 часов) "собираешь требования" — обходишь всех хоть как-то причастных по известным тебе бизнес-процессам, вроде получаешь картинку, что препредыдущему начальнику какого-то отдела были нужны какие-то ежедневные показатели работников для мотивации, которые никто не использует давно. Выпиливаешь, всё хорошо месяц, другой, полгода, а в январе прибегают начальники почти всех отделов и говорят, что у них годовой отчёт полную билеберду показывает.
Оказывается, где-то вне рамок системы были какие-то скрипты, у каждого отдела свой, причём с игнорированием ошибок, которые использовали эти показатели для расчёта своих раз в год, причём с игнорированием ошибок. А за это время система уже сменила версию языка, фреймворк, переехала с MySQL частично на PostgreSQL, а частично на MongoDB…
Всех обошёл, все подписали, что хотят и что кроме этого — ничего не хотят, теперь делаем.
А как возникли претензии «а чегойто у нас неправильно работает?! Срочно чините, пришли тут всякие и всё переломали!» показываешь бумажку/письмо и предлагаешь уточнять ТЗ с последующим допилом. Со временем из непонятной и неподдерживаемой кучки скриптов может получиться хорошая и рабочая документированная система.
Это если интересно работать именно в этой компании, если не интересно — после слов «вот тут какой-то код, доков нет, требований нет, заказчиков нет, разработчиков тоже нет, зависимости… а шойто такое?! короче, сделай так, чтоб лифт ходил не только вверх-вниз, а ещё и влево-вправо, тыжпрофессионал» улыбаешься и уходишь подальше.
Возможно, я не прав, но я дорожу своим психическим здоровьем.
Речь не про "делаем", речь про "чистим конюшни".
К тому же, во многих местах работают процессы риск-менеджмента, с оповещением всех потенциально затронутых изменениями в системе и перед разбором непонятных скриптов заводится новый риск.
Ну а если риски не оцениваются и никому ничего не нужно и некогда, но сделайте — я уже писал своё отношение.
PS Ведь в компании, про которую рассказываете, после форс-мажора поменяли процессы и завели что-то подобное?
если в профессиональные обязанности будет входить хотя бы раз в неделю построение красно-чёрных деревьев и написание быстрой сортировки — их стоит спрашивать у кандидата
А если посмотреть на содержание собеседований — может сложиться впечатление, что красно-чёрные деревья и сортировки пишут в каждой второй конторе. А в каждой пятой — не то, что раз в неделю, а по нескольку раз в день.
Люди, которые только и умеют брать инструмент и его использовать, умеют только брать инструменты, которые за них давно уже выбрали и использовать их, причем иногда так, что хочется плакать.
От знания алгоритмов и структур данных знания конкретного технологического стека магическим образом не прирастают.
Несколько лет назад у меня был прекрасный пример перед глазами с самописной БД. Самописная она была, разумеется, от того, что сумрачные гении времен начала нулевых сказали «third-party RDBMS это фу-фу, они или платные или кривые, мы щас быстренько сваяем!». И сваяли, и это жило в проде примерно 7 лет, пока продукт применялся к нуждам пары (больших) клиентов. Но годы прошли, появились конкуренты, большие клиенты задумали свалить, и встал вопрос о развитии продукта. Немедленно выяснилось, что самописную БД развивать невозможно вообще — большинство людей совершенно не желает к ней прикасаться, а те сумрачные гении, которые желают — жрут много денег и их силы всё равно крайне ограничены, так что говорить о feature parity с популярными продуктами просто фантастично, а фич для развития требовалось много — БД наконец-то надо было использовать в режимах отличных от тривиальных вставок и выборок, а оно такого не могло от слова «совсем».
Это конечно было не единственным фактором, в итоге похоронившим продукт — но одним из важнейших.
Второе — очевидная глупость.
Очевидно нет. Работало же, очень успешно и очень долго. Да, это в итоге превратилось в огромную проблему, но до этого жило столько времени, что все причастные уже успели получить серьезный профит, похлопать друг друга по плечам, и пойти работать куда-нибудь еще.
Мне кажется, масштабы задач очень разные
Это вам так кажется. Просто я описал свой случай с точки зрения последующего провала, а ashofthedream — c точки зрения текущего выигрыша. На самом деле в моем случае тоже никто не писал RDBMS — решали задачу «нам надо что-то для быстрой индексируемой записи с гарантиями большого потока информации и последующей выборки по индексам». Это уже сильно потом стало ясно, что тут нужен серьезный объем фич RDBMS, и на разных этапах жизни продукта некоторые самые «больные» фичи худо-бедно пытались добавлять.
Может статься, что и в примере выше троттлинг — это только макушка айсберга.
По идее redis должен справляться с таким потоком. Если по хорошему о защищать нужно скорее конфигам nginx. Если на уровне приложения то получится немасштабируемо. Нельзя будет запустить два экземпляры приложения
На редис там и так хорошая нагрузка была, поэтому было принято решение использовать что-то еще
что-то еще
интрига есть
И еще такой момент, к некоторым апи отдельные тротлеры привязаны, например у нас глобально — 10rps для пользователя, есть /api/a и есть /api/b где отдельный троттлер на 5rps, но всего у нас для пользователя 10rps. Ну то есть в некоторых случаях мы должны проверить аж три раза что пользователь может это сделать — глобально, в целом и частный случай.
Так вот, как это быстро сделать при помощи конфигов нжинса, когда есть пяток способов изменить стейт у пользователя?
Я всегда считал, что знание технологического стека дело вторичное, если кандитат знает его то это идет в плюс, если не знает, ничего страшного, минусом я это не считаю.
Смотря кто вам нужен. Если просто «толковый человек, а там разберется» — то одно. Если кто-то, кто за два дня войдет в курс дела и будет уже закрывать простые задачи, а через месяц будет шарить во всем проекте и сможет проектировать его дальше — то знание стека таки нужно, иначе «просто толковый человек» месяц будет только курить документацию и набивать базовые шишки, а правильно проектировать дальше — и вообще фиг знает когда сможет (сможет-то скорее всего быстро, но если напроектирует что-то не так, расплачиваться за это будет контора, а не он).
С третьей стороны, я не думаю что умение настроить вебпак или другой бандлер с нуля необходимый навык для абстрактного современного фронтендера, даже для сеньора. На каких-то проектах это может быть обязательным даже для джуна, а на каких-то какой-нибудь create-react-app или nx всё автоматизирует под капотом.
Ответ не так однозначен. Хороший работник может получиться из кандидата, который ПОСЛЕ приема на работу освоит теорию и будет строить вам ваши деревья. То есть при собеседовании он может и ответить на специальные вопросы.
Хороший работник может получиться из кандидата, который ПОСЛЕ приема на работу освоит теорию и будет строить вам ваши деревья.Не может. Потому что они нигде не фигурируют как что-то явно упоминаемое.
На них могут ссылаться где-нибудь в документации, но вряд ли вам дадут Кормена после приёма на работу и скажут «изучай».
Обычно предволагается, чтобы вы это сделали уже один раз, давным-давно, во время обучения.
А вот фреймворки появляются всё время новые, тут ожидать что вы их точно знаете зачастую бессмысленно — особенно если у фирмы есть есть свои «фирменные» надстройки над ними.
Ну так пусть фигурируют. У вас задача не схитрить, а получить человека в команду.
Ну так пусть фигурируют.Вы это сейчас… всерьёз? Предлагаете всей, ну вот просто всей компании буквально всё бросить и начать описывать базовые вещи из курсов Computer Science в коде и в документации ради того, чтобы получить ещё одного человека в команду?
У вас задача не схитрить, а получить человека в команду.Нет, это не конечная задача. Конечная задача — получить более качественный (или хотя бы такой же) код быстрее.
Если для того, чтобы его можно было взять на работу, остальная команда должна будет тратить лишние 10 или 100 человеко-лет каждый год (да, у нас большая команда) на то, чтобы везде-везде, где это релевантно прописать то, что человек, разбирающийся в CS и так знает… — то нафиг нам такой человек нужен?
Попробуйте не утрировать и взглянуть на вопрос здраво.
Это понятно. Но если он в течении первого дня разницу уразумеет и, соотв, начнет использовать их как следует? Ну разве это не хорошо?
В обоих случаях — доверять его решениям нельзя… а зачем нам нужен сеньор, решениям которого нельзя доверять?
Я ещё могу подобное простить джуну — чего-то недопонял, перепутал, ему никто не показывал ещё «как надо»… но сеньор — это, как бы, сложившийся специалист. И если он сложился в специалиста, которые понятия не имеет о сложности алгоритмов, кешах процессора и прочем… то нам… вот конкретно нам — он не нужен.
Кому-то, может быть, он и нужен — ну и отлично, там где всё это не нужно, я надеюсь, и о сортировках никто спрашивать не будет.
А если он начнёт гуглить перед выбором различия? Вот ваши названия мною воспринимаются не как названия структур данных, а как названия классов в каком-то конкретном рантайме. И если я могу предположить, что под LinkedList где-то лежит связный список, то вот что такое ArrayList могу только гадать, выглядит на первый взгляд как гибрид бульдога с носорогом. есть массивы, есть списки, а массивосписки как-то в базовых структурах данных не припомню. Какой-то класс, реализующий какой-то асбстрактный интерфейс списка, но под капотом содержащий массив? Или наоборот, интерфейс массива, а под капотом список?
А чётакова? Предварительная же оптимизация — это ж корень всех зол, сам Кнут сказал! Потом в профайлере всё увидим.
И если я могу предположить, что под LinkedList где-то лежит связный список, то вот что такое ArrayList могу только гадать, выглядит на первый взгляд как гибрид бульдога с носорогом.Это хорошо что вам это чудо тоже кажется диким. Это нормально. Но вот так вот Java устроена.
А если он начнёт гуглить перед выбором различия?То это значит, что он врёт либо про то, что он сеньор, либо про то, что он с Java работал. Это стандартная библиотека — причём та её часть, которая ещё из прошлого века идёт. Можно немного поработать с Java джуниором и с ней не столкнуться, но избежать её и стать сеньором — вряд ли получится.
(Не все равно может быть разве только в случае занимаемой памяти, 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 если он никому ни для чего не нужен?
И вот эта «невинная» операция — может так «протечь», что мало не покажется. Ну скажем если у нас обычно обрабатывается сто-двести заказов в день, а раз в год, в ту же процедуру, вам сгружают что-то на миллион строк.
И вот тут так может получиться, что даже если на бенчмарках всё работает быстрее на
ArrayList — но лучше всё-таки LinkedList. Ибо тот вызов, который случается раз в год вам будет, по итогу, каждый год устраивать аврал, когда вся ваша конструкция будет «вставать раком» и watchdog будет вам ваш сервис прибивать.Но если подумать — можно и с
ArrayList'ом обойтись. Скажем если «перекачивать» данные из одного такого в другой (и добавлять всегда в конец). Но для этого нужно знать, что добавление в конец в ArrayList — быстрое, а в другие места — медленное.А для этого, прежде всего, нужно понимать чем отличается
ArrayList от LinkedList и какие в них есть подводные камни.P.S. Кстати хорошие синьоры часто пишут
ArrayList (как вы верно заметили — он бывает полезнее в реальности), но говорят (голосом) «я сейчас всё допишу и посмотрю — не стоит ли тут LinkedList использовать». Это принимается… как приглашение обсудить всё это, когда код будет написан.Зависит конечно от частоты операций. Но я например не представляю, как делать предложенные Вами операции «по одиночке». То есть, как я понимаю, эти операции выполняются сразу пачкой, например «удалить все дубликаты строк». Тогда идиомой erase-remove это решается эффективнее, чем листами. А если нужно удалять по одному элементу… То как еще найти этот элемент? То есть представьте, что Вам нужно что-то удалить из середины списка. Но для этого же до этой середины еще нужно както дойти в случае листа. Получается тот самый «квадрат» (точнее линейный поиск в случае одного запроса), которого Вы так боялись
Получается тот самый «квадрат» (точнее линейный поиск в случае одного запроса), которого Вы так боялисьЕсли вы каждый раз проходите с начала — да. Но если вы обрабатываете элементы последовательно (то есть найдя один «нужный» элемент ищите другие в остатке, а не сканируя список с начала) — нет.
И да, конечно, работа с
ArrayList/LinkedList — это где-то близко к вершине айсберга… но если вы не знаете даже этого, то каков шанс, что вы не запутаетесь в дебрях этого айсберга.> И да, конечно, работа с ArrayList/LinkedList — это где-то близко к вершине айсберга… но если вы не знаете даже этого, то каков шанс, что вы не запутаетесь в дебрях этого айсберга.
Ага, это я понимаю. просто думал, у Вас есть какойто интересный пример работы с LinkedList
То это значит, что он врёт либо про то, что он сеньор, либо про то, что он с Java работал.
А если не врёт? Если он сеньор, с Java работал, но всего лишь месяц. Рекрутеры уговорили прийти на собеседование, потому что они решили, что подходящий кандидат, потому что где-то в резюме слово Java встретилось.
Даже собеседование с тестами прошёл (интернет — сила!), правда, потом представил себе, что придётся и дальше писать на ломаном русском ежедневно — извинился и ушёл.
Если он сеньор, с 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 в Resume или нет.
Наверное лучше упомянуть: больше шансов проскочить черещ HR, а с инженером-интервьюером как-нибудь договоритесь.
Главное не пытаться делать вид, что у вас шесть лет опыта работы на Java, а сразу заявить, что вы больше работали с той частью, что на PHP (или C#).
P.S. У меня у самого похожая ситуация, на самом деле: работать с Android и совсем избежать Java не получится, но количество кода на Java и C++, которое я пишу… разница где-то между 10x и 100x в пользу C++…
В тех случаях, когда он должен быть написан согласно правилам языка.
Того, что, на мой взгляд, в профессиональной деятельности и правда не надо кодить алгоритмы сортировки и вовсе никто не заметил. А может за это и минусы? :-[ ]
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.
Напрашивается идея: использовать
htonl… но MSVC в это случае… вызовет htonl!Впрочем другие компиляторы htonl нормально отрабатывают… и можно надеяться, что когда-нибудь… в светлом будущем… и MSVC поправят, так что — да замечание про то, что лучше бы использовать
htonl тоже будет неплохим… но идеальным, конечно, будет напоминание про _loadbe_i32 — которое работает с MSVC, но… не работает с GCC.P.S. Вообще же удивительно — сколько всякого интересного можно получить из кандидата при обсуждении даже такой, казалось бы, вполне тривиальной задачи. Ну вот такой язык C++ — куда ни глянь, всюду овраги, буераки да капканы…
И является ли именно эта функция узким местом, которое надо оптимизировать? Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?
Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?Вообще-то в имени функции был намёк.
И является ли именно эта функция узким местом, которое надо оптимизировать?С большой вероятностью. Если бы вы обратили на дальнейшую дискуссию, то заметили бы флажок компилятору -mmovbe. То есть это AMD и Intel не поленились и ради этой функции аж специальную инструкцию замутили — в добавление к той, что всегда была.
А что вообще делает эта функция? Что означают все эти интереснейшие вычисления?А это — уже вопрос к интервьюируемому, разве нет?
Иногда приходится задумываться даже о таких вещах. Например мы буквально сегодня задвинули в мастер рабочую версию бутлоадера для нашей железяки на микроконтроллере xmega128. Проблема была в том, что нужен был USB-стек, но он с трудом влезал в 8К памяти. Мне пришлось весьма сильно помочь молодому программисту с экономией памяти. Выгадывали буквально по 10 байт за раз. Программа, естественно, на голом С, ибо С++ туда ну совсем никак не лез. В итоге получилось 7800 байт, но был момент, когда программа весила 9000+. Наверное странно в 2019 году читать о нехватке памяти размером 8 килобайт. Вот таков он, суровый мир железячного программирования.
Но когда речь заходит о десятках миллионов запросов в секунду… такие мелочи начинают играть роль.
Да, разумеется, не весь код у нас так написан — есть даже и вспомогательные сервисы на Python, обращение к которым происходит раз в сутки… но вот есть и такое вот… и да — нам нужны люди, понимающие как такие вещи пишутся, в том числе. Особенно если они сеньоры.
P.S. Кстати не первый раз замечаю что наши проблемы — очень близки проблемам эмбеддеров. А разгадка простая — даже если у вас железо очень суровое и памяти «дофига» и ядер и всего-всего «дофига»… добавьте туда миллион запросов… и, вдруг, на один запрос — у вас ресусов ну вот ни разу не дофига… а почти столько, сколько в микроконтроллерах.
С другой стороны, если это правда Senior, он знает алгоритм сортировки слиянием
Он забыл уже. Это для его работы и не важно.
Зато сеньор делает то, то много полезнее для решения прикладных задач на фирме — корректно архитектуру проектирует.
А алгоритмы сортировки — это те знания, которыми может похвастать джун, который еще не умеет грамотно архитектурные вещи делать.
Знания сеньора — это знания как использовать и как сопрячь готовые компоненты, какие у них ограничения, когда лучше сделать так, а когда лучше сделать эдак.
Сеньор, что пишет алгорим сортировки самостоятельно… гм. Ну разве что чтобы отвлечься от рутины. Если понадобится что-то вычурное, то полагаю, сеньор знает о существовании тома третьего «Сортировка и поиск» книги Дональда Кнута «Искусство программирования»
Я обычно стараюсь расспрашивать человека в соответствии с его резюме. Ибо если мы отреагировали на него, то значит опыт человека для нас был релевантным. В зависимости от заявленного уровня компетенции кандидата, ставлю вопросы соответствующей сложности. Очень часто при этом всплывает, что в резюме пишутся вещи до кучи (ну типа слышал, что в конторе это используется, ну и написал, что есть опыт).
Недавно искали архитектора на новый проект (хотя архитектор там это было громко сказано), и одного кандидата уже до меня отсобеседовал мой начальник. И, мол, хороший кандидат, скорее всего возьмем его. Надо сказать, что начальник любитель прогонять кандидатов по классическим абстрактным задачкам, но при этом редко проверяет релевантный для нас опыт. Но т.к. работать кандидат должен был в перспективе со мной, то я с ним хотел провести просто дружескую встречу, на которой хотел лишь задать пару ключевых вопросов в неформальной обстановке. Но, увы, ответы на них оказались неубедительными. Тогда я пробил человека по ключевым позициям его резюме. И, увы, он везде плавал. Кандидат не был абсолютно слабым, но явно не имел достаточно опыта, чтобы предлагать архитектуру с нуля. Место мы ему предложили, но на ступень ниже. Увы, его амбиции были на ином уровне, и он отказался.
Так вот к чему я это… На олимпиадные задачки можно достаточно быстро натаскаться, а вот практический опыт нарабатывается только временем и трудом.
Практический опыт практическому опыту рознь, все дело в том, что тот или иной человек запоминает, и это происходит вне зависимости от него самого, синапсы образуются случайно. То есть наше запоминание это образование связей, по которым бегает сигнал и если мозг отключается больше, чем на 5-6 минут (при травме например), начинается разрыв этих самых связей и человек не может вспомнить как его зовут. Следовательно, образование новых связей и есть решение тех или иных задач. Бывает ломаешь голову над задачей, спустя какое-то время приходит решение, надо было лишь понять. Так вот это самое «лишь понять» это когда образуются новые связи. И связывают они между собой настолько отдаленные участки мозга, в которых хранится настолько разная и далекая информация (зрительные образы, слуховые, двигательно-моторные), что происходит это самое понимание. Но просто так это понимание не придет, нужно жить с некоторой мыслью какое-то время, чтобы дождаться образования новых синаптических связей и таким образом запустить механизм синтеза и увидеть, например, новую закономерность так, где вы ее не видели. Весь вопрос как долго человек может жить с той или иной мыслью, да и нужна ли она вообще…
кодить сеньер умеет полюбому
Одна только проблема — нужно сначала убедиться, что на собеседование пришел реальный синьор.
Не можешь вспомнить — выведи. Забыл как переменные в том алгоритме, который вам показали 20 лет назад на доске показали, назывались — дай им другое название.
Блин, почему все утверждают, что «реальную» практическую задачу они решат, а сортировку — ну никак не смогут написать? А они, вообще, пробовали? Или они, на самом деле, кода какого-либо уже лет пять не писали? Так тогда они и не «синьоры» никакие, нафиг они на эту позицию идут? PM — может быть, но никак не TLM…
Если воспринимать ту же сортировку слиянием как реальную задачу — то любой сеньор должен её мочь придумать. Не вспомнить. Не «выстрелить» решение, которое он когда-то заучил наизусть, как стих. А придумать. Что тут сложного и ужасного?
Ну блин, он про эту сортировку знает куда больше, чем про реальное задание, которое ему может достаться — что может ему помешать «сложить кубики», чтобы сделать работающее решение? Он уже не помнит как работает
for? Или if?Как раз если вы помните всё это — то да, написание сортировки ничего не даст. Как меня на собеседовании пропросили написать сортировку «кучей», но остановили, когда я нарисовал дерево этой самой кучи… потому что по нему видно было, что проблем не будет — задали сразу другой вопрос.
Да, представьте себе, если вы не собеседовании не помните как устроена сортировка слиянием — это не просто хорошо, это отлично. Прекрасный шанс посмотреть как бы будете решать практическую задачу… да, конкретно для вас в этот момент она становится практической… и её можно обсуждать именно в таком ракусе.
Одно дело налить чайку, покурить и спокойно вспомнить. Другое дело что надо вспомнить когда в углу тикает таймер. И ты понимаешь что у тебя впереди еще две задачи висят. У меня лично ступор. Что показывает этот тест на время? По-моему ничего. Мне что каждый день на работе необходимо будет вспоминать на время какие-то алгоритмы? Кто это вообще придумал. Кто вообще в здравом уме может держать в голове пару популярных фреймворков на изусть, пару баз данных, пару облачных сервисов, докеры, кубернейтсы, фронтэнд, бэкэнд. А тут сортиовка слиянием на время. Вы прикалываетесь? Может еще красно черное дерево повернуть или нейронную сеть накидать с нуля за 20 минут?
Другое дело что надо вспомнить когда в углу тикает таймер.А что — в реальной работе «таймер» никогда не тикает? Никогда ничего не делается «к демонстрации» или «к конференции»? Ну… вы счастливый человек… может быть и найдёте работу, где такого никогда не случается… но не у наc.
Мне что каждый день на работе необходимо будет вспоминать на время какие-то алгоритмы?Опять, блин, это слово у вас. Нет — вспоминать не нужно. Нужно решать задачи. И да — часто на время, к определённому сроку и нет — никто не будет вам из-за этого давать «карт-бланш» и разрешать «задивать» код, который даже вы сами не понимаете как работает.
А тут сортиовка слиянием на время. Вы прикалываетесь? Может еще красно черное дерево повернуть или нейронную сеть накидать с нуля за 20 минут?А почему бы и нет, собственно? Кто вам может помешать? Задачи простые, уточняющие вопросы вам никто задавать не запрещает… в чём проблема-то?
Ещё раз повторю: никто не требует от вас заучивать те же красно-чёрные деревья, как учат наизусть стихи — наизусть. И даже если вы перепутаете роль красных вершин и чёрных в том самом красно-чёрном дереве… я не обижусь… да, блин, если даже вы вместо красно-чёрного дерева соорудите AVL-дерево… я думаю тоже сойдёт.
Мне всего-навсего нужно увидеть как вы решаете задачи и пишите код… задача, которую вы, плюс-минус приблизительно, помните — идеальна, так как сокращает время на её формулировку, вот и всё.
P.S. Про нейронку, впрочем, я бы стал спрашивать только если бы у человека что-то было в резюме, с ними связанное. Можно проработать довольно долгое время и никогда, ни разу, с нейросетями в принципе не столкнуться — несмотря на весь хайп вокруг них. Но если вы говорите, что вы с ними работали… тогда да, конечно.
Никогда ничего не делается «к демонстрации» или «к конференции»?К демонстрации или конференции, особенно если нет времени, всё делается по принципу «фигак, фигак, и в продакшен». Там никто не упарывается по алгоритмами и оптимизации, от кода требуется только чтобы он запустился и хоть как-то отработал пару часов.
Сколько вы из этого времени будете писать сортировку?Минут 20, я думаю.
Ну напишет человек сортировку. А дальше что? Времени ни на что другое не останется уже.Ну и отлично. Я напишу как кандидат умеет писать код, кто-то другой — поговорит с ним на тему того, как проектировать сложные системы, ещё кто-то — как налаживать работу команды.
Почему вы считаете, что один интервьюер должен с одного интервью о кандидате узнать прям сразу всё?
Другое дело что подобные задачи на собеседовании вообще спорный вопрос.Нет, практика показывает, что это необходимый вопрос — если вы хотите нанять «синьора», который ещё и код писать может.
А с другой стороны — тестовые задания тоже делать никто не хочет, а брать человека на должность Senior SE и не проверить как он пишет код — тоже нельзя.Ну вот отсюда и растут эти задачи.
Они не проверяют (и не должны проверять!) вашу память. Они проверяют — умеете ли вы писать код.
P.S. Впрочем обычно всё-таки рекомендуется давать что-то «по мотивам»: задачу примерно такого же уровня сложности, но вот уж не совсем такую, чтобы человек её когда-то на доске видел. Но это, в общем, только чтобы психологически меньше на человека давило.
Всё, после этого скорее всего другой интервьюер ничего не узнает, потому что на следующий этап чувака уже не позовут. Вот в чем проблема.А где вы видите проблему? Кандидат спокойно пойдёт на другое интервью в другой фирме — и там уже всё будет хорошо. Если это была случайность. А мы возьмём на работу кого-то ещё. Не вижу трагедии.
Вы так рассуждаете, как будто «проваленное» интервью — это прям конец, всё, катастрофа.
В том, что такие задачи используются как первый (и поэтому единственный критерий)Это нормально. Так как наша задача — не забрать всех способных кандидатов, а максимально снизить вероятность того, что на работу возьмут человека, который не справится с задачами.
В других фирмах требования могут быть иными, никто ж не спорит…
Собственно если вам нужен именно Senior-чувак, а не олимпиадник — то проводить отбор по критерию где лучше справится олимпиадник странно.Ещё раз: «Senor-чувак» — это всё равно, в первую очередь, человек умеющий писать код. И, как вы верно заметили, олимпиадники такими задачками отсеиваются плохо, а сеньоры, незаметно для себя, переставшие быть программистами и ставшие менеджерами и алминистраторами — хорошо… так что как раз для них — эти задачки и хороши.
Для скайп-скрининга она слишком долгая, многие вещи не проверяетНу дыг для этого есть уже основное интервью с личным общением…
Ваше же предложение обладает одним, но очень существенным недостатком: написание таких утилит ещё хуже вкладывается в то самое пресловутое Skype-интервью, чем написание сортировки. А давать это как домашнее задание… ну если вы индусов, которые чужое решение будут предалагать не видели — то это ваше счастье.
именно вспомнить, за 20 минут написать не помня хорошо детали алгоритма и не заглядывая в гугл — весьма сложноЕсли вспомнить, то это не 20 минут будет, а 5. Нет — речь идёт именно о том, чтобы написать.
Кодинга там нет вообще, бесполезно проверять как человек пишет код по скайпу.Это, как бы, ваше мнение. У нас в компании считают иначе. Так что в добавление к Skype шарится ещё и Google Doc — и да, там смотрится как этот код появляется. И мы не одни такие.
Этот самый код, собственно, и является основным результатом собеседования — замечания интервьюера к нему… вещь немного вторичная.
Как я уже говорил, на скайпе/телефоне кодинга нет.И, как я говорил, именно и в первую очередь там кодинг там и есть.
Это выясняется элементарно же. На ревью кода спросите как добавить какую-нибудь фичу в проект.Да, но к этому моменты деньги на билеты и гостиницу уже потрачены, несколько часов специалистов заняты… куча затрат, которых можно элементарно избежать — просто посмотрев как человек пишет код.
В других фирмах, где требования иные (например где прибегает менеджер и надо под пристальным взглядом срочно писать алгоритм к демонстрации и конференции не пользуясь гуглом) — вариант с сортировкой отсеивает лучше, безусловно.Ну зачем же менеджера тут привлекать? Код-ревью делают другие инжинеры. И на их замечания нужно как-то реагировать. Ровно эта деятельность в подобном кодинге и проверяется.
Да, ситуация немного пожёще, чем в реальной работе, ну так и задача — на порядок, а то и на несколько, проще.
Умение писать код (и, соотвественно, умение решать простенькие алгоритмические задачки) — это неотъемлемая часть понятия «Software Engineer».
Не знаю — что там с музыкатами-виртуозами и гаммами, не спец, не знаю. Но в случае с программистами — я регулярно встречаю «сеньоров», которые реально код давно не пишут, а «руководят его написанием».
То есть аналогия тут не с «профессиональным музыкантом, не раз блестяще выступавшем на сцене», а, скорее, c «профессиональным музыкантом, не раз блестяще выступавшем на сцене… однако возможно последний раз — лет десять назад» (а после этого занимавщийся в основном организацией концертов для своего оркестра).
И вот если бы расклад был с музыкантами именно таким, как с программистами — я бы обязательно прогонял их через «гаммы».
А поскольку ситуация с «горе-сеньорами» — именно такова, то да, у нас все интервью начинаются с написания простенькой программы какой-нибудь (обычно всё-таки не совсем из учебника, но что-нибудь связанное с ним и несложное). Ну чтобы понять — код-то соискатель в принципе писать умеет или нет?
А уже потом, когда мы выяснили, что перед нами программист (Software Engineer) — можно выяснять, какого класса он программист: джуниор там или сеньор.
Так что в добавление к 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-служба просто исчезает в полном составе или отодвигается в сторону, а нужные люди нанимаются и работают на благо компании. Если же люди не нужны, то см. выше. Нытьё, вакансии, «заявления руководства».
Лично мне глаза открыл один из комментариев к очередной гневной статье про собеседование в вроде бы Amazon: 15 минут по скайпу, хрипящая связь, странная задача за 5 минут до конца собеседования, а потом «ваше время вышло» и HR отключается.
Так вот, в комментарии бывший сотрудник HR объяснил — в гугле на каждую открытую вакансию поступает в среднем 1500 резюме, из которых по формальным признакам отбирают примерно 200, а уже из них проводится 20 собеседований. Благодаря развитой сети филиалов, программам релокации и общей престижности за вакантное место конкурируют фактически все разработчики всей планеты. Миллиард индусов, китайцы, граждане ЕС, канадцы, местные — все. И поэтому «гугл» может себе позволить перебирать харчами, нанимая по желанию левой пятки только женщин C++ сеньоров ради гендерного равенства, или рыжих, ирландцев, геев, да хоть сеньораС#-CPL-подводного военного ныряльщика-негра-альбиноса.
Плюс эффект масштаба, тот же гугл нанимал по ~13тыс человек в год, то есть это около пары миллионов поступивших резюме, глаз и рука замучаных кадровиков замыливается и отдельные личности превращаются в цифры и галочки CRM.
а уж если нанимает не сама корпорация, а «кадровое агенство», то всё ещё в десять раз хуже
И уж совсем не вызывает понимания, когда от таких же проблем страдают «молодые динамично развивающиеся компании», в которых генеральный имеет возможность без напряга лично отсобеседовать каждого желающего.
Я знал, для чего нужна сортировка слиянием, я знал, как найти её код. Я лишь не мог вспомнить его.
По-моему невозможно знать, для чего нужна сортировка слиянием, не зная реализации её и некоторых ближайших сортировок
говорил он мне следующее что он все работы делал в институте сам а тут банальный баг пофиксить не может и большая часть того что он знает ему не нужна т.к. она реализована в библиотеках и наврятли он сделает лучше.
Мне всегда казалось, что если ты уже состоявшийся синьер (с трудом представляю что это, наверно матерый прогер который может сам ставить себе задачи, сам придумывать решения, сам реализовывать, да еще обладать чувством прекрасного), то на собеседовании ты можешь лениво говорить: «я это не знаю», «я это не пробовал». «Ну если вы настаиваете я могу попробовать придумать сортировку пузырьком, но это вряд ли будет быстро».
В общем, какая-то сферическая конина. Синьер уже много чего повидал и именно этим он и ценен. Тем, что не «лучше всех сыграет гамму», а досконально разберется в предметной области и порешает все проблемы. И он точно это сделает, потому что уже больше десятка раз это делал.
Хотя, если таки посты есть, значит они кому-то интересны?
Избитая тема.
Если специфика работы в компании предполагает, что умение написать сортировку напрямую связана с успешностью работы кандидата, то почему бы и нет. Но думаю это редкий случай.
Если кандидат заявляет, что он умелец в реализации алгоритмов/участник ACM/ещё как-то связан с этим, то тоже стоит проверить.
В остальных случаях собеседует не тот человек или программу собеседования создавал не тот человек.
Главная цель собеседования — понять, подходит ли человек для работы в вашей команде или компании и на какую должность(ну или соответствует ли позиции, если нужна только конкретная). А специфика у всех своя.
Если на достаточной дистанции кандидаты, умеющие объяснить, почему крышка от люка круглая, или пишущие сортировку на коленке за 5 минут, всегда показывают нужный уровень, то может это вам и подходит. Хотя без неудач от кандидатов, которые это делать не умеют и всегда не справляются с работой, картина всё равно будет неполной.
Но скорей всего у вас недостаточно таких данных для анализа, поэтому самыми лучшими вопросами будут вопросы и задачи по опыту, по специфики вашей работы и позволяющие выяснить, умеет ли и как кандидат думает, обучается и находит решения.
— Необходимо знание векторной математики.
— Подучил, пришел на собеседование.
— Час гоняли по задачкам с векторами и кватернионами.
Итог: за три года работы в студии векторная математика понадобилась всего два раза в задачах на пол часа — час. Причем пример решения гуглился первой же ссылкой.
Думаю, единственное, чем я отличаюсь от не изучавшего математику человека, так это разве что знанием самых базовых вещей. Ну и ещё, если мне положат на стол 10 сильно отличающихся вариантов решения задачи, где только 1 верный, то я почти наверняка быстро вычислю верный, а ничего никогда не учивший человек отбраковать заведомую ересь в таком эксперименте не сможет.
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!Меняем 5 монет на N элементов, получаем сложность сортировки O(N log N). Всё! Вот совсем всё!
2⁶=64<120=5!
Причём тут вообще вышка?
Ну почему люди так любят всё усложнять и так не любят думать?
Как вы вообще будете делать выбор если для вас задача написания своей сортировки — проблема?
Так и будем — возьмем на исследование по задаче день или два, проверим сколько стека занимает qsort, проверим можно ли убедить сортировки из стандартной библиотеки C++ не использовать память, поищем алгоритмы сортировки в интернете и выберем подходящий. В крайнем случае свой напишем, пусть и не за 10 минут, а за день. Вместо сортировки может быть какое-нибудь шифрование или драйвер ввода-вывода. Ничем не отличается от любой другой задачи. И как и любую другую задачу, совершенно необязательно знать ее во время собеседования.
Так и будем — возьмем на исследование по задаче день или два, проверим сколько стека занимает qsort, проверим можно ли убедить сортировки из стандартной библиотеки C++ не использовать память, поищем алгоритмы сортировки в интернете и выберем подходящий.Прекрасно — вот вы всё это проделали, выяснили что qsort вам подходит, всё написали и запустили в production… где ваша вся конструкция регулярно крешится и фирма терпит убытки. Ваши дельнейшие действия?
Вместо сортировки может быть какое-нибудь шифрование или драйвер ввода-вывода. Ничем не отличается от любой другой задачи.Отличается. Шифрование, работавшее в тестах — будет работать в боевом режиме. Во всяком случае я не представляю как так сделать, чтобы шифрование в тестах работало, а в боевом режиме нет. Драйвера… ну тут может быть по-всякому. А вот сортировка — с большой вероятностью пройдёт тесты и покрешится в боевом режиме… и я знаю почему (да и вы наверняка знаете, просто придуриваетесь).
И как и любую другую задачу, совершенно необязательно знать ее во время собеседования.Ну это ваше мнение — слава богу собеседование провожу я, а не вы…
запустили в production… где ваша вся конструкция регулярно крешится и фирма терпит убытки. Ваши дальнейшие действия?
Берем и исправляем. Ну а что, вам можно придумывать произвольные события без подробностей, а нам нельзя? Или даже не так — запустили в production и там все работает. Потому что изучили вопрос во время работы по задаче и сделали как надо.
и я знаю почему (да и вы наверняка знаете, просто придуриваетесь)
Я предполагаю, что вы намекаете на количество элементов, но не вижу никаких причин, почему реальное количество в продакшене нельзя учесть во время написания кода.
Ну это ваше мнение — слава богу собеседование провожу я, а не вы…
Вы требуете, чтобы кандидат на собеседовании знал любую задачу, которая встретится в будущем? Сомневаюсь.
Берем и исправляем.Как исправляем? Если вы даже не знаете — что у вас там падает, когда и почему?
Ну а что, вам можно придумывать произвольные события без подробностей, а нам нельзя?Можно конечно. Если вы готовы «раскрыть карты» и объяснить — почему так происходит.
Или даже не так — запустили в production и там все работает. Потому что изучили вопрос во время работы по задаче и сделали как надо.О! Вот с этого момента — поподробнее. Вы тут написали:проверим сколько стека занимает qsort. Как вы это проверять собрались? Экспериментами али ещё как-нибудь?
Я предполагаю, что вы намекаете на количество элементов, но не вижу никаких причин, почему реальное количество в продакшене нельзя учесть во время написания кода.Если бы я намекал на количество элементов. Ха. Всё было бы очень просто. Уж засунуть-то миллион элементов в массив и в тестах можно.
Ахилессова пята QuickSort всем, кто знает, как он устроен, известна: на «плохих» исходных данных он деградирует — и да, это приводит к переполнению стека. И избежать этого — довольно сложно. А вот что сделать можно легко — так это сделать так, чтобы на «популярных» «плохих последовательностях» (уже отсортированный массив, простейшие V или W образные последовательности) — всё работало хорошо. Поскольку в стандартной библиотеке так и сделано — то на тестах вы этого не заметите, так как не знаете «где копать». Но вот для ваших конкурентов (если они знают «где копать») создать последовательность, которая будет «укладывать ваш сервер на лопатки» — несложно.
Вы требуете, чтобы кандидат на собеседовании знал любую задачу, которая встретится в будущем?Я требую, чтобы кандидат знал хотя бы самые базовые вещи — MergeSort, QuickSort, Red-Black tree.
Задачи их написания я обычно не даю, могу, впрочем поговорить что делать с подобным вот сервером.
В любом случае кандидат должен уметь отвечать на вопрос: какая сложность у только что написанного им кода. Для любого кода… ну почти: раз в год, а то и реже — нам приходится писать-таки код, сложность которого неизвестна (потому что он слишком многого числа потенциально нам неизвестных переменных зависит). Он обкладывается тестами, логгингов и прочим… и всё равно за него всегла боязно — а вдруг мы чего-то не учли?
Но вот чего нам совершенно не нужно — так это иметь кучи такого кода только потому, что человек, писавший этот код на об «O большом», ни об устройстве кешей процессора не задумывался.
P.S. На собеседовании задачи, где решение имеет непонятную сложность, я разумеется, не даю…
Как исправляем? Если вы даже не знаете — что у вас там падает, когда и почему?
Мы не знаем, потому что вы не сказали, придумывая этот пример. А в реальном случае будет больше информации, вот и действия будут более конкретные.
Если вы готовы «раскрыть карты» и объяснить — почему так происходит.
Вы значит карты не раскрыли, а мы должны? Магически падает — магически чиним.
Вы тут написали: проверим сколько стека занимает qsort. Как вы это проверять собрались? Экспериментами али ещё как-нибудь?
Это вы написали про стек и qsort, я просто повторил ваши слова. Вы в курсе задачи, знаете что там у вас за устройство, работали с кодом проекта. Я — нет. Откуда я знаю, как вы собирались ограничивать qsort. Если бы я работал с таким проектом, я бы вам что-нибудь ответил, а так смысл гадать. Можно экспериментами, можно еще как-нибудь.
Я бы наверно вообще написал свою реализацию, так ограничивать проще. Но это я говорю как человек, который на C++ не пишет. И как человек, который не брал на исследование по этой задаче день или два.
Ахилессова пята QuickSort всем, кто знает, как он устроен, известна
Она известна всем, кто прочитает эту страничку в Википедии. Именно это я и имел в виду под словами "возьмем на исследование по задаче день или два, поищем алгоритмы сортировки в интернете и выберем подходящий". Там же написаны и методы обхода этого недостатка. А вот если изобретать с нуля, то можно и упустить какой-нибудь нетривиальный случай использования.
Там же написаны и методы обхода этого недостатка.Вот только до них ещё дочитать нужно. И нужно убедиться что ваша конкретная реализация их содержит.
Мы не знаем, потому что вы не сказали, придумывая этот пример.Почему не сказал? Сказал:Но вот для ваших конкурентов (если они знают «где копать») создать последовательность, которая будет «укладывать ваш сервер на лопатки» — несложно.
И как человек, который не брал на исследование по этой задаче день или два.Для того, чтобы «брать на исследование задачи день или два» — нужно вначале понимать, что эта проблема вообще имеется.
Если вы знаете, что и как там внутри — вы подозреваете, что эта проблема может существовать априори. И сможете понять — есть там проблема или нет куда быстрее, чем за день-два. А если вы «внутренним миром» вещей не интересуетесь — то будут казусы, подобные описанному.
И да, если вам нравится работать в конторах, где «коллеги и тимлид счастливы, когда баги ищутся в поте лица днями» — то ваш подход, в принципе, ничем неплох.
Почему не сказал? Сказал: Но вот для ваших конкурентов
Вы это сказали в том же комменте, в котором задали вопрос.
Для того, чтобы «брать на исследование задачи день или два» — нужно вначале понимать, что эта проблема вообще имеется.
Нет, чтобы брать время на исследование по задаче нужна только задача. Ну и отсутствие опыта ее решения ранее, что предполагается по условиям примера. Хотя и с опытом не мешало бы иногда проверять наличие новых решений. Вдруг там очередной TimSort придумали.
Если вы знаете, что и как там внутри — вы подозреваете, что эта проблема может существовать априори.
Если не знаем, то тем более вероятно, что там могут быть какие-то проблемы. Мы же знаем, что не знаем. Надо разобраться и узнать.
И сможете понять — есть там проблема или нет куда быстрее, чем за день-два.
Конечно, надо только статью в Википедии прочитать.
И да, если вам нравится работать в конторах, где «коллеги и тимлид счастливы, когда баги ищутся в поте лица днями»
Некорректно подразумевается истинность высказывания, что при таком подходе будут баги, которые ищутся днями.
Если вам не нравится работать в таких конторах — то этот подход тоже ничем не плох. Потому что он применяется любым программистом в любой незнакомой задаче.
Имхо, на многие подобные вопросы в IT ответ, неожиданно, "ДА!". Потому что примеров, когда люди не используют сами то, что делают для других, много.
Должен ли senior уметь написать сортировку за приемлемое время – вот тут скорее да, чем нет.
Некоторые кандидаты реально воспринимали предложение написать хоть какой-нибудь код, в принципе, как личное оскорбление: «как? вы хотите, чтобы я код писал?! этум пусть студенты занимаются, моё дело — стратегия!».
Вот только практика показывает, что отказ от написания кода приводит к тому, что эти «синьоры» начинают придумывать стратегии в духе той самой совы, которыя предлагала мышам сделаться ёжиками.
После часа общения, он приходит в состояние ступора, потому что он никогда раньше не работал с приложениями у которых есть внутренний богатый стейт, и это внутри как-то общается между собой. Оба приходим к выводу, что в нашем случае подход Х можно использовать лишь частично, потому что особого профита он не даст.
Кстати, он тем же вечером сам ответил, что не готов пойти к нам работать, потому что неинтересно ему. Ему не интересно писать кучу кода, своими руками.
Случай второй, собеседуем другого сеньора, он категорически отказывается писать код, и рассуждает как бы он это сделал и что бы применил из фреймворков, подходов, мой коллега улыбается, так как они это все уже прошли, и сейчас хотят к себе человека, который будет готов писать код, бизнес логика в некоторых местах достаточно сложная и требуется понимание того, что творишь. Как итог склонили кандидата показать код своего пет прожекта, банальное ревью на 15 минут выявило несколько проблем, в том числе и с перфомансов. Вдобавок — пару багов.
Ему не интересно писать кучу кода, своими руками.Ну вот в 9 случаях из 10 — это и есть проблема «сеньоров, не любящих алгоритмические задачи».
То есть вот я реально не видел синьоров, которые умели бы и любили бы писать код — и «не умели бы в сортировку». А вот любителей «руками водить»… и смотреть как «слоники бегают» — видел в количестве.
А они нам, представьте себе, и не нужны.
P.S. Это не значит что все хорошие кандидаты приходят от такой идеи в восторг… нет, некоторые спрашивают — а стоит на это время терять? Но услышав ответ «да, мне, для отчёта, нужен написанный вами код»… вздыхают и быстро его пишут. «Бес проблэм», как один чёрт в мультике говорил. Вполне остаётся время и на другие вопросы.
«да, мне, для отчёта, нужен написанный вами код»…
Хм… Знакомая история :)
А вы кого больше ищете — людей которые лопатой умеют разгребать задачи или придумывать прорывные идеи?
А вы кого больше ищете — людей которые лопатой умеют разгребать задачи или придумывать прорывные идеи?Людей, за которым не придётся переделывать код, прежде всего.
А умеют ли они «разгребать типичные задачи» или «гениально решать редкие» — это уже вторично.
Если в результате их деятельности количество багов в коде не растёт, а уменьшается — это уже прекрасно, остальное приложится.
Лихорадочно плюсую. Провожу собеседования минимум раз в неделю и поражаюсь, какое количество senior всякого рода людей полагает, что достаточно красиво поговорить о задаче, а не решить ее. И по 20 лет опыта у людей, и в интересных местах… Притом это касается и технических вещей, и не нетехнических.
Калифорния, Google, если что.
Сортировка сортировке рознь. Написать какую-то сортировку сеньор должен уметь, оценить её сложность и более-менее порядок области применимости — тоже. Написать конкретную ("любимую" собесдующего) с предоставленным алгоритмом — тоже. А вот какую-то конкретную по памяти -
Heapsort — посередине между mergesort/quicksort: в отличие от timsort — её описание не забывается и через 10 лет. В отличие от quicksort — её описание не помещается в одну строку… Её я на собеседовании спрашивать бы не стал… но знаю и людей, которые спрашивают. Меня, как я уже упоминал, спрашивали.
Мне кажется, что знать 2-3-4 самых «базовых» — небольшая проблема.
А мне кажется большая. Небольшая вот сейчас взять и прочитать алгоритмы. Может даже на коленке реализацию сделать на паре языков и бенчмарки погонять. А вот через год или пять-десять всё это на собеседовании вспомнить
А вот через год или пять-десять всё это на собеседовании вспомнитьУ меня между изучением сортировки кучей в школе и собеседованием, где про неё спрашивали прошло точно больше пяти лет (про десять не уверен).
Проблем не было.
Вообще чем больше мы тут разговариваем и общаемся — тем более явным становится тот факт, что проблемы возникают только у людей, которые не хотят всё это вспоминать на собеседовании. Считают ниже своего достоинства.
А вовсе не в том, что не могут.
Ну на нет и суда нет, как говорится. Компаний много, может быть кому-то и такие разработчики нужны.
Проблема то в том что люди как раз не могут часто а не «не хотят».
ПС: Немного в подтверждение вашей точки зрения — ИМХО реальный сеньор уважает себя и свой опыт и не хочет бесконечно проходить одинаковые собеседования. Он и так в себе уверен. И работу все равно найдет. Потому и оказывается заморочиться со всякими заданиями. У нас просто совсем не развита система хэдхантинга, когда рассматривается реальный опыт и человека пытаюся зацепить чем то а не экзамены проводят.
Вам я, как и другим оппонентам, советую почитать «Программистский камень». Несколько первых глав, по крайней мере. Как минимум чтобы понять разницу между картостроителями и паковщиками.
Вы похоже переносите ваши личные особенности памяти на всех и при этом делаете глобальные выводы — нехорошо.Нет, не хорошо… прекрасно. Потому что на самом деле все эти «алгоритмические» собсеседования — они как раз об этом.
Вы хоть почитайте что нибудь про механизмы памяти.Читал. Но в данном-то случае речь идёт не о памяти. А о том, что случается когда она вас подводит. Как устроена ваша ментальная картина мира? Что вы делаете, чтобы её «заштопать»? Какие механизмы привлекаете чтобы себя проверить?
Потому и стоит этот вечный плач на тему люков, красно-чёрных деревьев, теперь вот алгоритмических задач… и будет стоять. Мне же, в принципе, пофигу какую дыру в вашей «картине мира» исследовать. Важно чтобы «рядом» с дырой было достаточно «хоженых троп» (в «люках» — это бытовые знания, в алгоритмических задачах — это код, который вы пишите каждый день)… и нужна вещь, которую вы не помните (ещё раз — когда я показал, что прекрасно помню, что хорошо знаю как устроена «сортировка кучей» — меня остановили и задали другой вопрос). Ну и дальше можно уже смотрать как вы эту дыру будете «штопать».
Собеседование ведь — именно об этом, а не о том, как вы помните то, что учили когда-то в школе или универе.
Проблема то в том что люди как раз не могут часто а не «не хотят».Плохие картостроители, значит. Или вообще не картостроители.
P.S. Это, кстати, большая беда с паковщиками: узнав, что в данной компании спршивают, скажем, о сортировках — они иногда берут учебник и зазубривают оттуда всё про сортировки… ну это круто, конечно, но ничего в принципе не меняет. Если вы знаете всё о сортировках — «дыру для штопки» собеседующий найдёт какую-нибудь другую…
Я понял что вы работаете в месте мечты которе ищет только суперстаров мапперов и собеседователи гении психологии которые чутко отслеживают мышление претендента и выявляют гениев программирования.
В общем можно написать тонны текста по вашему комменту и еще больше по тексту из ссылки — но я не любитель писать посты, иначе так бы и сделал. В общем я понял что такие кампании как ваша лучше обходить стороной и остановимся на этом.
Еще одна теория про элиту и быдло.Ну если вам так хочется считать…
Ну что могу сказать вас походу торкнуло этой фигней.«Эта фигня» показала мне, чего я, на самом деле хочу от коллег.
А хочу, я в общем-то двух вещей… вернее не хочу двух вещей:
1. Не хочу переделывать написанный кем-то код из-за того, что он криво написан.
2. Не хочу объяснять дважды одну и ту же вещь своим коллегам.
И первое и второе связаны, в общем-то, с наличием целостной картины мира в голове.
Но если вы считаете, что это не нужно — то, как бы, без проблем.
В общем я понял что такие кампании как ваша лучше обходить стороной и остановимся на этом.Ну то есть Facebook/Google/Microsoft/Yandex — отпадают… а где вы собираетесь работать? В IBM (тут многие говорят, что там как раз таких требований нет — почему она, собственно, очень мало софта создаёт с нуля, но много покупает и адаптирует)?
Мне — так даже проще, выбор за вами…
Про целостную картину мира это хорошо сказано. Вот только я тоже имею вполне целостную картину мира и в нее вписывается например информация о функционировании ЦНС и памяти. А вот у вас нет.
По работе Facebook и Яндекс чур меня хотя и по разным причинам. Для гугла я слишком неизвестен. Рядовым собеседователем мне и рядом не надо ибо ищут там мясо с претензиями. А на место по моей квалификации не возьмут ибо для этого сначала надо отметиться в сообществе, а я слишком ленив для этого.
Microsoft еще куда-нишло, но он последнее время сильно испортился.
В общем гигантами дело не ограничивается. Да и мне не 20 лет чтобы гореть программированием ка единственным делом в жизни. Есть и другие интересы.
А с такими как вы я сталкивался и это либо молодые перечитавшие книжек типа той по ссылке и вообразившие что они супер гуру и собирающие таких же верующих. Либо просто слишком ограниченные люди думающие что эффективность написания кода это абсолют и выкладываться за мзду малую по полной это их призвание.
У меня между изучением сортировки кучей в школе и собеседованием, где про неё спрашивали прошло точно больше пяти лет (про десять не уверен).
Это между изучением и вопросом. Лет 15 назад я может быть и вспомнил бы. Но изучал 30 лет назад и немного задачек делал 25 лет назад. С тех пор вот вообще ни разу не пригодилось — ни разу сортировка там, где я мог бы выбрать её, не перепесиывая, например, SQL базу не была узким местом.
Ох понабежало. Года бегут, а интервью все хуже, думаю потому что очень много людей хотят работать в этой сфере. Алгоритмы и структуры данных это стандарт для выпускников вузов, если они отскакивают на зубок, значит предыдущий этап (образования) был успешно завершен. Что значит это для мид+ программиста? Ничего, это значит, кроме того, что перед интервью он потратил от 3-6 месяцев (да, бывает быстрее, но как правило у SSE нет особых проблем с работой и он не куда не спешит) сидя на leetcode, hackerrank и тп. решая задачи которые его буду спрашивать на интервью.
Никто не хочет портить свою репутацию, так что, человек как правило будет с неохотой ходить на интервью из за подобных каверзных вопросов и, необходимости долгой подготовки к вопросам и задачам слабо относящимся к работе.
А теперь представьте что SSE нужно потратить на подготовку с полгода чтобы пройти у вас интервью идеально (да конечно он хочет пройти его идеально он 10 лет в отрасли), а вы mid-grade компания, куда он пойдет к вам или в какой нибудь Google?
Вот и получается монополия, когда средние компании не могу показать нормальный софт, потому что у них просто нет людей способных проектировать, а лишь те кто может решать алгоритмические задачки. Ребята которые по полгода пишут какой нибудь фреймворк для "High Load" сайта с посещаемостью в 100 юзеров в день или крутой поисковой движок для того чтобы пользователь на сайте мог найти штаны по размеру, вместо использования готовых решений. А бизнес что — бизнес стоит на месте или умирает за это время.
Ну дак, задачки эти сейчас везде, мои поинт как раз таки в том, что эти самые сеньеры, остаются или там же или уходят в ТОП компании, в итоге средним компаниям практически ничего не остается. А все потому что средние компании требуют ровно таких же усилий для устройства в них как и ТОП компании. Куда вы пойдете? Скорее в топ где ЗП в 2 раза больше, например.
Если бы средние компании могли нанять лучших рабочих отказавшись от алгоритмических задач… то это было бы видно.
Ну не может же быть так, что все миллионы «середнячков» делают всё неправильно — и при этом те компании, которые делают иначе либо не существуют (это среди миллионов-то?), либо ну никак «не выстреливают», хотя всё делают «правильно» (а в каком смысле этот подход «правильный», если он этим компаниям не помогает???).
Ну не может же быть так, что все миллионы «середнячков» делают всё неправильно
Вы пытаетесь делать далекоидущие выводы из пары факторов (успешности найма хороших программистов и темпов роста компании), которые не то, что не рядом — но вообще в разных галактиках. И корреляции, которые между ними конечно же могут существовать — опосредованы на десятки степеней.
Я более того даже скажу — ни гугл, ни майкрософт, ни другие компании, представляющие собой существенную реальную ценность (не берем, скажем, нетфликс, ценность которого выражается исключительно толщиной розовых очков инвесторов, в то время как сам бизнес продолжает быть убыточным) — не пользовались «наймом олимпиадников» в те времена, когда закладывался базис их доходности и успешности. Разумеется, можно сказать, что олимпиадники явно смогли по крайней мере ничего не испортить в этом базисе, а то и успешно улучшить — но по крайней мере не вызывает сомнения тот факт, что для того, чтоб из «никого» стать гуглом — надо не олимпиадников нанимать, а делать совсем другие вещи. А олимпиадники как максимум помогут вам оставаться гуглом, если вы уже им являетесь.
PS: И если уж вы завели разговор о конторах — у IBM, например, практика найма совершенно другая, чем у хипстеров из калифорнии (по крайней мере, была совсем другой десяток лет назад, когда я там этой темы близко касался). Что совсем не мешает им быть и оставаться очень крупной софтверной компанией.
Я более того даже скажу — ни гугл, ни майкрософт, ни другие компании, представляющие собой существенную реальную ценность (не берем, скажем, нетфликс, ценность которого выражается исключительно толщиной розовых очков инвесторов, в то время как сам бизнес продолжает быть убыточным) — не пользовались «наймом олимпиадников» в те времена, когда закладывался базис их доходности и успешности.А кого они нанимали, извините? Начём вообще базируется ваша убеждённость в этом?
Для меня хорогим контрпримером является тот факт, что даже CEO, которого они наняли, чтобы инвесторы не сильно ворчали — оказался программист! Написавший, в своё время, lex и, соотвественно, человек прекрасно представляющий — и что такое язык C и как устроены компиляторы…
Разумеется, можно сказать, что олимпиадники явно смогли по крайней мере ничего не испортить в этом базисе, а то и успешно улучшить — но по крайней мере не вызывает сомнения тот факт, что для того, чтоб из «никого» стать гуглом — надо не олимпиадников нанимать, а делать совсем другие вещи.И какие же?
И если уж вы завели разговор о конторах — у IBM, например, практика найма совершенно другая, чем у хипстеров из калифорнии (по крайней мере, была совсем другой десяток лет назад, когда я там этой темы близко касался).Мало касались, я думаю.
Что совсем не мешает им быть и оставаться очень крупной софтверной компанией.IBM — это крупная консалтинговая компания. Тот факт, что они не создали никакого софта, который бы распространялся вот именно как софт — говорит о многом. Всё что они продают — это либо софт, который они где-то купили, либо софт, который прилагается к чему-то там.
А IBM Research (который как раз и порождает немалое количество «прорывных» вещей) — так у него принципы как раз похожи, на то, что практикует Google. Именно поэтому подобные рокировочки и происходят.
А кого они нанимали, извините?
Людей, которые хорошо решают проблемы, которые на тот момент времени нужно было обязательно решить. На этом же и империя Безоса стоит, кстати, на найме таких людей — в разное время и совсем с разными специализациями.
Для меня хорогим контрпримером является тот факт, что даже CEO, которого они наняли, чтобы инвесторы не сильно ворчали — оказался программист!
CEO наняли не тогда, когда поиск от гугла вставал на ноги. И не тогда, когда пара человек, работавших над совсем другими вещами, придумала AdWords. Не понимаю, почему вы это считаете «контрпримером».
Мало касались, я думаю.
А я думаю, что побольше вашего. Я очень порядочное количество лет провёл в той самой «где-то купили», откуда берется софт в самой IBM, и коммуцировал непосредственно с работниками IBM весьма достаточно.
Так вот, IBM в основном не создаёт софта, да. Большая его часть берется откуда-то еще, вот только перекладывается и переупаковывается (а иногда и пересобирается, причём прилично так) он таки на стороне IBM. И программистов у них для этих целей в штате весьма прилично.
Так может IBM стоит не на них, а? А как раз на продажниках, которые умеют продавать творения вот этих вот «гениев»?
И стоит ли тогда нанимать подобных «творцов»?
Ну то есть с одной стороны — вы приводите в пример IBM, как фирмы, которая «правильно» нанимает сотрудников, а с другой — вас не удивляет, когда эти сотрудники оказываются, мягко скажем, не очень высокого качества.
Уже в который раз замечаю, что у вас очень так себе с кванторами. И чтением.
Я привожу в пример IBM как фирму, которая нанимает сотрудников совсем иначе, нежели решением олимпиадных задач, и которая от этого совсем даже не рассыпалась. Более того, я выше писал о том, что выяснять зависимость между приёмами найма и ростом компании — это что-то из серии «вилами по воде». А вы это как аргумент заявили.
И да, меня совершенно не удивляет, что в любой (абсолютно любой) достаточно большой компании есть плохие сотрудники.
Так может IBM стоит не на них, а? А как раз на продажниках, которые умеют продавать творения вот этих вот «гениев»?
О, надо же, от аргумента о связи между наймом программистов и работой конторы вы дошли до осознания того, что другие люди в конторах тоже есть. Еще немного, и до вас дойдет, что другие люди везде есть — не только в IBM.
Я привожу в пример IBM как фирму, которая нанимает сотрудников совсем иначе, нежели решением олимпиадных задач, и которая от этого совсем даже не рассыпалась.Рассыпаться — не рассыпалась.
Лидерство в области написания ПО — потеряла. Причём давно. Как вы сами же признаёте.
Еще немного, и до вас дойдет, что другие люди везде есть — не только в IBM.А до вас, может быть, дойдёт, что есть компании, которые «стоят» на качестве своих программистов (и они как раз, склонны задавать все эти алгоритмические задачи на собеседованиях) и есть компании, которые качественный код не порождают — ибо им это не нужно.
Так вот современная IBM — относится ко второму классу.
В известные компании хотят все. И люди готовы к сложным долгим и нудным интервью. Если какой нибудь Apple на последнем этапе интервью попросят спеть в караоке, кандидаты все равно будут это делать.
С чего вы взяли что должны быть улучшения? Я вам говорю про деградацию, если раньше ты шёл в малоизвестную компанию то мог быть уверен что уровень интервью там будет лайтовее. И если тебе было лень сидеть неделями за подготовкой к интервью или тебе нравилась то чем занималась компания ты просто шёл и беседовал. Вы же понимаете что у людей бывают личные проблемы или например компания распалась, а не просто так он ищет работу ради высокой ЗП.
Если раньше у него было выбор между собеседованием на следующей день в Рога и Копыта, а на след. день офером, то сейчас идя в любую компанию это 3+ интенрвью. Дак зачем мне нужны Рога и Копыта и подготовка к ним на полгода, если я с тем же успехом пойду в какой нибудь Яндекс с большей ЗП и плюшками? (да возможно проект там будет не подуше, что в конечном итоге возможно убьет в душе хорошо программиста) Один хрен тоже время готовится к интервью, а ЗП больше.
Так что по моему мнению если раньше компания мид-грейда могла получить хорошего программиста или плохого, с вероятностью 50/50, то теперь это 10/90, потому что все меньше сеньеров настроены идти в Рога И Копыта, учитывая необходимый уровень подготовки. А теперь представьте какую нибудь e-commerce (маленькую компанию) только что открывшуюся, она готова брать с лайтовым интервью, потому что у них нет опыта, но вот беда из за того что большая часть компаний требует каких то нереальных интервью, люди начинают думать что все компании так делают.
В итоге мы теряем маленькие компании, а средние ищут прогреров по полгода. Зато корпорации процветают — что идеально для них.
А теперь представьте что SSE нужно потратить на подготовку с полгода чтобы пройти у вас интервью идеально (да конечно он хочет пройти его идеально он 10 лет в отрасли), а вы mid-grade компания, куда он пойдет к вам или в какой нибудь Google?
Зацепило про 10 лет в отрасли — а что тогда те, кто 20 лет в отрасли? 30 лет в отрасли? Они — кто? Я вот уже 18 лет в отрасли и знаю кучу людей опытнее меня…
На мой взгляд, Senior, может не помнить как реализовать ту или иную сортировку, но должен хотя бы знать какие бывают сортировки их плюсы, минусы и порядок работы.
Придумать какой-нибудь примитивный и не эффективный алгоритм сортировки достаточно несложно. Можно просто на этой задаче посмотреть как кандидат справляется с задачей. Как с алгоритмом, так и с реализацией. Это тоже будет маркер квалификации.
Вообще задачки по программированию сами по себе ничего не решают, это лишь еще один штрих (конечно весьма весомый) к "портрету" кандидата.
Когда я провожу собеседования, даже с Senior разработчиками на практической части я даю относительно простые задачи уровня FizzBuzz, знание каких-то базовых конструкций языка и иногда задачу на сортировку с помощью библиотечной функции.
Таких задач около 10, все они достаточно простые, но из разных предметных областей.
При этом хорошо видно на сколько кандидат хорошо умеет программировать и какие у него знания в разных областях.
однажды, ещё когда не умел программировать, помог незнакомой девушке на улице сумку донести до дома. разговорились по пути, она оказалась HR в какой-то компании. я её спросил есть ли какой-нибудь секрет, как устроиться на любую работу? она мне по секрету сказала, что в Москве тебя полюбому возьмут если вместо "сколько я буду получать" кандидат спросит "что я буду делать"
Пока вы там сортируете, сеньор решает реальные задачи, проектирует и пишет понятный код, оптимизирует проект, трезво оценивает сроки, задаёт нужные вопросы по ТЗ и учится.
оптимизирует проект
Вот. Вот здесь оно, "написание сортировок".
Это только в случае если сортировка оказалась узким местом. Такое бывает крайне редко в реальной жизни. А если уж случилось — с этим реально справиться даже не помня алгоритмов сортировок до возникновения проблемы.
Это только в случае если сортировка оказалась узким местом.Если вы это выяснили это после написания кода — то уже поздно что-то оптимизировать.
Прикидки с учётом «O большого» и всем известной таблички должны случаться до того, как вы свою любимую IDE запустите.
Моя оптимизация, которая стала работает примерно в 10 раз быстрее заключалась в двух вещах, первая, использование TreeSet, которая делает все эти операции при вставке в него, вторая, добирать данные после того как мы избавились от лишнего мусора. Потому что отсортировать список и сделать из него дистинкт — копейки по сравнению с десятикратным уменьшением доставания данных из редиса.
Когда я спросил, а зачем он так написал, ответ был прост — ну я не подумал, у меня это как-то быстро работало и так. Действительно зачем думать, зачем знать как работают структуры данных, зачем что-то знать про сложность операций. Он же сеньор, это он прошел когда учился в институте.
Он же сеньор, это он прошел когда учился в институте.Если бы «прошёл». Он это всё «сдал». Успешно. Себе — ничего не оставил.
И да, я понимаю почему это произошло именно так, он не конченный, как может показаться, просто он использовал метод, который возвращает все данные при загрузке, ну то есть лезет в базу, и потом для каждого проходится и дополняет данными из редиса. И дальше происходит фильтрация. Банальная невнимательность? Не понимание, что сейчас достаешь не пяток записей, с которыми придется работать, а там еще дальше куча всего происходит, прежде чем тебе потребуется дополнительная часть данных. В итоге, метод, который должен работать. Хорошо хоть не на каждую запись ходили в редис, а мультигетом…
А может всё куда банальней? Требование фильтрации появилось позже и не в том виде, в котором сейчас?
То есть, по второму пункту, если завтра придут и скажут, что нужно, например, только последнюю записи, то он просто в конец этого кода добавит «взять последний элемент из того, что получилось», потому что требование изменилось, нужно просто любыми способами, как можно меньше меняя код построиться под эти требования
Может просто "нужно вчера, сделай как можно быстрее и создай таску на рефакторинг/оптимизацию в бэклоге". И так там эта таска годами может лежать.
Только вот в какой-то момент ко мне пришло критическое мышление, а кому-то, хоть он и сеньор — нет, поэтому для него такие вещи, это обычно дело.
Хватит оправдывать программистов. Если человек написал дерьмовый код, то ему стоит сказать, что он написал дерьмовый код, и пусть думает дальше, как избежать этой ситуации в будущем. А то уже пришли к тому, что на ревью надо общаться, узнавать как у жены-тещи-собаки дела, и говорить аккуратно «мне кажется ты делаешь что-то не правильно, пойти это только мое мнение, но вот тут не стоит на каждый запрос выбирать все данные из пяти терабайтной базы, что бы найти одну сущность, знаешь, в базе данных можно выбрать одну сущность, и более того, существуют индексы...», что бы потом услышать «Ок, я услышал твое мнение, но мне так проще».
А я частенько бывал и с другой стороны этого утверждения. Сделал слишком заумную архитектуру, наложил слишком много ограничений и т.д. В результате часто от этого огребаешь. И это даже обиднее, чем просто «забил и пустил на самотек»: ты тратил время на продумывание архитектуры, крайних случаев, примеров использования, нетривиальную реализацию, а по итогу оно все также не работает.
Вот например, у меня есть один проект, в котором основная часть кода — ну, не совсем дерьмо, но на самом деле, ничего особенного. Глазу незачто зацепиться. Я знаю, как навесить вокруг этого кода офигенную архитектуру, которую хоть в рамочку вешай и всем показывай. Но проблема в том, что эта архитектура опирается на некоторые ограничения. И почти наверняка, когда я закончю эту архитектуру писать, придет менеджер с задачей, которая эту архитектуру как раз ломает (я даже знаю такую задачу, но чтото менеджер о ней уже давно не вспоминает). И что в результате мне с этим делать?
Сейчас, если такая задача вдруг возникнет, я смогу ее взять и реализовать в коде. Да, код станет еще большим говном, но и задача будет сделана. В случае же «классной» архитектуры, там даже костыль для этого дела придумать будет не так то просто.
В результате, довольно часто бывают такие ситуации, когда в какой-то части проекта код — гавно, но ты об этом не знаешь. Вот когда в ту часть кода придет задача, то ты посидишь, подумаешь и исправишь. А если в ту часть кода никаких задач нет — то и исправлять там нечего
А я в основном могу вспомнить только сознательные "косяки" (тактически оптимальные решения), с туду-комментариями и(или) тасками в бэклоге технического долга, которые принимаются во внимание в оценке следующей задачи, которая затрагивает этот кусок кода.
Иногда, да, бывает "Блин, кто эту чушь написал?! Бл..., я, если верить гит логам", но редко
Както делал на одной работе нечто похожее. Правда там не было тех разительных x10, но логика была примерно такаяже.
Проблема в том, что если сейчас убрать весь этот код, оставить только нужное, то потом хрен найдешь, как оно там было раньше, как в эту базу ходить, да и индексы все уже давным давно потерты.
Если смотреть с другой стороны, то те же сеньоры пишут код, из-за которого текут данные, придумывают архитектуру, из-за которой сканы паспортов лежат в /uploads/images/1.jpg, оптимизирую приложения так, что они падают от 10 параллельных запросов и выжирают месячный бюджет за 10 минут, а исправить это они не могут, так как сроки горят. Встречается такое в каждом втором посте из раздела /ИнформационнаяБезопасность/. Возможно, лучше бы сортировки писали.
Тогда возникает вопрос, а сеньоры ли они на самом деле.
Ни разу не нанимал их, так что сложно сказать. Но скорее всего это были бы смоделированные реальные ситуации, чтобы посмотреть как кандидат поведёт себя в них, какие решения предложит.
Да, я вот прямо задачки из учебника обычно не даю… люди обижатся. Но даю что-то похожее из практики.
И вот как-то так получаются что есть люди, которые их решают — и они же прекрасно пишут сортировки, если нужно… а есть те, кто этого сделать не могут — зато они могут прекрасно обсудить все перепитии, которые привели нас, когда-то, к этой задаче — вот только код написать не могут.
Ну вот типичная задача из этого списка: есть два односвязных списка, которые в некоторый момент «сливаются»… найти расстояние до этой точки от двух указателей, которые вам передаются в качестве аргумента — желательно не проходя эти списки до конца.
И вот есть люди, которые могут выпытать у меня — откуда взялись эти списки, какая версия Internet Explorer у нас была, когда мы упёрлись в производительность и массу других вещей.
Чего они не могут — так это взять и… написать код. Который решит эту задачу.
Ну и? Нафига они нам на позиции SSE? На PM'а — они бы, возможно, и подошли бы, но там другие задачи и другой вид собеседования…
За много лет работы мне эти сортировки не понадобились. Да, на заре получения образования и их проходила. Но успешно забыла, т.к. за все время моей работы они мне не понадобились. Да, для собеседования опять их прочитывала, но через неделю опять их забыла из-за ненадобности.
Не знание сортировки говорит о том, что я полный ноль?
Сеньеор — это человек наступивший на сотню граблей. Он имеет опыт как не наступить на аналогичные грабли.
Он должен увидеть, что тут нужно подцепить библиотеку и суметь определить какую. А где не нужно ничего подцеплять и писать свой велосипед, т.к. по этому моменту все библиотеки кривые.
А так же он должен видеть весь проект и корректировать работу джунов и мидлов.
Что у него спрашивать на собеседовании? Конечно опыт. С какими технологиями работал, какого размера был проект. Если человек дорос до сеньеора, то нет смысла задавать ТЗ — писать код. Это он уже показывал ранее, когда был джуном или мидлом.
Из моего опыта (я вроде бы мидл). Я 2 раза с перерывом в 3 года собеседовался в одну и ту же компанию. Первый раз меня попросили реализовать итератор для чего-то там. Ну блин, я каждый день их использую, но я не реализую его на доске за 30 минут, потому что их внешнее поведение мне нужно, а подробности их внутрянки мне нафиг не нужны постоянно.
Второй раз была более практическая задача на те же 30 минут, я предложил решение, о котором интервьюер даже не думал. Первый раз завалил интервью в итоге, второй раз все норм было.
P.s. А почему синьор не должен писать код? Может, конечно, от размера команды зависит. В небольших командах все равно это умение нужно, кмк.
Как минимум надо чтобы при слове, например, quicksort у человека в глазах появлялось понимание что есть такое понятие и он знал где, зачем и как можно ее применять. Хорошо, если он может в двух словах описать ее принцип — если читал про нее ранее, что-то да отложилось в глубинах памяти.
Если вы учились в институте, то должны уметь вычислять тройные интегралы. Вы мне сходу сможете его вычислить? Сомневаюсь. И сомневаюсь, что за час вы это легко и просто воспроизведете по памяти. Но вы же это учили. Так и здесь. Мне в работе это не требуется. Когда она требуется — для решения необычных задач. Это как на конференции было рассказано — решали задачи по быстрому открытию больших файлов. В жизни это может потребоваться на очень серьезных проектах, таких как ВК. Да, там большие нагрузки и там действительно они и сам PHP пилят. Но сколько у нас таких проектов?
P.s. А почему синьор не должен писать код? Может, конечно, от размера команды зависит. В небольших командах все равно это умение нужно, кмк.
А я утверждала, что он не должен писать? Я просто имею в виду зачем проверять на собеседованиях и так очевидное? Если бы он не умел, то не стал бы сеньором.
Вклинюсь — беда в том, что у вас и у кандидата могут быть очень разные представления о том, что такое сеньор. Вы подразумеваете способность писать код, а по факту ее может не быть, она может быть утрачена, — есть много вариантов.
Если бы не надо было бы это проверять — вообще можно собеседования не проводить.
- Сеньор?
- Конечно сеньор.
- Отлично, принят!
Совсем не факт, что есть, совсем не факт, что написано именно кандидатом, совсем не факт, что самостоятельно… и это все же косвенные данные — куда проще получить прямые, просто попросив написать код. И масса народу сразу отсеевается.
Обычно к этому моменту есть хоть что-то, выложенное на гихаб или битбакет.Вот как раз у синьоров очень часто если чего и выложено — так это что-то пяти, а то десятилетней давности. А то, что он делал в этом году — оно под NDA и вообще принадлежит не ему, а его работодателю.
«Живых» профилей на GitHub, на самом деле, примерно на два порядка меньше, чем программистов. Так что если отсечь всех, у кого на GitHub ничего нет за последний год — то это будет фильтр куда как пожёще, чем просьба написать сортировку.
Хорошо, если он может в двух словах описать ее принцип — если читал про нее ранее, что-то да отложилось в глубинах памяти.
Читал, и даже реализовывал на лабах. Отложилось только, что быстрая :)
Мысль на первый взгляд кажется логичной, но она разбивается о суровую действительность.
Когда устраивался на свою вторую работу ( меньше чем через два года после универа ) я получил должность Сеньора. Сейчас, спустя 9 лет, я все еще сеньор. Был ли я сеньором по моим нынешним стандартам 9 лет назад или для своей нынешней компании? Нет, определенно нет. Но для той компании XXX я был именно сеньором.
Так что, довольно очевидная мысль: сеньоры в разных компаниях разные. Если у человека в резюме написано «сеньор», это не означает что его уровень достаточен для «сеньора» в вашей компании, может даже на миддла недостаточен. А когда много собеседуешь, то периодически видишь «сеньоров», у которых знаний меньше чем джунов — особенно этим славится Индия, Пакистан и прочая Азия — 6-8 лет опыта в резюме, но весь этот опыт скорее всего существует только на бумаге.
Поэтому базовая проверка «может ли кандидат писать код» — как ни странно отсеивает очень много таких мошенников. Оказывается, что научиться пи.., простите, разговаривать, о технологиях, с которыми ты якобы работал — это несложно, любого индуса можно за пару недель научить или даже дней. Прочитает несколько статей на темы о которых написано в резюме и готово — разговаривает как живой. А вот писать код, который будет работать — здесь прочитать пару статей не получится, здесь крайне сложно сэмулировать, это можно продемонстрировать на собеседовании только если ты действительно умеешь писать код.
Это как «разговаривать о футбольной стратегии и тактике» и действительно играть в футбол — каждый первый мужик в стране может часами разговаривать о том, кого надо было выпустить на замену и какую схему надо было выбрать, но попадать по мячу может дай бог один из тысячи.
Плюс мы должны уметь обращаться к этому списку по индексу (требуется отображать кратко эту таблицу топ-10, пяток лиг, и мы должны показывать топ-10 в каждой лиге, и еще +-5 окружающих игрока).
Какую библиотеку мне следует подцепить, что бы оно работало? Ах да, количество ридов этой таблицы примерно 300-400 в секунду.
Все обновления были в одном треде, плюс индекс из map<userId, entry> сразу на нужную запись в list, что бы подвинуть ее при апдейте.
Более того, изначально были апдейты делать list<bucket>, что бы можно было сразу мувнуть запись на очень много позиций вверх, но самая простая реализация работала очень неплохо на таком объеме данных, обычно приходилось делать не больше 20-30 всплываний записи за раз, иногда бывали всплески когда двигали на 3-4 сотни, но это было нечасто.
1 (7810), 2-10,
11 (6790), 12-20,
101 (4200), 102-110,
145-149, 150 (2420, наш пользователь), 151-155
1000 (990), 1001-1010
10001-10010
Как это правильно достать из базы?
[146] - Entry(146, 2450, 61294)
[147] - Entry(147, 2435, 991223)
[148] - Entry(148, 2430, 67)
[149] - Entry(149, 2420, 13) + 20
и оно превратится в
[146] - Entry(146, 2450, 61294)
[147] - Entry(147, 2440, 13)
[148] - Entry(148, 2435, 991223)
[149] - Entry(149, 2430, 67)
Разобьем базу на подбазы с лимитом по 1000 элементов. Назовем из s1, s2…
То есть в подбазе (подбаза — это просто поле в таблице рейтинга) s1 лежат люди с местами 1..1000, s2 — 1001-2000 и т.д. (вариант, когда подбаза заполнена не полностью, здесь рассматривать не будем)
Когда нам нужно упдейтить какой-то элемент, например у него score был 40. Стал 60. Смотрим, рядом с какими элементами он будет стоять. То есть, рядом например элемент из подбазы s2 со score 59 и элемент из тойже подбазы s2 со score 61. Так как мы собираемся переместить наш элемент в подбазу s2, то получается, что из подбазы s2 лишний элемент нужно выкинуть (у нас ограничение на ровно 1000 элементов) в подбазу s3. Из подбазы s3 последний элемент нужно выкинуть в подбазу s4 и т.д.
Таким образом, для вставки элемента потребуется порядка 300000/1000=300 действий.
Для вычисления места, мы также знаем в какой подбазе лежит элемент. Если элемент лежит в подбазе s3, то до него 2000 + x элементов, где x можно вычислить, пересчитав все элементы с головы подбазы до нашего элемента, что не больше 1000 действий
То есть получается порядка 300 действий на вставку и 1000 на чтение.
Понятно, что это все равно в десятки раз медленнее велосипеда (и сложнее), просто, разминка для ума.
Можно попробовать реализовать. Быстрее текущего решения понятно что не будет, но в ограничения можно попробовать уложиться
А зачем тут сортировка, если event приходит на одного игрока? Пришел event — поменяли место игрока. Это один шаг из сортировки.
30 25 20 15 13 11 5 3 0, если у нас происходит изменение например 11, прилетело +10, мы должны поменять местами несколько записей, это и 13 и 15 и даже 20.
Ну да, нашли нужное место, поместили туда, остальные сдвинули. Сложность O(N). Вызов сортировки здесь не нужен, ни библиотечной, ни самописной.
idx = getIndexByUserId.get(userId);
leaderboard[ids].addScore(20)
leaderboard.sort()
leaderboard.each(index, entry -> getIndexByUserId.put(entry.userId, index))
Ведь мне нужен отсортированный массив и значит я буду использовать библиотечный метод. А индекс, потому что мне старший сказал, что поиск в списке очень медленный
Так даже не зная баблсорт это можно сделать, просто потому что по-другому сделать нельзя. Ну если не сортировать каждый раз заново конечно, что нормальный senior и не будет делать. О том и была речь в исходном комменте этой ветки — необязательно знать сортировку, чтобы правильно решить задачу.
ЗЫ: Это как раз один из тех редких случаев, когда явовский LinkedList уместен.
Ну потому что этот пример был в качестве возражения на коммент про сортировки и библиотеки. Непонятно, что в нем сложного, что надо алгоритмы знать и на собеседовании их спрашивать — передвинуть элемент в массиве со сдвигом других.
Достаточно ли быстро для ваших нужд или всё-таки всё равно нужно писать кастомный код… это нужно побенчмаркать… кастомный код можно довольно сильно дооптимизировать вот именно под случаи «небольшого сдвига».
Пишем все в базу, считаем что она с записью справляется.
Перечитываем все раз в минуту. Обновляем таблицу в памяти. База выдержит, по сравнению с записью это ерунда.
Любого игрока накладываем на эту таблицу из памяти с его новым результатом. То что у остальных результаты устаревшие до минуты никто и не заметит.
Нагрузка ерунда. Дифф небольшой. Шардируется при необходимости легко.
Все топы считаются так же раз минуту. Игрок влазит в них без проблем. Во всех топах держим +1 запись чтобы подменить при необходимости.
Если памяти не хватает выносим все в какой-нибудь Редис. Для него это все тоже ерунда, а не нагрузка.
Итого: Все работает на калькуляторе. И никаких заумных технологий. Маштабируется в любую сторону легко. Упереться можно только в запись в sql.
Актуальный это понятие относительное. Допустим мы честно читаем из базы, и выводим. Результат все равно будет не актуальный. Кто-то уже сыграл и его результат после чтения поменялся. Значит остается только торговаться о допустимой задержке.
Задержку тоже можно уменьшить записывая все изменения онлайн в тот же Редис. Паралельно с записью в базу. И из него пересчитывать топы и прочее раз в секунду. Из базы по прежнему все обновляем раз в минуту. Это опять таки шардируется и паралелится великолепно. Все можно делать на разных хостах асинхронно.
Чуть сложнее, но задержка падает на порядок. Хотя при игре длиной 10+ минут этого уже никто не заметит.
имя + очки + что там надо еще — значение. Если надо много имен. Миллионы с 0 просто не храним. Добавим если появятся.
Топы и прочие нужные короткие списки храним рядом отдельно. По такому же принципу.
Новые результаты просто в лог или очередь. Любую по вкусу. Воркер на соседней машине разгребает эту очередь и патчит данные в Редисе. Другой воркер на отдельной машине пересчитывает топы и прочую статистику.
Итого надо 3 калькулятора для обработки всего. Все 3 маленькие. Девопсы скажут спасибо. Базы отдельно от калькуляторов.
Все это по прежнему используем как базовую таблицу. Результаты последней игры пользователя просто накладываем на нее, отдаем пользователю и забываем то что отдали.
Очередь то тут для чего и соседняя машина с воркером?
Естесвенно это все применимо к действиетльно большой нагрузке. Когда у нас кучка беков отвечающих пользователю. И их желетельно разгружать от любых лишних задач.
На что мозг натренируешь, то он и будет успешно выполнять. И остаётся главный вопрос, что работодателю нужно в конкретном случае. Лучше уж если давать задачки, то по паттернам программирования. Это уж точно пригодится в работе почти каждого программиста.
Подожду, когда начнут жаловаться «ну и что что я не помню что такое сортировка или массив, это все можно нагуглить при необходимости».
Ну так вы пишите в вакансии сразу — мы разрабатываем корпоративные приложения, но на собеседовании спрашиваем алгоритмы сортировки.
list, который, на самом деле, как раз ArrayList.Если этого не знать, что можно породить такой код, что он даже по меркам python'а окажется недопустимо медленным.
Таки они есть у нас:
SplDoublyLinkedList
SplStack
SplQueue
SplHeap
SplMaxHeap
SplMinHeap
SplPriorityQueue
SplFixedArray
SplObjectStorage
Аргумент номер 0: Не помнить как работает «сортировка слиянием» может само по себе не страшно. Но это в общем-то простейший алгоритм, один из самых простых которые можно себе представить. Если человек не знает как работает сортировка слиянием, то вероятно он не знает как работает вообще никакой алгоритм, не так ли? Ну т.е. теоретически я могу себе представить человека, который помнит разные сложнейшие алгоритмы, но забыл сортировку слиянием — но на практике нет, я думаю так не бывает или бывает крайне редко. Таким образом получается речь не о сортировке слиянием, а об алгоритмах вообще. И даже не о самих алгоритмах, а об идеях за ними лежащими. Скажем, идея сортировки слиянием — это просто-напросто рекурсивный «разделяй и властвуй» плюс слияние отсортированных данных путем двигания двух указателей за линейное время. Не случайно на хаскеле она записывается в одну строчку. Если для человека «сортировка слиянием» оказалась слишком сложной, чтобы об этом вообще разговаривать — может он в принципе не рассматривает рекурсивные «разделяй-и-властвуй» идеи разбиения задач и объемов данных на подзадачи? А как у него с параллельной обработкой тогда, понимает ли он разницу между различными стратегиями параллельной обработки? А если он не понимает, что два отсортированных массива прекрасно сливаются за линейное время — может он постоянно в своих задачах упускает такую возможность — отсортировать массивы перед обработкой и делать линейный обход? Вместо этого он делает цикл работающий за o^2, как я неоднократно вижу у своих коллег, которые как раз пренебрежительно относятся к алгоритмам?
Дальше вы пишете что в 19 лет вам не понадобилось ничего из алгоритмов. А вы не задумывались, что «вам не понадобилось» именно по той простой причине что вы не знаете как они работают? Разумеется, если ты не знаешь как работает какая-то штука — то тебе значительно реже в голову приходит применить ее, или какие-то идеи, которые в ней используются. Предположим, я не умею работать с паяльником, у меня его и нет — и я за 33 года ни разу не применял паяльник в быту и прекрасно себя чуствую. Но это не говорит о бесполезности паяльника, если бы я был ас в паянии, вероятно я бы его не раз применял в разных ситуациях, где я сейчас обхожусь без него.
Так и с алгоритами: я, например, за 10 лет применял разные алгоритмы неоднократно в ситуациях когда использование готовых библиотек было невозможно по разным причинам. Не буду говорить что это часто происходило — даже не каждый год, но не исключено что это происходило редко из-за того что я не видел применения ( я все-таки сам не эксперт), а не потому что не было возможности применить.
И аргумент, который я оставлю последним в силу его яркой субъективности — его предложил мой знакомый из Гугла в свое время, он не мой, но заслуживает, возможно, внимания. Программирование — это оперирование сложными абстрактными объектами в голове определенного рода. Да, даже человек у которого плохо с этим «особенным» мышлением в состоянии изучая разные образцы кода, используя копипасты с доки и стековерфлоу писать какой-то код, который будет как-то где-то работать и что-то делать. Терпение и труд и куча лет практики в конце концов все перетрут. Но для гугла лучше нанять не такого «терпеливого», а человека со «способностями», человека который действительно имеет этот определенный образ мышления и кайфует от него. Причина в том, что такие люди по наблюдению Гугла значительно быстрее учатся в «нестандартных»" ситуациях и способны предложить решение даже для задач, для которых его нет на стековерфлоу.
Ну, и как правило, почему-то оказывается, что люди с этим «особенным» образом мышления — они хорошо проходят эти простые задачки на алгоритмы, они для них не вызывают никакого затруднений. В то время как для «ремесленников», скажем так, эти задачки оказываются почему-то очень трудны. «Ремесленник» с 10-летним опытом легко ответит на вопросы про особенности использумых им фреймворков или особенностей языков которые он использовал — но эти задачки для них сложны вплоть до того, что он, начинает считать сложным и требующим отдельного изучения какой-нибудь алгоритм «сортировки слиянием».
Разумеется если использовать только задачки будут false positives — с ними прекрасно справятся и вчерашние студенты в силу того, что совсем недавно изучали все эти алгоритмы. Но во-первых не каждый студент даже изучавший эти алгоритмы, способен их написать — почему-то и у них возникают проблемы, возможно опять же дело в особенностях мышления. Ну и студентов легко можно отсечь дополнительными вопросами уже по фреймворкам, языкам и паттернам, при желании.
Очень крутая статья по теме: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
Задачки по программированию — плохой способ оценки квалификации Senior Developer'а