Как и многие другие родившиеся в Канаде дети, я прошёл обучение в Королевской консерватории. Это не только физическое здание, где можно заниматься и выступать, но и стандартизированная учебная программа, а так же сертифицированные учителя, доступные практически в любом городе. Последние регулярно проводят экзамены по всей стране, чтобы учащиеся могли перейти на следующую ступень своего музыкального образования.
Упражнения нужны для обучения
Каждый экзамен имеет техническую составляющую и показательное выступление. Давайте поговорим о технической части. Для получения оценки, вы должны уметь выполнять несколько упражнений с вашим инструментом. На фортепиано в моём случае это были гаммы, арпеджио и т.д. Я уже и не вспомню их все.
По мере обучения, упражнения становятся всё более сложными, и выполнять их надо в более высокой тональности, пока на самом последнем экзамене вас не попросят выполнить любое упражнение в любой тональности.
После 14 лет изучения фортепиано, успешно сдав последний экзамен, любое упражнение на любой клавише мог выполнить и я. Но спустя ещё 14 лет, я даже не могу вспомнить названия всех этих упражнений. Смогу ли я заучить отрывок произведения и сыграть его на высоком уровне? Да без проблем!
Упражнения не нужны на практике
Готов поспорить, что из всех прошедших обучение в консерватории и ставших профессиональными музыкантами, очень немногие смогут выполнить произвольное упражнение. Да, некоторые из этих упражнений бывают нужны при подготовке к выступлению, но лишь частично, и вспоминают их только тогда, когда это действительно нужно.
На этой неделе, когда я занимался задачкой по программированию на Hackerrank, мне пришлось достать пыльный учебник по структурам данных и алгоритмам, чтобы написать сортировку слиянием.
Сперва я почувствовал себя крайне неуютно, но потом пришло озарение: это та же история, что и с упражнениями на фортепиано в Королевской консерватории. Да, когда-то они были важны, и мы зубрили на информатике разные виды сортировок. Но рост профессионального опыта заключается в понимании когда и где применять конкретные алгоритмы, вспоминая реализацию лишь в случае необходимости. Я знал, для чего нужна сортировка слиянием, я знал, как найти её код. Я лишь не мог вспомнить его.
Кто-то поспорит, что Senior Developer должен уметь написать сортировку, не прибегая к справочным материалам, ведь это азы. Но я в это просто не верю. Делает ли человека лучшим музыкантом способность отлично играть гаммы в любой момент времени? Конечно же нет! Более того, я утверждаю, что оттачивая мастерство в учебном упражнении, вы теряете время, которое могли бы потратить на решение прикладных задач.
Упражнения не должны использоваться при найме
Можете представить, чтобы профессионального музыканта, не раз блестяще выступавшего на сцене, на собеседовании попросили бы сыграть гаммы? А после этого, так и не перейдя к исполнению отрывка, сказали бы: «Мы вам перезвоним», ведь он не справился с азами идеально.
Такие мысли вызывают у меня тошноту. Но мы живём в 2019 году, когда подобное происходит сплошь и рядом на собеседованиях в сфере программирования.
Компании используют сторонние сервисы типа HackerRank в качестве фильтра для отсеивания претендентов. Многие отличные разработчики отсеиваются, потому что не упражняются в написании сортировок регулярно. Компании жалуются на нехватку квалифицированных кадров на рынке труда. И это повторяется раз за разом.
Кстати, я даже не говорю о собеседовании в офисе. Я имею в виду самый начальном этап найма, когда часто HR присылает ссылку на несколько задачек на HackerRank, ограниченных по времени. И, получив результат спустя 10-15 минут, принимает решение продолжать ли общение. Такой подход к найму программистов — проблема нашей отрасли.
Так как же оценить квалификацию Senior Developer'а?
Мой опыт собеседований кандидатов подсказывает, что нет ничего лучше сеанса парного программирования. Уделите час-полтора разработке с общим экраном. Поработайте вместе в своём окружении, со своими инструментами, над своим проектом. Переключитесь и поработайте в окружении соискателя, с его инструментами, над каким-нибудь его кодом. Вы очень быстро поймёте уровень человека по вопросам, которые он задаёт.
И проверки памяти на алгоритмы совсем не нужно.
Комментарии (332)
DrunkBear
24.12.2019 11:30+3Уже сотню раз мусолили эту тему же: если в профессиональные обязанности будет входить хотя бы раз в неделю построение красно-чёрных деревьев и написание быстрой сортировки — их стоит спрашивать у кандидата.
Если не входит — лучше спросить то, что входит.
Иначе получится тот самыйостров с ядовитым газом, воздушным шаром и вентиляторомТебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: «УТЕЧКА ЯДОВИТОГО ГАЗА!!!».
— Как так-то? Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что-то в проекте менял?
— Немного, швабры вынес…
— Швабры потолок держали!
— Что??? Что извините???
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар иуелетайте!sbnur
24.12.2019 11:45Классная история.
Реформаторский зуд лечится резкими обжигающими ударами по рукамmayorovp
24.12.2019 14:31+12В данном случае бить по рукам следовало того, кто это всё изначально соорудил.
JustDont
24.12.2019 14:54-1Не более, чем того, кто вместо достраивания всё сломал.
mayorovp
24.12.2019 15:09+6Чтобы можно было говорить про "сломал", оно должно было работать в прошлом.
Предположим, что главный герой этой истории всё сделал аккуратно и ничего не сломал. Что было бы дальше? Дальше уборщица вытащила бы одну из швабр, началась бы утечка, после чего все задохнулись бы в процессе поиска противогазов. Назначение вентилятора так и осталось бы нераскрытым, а для воздушного шара не нашлось бы пилота (и это в лучшем случае, в худшем он бы просто не взлетел без ТО).
JustDont
24.12.2019 15:16-1Чтобы можно было говорить про «сломал», оно должно было работать в прошлом.
Оно работало. Не как лаборатория, но работало.
Но я даже не об этом, а о том, что у перестраивателя вышла лаборатория для тех, кто способен дышать ядовитым газом. Что абсолютно точно так же не то, о чём его просили.DrunkBear
24.12.2019 16:01+1Правильный вывод немного в другом: прежде чем выкидывать из проекта всякие
швабрыкостыли и переделывать проект по тру канону — сначала посмотри, что они подпирают и зачем вообще были добавлены.mayorovp
24.12.2019 16:32А что можно было увидеть в этом случае? Если до швабр, которые подпирают потолок, ещё можно при наличии опыта как-то догадаться, то назначение вентилятора и воздушный шар заранее расшифровке не поддаётся.
Можно, конечно же, было позвонить знакомому заранее — но я за 10 лет работы по специальности ни разу не видел такой роскоши как контакты предыдущего разработчика.
DrunkBear
24.12.2019 16:39+3Доки.
Зачастую швабры в таких количествах и 120тонные вентиляторы немного документируются.
К тому же, в приличном обществе, перед уборкой костылей делают форк и прогоняют регресс-тесты, а не коммитятся на прод.mayorovp
24.12.2019 16:47+1Исходя из восклицания "Ты хотя бы записку на двери повесил бы, что швабры для держания потолка!" я заключаю, что записки не было.
Ну и в моей практике самые головоломные костыли как раз и не документируются. Видимо, потому что костыли пишутся в спешке, когда на документацию времени уже нет.
DrunkBear
24.12.2019 17:12Видимо, подняться ножками на этаж выше и глянуть что там такое, уже не поддерживается?
С кодом — тем более: прежде чем разбирать страшную фекалопалочную конструкцию — нужно понять, что она делает, а в идеале — собрать на этот кусок требования и написать тесты.VolCh
25.12.2019 11:08+1Когда нет контактов предыдущего разработчика — это ещё полбеды. А когда нет контактов предыдущего заказчика… Вот есть большой кусок кода, он что-то делает с данными, откуда-то берёт, обрабатывает, куда-то результаты складывает, но никто ни из разработки, ни из бизнеса не знает что делает и зачем. С неделю (40 часов) "собираешь требования" — обходишь всех хоть как-то причастных по известным тебе бизнес-процессам, вроде получаешь картинку, что препредыдущему начальнику какого-то отдела были нужны какие-то ежедневные показатели работников для мотивации, которые никто не использует давно. Выпиливаешь, всё хорошо месяц, другой, полгода, а в январе прибегают начальники почти всех отделов и говорят, что у них годовой отчёт полную билеберду показывает.
Оказывается, где-то вне рамок системы были какие-то скрипты, у каждого отдела свой, причём с игнорированием ошибок, которые использовали эти показатели для расчёта своих раз в год, причём с игнорированием ошибок. А за это время система уже сменила версию языка, фреймворк, переехала с MySQL частично на PostgreSQL, а частично на MongoDB…
DrunkBear
25.12.2019 13:45А вот за это и отвечает этап сбора требований: Ничего не понятно?
Всех обошёл, все подписали, что хотят и что кроме этого — ничего не хотят, теперь делаем.
А как возникли претензии «а чегойто у нас неправильно работает?! Срочно чините, пришли тут всякие и всё переломали!» показываешь бумажку/письмо и предлагаешь уточнять ТЗ с последующим допилом. Со временем из непонятной и неподдерживаемой кучки скриптов может получиться хорошая и рабочая документированная система.
Это если интересно работать именно в этой компании, если не интересно — после слов «вот тут какой-то код, доков нет, требований нет, заказчиков нет, разработчиков тоже нет, зависимости… а шойто такое?! короче, сделай так, чтоб лифт ходил не только вверх-вниз, а ещё и влево-вправо, тыжпрофессионал» улыбаешься и уходишь подальше.
Возможно, я не прав, но я дорожу своим психическим здоровьем.VolCh
26.12.2019 15:38Речь не про "делаем", речь про "чистим конюшни".
DrunkBear
27.12.2019 11:12У любой чистки есть цель: можно просто выкинуть мм… мусор из конюшни на задний двор (там никто не ходит и не видно), а можно увезти мусор с пользой на поля, ещё и стоила переделать, и дырявую крышу подлатать, зависит от того, будем этой конюшней дальше пользоваться или на снос её.
К тому же, во многих местах работают процессы риск-менеджмента, с оповещением всех потенциально затронутых изменениями в системе и перед разбором непонятных скриптов заводится новый риск.
Ну а если риски не оцениваются и никому ничего не нужно и некогда, но сделайте — я уже писал своё отношение.
PS Ведь в компании, про которую рассказываете, после форс-мажора поменяли процессы и завели что-то подобное?
softaria
25.12.2019 11:06Когда случилась утечка, он догадался позвонить прошлому прорабу, а перед демонтажом 120-тонного вентилятора — не догадался. Кто-то не очень сообразителен.
JustDont
24.12.2019 11:54если в профессиональные обязанности будет входить хотя бы раз в неделю построение красно-чёрных деревьев и написание быстрой сортировки — их стоит спрашивать у кандидата
А если посмотреть на содержание собеседований — может сложиться впечатление, что красно-чёрные деревья и сортировки пишут в каждой второй конторе. А в каждой пятой — не то, что раз в неделю, а по нескольку раз в день.
ashofthedream
24.12.2019 15:04Если человек прекрасно знает алгоритмы и структуры данных, то в большинстве случаев, он так же неплохо понимает как правильно следует использовать все те инструменты, которые он использует каждый день, плюсы, минусы и ограничения технологий, потому что все алгоритмы и структуры данных, как раз таки про ограничения, чем придется жертвовать ради того, что бы это работало быстро и не отбирало всю свободную память.
Люди, которые только и умеют брать инструмент и его использовать, умеют только брать инструменты, которые за них давно уже выбрали и использовать их, причем иногда так, что хочется плакать.JustDont
24.12.2019 15:15+14Одно из другого совершенно не вытекает. Чтоб «неплохо понимать», что у тебя там происходит на всех двадцати (или около того) уровнях абстракций от высокоуровневого DSL до машинного кода — нужно перелопатить огромное количество документации и кода. По-другому оно не работает. Человек, который «неплохо понимает» это всё — или уже потратил кучу времени, или принял (на веру) выводы тех, кто это сделал за него.
От знания алгоритмов и структур данных знания конкретного технологического стека магическим образом не прирастают.ashofthedream
24.12.2019 15:44+1Ох, из последнего, с чем пришлось столкнуться, была задача — для каждого пользователя необходимо сделать троттлинг по запросам, например не чаще двух запросов в секунду от одного пользователя. Первоначальная реализация была через таблицу в обычной базе данных, работала плохо и очень часто неправильно, с последующими костылями стала работать лучше, но скорость оставляла желать лучшего. Реализация c редисом была лучше, но так же имела свои минусы. По итогу я плюнул и написал свою реализацию, которая работает уже как полгода, выдерживает примерно 100-1500 запросов в секунду (при нагрузочном тесте использовались показатели примерно в 10 раз выше).
JustDont
24.12.2019 15:50+6Не готов комментировать конкретно ваш случай, я по другим вещам — но хочу заметить, что вот это вот «плюнул на всё и написал велосипед и он пашет» — оно обычно (не всегда, и я не берусь сказать, как у вас было) свидетельствует о том, что в алгоритмы человек смог, а вот знаний о инструментах у него маловато. И в итоге он пишет свои инструменты вместо того, чтоб заставить чужие работать надлежащим образом. И далеко не всегда это оправдано.
Несколько лет назад у меня был прекрасный пример перед глазами с самописной БД. Самописная она была, разумеется, от того, что сумрачные гении времен начала нулевых сказали «third-party RDBMS это фу-фу, они или платные или кривые, мы щас быстренько сваяем!». И сваяли, и это жило в проде примерно 7 лет, пока продукт применялся к нуждам пары (больших) клиентов. Но годы прошли, появились конкуренты, большие клиенты задумали свалить, и встал вопрос о развитии продукта. Немедленно выяснилось, что самописную БД развивать невозможно вообще — большинство людей совершенно не желает к ней прикасаться, а те сумрачные гении, которые желают — жрут много денег и их силы всё равно крайне ограничены, так что говорить о feature parity с популярными продуктами просто фантастично, а фич для развития требовалось много — БД наконец-то надо было использовать в режимах отличных от тривиальных вставок и выборок, а оно такого не могло от слова «совсем».
Это конечно было не единственным фактором, в итоге похоронившим продукт — но одним из важнейших.softaria
25.12.2019 11:12Мне кажется, масштабы задач очень разные — написать троттлинг vs написать свой RDBMS. Второе — очевидная глупость. Первое — вполне может оказаться обоснованным. Возможно, что там объем кода получился даже меньшим, чем объем конфигурации существующих инструментов.
JustDont
25.12.2019 11:42Второе — очевидная глупость.
Очевидно нет. Работало же, очень успешно и очень долго. Да, это в итоге превратилось в огромную проблему, но до этого жило столько времени, что все причастные уже успели получить серьезный профит, похлопать друг друга по плечам, и пойти работать куда-нибудь еще.
Мне кажется, масштабы задач очень разные
Это вам так кажется. Просто я описал свой случай с точки зрения последующего провала, а ashofthedream — c точки зрения текущего выигрыша. На самом деле в моем случае тоже никто не писал RDBMS — решали задачу «нам надо что-то для быстрой индексируемой записи с гарантиями большого потока информации и последующей выборки по индексам». Это уже сильно потом стало ясно, что тут нужен серьезный объем фич RDBMS, и на разных этапах жизни продукта некоторые самые «больные» фичи худо-бедно пытались добавлять.
Может статься, что и в примере выше троттлинг — это только макушка айсберга.
apapacy
24.12.2019 15:54+1По идее redis должен справляться с таким потоком. Если по хорошему о защищать нужно скорее конфигам nginx. Если на уровне приложения то получится немасштабируемо. Нельзя будет запустить два экземпляры приложения
ashofthedream
24.12.2019 16:33слишком сложно конфигами нжинкса дать одному пользователю допустим 2 запроса, а другому — 10.
На редис там и так хорошая нагрузка была, поэтому было принято решение использовать что-то ещеpolearnik
24.12.2019 17:48+1100-1500 запросов в секунду этофигня для редиса. Хотя конечно зависит от железа на котором запущено. Но у меня была ошибка однажды изза которой количесвто запросов в редис было 60к с пиками по 80к. Проц был загружен процентов на 10-20. Заметил случайно когда полез полюбоватся статистикой по редису
softaria
25.12.2019 11:14В чем сложность? На первый взгляд — несколько строчек в конфигурации. (Лично такое делал)
ashofthedream
25.12.2019 12:25Видимо сложность вот в чем: есть у нас абстрактный пользователь, у него дефолтные 2 запроса в секунду, дальше он зарегался у нас и вошел, окей, мы теперь говорим ему, что у него 5 запросов в секунду. Но при этом, если у этих пользователей набирается, ну представим себе что 20к запросов в сутки, мы говорим им пока. Но пользователь он допустим бабки еще кидает, то у него будет 10 запросов в секунду, но максимум 100к, а если кидает прям хорошо бабок, то и лимиты повыше.
И еще такой момент, к некоторым апи отдельные тротлеры привязаны, например у нас глобально — 10rps для пользователя, есть /api/a и есть /api/b где отдельный троттлер на 5rps, но всего у нас для пользователя 10rps. Ну то есть в некоторых случаях мы должны проверить аж три раза что пользователь может это сделать — глобально, в целом и частный случай.
Так вот, как это быстро сделать при помощи конфигов нжинса, когда есть пяток способов изменить стейт у пользователя?softaria
25.12.2019 14:18У нас было только два стейта и мы тупо вешали пользователю зашифрованную куку, по которой nginx определял его категорию.
Но, не факт, конечно, что такое решение подошло бы в вашем случае.ashofthedream
25.12.2019 14:28насколько мне известно, изначально примерно так и было настроено, что-то вроде реквест лимита и по куке определялось какой лимит у пользователя, но с появлением дополнительных требований, решили это перенести уже в код, а там и свое решение подтянулось
sentyaev
25.12.2019 15:16От знания алгоритмов и структур данных знания конкретного технологического стека магическим образом не прирастают.
Интересное мнение.
Я всегда считал, что знание технологического стека дело вторичное, если кандитат знает его то это идет в плюс, если не знает, ничего страшного, минусом я это не считаю.
Обычно на собеседовании задаю два вопроса:
- Вопрос про структуры данных, описываю исходные данные и необходимый результат. Основная идея вопроса посмотреть как кандидат будет работать с основными структурами данных. Например, что он будет делать если нужно будет сделать список из словаря, или из стека сделать очередь. Вариантов масса. И главное не правильность решения, а именно понять как он с ними работает.
- Второй вопрос на моделирование. Например я — руководитель компании, кандидат — разработчик. Я описываю бизнес компании, очень кратко задачу которую нужно решить и потом смотрю как кандитат подойдет к ее решению, какие вопросы будет задавать, что предложит реализовать сначала, что потом, какие вещи предложит не делать вовсе. Такое проектирование минут на 30-40.
А знание технологического стека считаю сомнительным, в смысле опираться на это при решении брать-не барать на работу. Ведь как отличить кто лучше — человек который просто знает стек и у него год-два опыта, или человек со знанием другого стека и с 10и летним опытом?
Я сам после 7 лет .NET, переходил на пару лет во фронтэнд и потом на python/django и большой разницы не заметил. Наибольшей проблемой было с Windows и тулов вокруг него перейти на Linux, но тут проблемой была просто привычка. Я даже не старался особо изучать Linux команды, просто читал маны по мере проявления задач и все.JustDont
25.12.2019 19:52Я всегда считал, что знание технологического стека дело вторичное, если кандитат знает его то это идет в плюс, если не знает, ничего страшного, минусом я это не считаю.
Смотря кто вам нужен. Если просто «толковый человек, а там разберется» — то одно. Если кто-то, кто за два дня войдет в курс дела и будет уже закрывать простые задачи, а через месяц будет шарить во всем проекте и сможет проектировать его дальше — то знание стека таки нужно, иначе «просто толковый человек» месяц будет только курить документацию и набивать базовые шишки, а правильно проектировать дальше — и вообще фиг знает когда сможет (сможет-то скорее всего быстро, но если напроектирует что-то не так, расплачиваться за это будет контора, а не он).sentyaev
26.12.2019 01:58У меня немного другой опыт, но я с вами по большому счету согласен. Сложно обсуждать некоего абстрактного кандидата. Да и я всего-то нанял человек 15 за все время, и только последних 5 по методу который описал. Да и ведь когда я говорю «кандидат разберется», я имею ввиду конкретного «Ивана Петрова», который придя на проект за день разобрался с Django'й, на второй задеплоил небольшой таск на прод, а через неделю уже делал код-ревью и мог понять питонячий тут стиль или нет.
JustDont
26.12.2019 10:11Ну да, есть еще такие штуки, как «близкий опыт», и тому подобное. Если человек всю жизнь (такие уже есть) писал на Typescript, то полагать, что он не сможет в Javascript — нет смысла. Сможет конечно. С другой стороны я на фронтэнде видел людей, которые как программисты хороши, но вот билд настроить и вебпак (или другой бандлер) поконфигурировать — им обязательно нужна помощь зала, потому что собственного опыта у них как-то вот не было совсем.
VolCh
26.12.2019 12:31С третьей стороны, я не думаю что умение настроить вебпак или другой бандлер с нуля необходимый навык для абстрактного современного фронтендера, даже для сеньора. На каких-то проектах это может быть обязательным даже для джуна, а на каких-то какой-нибудь create-react-app или nx всё автоматизирует под капотом.
JustDont
26.12.2019 16:02С четвертой стороны, я конечно не могу похвастаться огромным опытом, но еще ни разу не видел такого фронтэнда, где программистам не надо было бы быть чуточку девопсами. Create-react-app это лишь отправная точка, а потом всё равно какое-нибудь «доработать напильником» возникает.
VolCh
26.12.2019 16:15Есть проекты, где принципиально принято решение какой-нибудь сreate-react-app не реджектить, ни ревайерить и т. п. Ну и для каких-то редких случаев достаточно одного-двух человек в командеразработчиков, которые по совместительству будут чуточками девопсами.
CrocodileRed
25.12.2019 12:50Ответ не так однозначен. Хороший работник может получиться из кандидата, который ПОСЛЕ приема на работу освоит теорию и будет строить вам ваши деревья. То есть при собеседовании он может и ответить на специальные вопросы.
khim
25.12.2019 17:44Хороший работник может получиться из кандидата, который ПОСЛЕ приема на работу освоит теорию и будет строить вам ваши деревья.
Не может. Потому что они нигде не фигурируют как что-то явно упоминаемое.
На них могут ссылаться где-нибудь в документации, но вряд ли вам дадут Кормена после приёма на работу и скажут «изучай».
Обычно предволагается, чтобы вы это сделали уже один раз, давным-давно, во время обучения.
А вот фреймворки появляются всё время новые, тут ожидать что вы их точно знаете зачастую бессмысленно — особенно если у фирмы есть есть свои «фирменные» надстройки над ними.CrocodileRed
25.12.2019 17:47Ну так пусть фигурируют. У вас задача не схитрить, а получить человека в команду.
khim
25.12.2019 18:59Ну так пусть фигурируют.
Вы это сейчас… всерьёз? Предлагаете всей, ну вот просто всей компании буквально всё бросить и начать описывать базовые вещи из курсов Computer Science в коде и в документации ради того, чтобы получить ещё одного человека в команду?
У вас задача не схитрить, а получить человека в команду.
Нет, это не конечная задача. Конечная задача — получить более качественный (или хотя бы такой же) код быстрее.
Если для того, чтобы его можно было взять на работу, остальная команда должна будет тратить лишние 10 или 100 человеко-лет каждый год (да, у нас большая команда) на то, чтобы везде-везде, где это релевантно прописать то, что человек, разбирающийся в CS и так знает… — то нафиг нам такой человек нужен?CrocodileRed
25.12.2019 19:05Попробуйте не утрировать и взглянуть на вопрос здраво.
khim
25.12.2019 19:52Я и смотрю на вопрос здраво. Мне не нужен кандидат, который между ArrayList'ом и LinkedList'ом делает выбор на основании того, что ArrayList в алфавитном порядке первым стоит.
CrocodileRed
25.12.2019 19:56Это понятно. Но если он в течении первого дня разницу уразумеет и, соотв, начнет использовать их как следует? Ну разве это не хорошо?
khim
25.12.2019 20:22Нет. Потому что если человек — таки сеньор, то есть у него было несколько лет опыта — он про всё это так и не удосужился узнать, то он либо никогда не изучал Computer Science, либо изучил — но всё забыл.
В обоих случаях — доверять его решениям нельзя… а зачем нам нужен сеньор, решениям которого нельзя доверять?
Я ещё могу подобное простить джуну — чего-то недопонял, перепутал, ему никто не показывал ещё «как надо»… но сеньор — это, как бы, сложившийся специалист. И если он сложился в специалиста, которые понятия не имеет о сложности алгоритмов, кешах процессора и прочем… то нам… вот конкретно нам — он не нужен.
Кому-то, может быть, он и нужен — ну и отлично, там где всё это не нужно, я надеюсь, и о сортировках никто спрашивать не будет.
VolCh
26.12.2019 15:49А если он начнёт гуглить перед выбором различия? Вот ваши названия мною воспринимаются не как названия структур данных, а как названия классов в каком-то конкретном рантайме. И если я могу предположить, что под LinkedList где-то лежит связный список, то вот что такое ArrayList могу только гадать, выглядит на первый взгляд как гибрид бульдога с носорогом. есть массивы, есть списки, а массивосписки как-то в базовых структурах данных не припомню. Какой-то класс, реализующий какой-то асбстрактный интерфейс списка, но под капотом содержащий массив? Или наоборот, интерфейс массива, а под капотом список?
khim
26.12.2019 16:22Это Java. Да, представьте себе, там в стандартной библиотеке есть ArrayList. И да, в природе существуют программитсты, которые, когда им нужен List — выбирают ArrayList потому что он в документации первый в списке реализаций интерфейса (там перед ним ещё Collection и Set, но они не годятся — это тоже абстрактные интерфейсы, а не классы).
А чётакова? Предварительная же оптимизация — это ж корень всех зол, сам Кнут сказал! Потом в профайлере всё увидим.
И если я могу предположить, что под LinkedList где-то лежит связный список, то вот что такое ArrayList могу только гадать, выглядит на первый взгляд как гибрид бульдога с носорогом.
Это хорошо что вам это чудо тоже кажется диким. Это нормально. Но вот так вот Java устроена.
А если он начнёт гуглить перед выбором различия?
То это значит, что он врёт либо про то, что он сеньор, либо про то, что он с Java работал. Это стандартная библиотека — причём та её часть, которая ещё из прошлого века идёт. Можно немного поработать с Java джуниором и с ней не столкнуться, но избежать её и стать сеньором — вряд ли получится.
svr_91
26.12.2019 16:33О, вы та самая компания, которая знает, где LinkedList быстрее ArrayList-a? Расскажите пожалуйста. Мне кажется, с точки зрения явы там должно быть вообще все равно.
(Не все равно может быть разве только в случае занимаемой памяти, ArrayList может выделить сильно больше того, что необходимо)khim
26.12.2019 17:18Мне кажется, с точки зрения явы там должно быть вообще все равно.
Вам кажется? Или вы пробовали померить? Ну там взятьlistIteratorи начать этот список модифицировать? Добавляя/удаляя элементы в серединке?
И да, во многих случаях ArrayList будет быстрее — несмотря на то, что алгоритмы там получаются O(N?) вместо O(N) у LinkedList. Просто константа сильно меньше.
Но это вот нифига не значит, что нужно взять ArrayList и ждать пока профайлер чего-то там покажет. Потому что он не покажет. Более того — он так и будет показывать, что ArrayList быстрее. В ваших экспериментах.
А в проде — у вас сервера «ложиться» будут под нагрузкой. Более того: они могут продолжать «ложиться» даже притом, что даже на боевых данных профайлер будет показывать, что ArrayList быстрее!
Абстракции — текут. И кто-то должен с этими протечками что-то да делать.
Ну и? От кого вы ожидаете, что он устранит протечки? От сеньора или джуниора?
P.S. Кстати упомянутый вами факт, касающийся того, что если ArrayList, в какой-то момент, стал большим, то он по прежнему будет занимать кучу памяти даже если из него почти все элементы удалить — из той же оперы. Ещё одна «протечка» из абстракции, да.svr_91
26.12.2019 18:05Тоесть у вас есть реально подтвержденное поведение? Какой размер массива был? Какой тип вычислений? Я подозреваю, там еще может быть связано со сборщиком мусора, возможно удалять небольшие куски памяти ему проще, чем большие. Но было бы интересно получить этому подтверждение.
> Ну и? От кого вы ожидаете, что он устранит протечки? От сеньора или джуниора?
От любого наверно. То есть по вашему, синьер должен уметь устранять только протечки ArrayList-а? Никаких других протечек устранять он уметь больше не должен? Я о том, что не лучше ли выработать повторяемые методики поиска утечек, чем устранять эти самые утечки «методом тыка»?
Я вот в яве почти не работал, но в C++ я бы ни за что не догадался бы взять std::list в качестве коллекции. За 10 лет он мне потребовался всего один-единственный раз: когда нужно было гарантировать, что элементы, добавленные в список, никуда не денутся со своего места при любых манипуляциях с этим списком.khim
26.12.2019 19:07Тоесть у вас есть реально подтвержденное поведение? Какой размер массива был? Какой тип вычислений?
Вы сейчас притворятесь идиотом или правда не понимаете, что пишите чушь? Операция вставки элемента в 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 если он никому ни для чего не нужен?svr_91
26.12.2019 19:17От количества данных зависит конечно. Но вставка чегото «поближе к началу» это уже довольно странная операция на мой взгляд. Если вставлять совсем в начало, то есть ArrayDeque
khim
26.12.2019 19:46Да много чего есть. «Вставка вначало» — это, как правило, обработка типа «читаем строчки, иногда вместо одной вставляем две, а иногда, лишнее — удаляем». Ну или что-то более сложное (скажем ищем «парную строку» и удаляем сразу блок).
И вот эта «невинная» операция — может так «протечь», что мало не покажется. Ну скажем если у нас обычно обрабатывается сто-двести заказов в день, а раз в год, в ту же процедуру, вам сгружают что-то на миллион строк.
И вот тут так может получиться, что даже если на бенчмарках всё работает быстрее наArrayList— но лучше всё-такиLinkedList. Ибо тот вызов, который случается раз в год вам будет, по итогу, каждый год устраивать аврал, когда вся ваша конструкция будет «вставать раком» и watchdog будет вам ваш сервис прибивать.
Но если подумать — можно и сArrayList'ом обойтись. Скажем если «перекачивать» данные из одного такого в другой (и добавлять всегда в конец). Но для этого нужно знать, что добавление в конец вArrayList— быстрое, а в другие места — медленное.
А для этого, прежде всего, нужно понимать чем отличаетсяArrayListотLinkedListи какие в них есть подводные камни.
P.S. Кстати хорошие синьоры часто пишутArrayList(как вы верно заметили — он бывает полезнее в реальности), но говорят (голосом) «я сейчас всё допишу и посмотрю — не стоит ли тутLinkedListиспользовать». Это принимается… как приглашение обсудить всё это, когда код будет написан.svr_91
26.12.2019 20:34Для удаления в том же c++ существуют идиомы erase-remove. Для вставки тоже наверно можно чтото придумать. По моему, «портить» код LinkedList-ом только для того, чтобы чтото откудато удалить, это нехорошо. Лучше использовать другой подход
Зависит конечно от частоты операций. Но я например не представляю, как делать предложенные Вами операции «по одиночке». То есть, как я понимаю, эти операции выполняются сразу пачкой, например «удалить все дубликаты строк». Тогда идиомой erase-remove это решается эффективнее, чем листами. А если нужно удалять по одному элементу… То как еще найти этот элемент? То есть представьте, что Вам нужно что-то удалить из середины списка. Но для этого же до этой середины еще нужно както дойти в случае листа. Получается тот самый «квадрат» (точнее линейный поиск в случае одного запроса), которого Вы так боялисьkhim
26.12.2019 21:29Получается тот самый «квадрат» (точнее линейный поиск в случае одного запроса), которого Вы так боялись
Если вы каждый раз проходите с начала — да. Но если вы обрабатываете элементы последовательно (то есть найдя один «нужный» элемент ищите другие в остатке, а не сканируя список с начала) — нет.
И да, конечно, работа сArrayList/LinkedList— это где-то близко к вершине айсберга… но если вы не знаете даже этого, то каков шанс, что вы не запутаетесь в дебрях этого айсберга.svr_91
27.12.2019 08:54Ну тогда получается, что это «потоковый» алгоритм, который проходит сразу все элементы. Тогда думаю, будет лучше использовать аналоги идиомы erase/remove. Или, как Вы сами предложили, перекладывать элементы в другой массив.
> И да, конечно, работа с ArrayList/LinkedList — это где-то близко к вершине айсберга… но если вы не знаете даже этого, то каков шанс, что вы не запутаетесь в дебрях этого айсберга.
Ага, это я понимаю. просто думал, у Вас есть какойто интересный пример работы с LinkedList
VolCh
27.12.2019 07:37То это значит, что он врёт либо про то, что он сеньор, либо про то, что он с Java работал.
А если не врёт? Если он сеньор, с Java работал, но всего лишь месяц. Рекрутеры уговорили прийти на собеседование, потому что они решили, что подходящий кандидат, потому что где-то в резюме слово Java встретилось.
DrunkBear
27.12.2019 11:20Меня так звали 1с8 разрабатывать, сеньором, из-за того, что среди прочего в резюме была строка «поддержка интеграции с 1с».
Даже собеседование с тестами прошёл (интернет — сила!), правда, потом представил себе, что придётся и дальше писать на ломаном русском ежедневно — извинился и ушёл.
khim
28.12.2019 21:12Если он сеньор, с Java работал, но всего лишь месяц.
Но тогда у него об этом в резюме будет написано.
Рекрутеры уговорили прийти на собеседование, потому что они решили, что подходящий кандидат, потому что где-то в резюме слово Java встретилось.
Ну он и может быть подходящим кандидатом — просто спрашивать его тогда нужно будет не про Java…VolCh
28.12.2019 13:10Но тогда у него об этом в резюме будет написано.
Не факт, будет, например, написано 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
martin_wanderer
24.12.2019 12:47Статья «прекрасна»: утверждение, что профессиональному программисту не нужно уметь написать алгоритм сортировки, «доказывается» через недоказанное утверждение, что профессиональному музыканту не нужно уметь играть гаммы. И это несмотря на то, что как правило, и правда не надо. С другой стороны, если это правда Senior, он знает алгоритм сортировки слиянием. А, зная алгоритм, не проблема его и с нуля накодить.
adictive_max
24.12.2019 13:08Тут как бы вся статья о том, что «не надо учить» и «не надо уметь» — это две большие разницы.
smarthomeblog
24.12.2019 13:24+1Вы пишите на русском языке без ошибок. А сможете слету рассказать правила правописания и синтаксиса, изучаемые в школе? Или пару теорем доказать? Вот так и гаммами. Думаю, что если виртуозного музыканта попросят сыграть гамму на собеседовании, он просто развернется и уйдет.
dididididi
24.12.2019 13:41В каких случаях пишется разделительный мягкий знак?))
DrSavinkov
24.12.2019 14:10В тех случаях, когда он должен быть написан согласно правилам языка.
softaria
25.12.2019 11:15И еще в тех, когда он не должен быть написан согласно правилам языка, но пишущий не знает правил, либо сознательно их игнорирует.
martin_wanderer
24.12.2019 17:11Об этом и был мой комментарий: в статье, как и в Вашем комментарии приводятся аналогии, совсем не факт, что корректные. Допустим, вы правы про виртуоза ( я вот не виртуоз и не знаком ни с одним, так что не берусь за них судить). Так вот как это соотносится с программистом?
Того, что, на мой взгляд, в профессиональной деятельности и правда не надо кодить алгоритмы сортировки и вовсе никто не заметил. А может за это и минусы? :-[ ]
P.S. «Вы пишите на русском языке без ошибок» — я стараюсь, но после Вашей просьбы буду стараться еще большеsmarthomeblog
24.12.2019 17:35-1Насчет русского языка — это была не просьба, а утверждение :)
kontnoor
24.12.2019 18:05тогда в слове «пишите» есть одна ошибка
Mishiko
24.12.2019 14:41+5зная алгоритм, не проблема его и с нуля накодить
— нормальный senior не станет кодить с нуля, а вкрячит библиотечный метод или фреймворк который все это делает, тем он и отличается от junior-а.
утверждение, что профессиональному программисту не нужно уметь написать алгоритм сортировки
— я увидел в статье иной посыл: есть навыки на «кончиках пальцев» и сортировка к ним не относится. Нужно иметь знания о ней, но кодить ее по алгоритму это не нормально, когда есть 100500 библиотечных методов занимающихся этим. Адекватный вопрос для соискателя на должность senior — какие есть методы сортировки в стандартных библиотеках и какие алгоритмы сортировки они реализуют, ну и что вы примените для сортировки… чего то там типичного, заодно проверить понимание equls, hashCodeashofthedream
24.12.2019 15:01+1— нормальный senior не станет кодить с нуля, а вкрячит библиотечный метод или фреймворк который все это делает, тем он и отличается от junior-а.
Вот так и появляются сеньоры, которые не способны сами написать и 10 строчек кода, а если дело касается не стандартного флот — достал из базы, поменял пару значений, перевернул в другой объект, кинул дальше — то код получается на уровне того, что пишут джуты-самоучки.
Занимательный факт, большинство людей, которые считают, что не нужно ничего знать самому, нужно только взять библиотеку и впихнуть, работают с этим стандартным флоу и считают, что остальные области не существуют как факт. А все то, чем они пользуются пишет какой-то мегамозг, потому что ему больше нечем занятьсяA114n
24.12.2019 16:32+1Я надеюсь, что сами вы пишете только на ассемблере, причём сразу в машинных кодах.
Всё прочее было бы просто возмутительно с точки зрения вашего подхода.ashofthedream
24.12.2019 16:33-3И не надейся
A114n
24.12.2019 16:39+2В небольшом городке прихожане после воскресной проповеди подошли к священнику. Один из них набрался храбрости и задал вопрос, вертевшийся на языке у всех: «Вы призываете к скромности и бескорыстию — а ваш дом самый богатый в городе. Вы проповедуете умеренность и воздержание — и неоднократно выходите навеселе из трактира. Вы восхваляете смирение плоти — но много раз вас замечали выходящим из дома весёлых девиц. Как всё это совместить ?».
Священник ответил: «Дети мои, всё очень просто — делайте то, что я говорю, но не делайте того, что я делаю».
khim
24.12.2019 17:37Зачем же на ассмеблере-то писать? Для генерации ассеблера есть компиляторы. Но да, за ними иногда присматривать нужно.
Такой вот пример:
Казолось бы: не должно быть никакой разницы? Ан нет — вторая функция заметно быстрее… и понятно почему.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, значит скорость меня не слишком волнует по определению… но уметь это делать и, главное, делать в случаях, когда это полезно… таки нужно.SergeyMax
24.12.2019 23:53и понятно почему
Просто повезло, что у этого процессора есть XCHG/BSWAP.khim
25.12.2019 00:09Дык вопрос же не в этом, а в том — умеет ли компилятор это выражение «свернуть». Инструкции-то есть на всех распросранённых архитектурах: MIPS, ARM, POWER… вот только если использовать сложение — то это только clang умеет… а битовые операции — гораздо больше компиляторов «сворачивают».
0xd34df00d
25.12.2019 02:52big_indianпросто получилось или таки с намеком?khim
25.12.2019 03:42Где-то посередине. То есть с одной стороны — это «слегка индусский» код. С другой — в большинстве случаев оно работает-то нормально.
Напрашивается идея: использоватьhtonl… но MSVC в это случае… вызоветhtonl!
Впрочем другие компиляторы htonl нормально отрабатывают… и можно надеяться, что когда-нибудь… в светлом будущем… и MSVC поправят, так что — да замечание про то, что лучше бы использоватьhtonlтоже будет неплохим… но идеальным, конечно, будет напоминание про _loadbe_i32 — которое работает с MSVC, но… не работает с GCC.
P.S. Вообще же удивительно — сколько всякого интересного можно получить из кандидата при обсуждении даже такой, казалось бы, вполне тривиальной задачи. Ну вот такой язык C++ — куда ни глянь, всюду овраги, буераки да капканы…
nikbond
25.12.2019 11:26А что вообще делает эта функция? Что означают все эти интереснейшие вычисления?
И является ли именно эта функция узким местом, которое надо оптимизировать? Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?khim
25.12.2019 18:15Или, может, вместо индусских иероглифов стоило бы написать человекочитаемую функцию, с человекочитаемыеми именами из предметной области, и т.д?
Вообще-то в имени функции был намёк.
И является ли именно эта функция узким местом, которое надо оптимизировать?
С большой вероятностью. Если бы вы обратили на дальнейшую дискуссию, то заметили бы флажок компилятору -mmovbe. То есть это AMD и Intel не поленились и ради этой функции аж специальную инструкцию замутили — в добавление к той, что всегда была.
А что вообще делает эта функция? Что означают все эти интереснейшие вычисления?
А это — уже вопрос к интервьюируемому, разве нет?
DrGluck07
25.12.2019 18:30Очевидно делает преобразование из одного endian в другой endian. Я тут сразу вижу намёк на код на каком-то микроконтроллере, может даже на xmega или типа того (судя по ссылке всё-таки нет).
Иногда приходится задумываться даже о таких вещах. Например мы буквально сегодня задвинули в мастер рабочую версию бутлоадера для нашей железяки на микроконтроллере xmega128. Проблема была в том, что нужен был USB-стек, но он с трудом влезал в 8К памяти. Мне пришлось весьма сильно помочь молодому программисту с экономией памяти. Выгадывали буквально по 10 байт за раз. Программа, естественно, на голом С, ибо С++ туда ну совсем никак не лез. В итоге получилось 7800 байт, но был момент, когда программа весила 9000+. Наверное странно в 2019 году читать о нехватке памяти размером 8 килобайт. Вот таков он, суровый мир железячного программирования.khim
25.12.2019 19:03У нас другая сторона той же медали. Никаких микроконтроллеров, у нас очень «большое» (и дорогое) железо.
Но когда речь заходит о десятках миллионов запросов в секунду… такие мелочи начинают играть роль.
Да, разумеется, не весь код у нас так написан — есть даже и вспомогательные сервисы на Python, обращение к которым происходит раз в сутки… но вот есть и такое вот… и да — нам нужны люди, понимающие как такие вещи пишутся, в том числе. Особенно если они сеньоры.
P.S. Кстати не первый раз замечаю что наши проблемы — очень близки проблемам эмбеддеров. А разгадка простая — даже если у вас железо очень суровое и памяти «дофига» и ядер и всего-всего «дофига»… добавьте туда миллион запросов… и, вдруг, на один запрос — у вас ресусов ну вот ни разу не дофига… а почти столько, сколько в микроконтроллерах.DrGluck07
25.12.2019 21:55Я когда-то начинал ещё на Спектруме, снимал защиты с Bill Gilbert и Co, делал читы для игр, затем делал демо. В итоге многие приёмы мне потом пригодились на контроллерах и DSP. Когда памяти и герцев мало, а нужно что-то делать 100 000 раз в секунду. Или отладка с помощью одного светодиода, потому что JTAG не предусмотрен.
stilic
24.12.2019 15:36+4С другой стороны, если это правда Senior, он знает алгоритм сортировки слиянием
Он забыл уже. Это для его работы и не важно.
Зато сеньор делает то, то много полезнее для решения прикладных задач на фирме — корректно архитектуру проектирует.
А алгоритмы сортировки — это те знания, которыми может похвастать джун, который еще не умеет грамотно архитектурные вещи делать.
Знания сеньора — это знания как использовать и как сопрячь готовые компоненты, какие у них ограничения, когда лучше сделать так, а когда лучше сделать эдак.
Сеньор, что пишет алгорим сортировки самостоятельно… гм. Ну разве что чтобы отвлечься от рутины. Если понадобится что-то вычурное, то полагаю, сеньор знает о существовании тома третьего «Сортировка и поиск» книги Дональда Кнута «Искусство программирования»
tendium
24.12.2019 13:00+3Я обычно стараюсь расспрашивать человека в соответствии с его резюме. Ибо если мы отреагировали на него, то значит опыт человека для нас был релевантным. В зависимости от заявленного уровня компетенции кандидата, ставлю вопросы соответствующей сложности. Очень часто при этом всплывает, что в резюме пишутся вещи до кучи (ну типа слышал, что в конторе это используется, ну и написал, что есть опыт).
Недавно искали архитектора на новый проект (хотя архитектор там это было громко сказано), и одного кандидата уже до меня отсобеседовал мой начальник. И, мол, хороший кандидат, скорее всего возьмем его. Надо сказать, что начальник любитель прогонять кандидатов по классическим абстрактным задачкам, но при этом редко проверяет релевантный для нас опыт. Но т.к. работать кандидат должен был в перспективе со мной, то я с ним хотел провести просто дружескую встречу, на которой хотел лишь задать пару ключевых вопросов в неформальной обстановке. Но, увы, ответы на них оказались неубедительными. Тогда я пробил человека по ключевым позициям его резюме. И, увы, он везде плавал. Кандидат не был абсолютно слабым, но явно не имел достаточно опыта, чтобы предлагать архитектуру с нуля. Место мы ему предложили, но на ступень ниже. Увы, его амбиции были на ином уровне, и он отказался.
Так вот к чему я это… На олимпиадные задачки можно достаточно быстро натаскаться, а вот практический опыт нарабатывается только временем и трудом.
li4inka
24.12.2019 17:51+2Плюс ко всему синапсы человеческого мозга образуются случайно, можно годами усилено что-то зубрить или решать, а в долгосрочную память отложится, например, долгожданная встреча с друзьями. Человеческое мышление это не просто передача сложнозакодированного с помощью комбинаций из 25ти медиаторов сигнала. Все запоминание и мышление является морфогенетическим процессом. Те самые синапсы всю жизнь образуются и разрываются. Если вы хотите что-то запомнить навсегда необходимо перевести тот или иной процесс или информацию в синаптическую связь; а если гонять по старой связи как перед экзаменами или собеседованиями, то такая информация быстро забывается. То есть нужно время, чтобы образовались синапсы, а они в свою очередь образуются с конечной скоростью. Если верить книгам, то каждый день один нейрон образует по 2-3 синапса и столько же разрывает.
Практический опыт практическому опыту рознь, все дело в том, что тот или иной человек запоминает, и это происходит вне зависимости от него самого, синапсы образуются случайно. То есть наше запоминание это образование связей, по которым бегает сигнал и если мозг отключается больше, чем на 5-6 минут (при травме например), начинается разрыв этих самых связей и человек не может вспомнить как его зовут. Следовательно, образование новых связей и есть решение тех или иных задач. Бывает ломаешь голову над задачей, спустя какое-то время приходит решение, надо было лишь понять. Так вот это самое «лишь понять» это когда образуются новые связи. И связывают они между собой настолько отдаленные участки мозга, в которых хранится настолько разная и далекая информация (зрительные образы, слуховые, двигательно-моторные), что происходит это самое понимание. Но просто так это понимание не придет, нужно жить с некоторой мыслью какое-то время, чтобы дождаться образования новых синаптических связей и таким образом запустить механизм синтеза и увидеть, например, новую закономерность так, где вы ее не видели. Весь вопрос как долго человек может жить с той или иной мыслью, да и нужна ли она вообще…
smarthomeblog
24.12.2019 13:19По мне так удачное прохождение веселых задачек на онлайн ресурсах типа Codility или Codesignal гарантируют только одно — человек умеет решать веселые задачки. Если в это состоит бизнес компании, то такой подход оправдывает себя. Если нет, то это ИМХО потеря времени как соискателем, так и работодателем. Более резонно дать какую-то задачу из тех, что реально решаются в компании. Причем если мы говорим о сеньерах, задачи тут нужны абстрактые — кодить сеньер умеет полюбому :)
WraithOW
24.12.2019 14:01кодить сеньер умеет полюбому
Одна только проблема — нужно сначала убедиться, что на собеседование пришел реальный синьор.BiW
24.12.2019 14:10Проблема в том, что, я так подозреваю, знание наизусть алгоритмов сортировки не является точным индикатором сеньора.
ashofthedream
24.12.2019 15:09Почему-то многие считают, что алгоритмы это что-то такое непоколебимое и не подвержено изменению, но в какой-то момент эти люди узнают, что на основе многих современных алгоритмов можно решать очень эффективно вполне реальные бизнес задачи.
khim
24.12.2019 16:45+6А кто вам сказал, что от вас, блин, ожидается «знание наизусть» чего бы-то там ни было? Почему, блин, автор так зациклился на том, что он чего-то там не может вспомнить?
Не можешь вспомнить — выведи. Забыл как переменные в том алгоритме, который вам показали 20 лет назад на доске показали, назывались — дай им другое название.
Блин, почему все утверждают, что «реальную» практическую задачу они решат, а сортировку — ну никак не смогут написать? А они, вообще, пробовали? Или они, на самом деле, кода какого-либо уже лет пять не писали? Так тогда они и не «синьоры» никакие, нафиг они на эту позицию идут? PM — может быть, но никак не TLM…
Если воспринимать ту же сортировку слиянием как реальную задачу — то любой сеньор должен её мочь придумать. Не вспомнить. Не «выстрелить» решение, которое он когда-то заучил наизусть, как стих. А придумать. Что тут сложного и ужасного?
Ну блин, он про эту сортировку знает куда больше, чем про реальное задание, которое ему может достаться — что может ему помешать «сложить кубики», чтобы сделать работающее решение? Он уже не помнит как работаетfor? Илиif?
Как раз если вы помните всё это — то да, написание сортировки ничего не даст. Как меня на собеседовании пропросили написать сортировку «кучей», но остановили, когда я нарисовал дерево этой самой кучи… потому что по нему видно было, что проблем не будет — задали сразу другой вопрос.
Да, представьте себе, если вы не собеседовании не помните как устроена сортировка слиянием — это не просто хорошо, это отлично. Прекрасный шанс посмотреть как бы будете решать практическую задачу… да, конкретно для вас в этот момент она становится практической… и её можно обсуждать именно в таком ракусе.ashofthedream
24.12.2019 16:54Я уверен на больше чем сто процентов, что если человек, начнет ее придумывать, по остаткам воспоминаний о ней и будет это озвучивать, то встречными вопросами и подсказками вместе с интервьювером они придут к этому алгоритму и это будет засчитан как нехилый такой плюс.
zim32
24.12.2019 16:59+5Одно дело налить чайку, покурить и спокойно вспомнить. Другое дело что надо вспомнить когда в углу тикает таймер. И ты понимаешь что у тебя впереди еще две задачи висят. У меня лично ступор. Что показывает этот тест на время? По-моему ничего. Мне что каждый день на работе необходимо будет вспоминать на время какие-то алгоритмы? Кто это вообще придумал. Кто вообще в здравом уме может держать в голове пару популярных фреймворков на изусть, пару баз данных, пару облачных сервисов, докеры, кубернейтсы, фронтэнд, бэкэнд. А тут сортиовка слиянием на время. Вы прикалываетесь? Может еще красно черное дерево повернуть или нейронную сеть накидать с нуля за 20 минут?
khim
24.12.2019 17:20-1Другое дело что надо вспомнить когда в углу тикает таймер.
А что — в реальной работе «таймер» никогда не тикает? Никогда ничего не делается «к демонстрации» или «к конференции»? Ну… вы счастливый человек… может быть и найдёте работу, где такого никогда не случается… но не у наc.
Мне что каждый день на работе необходимо будет вспоминать на время какие-то алгоритмы?
Опять, блин, это слово у вас. Нет — вспоминать не нужно. Нужно решать задачи. И да — часто на время, к определённому сроку и нет — никто не будет вам из-за этого давать «карт-бланш» и разрешать «задивать» код, который даже вы сами не понимаете как работает.
А тут сортиовка слиянием на время. Вы прикалываетесь? Может еще красно черное дерево повернуть или нейронную сеть накидать с нуля за 20 минут?
А почему бы и нет, собственно? Кто вам может помешать? Задачи простые, уточняющие вопросы вам никто задавать не запрещает… в чём проблема-то?
Ещё раз повторю: никто не требует от вас заучивать те же красно-чёрные деревья, как учат наизусть стихи — наизусть. И даже если вы перепутаете роль красных вершин и чёрных в том самом красно-чёрном дереве… я не обижусь… да, блин, если даже вы вместо красно-чёрного дерева соорудите AVL-дерево… я думаю тоже сойдёт.
Мне всего-навсего нужно увидеть как вы решаете задачи и пишите код… задача, которую вы, плюс-минус приблизительно, помните — идеальна, так как сокращает время на её формулировку, вот и всё.
P.S. Про нейронку, впрочем, я бы стал спрашивать только если бы у человека что-то было в резюме, с ними связанное. Можно проработать довольно долгое время и никогда, ни разу, с нейросетями в принципе не столкнуться — несмотря на весь хайп вокруг них. Но если вы говорите, что вы с ними работали… тогда да, конечно.adictive_max
25.12.2019 02:29Никогда ничего не делается «к демонстрации» или «к конференции»?
К демонстрации или конференции, особенно если нет времени, всё делается по принципу «фигак, фигак, и в продакшен». Там никто не упарывается по алгоритмами и оптимизации, от кода требуется только чтобы он запустился и хоть как-то отработал пару часов.
balexa
24.12.2019 17:21+1Смотря сколько у вас есть времени. Обычно на собеседование выделяется час-два. Сколько вы из этого времени будете писать сортировку? Потом тесты к ней, потом поправить, потом оптимизировать по памяти. Ну напишет человек сортировку. А дальше что? Времени ни на что другое не останется уже. А так-то да, задача ничем не хуже других. Другое дело что подобные задачи на собеседовании вообще спорный вопрос.
А с другой стороны — тестовые задания тоже делать никто не хочет, а брать человека на должность Senior SE и не проверить как он пишет код — тоже нельзя.khim
24.12.2019 17:44+1Сколько вы из этого времени будете писать сортировку?
Минут 20, я думаю.
Ну напишет человек сортировку. А дальше что? Времени ни на что другое не останется уже.
Ну и отлично. Я напишу как кандидат умеет писать код, кто-то другой — поговорит с ним на тему того, как проектировать сложные системы, ещё кто-то — как налаживать работу команды.
Почему вы считаете, что один интервьюер должен с одного интервью о кандидате узнать прям сразу всё?
Другое дело что подобные задачи на собеседовании вообще спорный вопрос.
Нет, практика показывает, что это необходимый вопрос — если вы хотите нанять «синьора», который ещё и код писать может.
А с другой стороны — тестовые задания тоже делать никто не хочет, а брать человека на должность Senior SE и не проверить как он пишет код — тоже нельзя.
Ну вот отсюда и растут эти задачи.
Они не проверяют (и не должны проверять!) вашу память. Они проверяют — умеете ли вы писать код.
P.S. Впрочем обычно всё-таки рекомендуется давать что-то «по мотивам»: задачу примерно такого же уровня сложности, но вот уж не совсем такую, чтобы человек её когда-то на доске видел. Но это, в общем, только чтобы психологически меньше на человека давило.balexa
24.12.2019 18:17+3Минут 20, я думаю.
Кто-то напишет ее скажем за 40. Ну бывает, затупил человек, сразу не увидел косяк, начал переделывать. Значит ли это что второй кандидат хуже, менее опытен, менее сеньорен? Нет конечно, не значит ничего.
И вот тут то и вылезает проблема. Скорее всего, это собеседование первое, вообще по скайпу. На все собеседование выделяется час, из которых минут 15 вначале говорят за жизнь и про «расскажите случай, когда у вас были личные проблемы с коллегами на прошлой работе и как вы их решили» (привет Амазону).
В итоге второй человек может быть реально очень сеньорным чуваком, но вы (ну лично Вы возможно нет, а кто-то другой — да) в своей хайринговойсистеме напишете «все собеседование писал merge-sort, в процессе написания допускал ошибки, поправлял их после указания, написал не самое оптимальное по памяти решение».
Всё, после этого скорее всего другой интервьюер ничего не узнает, потому что на следующий этап чувака уже не позовут. Вот в чем проблема. В том, что такие задачи используются как первый (и поэтому единственный критерий)
Собственно если вам нужен именно Senior-чувак, а не олимпиадник — то проводить отбор по критерию где лучше справится олимпиадник странно. Вот в чем весь смысл моего пассажа.
Нет, практика показывает, что это необходимый вопрос — если вы хотите нанять «синьора», который ещё и код писать может.
Они не проверяют (и не должны проверять!) вашу память. Они проверяют — умеете ли вы писать код.
Я с этим и не спорю. Да, это само собой очевидно. Другое дело, что на мой взгляд именно сортировка — вариант весьма хреновый, если вам нужен именно человек с опытом, а не вчерашний олимпиадник. Для скайп-скрининга она слишком долгая, многие вещи не проверяет, а если у вас техническое собеседование на 6 часов — ну там можно и поинтереснее чего придумать, имхо.
Но это, в общем, только чтобы психологически меньше на человека давило.
В том числе. В целом, на мой взгляд, есть большой шанс что человек именно впадет в ступор и будет пытаться вспомнить, вместо того чтобы вывести самому. Ну или оскорбится. Мозг это не идеальная логическая машина, увы.
С критикой закончили, а теперь конструктив. Мне больше импонирует вариант для Senior-чуваков давать мелкую тестовую программку. Например написать программку для скачаивания файлов по списку урлов (аналог wget -i) за тот же самый час-два, с использованием любых библиотек. Или написать считалку слов в файле. И тут опыт и сеньорность очень хорошо видна — от того, как человек обрабатывает исключения и что дает на выход — готовую программу с -h флагом, какими-то простенькими тестами и скриптом сборки с готовым бинарником на выходе или у него какой-то франкенштейн который надо настраивать в IDE и который падает при любом случае, отличном от идеальных условий.khim
24.12.2019 19:54Всё, после этого скорее всего другой интервьюер ничего не узнает, потому что на следующий этап чувака уже не позовут. Вот в чем проблема.
А где вы видите проблему? Кандидат спокойно пойдёт на другое интервью в другой фирме — и там уже всё будет хорошо. Если это была случайность. А мы возьмём на работу кого-то ещё. Не вижу трагедии.
Вы так рассуждаете, как будто «проваленное» интервью — это прям конец, всё, катастрофа.
В том, что такие задачи используются как первый (и поэтому единственный критерий)
Это нормально. Так как наша задача — не забрать всех способных кандидатов, а максимально снизить вероятность того, что на работу возьмут человека, который не справится с задачами.
В других фирмах требования могут быть иными, никто ж не спорит…
Собственно если вам нужен именно Senior-чувак, а не олимпиадник — то проводить отбор по критерию где лучше справится олимпиадник странно.
Ещё раз: «Senor-чувак» — это всё равно, в первую очередь, человек умеющий писать код. И, как вы верно заметили, олимпиадники такими задачками отсеиваются плохо, а сеньоры, незаметно для себя, переставшие быть программистами и ставшие менеджерами и алминистраторами — хорошо… так что как раз для них — эти задачки и хороши.
Для скайп-скрининга она слишком долгая, многие вещи не проверяет
Ну дыг для этого есть уже основное интервью с личным общением…
Ваше же предложение обладает одним, но очень существенным недостатком: написание таких утилит ещё хуже вкладывается в то самое пресловутое Skype-интервью, чем написание сортировки. А давать это как домашнее задание… ну если вы индусов, которые чужое решение будут предалагать не видели — то это ваше счастье.balexa
25.12.2019 09:52+1А где вы видите проблему? Кандидат спокойно пойдёт на другое интервью в другой фирме
Нет никакой проблемы. Все так. Просто мы возращаемся к тому, откуда пришли — сеньор не способный вспомнить алгоритм внешней сортировки/КЧ/trie/etc (именно вспомнить, за 20 минут написать не помня хорошо детали алгоритма и не заглядывая в гугл — весьма сложно. И я не про названия переменных, чего вы к названиям прицепились) — не сеньор по вашей классификации. И в вашей фирме не нужен. А вчерашний студент — сеньор. Я ни в коем случае не критикую, дело ваше, ради бога. Просто напомню, что это несоответствие в логике и есть основная причина появления этой статьи и статей подобного рода
написание таких утилит ещё хуже вкладывается в то самое пресловутое Skype-интервью, чем написание сортировки.
Скайп-интервью — это как фильтр Блума. Там задача отсеять совсем неадекватов. Кодинга там нет вообще, бесполезно проверять как человек пишет код по скайпу. Кодить надо либо в офисе на расширенном интервью, либо дома. И желательно в одиночку.
Ваше же предложение обладает одним, но очень существенным недостатком:
Ну да. Как я уже говорил, на скайпе/телефоне кодинга нет.
Зато оно обладает другими, и очень существенными достоинствами — демонстрирует скилл «доведения до конца», демонстрирует навык создания расширябельной архитектуры и самое главное — очень хорошо укладывается в то как работаем мы в рабочем режиме — взять задачу, сесть за компьютер, через какое-то время отдать результат.
В других фирмах, где требования иные (например где прибегает менеджер и надо под пристальным взглядом срочно писать алгоритм к демонстрации и конференции не пользуясь гуглом) — вариант с сортировкой отсеивает лучше, безусловно.
ну если вы индусов, которые чужое решение будут предалагать не видели — то это ваше счастье.
Это выясняется элементарно же. На ревью кода спросите как добавить какую-нибудь фичу в проект.
PS: я в своем альма-матер у студентов лабы по программированию принимал.khim
25.12.2019 18:27именно вспомнить, за 20 минут написать не помня хорошо детали алгоритма и не заглядывая в гугл — весьма сложно
Если вспомнить, то это не 20 минут будет, а 5. Нет — речь идёт именно о том, чтобы написать.
Кодинга там нет вообще, бесполезно проверять как человек пишет код по скайпу.
Это, как бы, ваше мнение. У нас в компании считают иначе. Так что в добавление к Skype шарится ещё и Google Doc — и да, там смотрится как этот код появляется. И мы не одни такие.
Этот самый код, собственно, и является основным результатом собеседования — замечания интервьюера к нему… вещь немного вторичная.
Как я уже говорил, на скайпе/телефоне кодинга нет.
И, как я говорил, именно и в первую очередь там кодинг там и есть.
Это выясняется элементарно же. На ревью кода спросите как добавить какую-нибудь фичу в проект.
Да, но к этому моменты деньги на билеты и гостиницу уже потрачены, несколько часов специалистов заняты… куча затрат, которых можно элементарно избежать — просто посмотрев как человек пишет код.
В других фирмах, где требования иные (например где прибегает менеджер и надо под пристальным взглядом срочно писать алгоритм к демонстрации и конференции не пользуясь гуглом) — вариант с сортировкой отсеивает лучше, безусловно.
Ну зачем же менеджера тут привлекать? Код-ревью делают другие инжинеры. И на их замечания нужно как-то реагировать. Ровно эта деятельность в подобном кодинге и проверяется.
Да, ситуация немного пожёще, чем в реальной работе, ну так и задача — на порядок, а то и на несколько, проще.kalombo
26.12.2019 14:43+1khim, вы тут полсотни комментариев написали, но я так и не увидел четкой вашей позиции по поводу статьи(может быть просто пропустил, не заметил). А вопрос то простой на самом деле. Вы либо не признаете статью и говорите, что написание сортировок дает очень высокие шансы(например, 90%) выявить сеньора и поэтому в вашей фирме такие собеседования и вы считаете их идеальными. Либо вы соглашаетесь со статьей и говорите, что да, такие собеседования могут отсеять высокий процент(например, 50%) стоящих кандидатов-сеньоров, но вам важнее нанять нормального сеньора, нежели ошибиться с выбором, если вы будете проводить собеседования другого типа. В этом случае вы признаете проблему поднятую в статье.
khim
26.12.2019 16:43Моя позиция простая и её тут многие увидели — странно, что вам она оказалась незаметна.
Умение писать код (и, соотвественно, умение решать простенькие алгоритмические задачки) — это неотъемлемая часть понятия «Software Engineer».
Не знаю — что там с музыкатами-виртуозами и гаммами, не спец, не знаю. Но в случае с программистами — я регулярно встречаю «сеньоров», которые реально код давно не пишут, а «руководят его написанием».
То есть аналогия тут не с «профессиональным музыкантом, не раз блестяще выступавшем на сцене», а, скорее, c «профессиональным музыкантом, не раз блестяще выступавшем на сцене… однако возможно последний раз — лет десять назад» (а после этого занимавщийся в основном организацией концертов для своего оркестра).
И вот если бы расклад был с музыкантами именно таким, как с программистами — я бы обязательно прогонял их через «гаммы».
А поскольку ситуация с «горе-сеньорами» — именно такова, то да, у нас все интервью начинаются с написания простенькой программы какой-нибудь (обычно всё-таки не совсем из учебника, но что-нибудь связанное с ним и несложное). Ну чтобы понять — код-то соискатель в принципе писать умеет или нет?
А уже потом, когда мы выяснили, что перед нами программист (Software Engineer) — можно выяснять, какого класса он программист: джуниор там или сеньор.
michael_vostrikov
24.12.2019 20:17Если воспринимать ту же сортировку слиянием как реальную задачу
То любой программист сначала поищет доступную информацию.
michael_vostrikov
24.12.2019 20:27+3Если воспринимать ту же сортировку слиянием как реальную задачу — то любой сеньор должен её мочь придумать. Не вспомнить. Не «выстрелить» решение, которое он когда-то заучил наизусть, как стих. А придумать.
Mergesort появилась в 1945 году, quicksort в 1960, а timsort в 2002. Лучшие ученые по компьютерным наукам не могли придумать quicksort 15 лет, до timsort за 42 года никто не догадался, почему вдруг обычный человек должен уметь это сделать за полчаса во время собеседования?
khim
24.12.2019 22:01-1А то, что для изобретения нуля, отрицательных, а затем и комплексных чисел потребовались столетия — вас не смущает? Всё теперь, вычесть из двух три мы не можем — это ж столетия математических знаний нужно осваивать? Некоторые вещи, которые озобретались десятилетия или даже столетия являются, тем не менее, тривиальными… в нашей «системе координат» — просто они опираются на другие вещи, про которые ранее люди не знали.
Mergesort появилась в 1945 году, quicksort в 1960, а timsort в 2002.
Однако основная идея первого и второго — занимает по паре строк, а вот третьего — страница, а то и две, текста. Потому первые два легко можно написать во время собеседования, а вот timsort — я бы на собеседовании не давал.
Лучшие ученые по компьютерным наукам не могли придумать quicksort 15 лет,
Потому что для этого требуется понятие рекурсии. В ранних компьютерных системах рекурсивные алгоритмы были невозможны, так как в них не было стека. На машине без стека реализовать QuickSort действительно тяжело, на машине со стеком — он тривиален.
Но никто и не предлагает ведь писать QuickSort на языках без стека и рекурсии.michael_vostrikov
24.12.2019 22:22А то, что для изобретения нуля, отрицательных, а затем и комплексных чисел потребовались столетия — вас не смущает?
Не смущает. Для них точно такая же логика — если человек их не знает или забыл, странно требовать от него их переизобрести за несколько минут.
Однако основная идея первого и второго — занимает по паре строк
Потому первые два легко можно написать во время собеседованияЕсли человек эту идею не знает, то нельзя. Независимо от того, Senior он или нет.
В ранних компьютерных системах рекурсивные алгоритмы были невозможны, так как в них не было стека.
И что это меняет? Я сильно сомневаюсь, что Хоар придумал быструю сортировку через 10 минут после появления первой в мире машины со стеком.
Но никто и не предлагает ведь писать QuickSort на языках без стека и рекурсии
Вы предлагаете переизобрести некую сортировку с нуля, когда у человека ее название не ассоциируется с конкретным принципом организации действий для перестановки элементов.
khim
24.12.2019 23:29Если человек эту идею не знает, то нельзя.
Ну идею и досказать можно, если человек забыл. Всёж-таки там ещё и интервьюер есть. Человек же не в в сурдокамере интервью проходит.
Я сильно сомневаюсь, что Хоар придумал быструю сортировку через 10 минут после появления первой в мире машины со стеком.
Конечно нет. Вначале был изобретён QuickSort и некоторые другие алгоритмы — а уже потом, через несколько лет, появились PDP-8 и HP 2100 с аппаратным стеком для их поддержки. После чего то, что требовало от Хоара изобретательности и находчивости — стало рутиной.
Вы предлагаете переизобрести некую сортировку с нуля, когда у человека ее название не ассоциируется с конкретным принципом организации действий для перестановки элементов.
А почему оно ни с чем не ассоциируется, извините? Как так получилось?michael_vostrikov
25.12.2019 00:02Ну идею и досказать можно
"Скажите мне, как оно работает, а я вам код напишу"?) Ну так даже джуниор может, по готовому ТЗ писать. Можно тогда и сразу в интернете описание искать.
Конечно нет. Вначале был изобретён QuickSort и некоторые другие алгоритмы
Изначально вы сказали, что QuickSort не могли придумать потому что машин с рекурсивными алгоритмами не было, я исходил из этой информации. Если вначале, значит наличие или отсутствие таких машин ни при чем. Кто-то мог догадаться и раньше Хоара, но почему-то не догадался.
А почему оно ни с чем не ассоциируется, извините? Как так получилось?
По условиям примера. Человек не знает, что такое MergeSort, и вы говорите, что он должен ее придумать. Не вспомнить, а придумать. Если бы ассоциировалось, это и было бы "вспомнить".
khim
25.12.2019 00:38Изначально вы сказали, что QuickSort не могли придумать потому что машин с рекурсивными алгоритмами не было, я исходил из этой информации.
А читать мы умеем? Вот то, что я сказал:На машине без стека реализовать QuickSort действительно тяжело, на машине со стеком — он тривиален.
Я сказал, что его тяжело реализовать, а не что он был придуман потому что появились машины со стеком. Это, как бы, совершенно разные вещи.
Да и сами подумайте: как и зачем появились бы машины со стеком, если бы не было алгоритмов, которые на них можно было бы эффективно исполнять? Их какие-то мегамозги проектировали глядя в хрустальный шар и наблюдая там будущее?
Софт всегда идёт на полшага впереди железа. Вначале придумываются некоторые алгоритмы, которые можно ускорить добавив соответствующий аппаратный блок, а потом уж этот блок «запекается в кремнии».
Кто-то мог догадаться и раньше Хоара, но почему-то не догадался.
А почему не догадался? Потому что Шелл был идиотом? Нет, конечно. Просто пытался сделать сортировку из того, что у него было: циклы, проверки… нерекурсивные процедуры…
А вот Хоар догадался, что данные можно организовавать не только в массив, но и в более сложные струкрутры данных и проходить их не только линейно (как сортировка слиянием и Сортировка Шелла делают), но и более сложным, рекурсивным, образом.
Да, на машине без стека и рекурсии — это был гениальный прорыв, откровение… но сегодня мы уже полвека работаем с подобными машинами, у нас почти все структуры данных в округе (HTML/XML, JSON и прочие всякие DOM-деревья и CSS) рекурсивны, а принцип разделяй и властвуй вбит в подкорку каждого, уважающего себя, программиста! В этом мире QuickSort ну никак не должен быть проблемой.
Человек не знает, что такое MergeSort, и вы говорите, что он должен ее придумать. Не вспомнить, а придумать.
Но ведь придумывает-то он его не в вакууме! Он же, по условию задачи, программист-разработчик! Он, извините, программы пишет. Сегодня. Его не заморозили и не перенесли из середины 50х в наш мир. А тут ещё и название вполне «говорящее».
QuickSort же — это приложение одного из базовых (на сегодня базовых) методов к одной из простейших задач — сортировке. Условно говоря — это не изобретения концепции отрицательных чисел, а попытка придумать какой будет результат у умножения -1 на -1. Ну если вы забыли, вдруг. Это всё выводится из базовых свойств умножения. И вот точно также QuickSort выводится из приципа разделяй и властвуй… а уж если вы этого принципа не знаете… какой из вас сеньор?michael_vostrikov
25.12.2019 08:48-1Вот то, что я сказал
Я знаю, что вы сказали, я неправильно это понял.
Да и сами подумайте: как и зачем появились бы машины со стеком, если бы не было алгоритмов, которые на них можно было бы эффективно исполнять?
Затем, чтобы в стек данные ложить? Адрес возврата например?
мы уже полвека работаем с подобными машинами, у нас почти все структуры данных в округе рекурсивны
В этом мире QuickSort ну никак не должен быть проблемойЕсли человек не знает, что алгоритм сортировки с названием "абырвалг" — рекурсивный, он никак не сможет об этом догадаться. И даже если он спросит "рекурсивный он или нет?", то из знания только этого факта конкретный алгоритм вывести нельзя. Mergesort например тоже рекурсивный, только характеристики у него другие, и под "абырвалг" может скрываться и то и другое.
И вот точно также QuickSort выводится из приципа разделяй и властвуй
Рекурсивная форма MergeSort тоже выводится из этого принципа, только это другой алгоритм.
а уж если вы этого принципа не знаете… какой из вас сеньор?
Знание принципа никак не означает умения выдать любой алгоритм с его участием за несколько минут. Требуется спокойная обстановка и время, чтобы придумать последовательность действий и проверить, действительно ли она работает. То есть такие же условия, как и при изобретении этих алгоритмов в первый раз. И то это будет 1 алгоритм из всех возможных, потому что все возможные придумывали разные люди с разными знаниями и идеями.
QuickSort же — это приложение одного из базовых (на сегодня базовых) методов к одной из простейших задач — сортировке. Условно говоря — это не изобретения концепции отрицательных чисел
Для биологии это все совершенно неважно. Если человек не знал или забыл, в обоих случаях это работает одинаково, и на переизобретение с нуля требуется время. Время и условия, которые выходят за рамки собеседования.
khim
25.12.2019 18:46
Если нет рекурсии, то адрес возврата прекрасно кладётся прям в команду, которая будет, когда процедура завершится, осуществлять возврат. Да, сегодня считается дурным тоном делать самомодифицирующийся код — но в 50е никто в этом проблем не видел.Да и сами подумайте: как и зачем появились бы машины со стеком, если бы не было алгоритмов, которые на них можно было бы эффективно исполнять?
Затем, чтобы в стек данные ложить? Адрес возврата например?
Mergesort например тоже рекурсивный, только характеристики у него другие, и под «абырвалг» может скрываться и то и другое.
Нет. Классический merge sort — ни разу не рекурсивный. Там два вложенных цикла и 4 ленты.
Потому он и появился гораздо раньше, чем QuickSort.
Ну и нормально. Если вы его сделаете и доведёте до состояния, когда ему дополнительная память будет не нужна — я это тоже приму.И вот точно также QuickSort выводится из приципа разделяй и властвуй.
Рекурсивная форма MergeSort тоже выводится из этого принципа, только это другой алгоритм.
В качество дополнительного вопроса можно будет обсудить как вы доросли до сентора, так и не узнав, как устроен банальный QuickSort.
А «любой» и не нужен. Нужен работающий. Ну плюс с типичным временем O(N log N), памятью O(log N), вот это вот всё.а уж если вы этого принципа не знаете… какой из вас сеньор?
Знание принципа никак не означает умения выдать любой алгоритм с его участием за несколько минут.
После того, как будет написан работающий код — можно будет и этот код и алгоритм обсудить… поговорить про память, константу и всё такое прочее.
То есть такие же условия, как и при изобретении этих алгоритмов в первый раз.
Странно — а многие тут начинают вопить, что допуск к компьютеру (то есть возможность один раз положить в него стопку перфокарт и получить результат) раз в неделю с 2 до 3 часов ночи — это негуманно.
</sarcasm>
В том-то и дело, что все эти базовые алгоритмы люди придумывали без всякого Гугла и интерактивных сред — вот примерно в тех же условиях, в которых вы находитесь во время собеседования.
Только у них ещё и опыта работы не было и Computer Science тогда был в зачаточном состоянии…
Если человек не знал или забыл, в обоих случаях это работает одинаково, и на переизобретение с нуля требуется время. Время и условия, которые выходят за рамки собеседования.
Странно — а вот тут человек утверждает, кто это время — это «полчаса-час» даже без подсказок (если изначально теория за три месяца училась).
И мой опыт скорее с ним согласуется. И собеседование на этом строится.
Если же вы подходите к обучению по принципу «всё выучил, потом всё сдал, в голове ничего не осталось» и на повторное изучение чего-то, что вы изучали три месяца десять лет назад вам нужно не «полчаса-час», а снова три месяца… то тут уже неважно на какую позицию вы претендуете… потому что у вас будет абсолютно бесполезно спрашивать — почему вы приняли то или иное решение пять лет назад… а это бывает нужно. Особенно если вы были «сеньором» и ваши решения были реально существенными.michael_vostrikov
25.12.2019 20:12В том-то и дело, что все эти базовые алгоритмы люди придумывали без всякого Гугла и интерактивных сред — вот примерно в тех же условиях, в которых вы находитесь во время собеседования.
Когда это время собеседования занимает месяцы и годы?
Какой из алгортимов люди изобрели во время собеседования при устройстве на работу? Я о таких не слышал.
а многие тут начинают вопить, что допуск к компьютеру раз в неделю с 2 до 3 часов ночи — это негуманно
Вот именно про эту неделю я и говорю. Во времена всякого Гугла и интерактивных сред оно может сократиться до 1 дня или нескольких часов, при условии использования этого Гугла и интерактивных сред. И отсутствия сторонних наблюдателей и жестких временых рамок. Ну то есть да, как при любой научно-исследовательской работе.
Странно — а вот тут человек утверждает, кто это время — это «полчаса-час» даже без подсказок (если изначально теория за три месяца училась).
Ну и что? Если кто-то в интернете что-то утверждает, это должно быть справедливо для любых знаний и любых людей?
на повторное изучение чего-то, что вы изучали три месяца десять лет назад вам нужно не «полчаса-час», а снова три месяца
Между "полчаса-час" и "три месяца" есть куча промежуточных вариантов. Более вероятных.
Да даже и час на собеседовании обычно не ждут.
Да и час на собеседовании отличается от часа в спокойной рабочей обстановке.khim
25.12.2019 20:24Ну и что? Если кто-то в интернете что-то утверждает, это должно быть справедливо для любых знаний и любых людей?
Нет. Но это должно быть справедливо для людей, которых мы готовы взять к нам на работу.
Да даже и час на собеседовании обычно не ждут.
Всё так. Потому я вполне готов принять и не вполне правильное решение и даже обсуждать его.
Да и час на собеседовании отличается от часа в спокойной рабочей обстановке.
Но от отказа от его порождения — я принять не готов, извините.
Dolios
25.12.2019 10:34Вот этот коммент в топ надо или отдельным постом. А то псевдосиньоры выше такую дичь несут…
VolCh
26.12.2019 15:19Да, представьте себе, если вы не собеседовании не помните как устроена сортировка слиянием — это не просто хорошо, это отлично.
А если просто не знаешь? Ну вот не встречалась нигде и никогда. Ну может где-то просто прочитал лет 30 назад, что есть разные сортировки с разными принципами, может даже принцип был в двух словах описан, но это лишь прочитал один раз. А для "придумать" слишком мало исходных данных.
playermet
24.12.2019 17:51Даже наоборот, знание наизусть реализации множества алгоритмов сортировки это скорее признак студента-отличника.
pyrk2142
24.12.2019 14:10Компании используют сторонние сервисы типа HackerRank в качестве фильтра для отсеивания претендентов. Многие отличные разработчики отсеиваются, потому что не упражняются в написании сортировок регулярно. Компании жалуются на нехватку квалифицированных кадров на рынке труда. И это повторяется раз за разом.
Имхо, почти в всех статей про найм со стороны кандидатов встречаются два неявных предположения: собеседующие хотят нанять кого-то и собеседующим не все равно, пролетит ли подходящий кандидат (это встречается чуть реже).
Люди довольно массово считают, что собеседующий (HR, техлид, сеньор, ...) заинтересован в найме кандидата. Во многих случаях картина приоритетов и желаний другая:
1) Получить премию и зарплату
2) Порадовать себя (поделать что-то приятное, у некоторых — написать что-то крутое)
3) Сходить в отпуск
4) Поесть на обеде за счёт компании
5) Отдохнуть, так как объелся
6) Уйти домой пораньше
…
n) Нанять кандидата
…
n + много) Провести собеседование хорошо, чтобы кандидату было хорошо
…
n + крайне много) Написать тому, кто не подошёл, обьяснить причины и дать советы при наличии просьбы об этом.
Очень часто у собеседующих и нанимающих нет вообще никакой мотивации собеседовать и нанимать, кроме необходимости это имитировать, чтобы их не уволили. Пока лично у всех собеседующих нет мотивации на найм хорошего (!) кандидата, собеседования будут убогими, а люди — недовольными.
Недавно столкнулся с известной конторой, руководство которой заявляет, что им крайне нужны ещё разработчики. Контора не самая плохая, поэтому каким-то чудом сотрудники им посоветовали несколько неплохих программистов, которые ищут работу, дали их контакты. HR отдел не смог заставить себя написать им на почту (!), когда об этом узнали разработчики, то они сходили к руководству, которое просто погрозило пальцем, но не заставило написать потенциальным кандидатам (!). И все, трём отдельным группам людей найм новых сотрудников вообще не нужен. Но эта компания публично вешает кучу вакансий, постоянно ноет, что нужны новые люди, а никто не хочет идти, дефицит.
И второй момент: многие почему-то считают, что то, что хороший кандидат пролетает, должно расстраивать собеседующих. На куче рядовых позиций, где велико число потенциальных кандидатов, спокойно можно отсеивать кучу людей по любым признакам. Как минимум, так действуют многие компании. А вот когда компания начинает тонуть из-за нехватки людей, то нанимающие либо получают очень болезненный мотивирующий удар по голове от руководства (если оно видит проблему и решает заканчивать эти игры) и начинают нанимать вдумчиво, либо просто бегают, увеличивают количество обрабатываемых резюме, не меняя подходы. И начинают орать "На рынке дикий дефицит!!! Остались только некомпетентные, они даже красно-черный хешмап развернуть и отсортировать не могут!!!!11 Сеньоры устраиваются только по знакомству, их не выцепить на рынке1111111 Мы дико стараемся, премию нам, срочно премию!!!!"
A114n
24.12.2019 16:36Но эта компания публично вешает кучу вакансий, постоянно ноет, что нужны новые люди, а никто не хочет идти, дефицит.
Послушайте, ну значит люди не нужны.
Я пытаюсь это в каждой теме объяснять, но, видимо, нужно писать отдельную статью — просто на отдельную статью нет материала, потому что она укладывается в одну строку.
Если люди нужны — их нанимают, а если не нужны — ноют, что люди нужны, да вот никто не идёт или слишком дорого, или цвет волос не тот.
Если процесс найма /когда люди нужны/ тормозит HR-служба, то после этого HR-служба просто исчезает в полном составе или отодвигается в сторону, а нужные люди нанимаются и работают на благо компании. Если же люди не нужны, то см. выше. Нытьё, вакансии, «заявления руководства».
JamboJet
24.12.2019 19:10+1Очень много компаний это уже корпорации, которые too big to fail.
Лично мне глаза открыл один из комментариев к очередной гневной статье про собеседование в вроде бы Amazon: 15 минут по скайпу, хрипящая связь, странная задача за 5 минут до конца собеседования, а потом «ваше время вышло» и HR отключается.
Так вот, в комментарии бывший сотрудник HR объяснил — в гугле на каждую открытую вакансию поступает в среднем 1500 резюме, из которых по формальным признакам отбирают примерно 200, а уже из них проводится 20 собеседований. Благодаря развитой сети филиалов, программам релокации и общей престижности за вакантное место конкурируют фактически все разработчики всей планеты. Миллиард индусов, китайцы, граждане ЕС, канадцы, местные — все. И поэтому «гугл» может себе позволить перебирать харчами, нанимая по желанию левой пятки только женщин C++ сеньоров ради гендерного равенства, или рыжих, ирландцев, геев, да хоть сеньораС#-CPL-подводного военного ныряльщика-негра-альбиноса.
Плюс эффект масштаба, тот же гугл нанимал по ~13тыс человек в год, то есть это около пары миллионов поступивших резюме, глаз и рука замучаных кадровиков замыливается и отдельные личности превращаются в цифры и галочки CRM.Заголовок спойлерагугл тут это пример, подобная ситуация в любой крупной корпорации
а уж если нанимает не сама корпорация, а «кадровое агенство», то всё ещё в десять раз хужеadictive_max
25.12.2019 02:44Только соискателю как-то не легче от понимания почему вопрос «работы всей его жизни» решается на 60% рандомом. Ему важно, только то, что это рандом.
И уж совсем не вызывает понимания, когда от таких же проблем страдают «молодые динамично развивающиеся компании», в которых генеральный имеет возможность без напряга лично отсобеседовать каждого желающего.DrunkBear
25.12.2019 15:10Культ Карго?
«Начнём делать как Гугл — станем новым Гугл!»
Ну или величие ударяет в голову, в стиле «да кто они такие, чтоб Я лично их собеседовал, за воротами очередь, а в hh/superjob тыщщи вакансий!»
Ketovdk
24.12.2019 14:56+1Я знал, для чего нужна сортировка слиянием, я знал, как найти её код. Я лишь не мог вспомнить его.
По-моему невозможно знать, для чего нужна сортировка слиянием, не зная реализации её и некоторых ближайших сортировокknstqq
24.12.2019 21:22так не нужно реализацию знать, нужно знать общую идею. А как назвать переменные и в каком порядке пусть цикл — детали реализации.
Ketovdk
24.12.2019 21:50+1так никто и не требует доскональное знание реализации, но зная общую идею написать (не мега оптимально, но все же вы сможете) вы сможете. Ну и не зная реализации merge невозможно догадаться до того, что она лучше работает при стабильной сортировке и хуже при обычной
maxnosib
24.12.2019 15:49полностью согласен с автором для примера можно взять студента отличника который работал со мной и я ему помогал с элементарными вещами в минуты отчаянья и для него было как магия.
говорил он мне следующее что он все работы делал в институте сам а тут банальный баг пофиксить не может и большая часть того что он знает ему не нужна т.к. она реализована в библиотеках и наврятли он сделает лучше.
andi123
24.12.2019 18:02+1Странный пост, конечно.
Мне всегда казалось, что если ты уже состоявшийся синьер (с трудом представляю что это, наверно матерый прогер который может сам ставить себе задачи, сам придумывать решения, сам реализовывать, да еще обладать чувством прекрасного), то на собеседовании ты можешь лениво говорить: «я это не знаю», «я это не пробовал». «Ну если вы настаиваете я могу попробовать придумать сортировку пузырьком, но это вряд ли будет быстро».
В общем, какая-то сферическая конина. Синьер уже много чего повидал и именно этим он и ценен. Тем, что не «лучше всех сыграет гамму», а досконально разберется в предметной области и порешает все проблемы. И он точно это сделает, потому что уже больше десятка раз это делал.
Хотя, если таки посты есть, значит они кому-то интересны?
411
24.12.2019 19:02+1Избитая тема.
Если специфика работы в компании предполагает, что умение написать сортировку напрямую связана с успешностью работы кандидата, то почему бы и нет. Но думаю это редкий случай.
Если кандидат заявляет, что он умелец в реализации алгоритмов/участник ACM/ещё как-то связан с этим, то тоже стоит проверить.
В остальных случаях собеседует не тот человек или программу собеседования создавал не тот человек.
Главная цель собеседования — понять, подходит ли человек для работы в вашей команде или компании и на какую должность(ну или соответствует ли позиции, если нужна только конкретная). А специфика у всех своя.
Если на достаточной дистанции кандидаты, умеющие объяснить, почему крышка от люка круглая, или пишущие сортировку на коленке за 5 минут, всегда показывают нужный уровень, то может это вам и подходит. Хотя без неудач от кандидатов, которые это делать не умеют и всегда не справляются с работой, картина всё равно будет неполной.
Но скорей всего у вас недостаточно таких данных для анализа, поэтому самыми лучшими вопросами будут вопросы и задачи по опыту, по специфики вашей работы и позволяющие выяснить, умеет ли и как кандидат думает, обучается и находит решения.
kreo_OL
24.12.2019 20:00+8История из жизни:
— Необходимо знание векторной математики.
— Подучил, пришел на собеседование.
— Час гоняли по задачкам с векторами и кватернионами.
Итог: за три года работы в студии векторная математика понадобилась всего два раза в задачах на пол часа — час. Причем пример решения гуглился первой же ссылкой.gohan
25.12.2019 02:59Вот-вот. У меня был период в жизни, когда я хорошо умел решать всякие задачки по высшей математике, потому что изучал всё это. Теперь я решить никакие более-менее сложные задачи не смогу без учебников и гуглежа, даже если на карту поставят мою жизнь. Значит ли это, что я полный дебил? Ну, не исключено. Но более вероятно, что за 10 лет работы я тупо ни единого раза не применял те знания, и они успешно отошли в туман.
Думаю, единственное, чем я отличаюсь от не изучавшего математику человека, так это разве что знанием самых базовых вещей. Ну и ещё, если мне положат на стол 10 сильно отличающихся вариантов решения задачи, где только 1 верный, то я почти наверняка быстро вычислю верный, а ничего никогда не учивший человек отбраковать заведомую ересь в таком эксперименте не сможет.0xd34df00d
25.12.2019 04:56Думаю, дело ещё и в том, что вам вспомнить это можно будет за на порядок-два меньшее время, чем не изучавшему человеку — изучить с нуля.
kreo_OL
25.12.2019 05:48Знание базовых вещей решает. Я по факту не вижу ни чего плохо в том что у меня спросят про сортировку. Но не понимаю зачем я должен буду решать по ней задачки и писать код без справочного материала . Я конечно не сеньор, но уже на моем уровне багаж знаний просто огромен, у сеньоров еще больше я так полагаю, когда это все подробно помнить? Знаешь какая сортировка лучше другой, чем отличаются и какую в какой задачи применить, отлично. А саму сортировку написать можно и с материалом, ведь если знаешь, то сможешь и нагуглить быстро, а если не знаешь, то и гуглить будешь дольше — если вообще нагуглишь)
puyol_dev2
24.12.2019 20:47Не читал статью, но по заголовку все логично. Senior должен прежде всего уметь проектировать систему. Если честно, слабо представляю как можно наложить на эту задачу классические задачки по программированию
khim
24.12.2019 22:03+1Senior должен прежде всего уметь проектировать систему.
Полное название должности, всё-таки, «Senion Software Engineer». Так вот если кандидат — вообще не «Software Engineer»… то уже неважно: Senior он или Junior.adictive_max
25.12.2019 02:51Так вот если кандидат — вообще не «Software Engineer»… то уже неважно: Senior он или Junior.
Должен ли инженер-строитель уметь самолично укладывать кирпичи, чтобы быть хорошим инженером?
Должен ли инженер-машиностроитель уметь лично управлять токарным станком?
Должен технолог производства уметь воспроизводить все этапы ручным оборудованием?
и т.д.
Понятно, что ничего из этого в работе не помешает, и будет только плюсом. Но являются ли такие навыки обязательными?khim
25.12.2019 03:59Понятно, что ничего из этого в работе не помешает, и будет только плюсом. Но являются ли такие навыки обязательными?
Нет, конечно. Работа инжинера кончается там, где начинается повторяющаяся работа без элементов творчества.
И таких навыков у software engineer'а — тоже вагон. Он не должен уметь превращать программу на C в машинный код (для этого существует компилятор), он не должен уметь расставлять пробелы (для этого существует автоформаттеры) и прочее.
Да, в общем-то, даже следить за своим сервисом он не всегда должен (для этого админы есть).
Но написание кода — никогда не бывает рутиной. Мы можем уделять ему больше или меньше внимания, но если мы пишем код — то это всегда творческий процесс. Я чуть выше обсуждал ситуацию, когда банальное чтение четырёх байт из памяти может потребовать массы обсуждений.
Я не говорю, что каждая ваша строка кода будет превращаться в подобный квест (так вы 100 строк программы будете писать год), но если вдруг это потребовалось… да вы должны это уметь. А кто, собственно? Junior или NewGrad? Ну вот кто? Кроме вас?adictive_max
25.12.2019 04:38Но написание кода — никогда не бывает рутиной.
Честно, я вам завидую, если для вас написание ЛЮБОГО кода не является рутиной.
Писать код — это ооооочень широкое понятие, и в любом случае написание кода — это и есть рутина.
ИМХО, работа software engineer'а, особенно уровня Senion — не писать код, а решать проблемы. Писание кода — это инструмент, причём далеко не единственный.
но если вдруг это потребовалось… да вы должны это уметь. А кто, собственно? Junior или NewGrad? Ну вот кто? Кроме вас?
Вопрос в том, должен ли я это уметь постоянно, или быстро этому научиться по мере надобности. Я тоже умею играть в эту игру, и могу насочинять вам пару тысяч навыков, которые неплохо бы иметь в любой профессии «ну просто на всякий случай, кто если не вы». И поддержание которых в актуальном состоянии сожрёт всё ваше время, не занятое сном.
Дело тут не в том, что кому-то лень, мозгов не хватает, ЧСВ жмёт и т.д., хотя и не без этого. Ресурсы мозга ограничены. Как не упарывайся, а запомнить больше, чем в него помещается, невозможно. Чем больше знаний вы держите и постоянно обновляете просто про запас, «потому что кто, если не вы», тем меньше места остаётся под всё остальное, в т.ч. под то, что нужно прямо здесь и сейчас.PleaseKING
25.12.2019 05:51Разумеется, написание кода — не единственный навык, необходимый инженеру-программисту вне зависимости от уровня. Но в отсутствие его он перестает быть инженером, вот в чем беда. Превращается в кого угодно, но перестает быть инженером. Может быть, не все с этим согласятся, но лично я в это верю, и люди, задающие такие вопросы на собеседованиях — тоже.
adictive_max
25.12.2019 06:48Давайте для начала так. Написание алгоритмов сортировки по памяти или «банальное чтение четырёх байт из памяти» — это не сферическое в вакууме «умение писать код». Это навыки решения вполне конкретного класса задач.
Должен ли любой Senion знать их на достаточном уровне, чтобы продемонстрировать на получасовом собеседовании?
Даже если ни разу в жизни с подобными задачами не сталкивался и на работе у вас не столкнётся?
Даже если в принципе не может столкнутся из-за специфики рабочего стека?
Но в отсутствие его он перестает быть инженером
А можно точный и поимённый список, без чего инженер — не инженер?PleaseKING
25.12.2019 08:43+1Я тут солидаризируюсь с предыдущими комментаторами — это такая же задача, как любая другая, и ее надо решить. Я не стал бы требовать конкретного алгоритма, но я бы смотрел на качество кода, на качество тестов, на процесс анализа проблемы, на знакомство с языковыми конструкциями и примитивами (благо язык реализации кандидат выбирает сам) — но, разумеется, мелкие ошибки не в счет, на умение оценить сложность, на умение обобщить решение за пределами исходной постановки задачи. Конкретное задание — лишь пример и повод для разговора.
А можно точный и поимённый список, без чего инженер — не инженер?
Ну вот без всех перечисленных выше пунктов как минимум, и вряд ли список полный. Для опытных кандидатов, разумеется.
khim
25.12.2019 19:22но, разумеется, мелкие ошибки не в счет
Не совсем так. Мелкие ошибки тоже важны — но не в разрезе «совершил ошибку — сразу за дверь», а «увидит ли их кандидат, сможет ли он их исправить если ему на них указать» и так далее.
Ну всё, как в обычной работе — только задача «плёвая».
VolCh
26.12.2019 16:13Вот, а писать какую-то известную сортировку по идее не работа инженера. В худшем случае в задаче предполагающей выбор сортировки, инженеру надо узнать/вспомнить какие алгоритмы сортировки есть (гугл), каковы их характеристики по сложности и памяти, какие есть в стандратной библиотеки, сторонних и сколько будет стоить написать реализацию своими силами и лишь потом делать выбор.
khim
26.12.2019 16:53А почему это, собственно, не работа инжинера? Я чья это работа, извините? Почему вы вообще уверены, что у вас всегда и при любых условиях будет возможность использовать стандартную библиотеку?
Вот, совершенно практическая, недавно возникшая задача: мы пишем систему, где нельзя использовать стандартные функции работы с памятью (почему и как отдельный вопрос… но вот так вот, нельзя) и нам нужно экономить стек. Что будет эффективнее — написать свою сортировку или как-то ограничить qsort? Или как-то убедить сортировки из стандартной библиотеки C++ не использовать память?
Как вы вообще будете делать выбор если для вас задача написания своей сортировки — проблема?VolCh
27.12.2019 07:52Я не уверен, я написал, что в худшем случае придётся писать свою реализацию известного алгоритма, если стандартные или сторонние почему-то не подходят. В наихудшем случае свой алгоритм придумать, который окажется быстрее на конкретных данных, ну не знаю, когда априори известно, что на 99% 99% элементов уже будут отсортированы, но в обратном порядке.
И проблема для меня написать сортировку по конкретному алгоритму, который вы называете, а я не знаю. Вот пузырьковую знаю, могу написать на трёх языках нескольких версий каждого на бумажке. А остальные только с алгоритмом перед глазами. Хотя лет 27 назад писал на лабах три минимум с бенчмарками на разных данных, но даже названий не помню каких. Из теории помню вроде только что есть теорема, по которой сортировка на случайных данных не может быть проще чем O(N*log(N)) и алгоритм пузырьковой за минуту вспомню.
khim
28.12.2019 21:13Из теории помню вроде только что есть теорема, по которой сортировка на случайных данных не может быть проще чем O(N*log(N)) и алгоритм пузырьковой за минуту вспомню.
Ну если вы хотя бы эту теорему быстренько доказать можете — уже хорошо.VolCh
28.12.2019 13:14Конечно не смогу. Не факт, что даже когда-либо это доказательство видел, а для выведения самому нет даже мысли какой раздел десятки лет назад изученной вышки применять.
michael_vostrikov
28.12.2019 14:22+1Как вы вообще будете делать выбор если для вас задача написания своей сортировки — проблема?
Так и будем — возьмем на исследование по задаче день или два, проверим сколько стека занимает qsort, проверим можно ли убедить сортировки из стандартной библиотеки C++ не использовать память, поищем алгоритмы сортировки в интернете и выберем подходящий. В крайнем случае свой напишем, пусть и не за 10 минут, а за день. Вместо сортировки может быть какое-нибудь шифрование или драйвер ввода-вывода. Ничем не отличается от любой другой задачи. И как и любую другую задачу, совершенно необязательно знать ее во время собеседования.
khim
28.12.2019 21:18Так и будем — возьмем на исследование по задаче день или два, проверим сколько стека занимает qsort, проверим можно ли убедить сортировки из стандартной библиотеки C++ не использовать память, поищем алгоритмы сортировки в интернете и выберем подходящий.
Прекрасно — вот вы всё это проделали, выяснили что qsort вам подходит, всё написали и запустили в production… где ваша вся конструкция регулярно крешится и фирма терпит убытки. Ваши дельнейшие действия?
Вместо сортировки может быть какое-нибудь шифрование или драйвер ввода-вывода. Ничем не отличается от любой другой задачи.
Отличается. Шифрование, работавшее в тестах — будет работать в боевом режиме. Во всяком случае я не представляю как так сделать, чтобы шифрование в тестах работало, а в боевом режиме нет. Драйвера… ну тут может быть по-всякому. А вот сортировка — с большой вероятностью пройдёт тесты и покрешится в боевом режиме… и я знаю почему (да и вы наверняка знаете, просто придуриваетесь).
И как и любую другую задачу, совершенно необязательно знать ее во время собеседования.
Ну это ваше мнение — слава богу собеседование провожу я, а не вы…michael_vostrikov
27.12.2019 23:26запустили в production… где ваша вся конструкция регулярно крешится и фирма терпит убытки. Ваши дальнейшие действия?
Берем и исправляем. Ну а что, вам можно придумывать произвольные события без подробностей, а нам нельзя? Или даже не так — запустили в production и там все работает. Потому что изучили вопрос во время работы по задаче и сделали как надо.
и я знаю почему (да и вы наверняка знаете, просто придуриваетесь)
Я предполагаю, что вы намекаете на количество элементов, но не вижу никаких причин, почему реальное количество в продакшене нельзя учесть во время написания кода.
Ну это ваше мнение — слава богу собеседование провожу я, а не вы…
Вы требуете, чтобы кандидат на собеседовании знал любую задачу, которая встретится в будущем? Сомневаюсь.
khim
28.12.2019 00:27Берем и исправляем.
Как исправляем? Если вы даже не знаете — что у вас там падает, когда и почему?
Ну а что, вам можно придумывать произвольные события без подробностей, а нам нельзя?
Можно конечно. Если вы готовы «раскрыть карты» и объяснить — почему так происходит.
Или даже не так — запустили в production и там все работает. Потому что изучили вопрос во время работы по задаче и сделали как надо.
О! Вот с этого момента — поподробнее. Вы тут написали:проверим сколько стека занимает qsort. Как вы это проверять собрались? Экспериментами али ещё как-нибудь?
Я предполагаю, что вы намекаете на количество элементов, но не вижу никаких причин, почему реальное количество в продакшене нельзя учесть во время написания кода.
Если бы я намекал на количество элементов. Ха. Всё было бы очень просто. Уж засунуть-то миллион элементов в массив и в тестах можно.
Ахилессова пята QuickSort всем, кто знает, как он устроен, известна: на «плохих» исходных данных он деградирует — и да, это приводит к переполнению стека. И избежать этого — довольно сложно. А вот что сделать можно легко — так это сделать так, чтобы на «популярных» «плохих последовательностях» (уже отсортированный массив, простейшие V или W образные последовательности) — всё работало хорошо. Поскольку в стандартной библиотеке так и сделано — то на тестах вы этого не заметите, так как не знаете «где копать». Но вот для ваших конкурентов (если они знают «где копать») создать последовательность, которая будет «укладывать ваш сервер на лопатки» — несложно.
Вы требуете, чтобы кандидат на собеседовании знал любую задачу, которая встретится в будущем?
Я требую, чтобы кандидат знал хотя бы самые базовые вещи — MergeSort, QuickSort, Red-Black tree.
Задачи их написания я обычно не даю, могу, впрочем поговорить что делать с подобным вот сервером.
В любом случае кандидат должен уметь отвечать на вопрос: какая сложность у только что написанного им кода. Для любого кода… ну почти: раз в год, а то и реже — нам приходится писать-таки код, сложность которого неизвестна (потому что он слишком многого числа потенциально нам неизвестных переменных зависит). Он обкладывается тестами, логгингов и прочим… и всё равно за него всегла боязно — а вдруг мы чего-то не учли?
Но вот чего нам совершенно не нужно — так это иметь кучи такого кода только потому, что человек, писавший этот код на об «O большом», ни об устройстве кешей процессора не задумывался.
P.S. На собеседовании задачи, где решение имеет непонятную сложность, я разумеется, не даю…
ashofthedream
26.12.2019 17:40но задача этого самого инженера может быть написание куска бизнес логики, основанного на одной из этих сортировок, потому что если это делать без пиггибекинга, то решение может занять O(n), а при большом количестве данных, это черт подери очень медленно
Static_electro
25.12.2019 09:06Имхо, на многие подобные вопросы в IT ответ, неожиданно, "ДА!". Потому что примеров, когда люди не используют сами то, что делают для других, много.
kreo_OL
25.12.2019 05:51Сеньор так же должен в случае чего реализовать все что он на проектировал за минимальное время. А так же объяснить и показать сотруднику который будет реализовывать на проектированное в случае если у сотрудника будет какая то проблема.
adictive_max
25.12.2019 06:51должен в случае чего реализовать все что он на проектировал за минимальное время
Ну это опять же вопрос, обязан ли прораб уметь класть кирпичи быстрее каменщика, плитку ровнее плиточника, проводку аккуратнее электрика и т.д?PleaseKING
25.12.2019 08:45В вашей аналогии прораб — это менеджер — и да, конечно, он не обязан и не может быть лучше каждого члена команды. Но старший каменщик должен уметь класть плитку, да. А старший инженер — это инженер. И код писать он уметь, разумеется, должен.
ftdgoodluck
24.12.2019 20:58Должен ли senior помнить наизусть любой алгоритм сортировки – скорее нет, знание наизусть навряд ли поможет в работе
Должен ли senior уметь написать сортировку за приемлемое время – вот тут скорее да, чем нет.khim
24.12.2019 22:07-1Это очевидно вам, но почему-то неочевидно дикому количеству «сеньоров», которые отстаивают своё право не писать код.
Некоторые кандидаты реально воспринимали предложение написать хоть какой-нибудь код, в принципе, как личное оскорбление: «как? вы хотите, чтобы я код писал?! этум пусть студенты занимаются, моё дело — стратегия!».
Вот только практика показывает, что отказ от написания кода приводит к тому, что эти «синьоры» начинают придумывать стратегии в духе той самой совы, которыя предлагала мышам сделаться ёжиками.ashofthedream
24.12.2019 23:01Расскажу про пару случаев из жизни, примерно два года назад побеседовал человека, 11 лет опыта разработки, две компании с громким именем, далеко не посредственные проекты, зная специфику нашего проекта спрашиваю про всякие штуки связанные с многопоточностью, на что получаю невразумительный ответ, что не нужна она в начале 2018 года и все проблемы можно решить при помощи подхода Х, так как это был уже третий вопрос по делу, на который этот сеньор софтвейр енжинер не смог толком ответить (а собственно решение уже принято), время — вечер, и рабочий день у меня закончился, то цепляюсь за его ответ и предлагаю посмотреть код, и вместе решить, как можно этот подход применить (ладно, тут еще был один фактор, я немного сменил область деятельности и активно знакомился с этим подходом, личный интерес...).
После часа общения, он приходит в состояние ступора, потому что он никогда раньше не работал с приложениями у которых есть внутренний богатый стейт, и это внутри как-то общается между собой. Оба приходим к выводу, что в нашем случае подход Х можно использовать лишь частично, потому что особого профита он не даст.
Кстати, он тем же вечером сам ответил, что не готов пойти к нам работать, потому что неинтересно ему. Ему не интересно писать кучу кода, своими руками.
Случай второй, собеседуем другого сеньора, он категорически отказывается писать код, и рассуждает как бы он это сделал и что бы применил из фреймворков, подходов, мой коллега улыбается, так как они это все уже прошли, и сейчас хотят к себе человека, который будет готов писать код, бизнес логика в некоторых местах достаточно сложная и требуется понимание того, что творишь. Как итог склонили кандидата показать код своего пет прожекта, банальное ревью на 15 минут выявило несколько проблем, в том числе и с перфомансов. Вдобавок — пару багов.
khim
24.12.2019 23:37Ему не интересно писать кучу кода, своими руками.
Ну вот в 9 случаях из 10 — это и есть проблема «сеньоров, не любящих алгоритмические задачи».
То есть вот я реально не видел синьоров, которые умели бы и любили бы писать код — и «не умели бы в сортировку». А вот любителей «руками водить»… и смотреть как «слоники бегают» — видел в количестве.
А они нам, представьте себе, и не нужны.
P.S. Это не значит что все хорошие кандидаты приходят от такой идеи в восторг… нет, некоторые спрашивают — а стоит на это время терять? Но услышав ответ «да, мне, для отчёта, нужен написанный вами код»… вздыхают и быстро его пишут. «Бес проблэм», как один чёрт в мультике говорил. Вполне остаётся время и на другие вопросы.
TheKnight
25.12.2019 01:35«да, мне, для отчёта, нужен написанный вами код»…
Хм… Знакомая история :)
А вы кого больше ищете — людей которые лопатой умеют разгребать задачи или придумывать прорывные идеи?khim
25.12.2019 04:02А вы кого больше ищете — людей которые лопатой умеют разгребать задачи или придумывать прорывные идеи?
Людей, за которым не придётся переделывать код, прежде всего.
А умеют ли они «разгребать типичные задачи» или «гениально решать редкие» — это уже вторично.
Если в результате их деятельности количество багов в коде не растёт, а уменьшается — это уже прекрасно, остальное приложится.
PleaseKING
25.12.2019 00:05Лихорадочно плюсую. Провожу собеседования минимум раз в неделю и поражаюсь, какое количество senior всякого рода людей полагает, что достаточно красиво поговорить о задаче, а не решить ее. И по 20 лет опыта у людей, и в интересных местах… Притом это касается и технических вещей, и не нетехнических.
Калифорния, Google, если что.
VolCh
28.12.2019 17:48+1Сортировка сортировке рознь. Написать какую-то сортировку сеньор должен уметь, оценить её сложность и более-менее порядок области применимости — тоже. Написать конкретную ("любимую" собесдующего) с предоставленным алгоритмом — тоже. А вот какую-то конкретную по памяти -
khim
28.12.2019 21:22Мне кажется, что знать 2-3-4 самых «базовых» — небольшая проблема. Вот timsort — это уже, пожалуй, сложновато. А mergesort, quicksort — чего там сложного-то?
Heapsort — посередине между mergesort/quicksort: в отличие от timsort — её описание не забывается и через 10 лет. В отличие от quicksort — её описание не помещается в одну строку… Её я на собеседовании спрашивать бы не стал… но знаю и людей, которые спрашивают. Меня, как я уже упоминал, спрашивали.VolCh
28.12.2019 13:22Мне кажется, что знать 2-3-4 самых «базовых» — небольшая проблема.
А мне кажется большая. Небольшая вот сейчас взять и прочитать алгоритмы. Может даже на коленке реализацию сделать на паре языков и бенчмарки погонять. А вот через год или пять-десять всё это на собеседовании вспомнить
avengerweb
25.12.2019 00:16Ох понабежало. Года бегут, а интервью все хуже, думаю потому что очень много людей хотят работать в этой сфере. Алгоритмы и структуры данных это стандарт для выпускников вузов, если они отскакивают на зубок, значит предыдущий этап (образования) был успешно завершен. Что значит это для мид+ программиста? Ничего, это значит, кроме того, что перед интервью он потратил от 3-6 месяцев (да, бывает быстрее, но как правило у SSE нет особых проблем с работой и он не куда не спешит) сидя на leetcode, hackerrank и тп. решая задачи которые его буду спрашивать на интервью.
Никто не хочет портить свою репутацию, так что, человек как правило будет с неохотой ходить на интервью из за подобных каверзных вопросов и, необходимости долгой подготовки к вопросам и задачам слабо относящимся к работе.
А теперь представьте что SSE нужно потратить на подготовку с полгода чтобы пройти у вас интервью идеально (да конечно он хочет пройти его идеально он 10 лет в отрасли), а вы mid-grade компания, куда он пойдет к вам или в какой нибудь Google?
Вот и получается монополия, когда средние компании не могу показать нормальный софт, потому что у них просто нет людей способных проектировать, а лишь те кто может решать алгоритмические задачки. Ребята которые по полгода пишут какой нибудь фреймворк для "High Load" сайта с посещаемостью в 100 юзеров в день или крутой поисковой движок для того чтобы пользователь на сайте мог найти штаны по размеру, вместо использования готовых решений. А бизнес что — бизнес стоит на месте или умирает за это время.
khim
25.12.2019 00:43Погодите — но ведь куда-то же эти «синьоры», в конце-то концов, устраиваются. То есть где-то есть куча людей, которые набирают людей «правильно», не давая алгоритмических задачек и не мучая всякими дурацкими вещами людей… почему же эти-то компании не взлетают и не «закапывают» все те компании, у которых «просто нет людей способных проектировать, а лишь те кто может решать алгоритмические задачки»?
avengerweb
25.12.2019 01:05Ну дак, задачки эти сейчас везде, мои поинт как раз таки в том, что эти самые сеньеры, остаются или там же или уходят в ТОП компании, в итоге средним компаниям практически ничего не остается. А все потому что средние компании требуют ровно таких же усилий для устройства в них как и ТОП компании. Куда вы пойдете? Скорее в топ где ЗП в 2 раза больше, например.
khim
25.12.2019 01:31+1Конечно. Но ведь задача любого собеседования — не «сделать приятное» соискателю, а нанять подходящих работников.
Если бы средние компании могли нанять лучших рабочих отказавшись от алгоритмических задач… то это было бы видно.
Ну не может же быть так, что все миллионы «середнячков» делают всё неправильно — и при этом те компании, которые делают иначе либо не существуют (это среди миллионов-то?), либо ну никак «не выстреливают», хотя всё делают «правильно» (а в каком смысле этот подход «правильный», если он этим компаниям не помогает???).JustDont
25.12.2019 01:53Ну не может же быть так, что все миллионы «середнячков» делают всё неправильно
Вы пытаетесь делать далекоидущие выводы из пары факторов (успешности найма хороших программистов и темпов роста компании), которые не то, что не рядом — но вообще в разных галактиках. И корреляции, которые между ними конечно же могут существовать — опосредованы на десятки степеней.
Я более того даже скажу — ни гугл, ни майкрософт, ни другие компании, представляющие собой существенную реальную ценность (не берем, скажем, нетфликс, ценность которого выражается исключительно толщиной розовых очков инвесторов, в то время как сам бизнес продолжает быть убыточным) — не пользовались «наймом олимпиадников» в те времена, когда закладывался базис их доходности и успешности. Разумеется, можно сказать, что олимпиадники явно смогли по крайней мере ничего не испортить в этом базисе, а то и успешно улучшить — но по крайней мере не вызывает сомнения тот факт, что для того, чтоб из «никого» стать гуглом — надо не олимпиадников нанимать, а делать совсем другие вещи. А олимпиадники как максимум помогут вам оставаться гуглом, если вы уже им являетесь.
PS: И если уж вы завели разговор о конторах — у IBM, например, практика найма совершенно другая, чем у хипстеров из калифорнии (по крайней мере, была совсем другой десяток лет назад, когда я там этой темы близко касался). Что совсем не мешает им быть и оставаться очень крупной софтверной компанией.khim
25.12.2019 04:14Я более того даже скажу — ни гугл, ни майкрософт, ни другие компании, представляющие собой существенную реальную ценность (не берем, скажем, нетфликс, ценность которого выражается исключительно толщиной розовых очков инвесторов, в то время как сам бизнес продолжает быть убыточным) — не пользовались «наймом олимпиадников» в те времена, когда закладывался базис их доходности и успешности.
А кого они нанимали, извините? Начём вообще базируется ваша убеждённость в этом?
Для меня хорогим контрпримером является тот факт, что даже CEO, которого они наняли, чтобы инвесторы не сильно ворчали — оказался программист! Написавший, в своё время, lex и, соотвественно, человек прекрасно представляющий — и что такое язык C и как устроены компиляторы…
Разумеется, можно сказать, что олимпиадники явно смогли по крайней мере ничего не испортить в этом базисе, а то и успешно улучшить — но по крайней мере не вызывает сомнения тот факт, что для того, чтоб из «никого» стать гуглом — надо не олимпиадников нанимать, а делать совсем другие вещи.
И какие же?
И если уж вы завели разговор о конторах — у IBM, например, практика найма совершенно другая, чем у хипстеров из калифорнии (по крайней мере, была совсем другой десяток лет назад, когда я там этой темы близко касался).
Мало касались, я думаю.
Что совсем не мешает им быть и оставаться очень крупной софтверной компанией.
IBM — это крупная консалтинговая компания. Тот факт, что они не создали никакого софта, который бы распространялся вот именно как софт — говорит о многом. Всё что они продают — это либо софт, который они где-то купили, либо софт, который прилагается к чему-то там.
А IBM Research (который как раз и порождает немалое количество «прорывных» вещей) — так у него принципы как раз похожи, на то, что практикует Google. Именно поэтому подобные рокировочки и происходят.0xd34df00d
25.12.2019 04:50как устроены компиляторы…
От lex до современных компиляторов как от китайских фейерверков пятивековой давности до Falcon Heavy.
JustDont
25.12.2019 09:40А кого они нанимали, извините?
Людей, которые хорошо решают проблемы, которые на тот момент времени нужно было обязательно решить. На этом же и империя Безоса стоит, кстати, на найме таких людей — в разное время и совсем с разными специализациями.
Для меня хорогим контрпримером является тот факт, что даже CEO, которого они наняли, чтобы инвесторы не сильно ворчали — оказался программист!
CEO наняли не тогда, когда поиск от гугла вставал на ноги. И не тогда, когда пара человек, работавших над совсем другими вещами, придумала AdWords. Не понимаю, почему вы это считаете «контрпримером».
Мало касались, я думаю.
А я думаю, что побольше вашего. Я очень порядочное количество лет провёл в той самой «где-то купили», откуда берется софт в самой IBM, и коммуцировал непосредственно с работниками IBM весьма достаточно.
Так вот, IBM в основном не создаёт софта, да. Большая его часть берется откуда-то еще, вот только перекладывается и переупаковывается (а иногда и пересобирается, причём прилично так) он таки на стороне IBM. И программистов у них для этих целей в штате весьма прилично.
0xd34df00d
25.12.2019 04:48+1И если уж вы завели разговор о конторах — у IBM, например, практика найма совершенно другая, чем у хипстеров из калифорнии (по крайней мере, была совсем другой десяток лет назад, когда я там этой темы близко касался). Что совсем не мешает им быть и оставаться очень крупной софтверной компанией.
Работал бок о бок с синиор C++ софтваре инженер/дата саентистом, пришедшим из IBM, который думал, что
int a[n]для известного только в рантаймеnаллоцирует память в хипе «когда нужно», и очень удивлялся, когда программа упала в проде под нагрузкой, завалившей стек.
Скрытый текст… чем подарил мне неделю почти отпуска, так как к тому моменту я понял, что мои коллеги и тимлид счастливы, когда баги ищутся в поте лица днями, а когда баги находятся быстрее, то, ну, не очень счастливы. Так что я посмотрел полчаса, нашел проблему, доказал себе, что дело в ней, и остаток недели выдавливал из себя пот, кажется, изучением линзочек в хаскеле, или что я там изучал для себя в тот раз.
JustDont
25.12.2019 09:43Это-то как раз естественно — принцип Питера и тому подобные вещи никто не отменял. Чем больше контора, тем больше в ней работников, которые не являются необходимыми и могут даже немножечко вредить, и контора этого не ощутит. Я думаю, что в таком монстре, как IBM — можно и на целые отделы таких напороться.
khim
25.12.2019 19:33Ну то есть с одной стороны — вы приводите в пример IBM, как фирмы, которая «правильно» нанимает сотрудников, а с другой — вас не удивляет, когда эти сотрудники оказываются, мягко скажем, не очень высокого качества.
Так может IBM стоит не на них, а? А как раз на продажниках, которые умеют продавать творения вот этих вот «гениев»?
И стоит ли тогда нанимать подобных «творцов»?JustDont
25.12.2019 20:02Ну то есть с одной стороны — вы приводите в пример IBM, как фирмы, которая «правильно» нанимает сотрудников, а с другой — вас не удивляет, когда эти сотрудники оказываются, мягко скажем, не очень высокого качества.
Уже в который раз замечаю, что у вас очень так себе с кванторами. И чтением.
Я привожу в пример IBM как фирму, которая нанимает сотрудников совсем иначе, нежели решением олимпиадных задач, и которая от этого совсем даже не рассыпалась. Более того, я выше писал о том, что выяснять зависимость между приёмами найма и ростом компании — это что-то из серии «вилами по воде». А вы это как аргумент заявили.
И да, меня совершенно не удивляет, что в любой (абсолютно любой) достаточно большой компании есть плохие сотрудники.
Так может IBM стоит не на них, а? А как раз на продажниках, которые умеют продавать творения вот этих вот «гениев»?
О, надо же, от аргумента о связи между наймом программистов и работой конторы вы дошли до осознания того, что другие люди в конторах тоже есть. Еще немного, и до вас дойдет, что другие люди везде есть — не только в IBM.khim
25.12.2019 20:28Я привожу в пример IBM как фирму, которая нанимает сотрудников совсем иначе, нежели решением олимпиадных задач, и которая от этого совсем даже не рассыпалась.
Рассыпаться — не рассыпалась.
Лидерство в области написания ПО — потеряла. Причём давно. Как вы сами же признаёте.
Еще немного, и до вас дойдет, что другие люди везде есть — не только в IBM.
А до вас, может быть, дойдёт, что есть компании, которые «стоят» на качестве своих программистов (и они как раз, склонны задавать все эти алгоритмические задачи на собеседованиях) и есть компании, которые качественный код не порождают — ибо им это не нужно.
Так вот современная IBM — относится ко второму классу.
avengerweb
25.12.2019 08:08В известные компании хотят все. И люди готовы к сложным долгим и нудным интервью. Если какой нибудь Apple на последнем этапе интервью попросят спеть в караоке, кандидаты все равно будут это делать.
С чего вы взяли что должны быть улучшения? Я вам говорю про деградацию, если раньше ты шёл в малоизвестную компанию то мог быть уверен что уровень интервью там будет лайтовее. И если тебе было лень сидеть неделями за подготовкой к интервью или тебе нравилась то чем занималась компания ты просто шёл и беседовал. Вы же понимаете что у людей бывают личные проблемы или например компания распалась, а не просто так он ищет работу ради высокой ЗП.
Если раньше у него было выбор между собеседованием на следующей день в Рога и Копыта, а на след. день офером, то сейчас идя в любую компанию это 3+ интенрвью. Дак зачем мне нужны Рога и Копыта и подготовка к ним на полгода, если я с тем же успехом пойду в какой нибудь Яндекс с большей ЗП и плюшками? (да возможно проект там будет не подуше, что в конечном итоге возможно убьет в душе хорошо программиста) Один хрен тоже время готовится к интервью, а ЗП больше.
Так что по моему мнению если раньше компания мид-грейда могла получить хорошего программиста или плохого, с вероятностью 50/50, то теперь это 10/90, потому что все меньше сеньеров настроены идти в Рога И Копыта, учитывая необходимый уровень подготовки. А теперь представьте какую нибудь e-commerce (маленькую компанию) только что открывшуюся, она готова брать с лайтовым интервью, потому что у них нет опыта, но вот беда из за того что большая часть компаний требует каких то нереальных интервью, люди начинают думать что все компании так делают.
В итоге мы теряем маленькие компании, а средние ищут прогреров по полгода. Зато корпорации процветают — что идеально для них.
balexa
25.12.2019 10:39В итоге мы теряем маленькие компании, а средние ищут прогреров по полгода.
Тут как раз проблемы нет. Если вы Рога и Копыта — не стоит изображать из себя Эпл и Гугл в одном лице. И да, стоит смириться с тем, что офигенные разработчики вам не по карману.
А если вы ищете среднего прогера полгода — либо у вас завышенные требования, либо заниженная зарплата.VolCh
28.12.2019 19:57Суть комментария выше, что разработчики ожидают от "Рога и Копыта", что там тоже будут просить сортировку писать на собесе, а потому идти туда особого смысла нет, если в условном Гугле или Яндексе будут справшивать то же самое, а предложение сделают лучше.
0xd34df00d
25.12.2019 05:00ЗП — не единственный мотиватор. И даже с некоторого уровня не основной. Вот ещё, например:
- Решаемые задачи.
- Технологический стек.
- Количество легаси.
- Количество бюрократии и формальных правил.
- Личные знакомства.
- Отношение к вашему опенсорсу в личное время (я поэтому в гугл не пошел, да).
- Социальная политика компании (и поэтому тоже).
kreo_OL
25.12.2019 05:39А от куда вы уверены что эти сеньоры устраиваются потом на подходящие должности? У них могут быть и личностные особенности изза которых например задолбавшись найти работу подходящую идет на завод по производству упаковки сисадмином за теже деньги. И пилит там же на работе фриланс\пет\опенсорс. Лично знаю такого. И не исключаю случаев когда сеньор который мог бы поднять какую нибудь компанию на уровень выше, идет просто в другую сферу\должность где если он и может чтото поднять, то все ровно этот взлет остается незаметен.
khim
25.12.2019 19:35А от куда вы уверены что эти сеньоры устраиваются потом на подходящие должности?
Ну приходят-то они «с богатым послужным списком». Предположить, что он оборвётся из-за того, что вот конкретно мы им отказали — это уже какой-то совсем яростной манией величия обладать.
PleaseKING
25.12.2019 08:47А теперь представьте что SSE нужно потратить на подготовку с полгода чтобы пройти у вас интервью идеально (да конечно он хочет пройти его идеально он 10 лет в отрасли), а вы mid-grade компания, куда он пойдет к вам или в какой нибудь Google?
Зацепило про 10 лет в отрасли — а что тогда те, кто 20 лет в отрасли? 30 лет в отрасли? Они — кто? Я вот уже 18 лет в отрасли и знаю кучу людей опытнее меня…
avengerweb
25.12.2019 09:05Дело ведь в не в годах, а во отношение. Себя к себе, многие программисты считают себя недостаточно хорошими, хотя на самом деле это не так, что приводит к более долгому периоду подготовки к интервью, самокритика все дела
kx13
25.12.2019 01:04На мой взгляд, Senior, может не помнить как реализовать ту или иную сортировку, но должен хотя бы знать какие бывают сортировки их плюсы, минусы и порядок работы.
Придумать какой-нибудь примитивный и не эффективный алгоритм сортировки достаточно несложно. Можно просто на этой задаче посмотреть как кандидат справляется с задачей. Как с алгоритмом, так и с реализацией. Это тоже будет маркер квалификации.
Вообще задачки по программированию сами по себе ничего не решают, это лишь еще один штрих (конечно весьма весомый) к "портрету" кандидата.
Когда я провожу собеседования, даже с Senior разработчиками на практической части я даю относительно простые задачи уровня FizzBuzz, знание каких-то базовых конструкций языка и иногда задачу на сортировку с помощью библиотечной функции.
Таких задач около 10, все они достаточно простые, но из разных предметных областей.
При этом хорошо видно на сколько кандидат хорошо умеет программировать и какие у него знания в разных областях.
3263927
25.12.2019 01:41однажды, ещё когда не умел программировать, помог незнакомой девушке на улице сумку донести до дома. разговорились по пути, она оказалась HR в какой-то компании. я её спросил есть ли какой-нибудь секрет, как устроиться на любую работу? она мне по секрету сказала, что в Москве тебя полюбому возьмут если вместо "сколько я буду получать" кандидат спросит "что я буду делать"
realimba
25.12.2019 02:08Возьмем например ORB SLAM 2 (https://github.com/raulmur/ORB_SLAM2/blob/master/src/System.cc), казалось бы, невероятно продвинутые в матане и алгоритмах исследователи и такая лютейшея реализация с детскими косяками, утечками, дедлоками и крешами на ровном месте. И что интересно, большая часть научных проектов с доступными исходниками — просто дичь! Как же так, ведь такие умные люди… :D
emmibox
25.12.2019 04:47Они не программируют ради программирования — а задачу решают.
Задача быстрой сортировки решается вызовом qsort из стандартной библиотеки или из апи виндов. т.е. буквально — в одну строку!
bondeg
25.12.2019 03:55Пока вы там сортируете, сеньор решает реальные задачи, проектирует и пишет понятный код, оптимизирует проект, трезво оценивает сроки, задаёт нужные вопросы по ТЗ и учится.
Static_electro
25.12.2019 09:14+1оптимизирует проект
Вот. Вот здесь оно, "написание сортировок".
bondeg
25.12.2019 17:33Это только в случае если сортировка оказалась узким местом. Такое бывает крайне редко в реальной жизни. А если уж случилось — с этим реально справиться даже не помня алгоритмов сортировок до возникновения проблемы.
khim
25.12.2019 19:38Это только в случае если сортировка оказалась узким местом.
Если вы это выяснили это после написания кода — то уже поздно что-то оптимизировать.
Прикидки с учётом «O большого» и всем известной таблички должны случаться до того, как вы свою любимую IDE запустите.bondeg
25.12.2019 20:01Если у нас бекенд на вебе — то никогда не поздно)
khim
25.12.2019 20:31Это если вас не волнуют денежные затраты. Передалка неправильной архитектуры в правильную зачастую стоит дороже, чем создание правильной архитектуры с нуля.
То есть даже если кто-то вам неправильно спроектированную версию подарил забесплатно — это всё равно может быть невыгодно.
ashofthedream
26.12.2019 18:08у меня тут не так давно была микро задача по оптимизации, страница долго грузиться, происходит следующее, мы достаем 1-2к записей из базы, дальше происходит следующее, делаются некоторые преобразования этой записи, добирается инфа по этим записям из редиса, дальше, программист этот список сортирует и делает distinct по этому листу, в итоге получаем примерно 10% от всех записей, которые и отдаем на клиент.
Моя оптимизация, которая стала работает примерно в 10 раз быстрее заключалась в двух вещах, первая, использование TreeSet, которая делает все эти операции при вставке в него, вторая, добирать данные после того как мы избавились от лишнего мусора. Потому что отсортировать список и сделать из него дистинкт — копейки по сравнению с десятикратным уменьшением доставания данных из редиса.
Когда я спросил, а зачем он так написал, ответ был прост — ну я не подумал, у меня это как-то быстро работало и так. Действительно зачем думать, зачем знать как работают структуры данных, зачем что-то знать про сложность операций. Он же сеньор, это он прошел когда учился в институте.khim
26.12.2019 19:08Он же сеньор, это он прошел когда учился в институте.
Если бы «прошёл». Он это всё «сдал». Успешно. Себе — ничего не оставил.ashofthedream
26.12.2019 19:18Ладно, в моем примере действительно не важно потрачу ли я дополнительные миллисекунды на эти две операции (было бы важно, то вполне возможно был бы вручную написан мержсорт, который на стадии merge уже отбрасывал бы все лишнее. Но серьезно, ты не подумал, что вначале надо это отфильтровать все, а потом уже слазять за данными в редис? ну то есть тебя не смущает, что у тебя происходит в 10 раз больше ненужных вызовов.
И да, я понимаю почему это произошло именно так, он не конченный, как может показаться, просто он использовал метод, который возвращает все данные при загрузке, ну то есть лезет в базу, и потом для каждого проходится и дополняет данными из редиса. И дальше происходит фильтрация. Банальная невнимательность? Не понимание, что сейчас достаешь не пяток записей, с которыми придется работать, а там еще дальше куча всего происходит, прежде чем тебе потребуется дополнительная часть данных. В итоге, метод, который должен работать. Хорошо хоть не на каждую запись ходили в редис, а мультигетом…VolCh
27.12.2019 07:56А может всё куда банальней? Требование фильтрации появилось позже и не в том виде, в котором сейчас?
ashofthedream
28.12.2019 13:52Два момента, история гита говорит о том, что если оно появилось позже, то все равно это было в рамках работы над этой задачей. А во-вторых, если бы оно появилось позже и менялось со временем, это не повод не смотреть на уже написанный код и понимать что там написано.
То есть, по второму пункту, если завтра придут и скажут, что нужно, например, только последнюю записи, то он просто в конец этого кода добавит «взять последний элемент из того, что получилось», потому что требование изменилось, нужно просто любыми способами, как можно меньше меняя код построиться под эти требованияVolCh
28.12.2019 20:01Может просто "нужно вчера, сделай как можно быстрее и создай таску на рефакторинг/оптимизацию в бэклоге". И так там эта таска годами может лежать.
ashofthedream
28.12.2019 01:09и еще сотня-другая внешних причин почему программист — лапочка, а все остальные делают так, что бы эта лапочка плохо работала. Увы, большинство программистов косячат только в путь, более того, я сам кучу своих косяков могу вспомнить, причины — разные, но это мой косяк, не посмотрел, по думал, не так понял, не уделил этому должное внимание.
Только вот в какой-то момент ко мне пришло критическое мышление, а кому-то, хоть он и сеньор — нет, поэтому для него такие вещи, это обычно дело.
Хватит оправдывать программистов. Если человек написал дерьмовый код, то ему стоит сказать, что он написал дерьмовый код, и пусть думает дальше, как избежать этой ситуации в будущем. А то уже пришли к тому, что на ревью надо общаться, узнавать как у жены-тещи-собаки дела, и говорить аккуратно «мне кажется ты делаешь что-то не правильно, пойти это только мое мнение, но вот тут не стоит на каждый запрос выбирать все данные из пяти терабайтной базы, что бы найти одну сущность, знаешь, в базе данных можно выбрать одну сущность, и более того, существуют индексы...», что бы потом услышать «Ок, я услышал твое мнение, но мне так проще».
svr_91
28.12.2019 09:02+1> но это мой косяк, не посмотрел, по думал, не так понял, не уделил этому должное внимание.
А я частенько бывал и с другой стороны этого утверждения. Сделал слишком заумную архитектуру, наложил слишком много ограничений и т.д. В результате часто от этого огребаешь. И это даже обиднее, чем просто «забил и пустил на самотек»: ты тратил время на продумывание архитектуры, крайних случаев, примеров использования, нетривиальную реализацию, а по итогу оно все также не работает.
Вот например, у меня есть один проект, в котором основная часть кода — ну, не совсем дерьмо, но на самом деле, ничего особенного. Глазу незачто зацепиться. Я знаю, как навесить вокруг этого кода офигенную архитектуру, которую хоть в рамочку вешай и всем показывай. Но проблема в том, что эта архитектура опирается на некоторые ограничения. И почти наверняка, когда я закончю эту архитектуру писать, придет менеджер с задачей, которая эту архитектуру как раз ломает (я даже знаю такую задачу, но чтото менеджер о ней уже давно не вспоминает). И что в результате мне с этим делать?
Сейчас, если такая задача вдруг возникнет, я смогу ее взять и реализовать в коде. Да, код станет еще большим говном, но и задача будет сделана. В случае же «классной» архитектуры, там даже костыль для этого дела придумать будет не так то просто.
В результате, довольно часто бывают такие ситуации, когда в какой-то части проекта код — гавно, но ты об этом не знаешь. Вот когда в ту часть кода придет задача, то ты посидишь, подумаешь и исправишь. А если в ту часть кода никаких задач нет — то и исправлять там нечего
VolCh
28.12.2019 13:35А я в основном могу вспомнить только сознательные "косяки" (тактически оптимальные решения), с туду-комментариями и(или) тасками в бэклоге технического долга, которые принимаются во внимание в оценке следующей задачи, которая затрагивает этот кусок кода.
Иногда, да, бывает "Блин, кто эту чушь написал?! Бл..., я, если верить гит логам", но редко
svr_91
28.12.2019 14:07> То есть, по второму пункту, если завтра придут и скажут, что нужно, например, только последнюю записи, то он просто в конец этого кода добавит «взять последний элемент из того, что получилось»
Както делал на одной работе нечто похожее. Правда там не было тех разительных x10, но логика была примерно такаяже.
Проблема в том, что если сейчас убрать весь этот код, оставить только нужное, то потом хрен найдешь, как оно там было раньше, как в эту базу ходить, да и индексы все уже давным давно потерты.
pyrk2142
25.12.2019 16:10Если смотреть с другой стороны, то те же сеньоры пишут код, из-за которого текут данные, придумывают архитектуру, из-за которой сканы паспортов лежат в /uploads/images/1.jpg, оптимизирую приложения так, что они падают от 10 параллельных запросов и выжирают месячный бюджет за 10 минут, а исправить это они не могут, так как сроки горят. Встречается такое в каждом втором посте из раздела /ИнформационнаяБезопасность/. Возможно, лучше бы сортировки писали.
bondeg
25.12.2019 17:31Тогда возникает вопрос, а сеньоры ли они на самом деле.
khim
25.12.2019 19:39Вопрос-то возникает, а как вы предлагаете на него ответ давать?
bondeg
25.12.2019 20:05Ни разу не нанимал их, так что сложно сказать. Но скорее всего это были бы смоделированные реальные ситуации, чтобы посмотреть как кандидат поведёт себя в них, какие решения предложит.
khim
25.12.2019 20:41Я тоже этот подход предпочитаю… но на самом деле никакой разницы между «смоделированными реальными ситуациями» и написанием сортировки — нет особо.
Да, я вот прямо задачки из учебника обычно не даю… люди обижатся. Но даю что-то похожее из практики.
И вот как-то так получаются что есть люди, которые их решают — и они же прекрасно пишут сортировки, если нужно… а есть те, кто этого сделать не могут — зато они могут прекрасно обсудить все перепитии, которые привели нас, когда-то, к этой задаче — вот только код написать не могут.
Ну вот типичная задача из этого списка: есть два односвязных списка, которые в некоторый момент «сливаются»… найти расстояние до этой точки от двух указателей, которые вам передаются в качестве аргумента — желательно не проходя эти списки до конца.
И вот есть люди, которые могут выпытать у меня — откуда взялись эти списки, какая версия Internet Explorer у нас была, когда мы упёрлись в производительность и массу других вещей.
Чего они не могут — так это взять и… написать код. Который решит эту задачу.
Ну и? Нафига они нам на позиции SSE? На PM'а — они бы, возможно, и подошли бы, но там другие задачи и другой вид собеседования…
kimisa
25.12.2019 07:04Я тоже не понимаю зачем знать и уметь реализовывать сортировки. Что это дает? Оно поможет создать грамотную архитектуру проекта или базы?
За много лет работы мне эти сортировки не понадобились. Да, на заре получения образования и их проходила. Но успешно забыла, т.к. за все время моей работы они мне не понадобились. Да, для собеседования опять их прочитывала, но через неделю опять их забыла из-за ненадобности.
Не знание сортировки говорит о том, что я полный ноль?
Сеньеор — это человек наступивший на сотню граблей. Он имеет опыт как не наступить на аналогичные грабли.
Он должен увидеть, что тут нужно подцепить библиотеку и суметь определить какую. А где не нужно ничего подцеплять и писать свой велосипед, т.к. по этому моменту все библиотеки кривые.
А так же он должен видеть весь проект и корректировать работу джунов и мидлов.
Что у него спрашивать на собеседовании? Конечно опыт. С какими технологиями работал, какого размера был проект. Если человек дорос до сеньеора, то нет смысла задавать ТЗ — писать код. Это он уже показывал ранее, когда был джуном или мидлом.grondek
25.12.2019 08:43Как минимум надо чтобы при слове, например, quicksort у человека в глазах появлялось понимание что есть такое понятие и он знал где, зачем и как можно ее применять. Хорошо, если он может в двух словах описать ее принцип — если читал про нее ранее, что-то да отложилось в глубинах памяти.
Из моего опыта (я вроде бы мидл). Я 2 раза с перерывом в 3 года собеседовался в одну и ту же компанию. Первый раз меня попросили реализовать итератор для чего-то там. Ну блин, я каждый день их использую, но я не реализую его на доске за 30 минут, потому что их внешнее поведение мне нужно, а подробности их внутрянки мне нафиг не нужны постоянно.
Второй раз была более практическая задача на те же 30 минут, я предложил решение, о котором интервьюер даже не думал. Первый раз завалил интервью в итоге, второй раз все норм было.
P.s. А почему синьор не должен писать код? Может, конечно, от размера команды зависит. В небольших командах все равно это умение нужно, кмк.kimisa
25.12.2019 08:52Как минимум надо чтобы при слове, например, quicksort у человека в глазах появлялось понимание что есть такое понятие и он знал где, зачем и как можно ее применять. Хорошо, если он может в двух словах описать ее принцип — если читал про нее ранее, что-то да отложилось в глубинах памяти.
Если вы учились в институте, то должны уметь вычислять тройные интегралы. Вы мне сходу сможете его вычислить? Сомневаюсь. И сомневаюсь, что за час вы это легко и просто воспроизведете по памяти. Но вы же это учили. Так и здесь. Мне в работе это не требуется. Когда она требуется — для решения необычных задач. Это как на конференции было рассказано — решали задачи по быстрому открытию больших файлов. В жизни это может потребоваться на очень серьезных проектах, таких как ВК. Да, там большие нагрузки и там действительно они и сам PHP пилят. Но сколько у нас таких проектов?
P.s. А почему синьор не должен писать код? Может, конечно, от размера команды зависит. В небольших командах все равно это умение нужно, кмк.
А я утверждала, что он не должен писать? Я просто имею в виду зачем проверять на собеседованиях и так очевидное? Если бы он не умел, то не стал бы сеньором.PleaseKING
25.12.2019 10:20Вклинюсь — беда в том, что у вас и у кандидата могут быть очень разные представления о том, что такое сеньор. Вы подразумеваете способность писать код, а по факту ее может не быть, она может быть утрачена, — есть много вариантов.
Если бы не надо было бы это проверять — вообще можно собеседования не проводить.
- Сеньор?
- Конечно сеньор.
- Отлично, принят!
kimisa
25.12.2019 10:40Обычно к этому моменту есть хоть что-то, выложенное на гихаб или битбакет. Разве этого не достаточно? Ну и плюс обсуждение что делал до этого. Разве нельзя будет понять что делал действительно человек или нет?
PleaseKING
25.12.2019 19:40Совсем не факт, что есть, совсем не факт, что написано именно кандидатом, совсем не факт, что самостоятельно… и это все же косвенные данные — куда проще получить прямые, просто попросив написать код. И масса народу сразу отсеевается.
khim
25.12.2019 19:43Обычно к этому моменту есть хоть что-то, выложенное на гихаб или битбакет.
Вот как раз у синьоров очень часто если чего и выложено — так это что-то пяти, а то десятилетней давности. А то, что он делал в этом году — оно под NDA и вообще принадлежит не ему, а его работодателю.
«Живых» профилей на GitHub, на самом деле, примерно на два порядка меньше, чем программистов. Так что если отсечь всех, у кого на GitHub ничего нет за последний год — то это будет фильтр куда как пожёще, чем просьба написать сортировку.
VolCh
28.12.2019 20:03Хорошо, если он может в двух словах описать ее принцип — если читал про нее ранее, что-то да отложилось в глубинах памяти.
Читал, и даже реализовывал на лабах. Отложилось только, что быстрая :)
valergrad
25.12.2019 15:26+4«Если человек дорос до сеньора, то нет смысла задавать ТЗ — писать код. Это он уже показывал ранее, когда был джуном или мидлом.»
Мысль на первый взгляд кажется логичной, но она разбивается о суровую действительность.
Когда устраивался на свою вторую работу ( меньше чем через два года после универа ) я получил должность Сеньора. Сейчас, спустя 9 лет, я все еще сеньор. Был ли я сеньором по моим нынешним стандартам 9 лет назад или для своей нынешней компании? Нет, определенно нет. Но для той компании XXX я был именно сеньором.
Так что, довольно очевидная мысль: сеньоры в разных компаниях разные. Если у человека в резюме написано «сеньор», это не означает что его уровень достаточен для «сеньора» в вашей компании, может даже на миддла недостаточен. А когда много собеседуешь, то периодически видишь «сеньоров», у которых знаний меньше чем джунов — особенно этим славится Индия, Пакистан и прочая Азия — 6-8 лет опыта в резюме, но весь этот опыт скорее всего существует только на бумаге.
Поэтому базовая проверка «может ли кандидат писать код» — как ни странно отсеивает очень много таких мошенников. Оказывается, что научиться пи.., простите, разговаривать, о технологиях, с которыми ты якобы работал — это несложно, любого индуса можно за пару недель научить или даже дней. Прочитает несколько статей на темы о которых написано в резюме и готово — разговаривает как живой. А вот писать код, который будет работать — здесь прочитать пару статей не получится, здесь крайне сложно сэмулировать, это можно продемонстрировать на собеседовании только если ты действительно умеешь писать код.
Это как «разговаривать о футбольной стратегии и тактике» и действительно играть в футбол — каждый первый мужик в стране может часами разговаривать о том, кого надо было выпустить на замену и какую схему надо было выбрать, но попадать по мячу может дай бог один из тысячи.
ashofthedream
26.12.2019 17:45окей, есть задача, есть таблица лидеров, туда постоянно, 150-200 раз в секунду добавляются данные, кто-то сыграл в игру, получил очки и в рейтинговой таблице должен измениться его статус, у игрока было 20 очков, он получил пять, соотвественно он должен подняться выше (или опуститься ниже), потому что за это время все соседние игроки получили гораздо больше очков.
Плюс мы должны уметь обращаться к этому списку по индексу (требуется отображать кратко эту таблицу топ-10, пяток лиг, и мы должны показывать топ-10 в каждой лиге, и еще +-5 окружающих игрока).
Какую библиотеку мне следует подцепить, что бы оно работало? Ах да, количество ридов этой таблицы примерно 300-400 в секунду.svr_91
26.12.2019 18:08А какой размер таблицы? 150-200 раз в секунду не выглядит слишком большим числом
ashofthedream
26.12.2019 18:09до 200-300к записей за свое существование вырастает.
svr_91
26.12.2019 18:10Тогда да. Приличненько
ashofthedream
26.12.2019 18:11причем как и любой лидерборд у нее очень большой тейл, особенно игроки, у которых 0 валяется, опять же, так маркируются игроки, которые уже сыграли во время чемпа хотя бы одну игру
svr_91
26.12.2019 18:20Вообще, конечно зависит от более полного описания задачи. Если мы не хотим потерять эту таблицу при перезапуске сервера, то имя такой библиотеки — *sql
ashofthedream
26.12.2019 18:28конечно не хотим, поэтому все данные у нас и так есть в скуле, но вот работаем мы с уже построенной таблицей в памяти, приходит ивент — игрок сыграл в игру +20 очков ему, мы сохраняем это в базу, и в базе у него уже будет обновленное значение, а дальше вставляем в нашу вьюху в памяти.
Все обновления были в одном треде, плюс индекс из map<userId, entry> сразу на нужную запись в list, что бы подвинуть ее при апдейте.
Более того, изначально были апдейты делать list<bucket>, что бы можно было сразу мувнуть запись на очень много позиций вверх, но самая простая реализация работала очень неплохо на таком объеме данных, обычно приходилось делать не больше 20-30 всплываний записи за раз, иногда бывали всплески когда двигали на 3-4 сотни, но это было нечасто.svr_91
26.12.2019 19:14Мм. Может, я чегото не понимаю, но почему бы сразу не читать из sql?
ashofthedream
26.12.2019 19:32у меня entry выглядит следующим образом idx, score, userId. В базе — userId, score. Мне нужно достать топ и показать пользователю следующим образом — top10 в каждой лиге, а их допустим 5, и они все допустим расположены примерно так 1-10, 11-100, 101-1000, 1001-10000, 10001 — end + 5 окружающих от пользователя, а он в рейтинге на 150 месте с 2420 очками, то есть у меня список, который я отправлю пользователю будет такой:
1 (7810), 2-10,
11 (6790), 12-20,
101 (4200), 102-110,
145-149, 150 (2420, наш пользователь), 151-155
1000 (990), 1001-1010
10001-10010
Как это правильно достать из базы?svr_91
26.12.2019 20:25Ну хотя да, я что-то не подумал, что вычислить конкретное место в таблице будет несколько сложно. И спозиционироваться к определенному месту тоже. Хотя, базы данных сейчас умные. Может там что-то придумали специально для этого
ashofthedream
26.12.2019 20:38я немного подумал. как бы можно было бы это в базе сделать, но тут один момент, больше связанный в перфомансом: в своем списке, когда сущность всплывает, я меняю еще значения idx, ну то есть есть прилетает UpdateScore(13, 20), я делаю Entry e = entriesByUserId.get(update.userId) и дальше лезу в метод который меняет лидерборд примерно так:
[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)
svr_91
26.12.2019 21:17Тоже немного подумал, как это сделать в базе.
Разобьем базу на подбазы с лимитом по 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 на чтение.
Понятно, что это все равно в десятки раз медленнее велосипеда (и сложнее), просто, разминка для ума.
Можно попробовать реализовать. Быстрее текущего решения понятно что не будет, но в ограничения можно попробовать уложитьсяashofthedream
26.12.2019 21:43Вот кстати это очень похоже на одну из оптимизаций, которую мы хотели применить, потому что боялись, что все таки вставка работает то o(m), и может быть например o(n) в худшем случае, а это уже очень долго, но все таки погоняв в реальной жизни оба варианта остановились на первом, а косяк с «все зависло на полчаса потому что мы обновляем наши полтора миллиарда записей, потому что кто-то с последнего места выбрался в топ...» решались при помощи несколько апдейтов, гранулярно, например +50000, можно разбить на кучу мелких апдейтов по 1к очков, спайки исчезнут
svr_91
27.12.2019 08:56Ну да, просто обсуждалось, можно ли это реализовать на sql-е. Вроде можно, правда на порядок сложнее. Но может, в sql-е уже есть специальный индекс на эту тему, нужно бы поискать
michael_vostrikov
26.12.2019 21:16А зачем тут сортировка, если event приходит на одного игрока? Пришел event — поменяли место игрока. Это один шаг из сортировки.
ashofthedream
26.12.2019 21:29у нас есть отсортированный список, мы изменяем значение и должны сохранить его в том же отсортированном виде, ну то есть из
30 25 20 15 13 11 5 3 0, если у нас происходит изменение например 11, прилетело +10, мы должны поменять местами несколько записей, это и 13 и 15 и даже 20.michael_vostrikov
26.12.2019 21:34Ну да, нашли нужное место, поместили туда, остальные сдвинули. Сложность O(N). Вызов сортировки здесь не нужен, ни библиотечной, ни самописной.
ashofthedream
26.12.2019 21:40давай я сошлюсь на том, что я это сделал вдохновившись баблсортом, а не использовал что-то вроде:
idx = getIndexByUserId.get(userId);
leaderboard[ids].addScore(20)
leaderboard.sort()
leaderboard.each(index, entry -> getIndexByUserId.put(entry.userId, index))
Ведь мне нужен отсортированный массив и значит я буду использовать библиотечный метод. А индекс, потому что мне старший сказал, что поиск в списке очень медленныйmichael_vostrikov
26.12.2019 21:48Так даже не зная баблсорт это можно сделать, просто потому что по-другому сделать нельзя. Ну если не сортировать каждый раз заново конечно, что нормальный senior и не будет делать. О том и была речь в исходном комменте этой ветки — необязательно знать сортировку, чтобы правильно решить задачу.
JustDont
26.12.2019 22:49Я чего-то недопонял может, но к чему тут сортировки вообще? Задача вообще выглядит как небольшое упражнение на структуры данных: связанный список тут быстро справляется со всеми нужными операциями кроме «подвинуть элемент из конца в начало», там придётся весь список проехать. Ergo, просто взять связанный список, и потом отдельно оптимизировать операции «длинных» перестановок по нему?
ЗЫ: Это как раз один из тех редких случаев, когда явовский LinkedList уместен.michael_vostrikov
27.12.2019 00:04Ну потому что этот пример был в качестве возражения на коммент про сортировки и библиотеки. Непонятно, что в нем сложного, что надо алгоритмы знать и на собеседовании их спрашивать — передвинуть элемент в массиве со сдвигом других.
ashofthedream
27.12.2019 00:22И опять же, почему все привязались к этим сортировкам, есть много что спросить из алгоритмов и структур данных. алгоритмы != пять основных видов сортировок, да, это достаточно большая и объемная тема и для других алгоритмов, но например задача про этот лидерборд очень показательна, потому что люди иногда такую ересь придумывают, что хочется плакать. И да, многие считают, что можно использовать стабильные сортировки так как это будет быстро, т.к. только часть элементов будет перемещена.
khim
27.12.2019 00:57Если использовать уже упоминавшийся тут где-то timsort, то да — это будет достаточно быстро.
Достаточно ли быстро для ваших нужд или всё-таки всё равно нужно писать кастомный код… это нужно побенчмаркать… кастомный код можно довольно сильно дооптимизировать вот именно под случаи «небольшого сдвига».
ashofthedream
27.12.2019 00:18LL в чистом виде тут будет работать плохо, потому что, обращение по индексам, но его модификация — skip list, хорошо бы отработала, но мое решение было написано буквально за пару часов, и черт подери, оно для нашей набора данных работало очень неплохо, оптимизации планировались, но так и не вернулись к ним, банально было лень переделывать и так хорошо работающий механизм
Pavenci
25.12.2019 09:39Ни разу не было алгоритмов, сортировок, олимпиадных задач потому что я сознательно игнорирую предложения от больших корпораций, которым 100% на меня будет начхать.
Отдаю предпочтение mid компаниям, где ты являешься по-настоящему частью команды и от твоих решений и действий, как разработчика напрямую зависит работа бизнеса (прода). Могу отметить, что в таких компаниях ситуация на собеседованиях бывает разная, но у меня чаще всего была просто дружеская беседа, в ходе которой сразу видно как человек мыслит. А практические скиллы проверяются либо одной задачкой из реального кейса компании либо обсуждением github или pet проекта. Не встречал ещё опытного разработчика, у которого бы не было своего проекта для души.
И на мой взгляд это гораздо интереснее, чем потеть на интервью, где за 20 минут надо вспомнить что-то, что никогда не пригодится тебе в работе.
Для смеха, вспоминаю одно собеседование, где в теоретической части утомительно спрашивали определения из учебника. Естественно я их дословно не зубрил, отвечал рассуждениями из своей практики. И знаете что — они мне в конце такие говорят: «Мы видим что вы больше практик, у вас виден опыт, но нам важна теория, поэтому до свидания» :)))
То есть компании не нужны люди, которые будут работать, создавать продукты, запускать проекты, а нужны люди, которые будут делать что-то неведомое, но явно не развивать компанию.khim
25.12.2019 19:46Не встречал ещё опытного разработчика, у которого бы не было своего проекта для души.
Может быть потому что вы их просто отсеиваете? Я встречал. И не одного.
VMichael
25.12.2019 10:28У меня как то сложилось, что лучший эффект при найме дает «разговор за жизнь» на тему, по которой набираешь людей или устраиваешься на работу.
Тоже проходили задачки прикольные, тесты длинные и короткие, и в итоге остался фактически отбор по резюме и «разговор за жизнь».
На данной работе меня привлекают к интервью кандидатов периодически, но решения принимаю не я (это, конечно, расслабляет :) ), и мне лестно видеть, что кандидаты, которых я рекомендую, работают хорошо, а те, которых я не рекомендовал, но их взяли, приносят некоторые проблемы (в целом конечно и те и те работают, вопрос в нюансах быть может).
Сортировку я не спрашиваю, нам в работе она как то не пригождается, у нас сортирует СУБД. Я считаю разговаривать нужно о вещах, которые будут реально нужны в работе, а не об абстрактных каких то около программистских понятиях.
Если в работе будет написание сортировок или хотя бы нужно будет делать выбор, какую из них применять, то да, нужно о них говорить.
Еще, мне важен психологический климат. Т.е. чтобы мне было комфортно с людьми работать. И я набираю таких людей и устраиваться стараюсь к таким людям.
Очень часто люди, которые требуют, «чтобы потом не приходилось за кем то чего то там доделывать», они не комфортны в общении, с ними психологически тяжело работать, даже если они прямо таки суперспецы. Со временем начинаешь ценить психологический комфорт на работе. И я готов ради этого даже пожертвовать какой то частью дохода, занимая не самые топовые позиции, в не самых топовых компаниях, к примеру. И вопросы на собеседовании и само собеседование это маркер.
Трагедии конечно никакой нет в этом. Компании (люди) набирают тех, кого желают и могут, а люди устраиваются в итоге, куда желают и могут. Равновесие :)
P/S Комментарий выше, появившийся пока я писал, от Pavenci похоже о том же, одобряю ;)Pavenci
25.12.2019 14:04Очень часто люди, которые требуют, «чтобы потом не приходилось за кем то чего то там доделывать», они не комфортны в общении, с ними психологически тяжело работать, даже если они прямо таки суперспецы.
Тысяча плюсов вам. Каждое слово поддерживаю. Кстати, по поводу дохода, он зачастую бывает либо на том же уровне либо даже выше чем у бюрократических машин корпораций (из собственного опыта). Главное чтобы было комфортно и спокойно работать.
Anocean
25.12.2019 12:10На что мозг натренируешь, то он и будет успешно выполнять. И остаётся главный вопрос, что работодателю нужно в конкретном случае. Лучше уж если давать задачки, то по паттернам программирования. Это уж точно пригодится в работе почти каждого программиста.
valergrad
25.12.2019 15:35+3Раньше, лет 10 назад, кандидаты которых отсеивали на интервью по алгоритмам, жаловались «Ну и что что я не помню как там из красно-черного дерева элементы удалять, это все можно нагуглить при необходимости». Это, как я понимаю, перестали спрашивать. Сейчас жалуются на то, что «ну и что что я не помню как работает сортировка слиянием, это все можно нагуглить при необходимости».
Подожду, когда начнут жаловаться «ну и что что я не помню что такое сортировка или массив, это все можно нагуглить при необходимости».Eldhenn
25.12.2019 16:27-1За 19 лет стажа мой опыт работы с сортировками не вышел за рамки вызова sort(). Даже qsort() никогда не вызывал. Есть основания думать, что в ближайшие 30 лет всё останется примерно так же. Зачем мне «помнить как работает сортировка слиянием»?
khim
25.12.2019 19:47Незачам. И идти работать туда, где это нужно — тоже незачем.
VMichael
25.12.2019 20:07Еще незачем идти работать туда, где собеседующий думает, что они тебе нужны ;)
khim
25.12.2019 20:42Ну или так. Только вот беда: идут. А потом обижаются.
Eldhenn
26.12.2019 07:43Ну так вы пишите в вакансии сразу — мы разрабатываем корпоративные приложения, но на собеседовании спрашиваем алгоритмы сортировки.
DrunkBear
26.12.2019 10:45Вот мы плавно и подошли к «требуются молодые стрессоустойчивые фуллстек-сеньоры, опыт от 8 лет, знание 10 фреймворков и всех паттернов», где на экзамене обязательно спросят общие принципы работе нейросети и сколько красно-чёрных деревьев влезет в Empire State Building, а на практике придётся ворошить 15летнее legacy-спагетти без доков, зато полностью зависящее от пары сотен глобальных переменных ( как Oracle database)
ashofthedream
26.12.2019 17:46как я уже говорил выше, многие люди считают, что кроме достать данные из базы, конвертнуть их в другое представление и отдать дальше — задач не бывает.
JustDont
26.12.2019 22:52Ну люди-то в общих чертах правы: всё (абсолютно всё) программирование — это всего лишь преобразование данных. Просто, как говорится, есть нюанс.
ashofthedream
27.12.2019 00:23в пхп так вообще разделение на структур данных нет, там этот, как его — ассоциативный массив
khim
27.12.2019 01:00А в python есть нечто под названием
list, который, на самом деле, как разArrayList.
Если этого не знать, что можно породить такой код, что он даже по меркам python'а окажется недопустимо медленным.
VolCh
27.12.2019 08:02Таки они есть у нас:
SplDoublyLinkedList
SplStack
SplQueue
SplHeap
SplMaxHeap
SplMinHeap
SplPriorityQueue
SplFixedArray
SplObjectStorage
apapacy
Я так и не понял является ли автор профессиональным программистом или профессиональным музыкантом. Кажется ни тем ни другим. При приеме на работу в оркестре музыкантов обычно тестируют по сборникам оркестровых сложностей по виду его инструмента. И все кто хочет играть в оркестре с этим сборником так или иначе работают. Что касается гамм — именно так на русском звучит слово scales — то если музыкант всю жизнь их не играет он рискует потерять скилы еслии это конечно не супергений которому это не нужно.
Что касается знания алгоритмов наверное при приеме на работу в ibm или ms это важно. Для 100500 вебстудии выглядит как лишнее. Хотя сам писал сортировку quicksort при приеме на работу.
Rezzet
Когда-то решал очень сложные тройные интегралы, сейчас квадратное уравнение с трудом решу. Почему так? Да потому что последний раз хоть какое-то уравнение решал 15 лет назад. Я даже задачку по геометрии 7 класса не решу. Это значит что у меня плохое образование? Нет это значит, что давно этого не делал и все забыл. То же самое с алгоритмами и даже синтаксисом языка. Помнишь только то, что делал последние 2-3 года. Зато помню как работает ядро postgress, оно кстати вообще на C написано, потому что буквально пол года назад писал к нему плагин. Помню как отлаживать в windbg, по когда у меня спросили какая функция будет вызвана в простой задачке на с++ я растерялся, действительно сложно удерживать в голове пару десятков правил которые подолгу не нужны и по большому счету применимы в выдуманном коде, причем в таком за написание которого реально уволят, т.к. он нарушает все правила и постулаты «хорошего» кода.
dom1n1k
Но на практике есть огромная разница между состояниями «знал и разбирался, но уже подзабыл» и «никогда и не знал, но в случае надобности обещаю быстро нагуглить, чесслово!»
В первом случае действительно могут быть проблемы написать код сходу, но немного времени и справочных материалов — и всё отлично получится. А во втором даже с гуглежом реализация скорее всего получится кривая, потому что у человека нет понимания. Часто, кстати, даже нет понимания что конкретено нужно гуглить.
JustDont
Да, и не всегда эта разница в пользу первых. Первые — это не только те, которые «если что, быстренько вспомнят», но и те, которые если что, схватятся за устаревшие в данный момент вещи, потому что когда они разбирались — это всё еще было актуально, но сейчас уже нет.
Единственный принципиально важный тут навык — это общая способность человека учиться. Те, кто могут — учатся быстро и продуктивно, те кто не могут — или нагуглят не то, или возьмут устаревшее, и так далее. Впрочем, побочка тут тоже есть — те, кто эффективно учатся — как правило менее приспособлены к тому, чтоб пилить что-то годами на неизменном стеке.
dom1n1k
Быстро устаревают только реализации, то есть инструментально-фреймворковые повертия. Фундаментальные вещи (алгоритмы, структуры данных, архитектурные паттерны, матаппарат) актуальны десятилетиями. Приводимым в статье в качестве примера сортировкам так вообще больше полувека и никуда они не денутся.
А фразу про «общую способность учиться» я слышал много раз. С одной стороны с ней трудно не согласиться. Но с другой, часто за это умение выдают способность прыгать по верхам и жонглировать модными базз-вордами.
JustDont
… на то и фундаментальные, что изучаются один раз и не забываются. Там не такой большой объем информации.
Разница только в том, кто что считает «фундаментальным». Некоторые и алгоритмы сортировки называют фундаментальными. Но да кто ж им доктор.
Не вижу никакой связи, если смотреть по результатам (а по чему еще смотреть, по способности нагнать словесной пурги?).
khim
Никто ж не просит идеальную реализацию вспомнить. Я помню как один из кандидатов вообще «сортировку слиянием в стиле QuickSort» изобразил… сливая каждый раз в новый массив. И что? Это плохая сотрировка? Да — потому что память транжирит. Кандидат «всё понял», напрягся, сделал «merge-in-place» (хотя изначальная задача этого, в общем-то, не требовала), получил от меня хорошую оценку — видно сразу и чего человек помнит и чего он умеет.
Вот последнее чего от вас хочет интервьюер — умения воспроизвести в точности то, что вы когда-то, лет 20 назад один раз на доске увидели… Вот это — точно бессмысленное умение.
Ну, например, по количеству времени, которое уйдёт у меня на то, чтобы «причесать» то, что кандидат, если его примут на работу, сотворит.
И этот показатель для меня важнее чем умение что-то там сотворить «на скорость» исходя из «новых принципов» (которые новые только потому что историю забыли).
JustDont
Это вы щас с барского плеча за всех интервьюеров сказали?
khim
Это то чего меня на тренингах по проведению интервью учили.
Идеальная память в современном мире не нужна — у нас есть компьютеры и Гугл. А вот умение писать код — очень даже нужно. И особенно — у сеньоров.
И да — вот именно это подобные задачи и призваны проверять.
JustDont
Замечательные тренинги. Осталось разобраться, почему (по моему скромному опыту) более половины интервью — это что угодно, но только не попытки понять, может ли кандидат писать код.
khim
Ну потому что «умение писать код» — это требование досаточное только для NewGrad'а. Уже от Junior'а — требуют больше.
JustDont
Я вот вижу, что с навыком чтения тоже часто очень плохо. Требовать от программистов требуют очень многого, но вот оценивать конкретно способность писать полезный код — проверяют очень мало.
Самое частое явление — попытки «проверять» через игру в экзамен по заковыристым практикам; на втором месте — через игру в реализацию стандартных библиотек (от разворотов строк до сортировок до чёрно-красных деревьев).
Желание проверить на чём-то ближе к делу — где-то в конце списка. Хотя казалось бы. Впрочем, даже вот вы, начитавшийся семинаров и (наверное) наслушавшийся прочих умных книжек — усиленно топите за сортировки. Хотя конечно может быть у вас там такая область, что сортировки страсть как нужны и важны. Но я в этом заочно сомневаюсь.
ЗЫ: Я по важным семинарам не ходил, но мое, успешно поработавшее на очень малом количестве случаев, мнение — очень простое. Проверять нужно способность кандидата писать код, именно типичный для предметной области. Проверять это можно не лично, а заочным тестовым заданием. Проверить потом тот факт, что кандидат написал код сам, а не организовал помощь зала — можно банальным FizzBuzz и подобными заданиями. Убедительно выстроить обманную схему, при которой кандидат очно будет настолько же уверенно (или неуверенно) писать простенький алгоритм на 10-15 минут, насколько уверенно (или неуверенно) вылядит его решение заочного задания — весьма сложно. И в любом случае, если вы не гугл или MS — вопрос обмана для вас стоит далеко не на первом по важности месте. А вот вопрос найма кого-нибудь вменяемого, да желательно не очень задорого, на рынке, на котором работников гораздо меньше, чем работы — будет очень важным.
khim
А вот попросить что-то простое, техническое… можно запросто. Если человек, условного говоря, не знает какой рукой за какую ручку рубанок брать — это будет видно сразу.
Вот и сортировки эти и разворачивания списков — это вот такое, простое и техничное средство отсеять тех, кто не знает чем
ifотwhileотличается.Ну вот если вы находитесь в этом положении и для вас действительно важно кандидата не упустить… то да — тут подходы меняются.
Однако на практике — это не самый лучший подход. Гораздо проще и надёжнее начинать искать людей тогда, когда имеющиеся ещё не загружены на 120%… и потихотьку, без суеты и штупмовщины — найти того, кто вам нужен.
Ну не должно быть так, чтобы от того — удатстся ли вам кого-то найти на этой неделе или нет — зависела судьба фирмы.
А если нет спешки — то и ситуации с «рынком, на котором работников гораздо меньше, чем работы» — не будет.
Которое кандидат не будет делать, а просто пойдёт туда, где ему что-нибудь скажут после часового Skype-интервью, а не после двух дней, потраченных на тестовое задание.
Вы вообще-то сами говорили о ситуации с «рынком, на котором работников гораздо меньше, чем работы»… зачем кто-то будет делать какое-то тестовое задание забесплатно, если есть полно предложений, где этого можно не делать?
Отказ от тестовых заданий у нас, например, произошёл не просто так, а после того, как было проведено некоторое количество собеседований по разным схемам и было выяснено, что само предложение тестового задания отпугивает кандидатов куда сильнее, чем любые вопросы на собеседовании.
Причём чем на более высокую позицию ищут людей — тем больше отсев.
kalombo
Вы ошибаетесь, сортировки списков — это простое и техническое средство отсеять тех, кто перед собеседованием не тренировался специально сортировать эти списки.
Полностью с вами согласен, но у меня возникает следующий вопрос, а зачем я буду зубрить сортировки и решать синтетические задачки на hackerrank или leetcode, когда я могу пойти в контору, где оценят мой опыт, а не будут навязывать решение никому ненужных задачек? Собственно, последний раз у меня так и произошло, когда одна небезызвестная контора прислала мне кучу литературы и ссылок на задачки, чтобы подготовиться и пройти их собеседование, то я просто пошел в другую и, потратив 1.5 часа на обсуждение моего опыта и отвечая на технические вопросы, получил оффер. В случае же с небезызвестной компанией мне нужно было бы взять отпуск на недельку другую, сидеть и повторять эти алгоритмы и прорешивать эти задачки.
Static_electro
Так замечательно же получилось в итоге? Вы устроились куда хотели, не напрягаясь.
Dolios
Вот не соглашусь. Я последний раз работал со списками 20 лет назад в универе. Когда стал решать задачки на списки, оказалось что почти все я прекрасно помню. Да, я не помню специфических алгоритмов, типа поиска цикла с О(1) ограничением по памяти, но в целом все довольно хорошо.
То же касается основных алгоритмов сортировок. Достаточно принцип помнить.
И, да, на работе я руками списки не вращаю и сортировок не пишу.
JustDont
Да. Это гораздо лучше, чем спрашивать про круглые люки, или играть в начинающего детектива и дедуцировать, как же человек может готовить, если вы его попросили «что-то простое, техническое...», но на самом деле вам от него обеды нужны.
Вы же понимаете, что ваше «на практике» — оно никак не относится к эффективности найма? Вы просто говорите «а мне норм неэффективно нанимать, потому что я нанимаю заранее и всю свою кривизну процесса найма уже оплатил» (зарплатой людей, которые еще пока не особо нужны). А гуглу норм неэффективно нанимать, потому что у них всё равно будет очередь за дверями, даже если они будут нанимать очень плохо. Это просто перенос проблемы в другое место, туда, где её можно залить деньгами или репутацией, и сделать вид, что никакой проблемы нет.
Сами придумали про 2 дня, сами дальше пофантазировали.
Тестовое заочное задание — оно не для задач на 2 дня. Оно для задач, которые требуют больше 15 минут, потому что на формат очного собеседования на часик протяженные задачи ложатся не очень хорошо — там и без этого есть о чём побеседовать с человеком. Задачу на полчаса или час — тоже лучше давать заочно.
VolCh
Прежде чем вообще думать о процессе испытания (тестовые, собеседования и т. п.) нужно определиться будут к нам кандидаты в очереди стоять или мы каждого с парой ключевых слов в резюме (из нашего списка в 20) будем уговаривать хотя бы вакансию нашу посмотреть. Ну или хотя бы кто ЦА нашей вакансии — люди, которым срочно нужна работа, люди, потихоньку ищущие новую работу с условиям получше чем на текущей, или люди, которые вполне текущей работой довольные.
Вот в последнем случае давать тестовое до собесдования — это похоронить вакансию в подавляющем большинстве случаев, там согласие вообще хоть как-то пообщаться сложно получить, по крайней мере пока не предоставишь "продающую" полную вакансию, описание компании, заказчика, проекта, позиции со многими нюансами техническими и организационными, а не обычные "ищем работника работу работать, требования: знать весь наш стэк"
JustDont
Для таких случаев надо вообще не с тестового начинать, как вы сами же и пишете. А с «а что мы такого вообще можем предложить, чтоб на нас обратили внимание?».
VolCh
Я к тому, что в целом предлагая тестовое, да ещё с самого начала и, конечно, неоплачиваемое, нужно понимать, что сразу отсекаете большой круг потенциальных соискаталей с квалификаций, обычно, выше среднего, если в целом у вас условия средние. Да ещё внятно не описанные.
inkelyad
Зависит от точки зрения. Память, тренировка и знание используемых библиотек и технологий наизусть дают беглость.
Одно дело каждую функцию "ну должна же такая быть в библиотеке" искать по 30 секунд в Гугле. И другое — сразу писать, не отвлекаясь на поиск, а думать о той части кода, которого в библиотеке точно нет и которую, тебе, собственно, и написать надо.
JustDont
Затраты времени на «написать код» в любом случае и рядом не стоят с затратами времени на, собственно, решение задачи. Даже если вы не по 30 секунд на функцию будете в справочник лезть, а по 5 минут.
Если работник у вас в основном пишет код — скорее всего на этого работника приходится еще два работника, которые собственно решают задачи, и выдают ему подробнейшее ТЗ, которое он потом просто транспилирует в код.
inkelyad
А в этом случае знание наизусть помогают задачу не решать, а взять готовое решение. Потому что ты помнишь, где и какое решение уже есть.
JustDont
Набор стандартных функций очень многих языков примерно одинаков. Это никак не меняет того факта, что я не помню, какие именно там в каждом есть функции, и как их вообще применять. Да что там, я на JS, на котором я пишу постоянно и всегда — пишу с открытым MDN, потому что вместо заучивания функций я лучше чем-нибудь более полезным займусь, а документация и гугл никуда не денутся (а если и денутся — у меня будут проблемы совсем иного масштаба нежели «теперь доку посмотреть негде»).
0xd34df00d
Чтобы сформировать связи.
Я не помню особенности арифметики ординалов, но мне потребуется полчаса-час, чтобы вспомнить, а не три месяца на чтение книги по теории множеств, как в первый раз.
khim
Ну если вам потребуется «полчаса-час, чтобы вспомнить» без посторонней помощи, то с подсказками вы сможете что-то сможете придумать и быстрее, скорее всего.
leschenko
Простите, а когда это для QuickSort нужен был новый (дополнительный) массив? Он там не нужен. И что это за такой стиль QuickSort?
Есть мнение, что кто-то сам не так уж хорошо в алгоритмах разбирается, чтобы кого-то "собеседовать". Это как раз тот случай, когда не надо "спрашивать про алгоритмы".
khim
Есть мнение, что умение читать и понимать прочитанное — тоже входит в необходимые умения для Senior Software Engineer. Хотя формально в требованиях к вакансии — этого и нет.
leschenko
Уважаемый, я хотел указать на 2 момента:
О том, что ваш соискатель использовал в другом алгоритме не самое лучшее решение я ни слова не сказал.
Поэтому возвращаю вам назад претензии о чтении и понимании прочитанного.
ashofthedream
Я согласен с тем, что спрашивать на собеседования про алгоритмы сортировки это моветон, хотя есть много интересных задач, которые очень быстро и легко решаются, например при использовании того же mergesort/heapsort.
Да и в целом, как можно доверять человеку, который, например не знает отличия list от set или, например, не может инвертнуть простое сапомисное дерево из нод c value, left, right. Ну и понятия не имеет, что такое сложность алгоритма.
koeshiro
Есть мнение, что такие вопросы можно решить показывая код, и прося определить сложность выполнения этого алгоритма.
khim
Умение читать код — тоже полезно, но оно, к сожалению, отличается от умения его писать.
prishelec
Я высшую математику знал на достаточно хорошем уровне. Сейчас с ходу не найду какую нибудь даже производную. Видно я уже не годен для IT, пора на пенсию.
khim
А вы уверены? Попробуйте. Возьмите листочек бумажки, попробуйте вспомнить — почему оно всё так, прикиньте как могли бы выглядеть производные суммы, произведения, всяких синусов-косинусов.
Потом погуглите — проверьте.
Если вы математику действительно знали (умели отвечать на вопрос "почему синус 30 градусов равен ?", например), то проблем быть не должно: за паутинку в уголке потяните — вся сеть и вытянется…
prishelec
Думаю, что больше, подходит «знал». Первый три курса (вышки) из четырех разбирал материал с удовольствием. На четвертом – уже была работа, поэтому учил по минимуму.
khim
Тогда вот попробуйте взять производную какой-нибудь сложной функции — и засеките время.
Легко могу поверить в то, что времени потребуется раза два-три-четыре больше, чем в лучшие времена.
А вот в то, что ничего не получится… ну не верю.
Вот то, что вы учили на четвёртом курсе — могли и забыть. А первые один-два — наверняка остались в памяти, нужно только «чуток поскоблить».
Viceroyalty
Ну да — и сложные случаи для решения которых нужно вывести теоремы нетривиально следующие из определений и утверждений? Или это уже для интегралов, а с производными все просто? Что-то я забыл матан совсем. Впрочем за 15 лет немудрено.
Чему равна производная логарифма и степенной функции, а также произведения, отношения и аргумента функции я все-равно не помню и знания того что это предел разностного отношения мне не помогут. Там ведь идут теоремы формулировок которых я не помню, а вывести и доказать их самому когда даже не помнишь о чем теорема-то должна быть — увольте.
Так что без предварительного освежения курса мат анализа (или хотя-бы чтения правил дифференцирования) — никак.
Вы сами давно изучали матан? И если да, то освежали ли после обучния раз предполагаете, что человек вспомнит через десятки лет? Или вы знакомы с хаброжителем prishelec и речь идет о нескольких годах?
khim
Как это не помогут? Ну вы же когда изучали всё это выводили их из этого отношения как-то? Неужели сейчас тупее стали? Или нет? Или не выводили? И все эти школьные (a+b)?=a?+3a?b+3ab?+b? — прошли мимо вас? А как же Треугольник Паскаля?
Вы точно не можете этого вспомнить? А может быть не хотите?
Уволить — это завсегда не проблема. Но и вспомнить формулировки — тоже. Если хотеть. Если не хотеть, и придумывать отмазки… дело другое, для этого даже и 15 лет ждать не нужно, забыть что угодно можно и за год — если не хотеть помнить.
Viceroyalty
Сравнили
жопу с пальцемэлементарные вещи и матанА чего мне помнить то, что я не использую даже опосредованно?
И да — как уже говорил в соседнем топике — «шли бы вы в баню» (с)
VolCh
Выводили же, как правило, не самостоятельно, а переписывая с доски. И с неочевидніми преобразованиями. Вот при виде a^2+2ab+b^2 может и шевельнулось бы что-то в памяти, типа вроде была какая-то формула, которую можно погуглить, а при a?+3a?b+3ab?+b? уже нет.
Viceroyalty
в том то и дело, что не очевидно что нужно вывести и что использовать.
Естественно студенты выводят сами и не раз — на коллоквиумах и экзаменах, вызубрить такое невозможно, но что через что доказывается и для чего через 15 лет неиспользования точно никто не помнит. И да — мы же говорим о матанализе а не о школьной алгебре?
VolCh
Так я вас поддерживаю в треде, а не противоречу. И что проблемы даже со школьной алгеброй.
ashofthedream
У меня однажды на собеседовании была задача, написать потокобезопасный map с открытой адресацией, но при этом я это делал на своем ноутбуке, у меня был доступ ко всему интернету, уже подготовленный проект с тестами и у меня было чуть больше двух часов времени и потом я объяснял почему я сделал именно так. И не смотря на то, что это было адски сложно, это было на самом деле круто. И да, за два часа написать это правильно — нереально, если только ты постоянно такие штуки не пишешь. Но важно было то, как я это сделал.
Bronx
А мне однажды предложили в качестве домашнего задания написать потокобезопасный менеджер памяти для объектов фиксированного размера (С++), с тестами (google test) и бенчмарками (google benchmark), и чтобы было production-ready. Сложность задания они оценили "часов пять-шесть".
Я до этого никаких менеджеров памяти не писал, как-то хватало стандартных, у нас не геймдев, но решил развлечься. На выходных почитал теорию, размахнулся и накидал lock-free реализацию, С++17, оформил всё по канону, тесты к ней, комментарии, документация, только бенчмарки не сделал из-за проблем прикручивания google benchmark к visual studio (мы в конторе не использовали его, я честно написал что опыта с ним не имею). Реализация наверняка имела неотловленные тестами баги, но выглядела неплохо, как по мне. Явно не на "часов шесть".
Ответ интевьюера был коротким: "not sophisticated enough". И всё. Я так и не понял, что это было — то ли я действительно слишком туп был для них, то ли интервьюер не разобрался, то ли ещё что-то.
ashofthedream
Одна компания в качестве домашнего задания предлагает написать небольшой язык и иде к нему.
Bronx
Тоже "задание часов на шесть"? :)
ashofthedream
Они оценили это на 2-3 недели, и да, я его сделал. И да, было интересно разобраться в области, которая совершенно не моя.
Bronx
Надеюсь, эту работу оценили не отпиской из 3-х слов.
ashofthedream
Как итог — съездил еще в другой город
tendium
Мой опыт показывает, что если компания действительно ищет человека, то она обычно не имеет мозг сложными заданиями. А со сложным заданием вас с вероятностью 90% отопнут. Вот примеры из моего опыта:
У некоторых собеседователей просто есть психологическая проблема — они ищут подобного себе, но если человек чуток слабже, чем они, то это всё, зашквар, не брать. А если человек чуть-чуть (или очень) сильнее, чем они, то ищется формальный повод, чтобы ткнуть носом и сказать — иди, учись еще, студент. Такое себе самоутверждение.
VolCh
Это может быть не психологической проблемой, а ситуативной логикой. Я собеседовал и кандидатов в помощники себе, и кандидатов в напарники, и кандидатов в начальники себе, и просто кандидатов толком не зная куда, максимум в коридорах или в лифте с которыми, если что, встречаться буду. Всегда подход разный.
А ещё бывает конфликт интересов бизнеса и личных — это не психологическая проблема, а этическая.
khim
У нас как раз подобную штуку один человек писал, так он потратил два часа на написание и примерно две недели на консультации с разными документами на тему правильной реализациии lock-free структур данных.
Я думаю это был сарказм… но сарказм плохо работает в письменном виде.
Bronx
Может и сгодилось бы, трудно сказать. В ходе личного интервью команда рассказывала мне, как они борятся за быстродействие, отзывчивость, память и проч., поэтому мне показалось, что делать на мьютексах — это слишком просто для них, и постарался показать лучшее. Ну и да, бОльшую часть времени у меня отъело чтение теории. Может это действительно был overkill, и ревьюер был саркастичен, но тогда, я полагаю, мне повезло, что я туда не попал.
prishelec
Т.е. вы не дали HR шансов на выигрыш?
ashofthedream
Меня изначально предупреждали, что собеседование займет порядка трех часов и будет одна долгая задача, и желательно подготовиться к этому, а если я не люблю маки, то лучше взять собой ноут со своей любимой осью и настроеным рабочим окружением, что бы не тратить время. Какая именно будет задача — не сказали.