ODuo Batteries@Asker1987
Инженер
Information
- Rating
- 5,134-th
- Location
- Таганрог, Ростовская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Фулстек разработчик, Технический директор
Ведущий
Управление людьми
Управление проектами
Управление компанией
Руководство стартапом
Автоматизация процессов
Построение команды
Последняя фраза улыбнула. Годнота, лайк. На собеседовании спрашивают совсем азы, материал избыточный, но хороший.
Задач огромное множество. Для пространственных хороши.
Муравьиные алгоритмы: больше для транспортных задач (TSP, VRP и их модификации) подходят. Но это медленный алгоритм, нужно аккуратно применять настройки.
Пчелиные: разбиение графа, размещение и т.д. В целом быстрый алгоритм. Алгоритм интересен разноролевыми агентами. В некоторых задачах эта технология проецируется очень классно. Об этом ниже.
Не все роевые алгоритмы применял, каждый год парочка новых, и на практике не впечатлили большинство.
Основной инструмент роевых алгоритмов - технология взаимодействия многоагентной системы и часто разноролевые агенты, поэтому очень любят применять в групповом управлении автономными системами. Например, дроны. Там им равных нет. Разве что ГА, но это если один дрон, а не группа.
100% попадание. Как джавист орнул про собесы в России. Всё точь-в-точь. Токсичность, высокомерие, зачастую желание уколоть. Тупые попытки подловить, необходимость в вопросах про GC так и осталась для меня загадкой, а-ля какой GC появился в 2013-м? Дотошность в паттернах - я как-то начал записывать паттерны - чуть больше 100? половина паттернов в МСА - самоочевидная вещь, которому придумали термин. Если не ответил по термину, то это приравнивается автоматически к незнанию технологий реализующих этот термин/паттерн.
Что самое забавное, самое лёгкое интервью(все 3 этапа) были у... Яндекса!!! Да много кода, да много алгоритмов, но ни на одном этапе не требовалось зубрежных знаний.
Большинство интервьюеров просто испуганные инженеры, у которых синдром самозванца умножается на ответственность за интервью. И все их комплексы начинают вылезать наружу.
Попробуй в codingame.com. Там есть и контесты с мультиагентными системами. Люди часто юзают генетические алгоритмы - иногда даже выигрывают контесты с ГА.
Может, это песочница в сравнении с твоей симуляцией, но хорошая площадка отработать алгоритмы.
Ваше восприятие о заводчанам и таксистами основано на искаженном интернетом ощущении. Это как раз доказывает, что вы далеки от реальной жизни. В реальности, Задорнова давно не показывают на ТВ, ещё до его смерти, что само по себе произошло давно. Задорнов и Малышева - это просто уничитжительные мемы, сгенерированные либеральным прогрессивными бомондом в отношении заводчан, мол смотрите какие они узкие и что они смотрят, они ещё и АУЕ, фу. Ещё и голосуют не правильно, по-любому быдло, давайте стебать их.
1-2. Нет, речь не шла о подзадаче, это многокритериальная задача, эту задачу нельзя разбить на подзадачи (если речь не о пространстве поиска), можно только выделять дополнительные критерии.
3.
Зачем писать, что белое - это белое? Возможно, для какой-то аудитории это новость. Это курс дискретной математики 2 курса технического ВУЗа.
Если не риторический вопрос, почитайте статьи с экспериментальными сравнениями, бенчмаркинг, все в цифрах дают. Особенно в зарубежных любят цифры.
4.
Извините, "читала" - это не опыт. Это отсутствие опыта. Погуглите "решение задачи одномерной упаковки", у Вас на первой же странице вывалятся статьи с именами авторов, в том числе вышеуказанных (не Гэри) и почти все про ГА или рой. На своем веку написал не менее 300 ГА, хотя мой основной профиль - роевые методы. Редко подводят, лучше иногда роевые бывают (муравьиные, пчелиные и т.д.).
На счет оперативности, вернусь к кейсу с управлением роботов. Весьма сложная задача, к тому же с динамически меняющиейся средой. Лучший алгоритм в мире, среди тысяч талантливых программистов. Знаете сколько время отклика алгоритма для принятия решения? 50мс. 50 миллисекунд. Это было жесткое ограничение соревнования, так что 50 мс это достоверно известное время отклика, и никакая быстрая эвристика не могла противостоять. Проблема ГА - высокий порог входа. Не написав пару сотен ГА, не появится навык проектирования эффективных ГА. Так что не спешите аппелировать к опыту, ограниченному лишь чтением. По моему опыту, даже матерые грантоежки со степенями не способны писать эффективный ГА.
Выбор обоснован проекцией моего опыта работы с бионспирированными алгоритмами (эволюционные, роевые). Роевые я отсек интутивно, так как они красиво кладутся на другие задачи, у них механика поиска слишком узкая в отличие от ГА, но дают более эффективные решения там, где их можно приложить. ГА же можно применять в любой непонятной ситуации. К примеру в международном чемпионате по программировани ИИ для роботов с 4-5 тысячами участников 1 место занял кодер, написавший ГА для робота.
В NP-задачах в контексте ГА речь всегда заходит об их модификации. ГА сам по себе - подход эволюционного моделирования, именно подход, а не пошаговый алгоритм. Операторы кроссинговера, мутации и отбора сильно зависят от выбранного способа кодировки хромосомы (решения) и контекста задачи (двигателя эволюции). Поэтому нет точного пошагового определения ГА, это про подход, можно максимум уточнить, какую модель использует ГА - Де Фриза, Ламарка, Дарвина и т.д. Но этого недостаточно для реализации, способ кодировки хромосомы каждый сам для себя определяет, а оттуда все операторы зависят.
Можете минусовать до талого))) Но если не видите своей ошибки, после того как трижды ткнули, то тут уже ничего не поделать. Даже собственные ссылки, которые беспорядочно нагуглили, не проверили. Ну хотя бы откройте свою же ссылку про Collections.sort или про List.sort и почитайте, наконец, хотя бы java-doc в своих же приведенных ссылках кроме последих двух:
This implementation is a stable, adaptive, iterative mergesort
Еще раз: mergesort. От себя добавлю: MERGESORT
Все же дам подсказку: есть такая штука в Java - перегрузки. Ищите свою ошибку.
Светлана, я прекрасно знаком с жадными стратегиями для различных NP задач, это моя специализация. 22% - это фейл в мире оптимизации. Из Ваших же утверждений логично следует (но это и без них понятно), что неизвестно как сильно отклониться от оптимимума примитивный жадный алгоритм. То ли 22%, то ли меньше. Борьба, как правило, идет за 0-1%, а FFD в научных статьях могут упоминать только в качестве сравнения и в учебной литературе.
Попробуйте ознакомиться с другой литературой, в частности по оптимизации. Изучите методы ИИ, эволюционные подходы. Почитайте Курейчика В.М., Лебедева Б.К., Гладкова Л.А. и т.д. Да хоть любую зарубежную статью с бенчмарками - FFD у всех показывает худший результат. Есть мастодонты и в России, не только за бугром все хорошо. Попробуйте реализовать в конце концов генетический алгоритм. Единственный плюс простых алгоритмов, которые приводят ТОЛЬКО для примера - это скорость.
Я уже молчу о том, что одномерная упаковка - это упрощенная модель реальной задачи, а в реальности критериев гораздо больше, что делает пространство поиска гораздо сложнее и не гладкой, а у жадных стратегий строго одна эвристика по одному критерию.
В контексте бизнес-задачи важно было показать, что упрощение и сведение к одномерной упаковке имеет место быть и это доказывает NP-полноту задачи, отсюда можно смело переходить к методам ИИ.
Да уж... Перечитайте ещё раз. Потом можете погуглить, хотя уверен уже многократно пытались. На крайний случай открыть IDE. Шучу, ничего не надо, оставлю просто скриншот о сортировке в Collections. И заметь акцент о стабильности. Можешь попутно погуглить, что это.
Все именно так. Товарищи выше ушли в какие-то странные не имеющие к делу рассуждения. Речь была о том, что мои отклики на вакансии игнорились 99%, я даже ни с кем не общался, никаких интервью, ни скрининга, ни превью, отклоняли на этапе просмотра резюме в хз. Но стоило в своем городе зайти в 2 компании, и от обоих оффер, причем без тех. интервью. Они просто по внутренним каналам вышли на мой нетворкинг. Поэтому да, личные контакты, нетворкинг работают, при большом опыте.
Я вообще не понял: вопрос задан так, будто знание алгоритма решения задачи делает решение задачи медленнее, чем не знание. Эээ... Это что сейчас было? Видимо имелось в виду, что некогда учить и применять алгоритмы на ходу. Но извините, речь о том, что алгоритмы надо знать на входе, именно в этом суть. Если в компанию берут без оглядки на алгоритмы, а потом вы отказываетесь в ситуации, в которой описали, то почему вопрос с претензией к алгоритмам поставлен? Я Вас удивлю, но алгоритмы всегда выглядят короче, эстетичнее, чем сумбурный код O(n^2). Какой-то алгоритм Дейкстра на графах буквально в 6-7 строчек. Если вы не знаете этот алгоритм, но за что не родите его, даже загуглив, уйдет уйма времени на осмысление. А если знаете, то это 1.5-2 минуты. Так что в вашем вопросе, как раз таки камень в огород антиалгоритмистов, а не наоборот.
Видимо, перепутали. В комментарии речь о коллекциях, а не arrays
В этом и ваша проблема. У меня коллега, НЕ олимпиадник. Полтора месяца пытался сделать задачу. Целый сеньор. Сроки сорвались, проект даже до MVP не дошел. Много читал, чтобы решить проблему, но вот беда - он даже не знал, что надо гуглить. Потому что как ни странно ваш тезис - алгоритмы про решение олимпиадных задач - абсолютно нелепый. Алгоритмы придумали из бизнес задач, а на олимпиадах дают упрощённые мат модель реальных задач. И вот сеньор не увидел эту мат модель, вернее не смог клиентскую постановку задачи свести к известной задаче. Это была NP задача, которую никто не увидел. Никто из профессиональных перекладывателей джсонов. Компания упустила жирного Лида. И таких задач полно. Просто когда тупо не знаешь, не можешь это увидеть и даже никаких идей не возникает, что именно гуглить и надо ли гуглить. Начинается хаотичное барахтанье в луже догадок.
Не раз видел подобное в разных компаниях за 14 лет у коллег не олимпиадников.
Светлана, напишите, пожалуйста, критерий оценки алгоритма. Как вы пришли к оценке "прекрасно"? Не в обиду Гэри Джонсону, но это примитивный жадный алгоритм, даётся студентам на лабораторной. Я его лично не знаю, но скорее всего, он просто, как и прочие авторы, приводил все алгоритмы подряд, как пример очередной простой стратегии. У любых NP-задач есть полно различных алгоритмов для решения, и все они как правило, основаны на одной простой эвристике и относятся к классу жадных стратегий.
Сложных алгоритмов не надо. Но если честно, обход графа - это очень простая задача. Обход в ширину и глубину надо знать. 6-7 строк ейбоху не сложно. А в остальном хорошо бы знать хотя бы названия алгоритмов, чтобы человек понимал в какую сторону гуглить. Я в свою очередь наблюдал, как компания теряла лидов, из-за того что вовремя не распознала суть проблемы. А всего лишь нужно было знать о существовании такого класса задач как NP. Если знать хотя бы классы задач, уже можно вовремя остановиться и делегировать на алгоритмистов или на аутсорсинг отдать. Эти задачи часто появляются, просто если не знать, то и не поймёшь, что они есть и есть программы для них. Если не знать, то даже не поймёшь, что гуглить, потому что клиент не приходит с постановкой "дан связный двунаправленный граф с весами". На первый взгляд все видят всегда перекладывание джсонов.
Ну зачем же сразу фаанг? В Яндексе из 4х этапов 2 посвящены написанию алгоритмов и ещё один практически про алгоритмы - оптимизационная задачка. Вряд ли можно обвинить Яндекс в слабых программистах. Если компания не может раскрыть потенциал алгоритмистов, это отчасти проблема компании.
Я тоже читал в профильных группах ВК гневные комментарии об алгоритмах (никто не любит этот порог). Это было забавно, потому что ВК написан 2кратным чемпионом мира по программированию (Николай Дуров, не Павел).
Из-за неспособности генерировать оптимизацию и эффективные алгоритмы, эффективные архитекторы зачастую раньше времени скочат на микросервисы, усложняя преждевременно продукт, а "сопливые" связи гордо именуют "слабосвязанностью".
Считаю, что одна секция на алгоритмы хотя бы примитивные должна оставаться. Это отсекает львиную долю залетных вайтишников. Своим стажерам всегда объясняю, что владеть МРТ(читай фреймворки) это хорошо и необходимо для классного врача, но владеть скальпелем обязан каждый.
За алгоритмы грустно, конечно. Вроде бы они дали результат, судя из текста. Но, судя из того же текста, вы ненавидите алгоритмы как и все. Один из комментариев очень показательный: "я исключил полностью из собеседований то, через что проходить мне не нравилось самому". Думаю, вы этому так же подвержены. Все подвержены. В итоге мы получили новое поколение сеньоров, которые ненавидели секцию алгоритмов в бытность джуниором, и теперь секция "проверка способности мыслить" исключена. Теперь комьюнити отрицает алгоритмы и придумывает всяческие причины доказать свою правоту, вымышленные кейсы о незадачливых олимпиадниках. В то время как все мои олимпиадники (я их тренировал ещё будучи студентом) занимают позиции тимлидов и руководителей отделов разработки в своих компаниях. Самое худшее, что может случиться с олимпиадником - заскучает от вопросов архитектуры, потому что в этом нет вызова, это просто рутинная последовательность действий, описанная многими стоковыми фреймворковыми программистами. Любое знание получается со скоростью чтения, в отличие от алгоритмов - тут требуется умение мыслить творчески.
У меня были такие. Как правило, когда интервьюер не знает как проводить собеседование, не готов к этой ответственности, он начинает сумбурно спрашивать из своего текущего опыта. Особенно за архитектуру. "Вот мы 2 недели решали задачку, планировали архитектуру, ее суть в том-то" и мне предлагают за 5 минут решить то, на что они потратили за 2 недели. Такой подход очень искажен. Если у интервьюера все ответы, проблематика в кеше хранятся, потому что он этим живёт и прямо сейчас занимается, то кандидат вообще не имеет к этому отношения. И от него требуют всегда быстрого ответа, на изучение чего собеседник тратил сопоставимо больше времени. В итоге интервьюер получает искаженное восприятие.
Годнота. Тоже ровно 14 лет в программировании с 2010-го. Программировать сложно. Следовало ещё добавить аспект как раз про возраст/опыт. Способность потреблять некоторый объем информации и держать тонус/фокус обратно пропорционально возрасту/опыту, как ни странно. Если в 22 года ты горишь кодингом и можешь инвестигировать проблему до 5 утра, то ближе к 40, несмотря на весь опыт, переработать большой объем информации сложно. Потому что к 7 вечера ребёнок требует внимания, надо ложиться в 9-10, чтобы утром отвезти его в садик, да и организм не тот, чтобы ночью работать. В 20-25 несмотря на мЕньший опыт у тебя есть люфт во времени и "на половину пустой стакан". А опыт из флешбеков о вымерших технологиях не всегда релевантен. Дорогу молодым! ?