Comments 41
Намного важнее то, какие положительные качества и навыки вырабатывает в себе такой спортсмен:
Командная работа. Вы втроём решаете общие задачи, учитесь распределять нагрузку, помогать друг другу искать ошибки, дополнять решения.
Умение сформулировать проблему. Соревновательная задача обычно описана естественным языком, из которого тебе еще нужно понять суть, составить математическую модель, доказать её, проверить.
Качественный результат. Твоё решение должно решать поставленную задачу, желательно с первого раза. Поэтому, ты проверяешь и перепроверяешь его. Отрабатываешь граничные кейсы, сам придумываешь тесты и сам тестируешь.
Умение работать в условиях ограничений, давления. 5 часов на 10-12 задач — это очень мало, на самом деле. Часто приходится выбирать, в какие задачи вкладывать усилия в первую очередь, а какие отбросить.
Если ты начинающий программист и приходишь на работу в IT компанию, то первые два пункта будут делать за тебя старшие коллеги. Как и четвертый. Третий пункт это в целом база - если программа не работает, от нее нет толка (что в спортивном программировании, что в обычном).
Не раз я слышал о том, что навыки, полученные на соревнованиях или при подготовке, никак не помогают в работе, а в худшем случае, даже мешают и создают проблемы другим.
У спортивного и "бизнес" программирования разные задачи и ограничивающие условия.
В спортивном программировании: ограничения по памяти, производительности, времени на решение задачи.
В "бизнес" программировании: трех ограничений выше в 99% случаев нет. Но твой код должен быть поддерживаемым и расширяемым.
Вот и получается, что навыки вообще не пересекаются, а стремление написать "эффективный" код плохо отражается на действительно требуемых качествах
В спортивном программировании: ограничения по памяти, производительности, времени на решение задачи.
В "бизнес" программировании: трех ограничений выше в 99% случаев нет. Но твой код должен быть поддерживаемым и расширяемым.
Не соглашусь. В бизнесе очень часто эффективность не менее важна чем поддерживаемость. И тут приходится искать баланс и решения где одно не вступает в противоречие с другим.
Спортивное программирование имеет обычно больше ограничений, чем бизнес программирование, и эти ограничения могут привносить отпечаток - будь то выжимание байтов с использованием нечитаемых техник вместо вызова каких-нибудь simd интрисиков, написанием кастомных имплементаций того что и без этого есть в стандартной библиотеке, как результат - нечитаемый код и непрагматичный NIH-синдром. Ну и командная работа в спортивном программировании - это скорее исключение.
Спортивное программирование это скорее индикатор, чтобы показать человеку чего тот не знает и каким подходам можно научиться.
Сразу видно, человек с олимпиадным програмимрованием не знаком.
с использованием нечитаемых техник вместо вызова каких-нибудь simd интрисиков,
На олимпиадах их обычно нельзя использовать. Самый адский хак - это битовая магия какая-нибудь. И даже если ее потом использовать в индустриальном коде, ее запросто можно написать очень даже читаемой.
Ну и командная работа в спортивном программировании - это скорее исключение.
Самое пристижное и популярное соревнование - ICPC - командное. Трем людям дается один компьютер и они должны: разделять задачи, объяснять свое решение, писать его так, чтобы двое других поняли.
Даже без этого в олимпиадной среде надо уметь объяснять свое решение и понимать чужие. Потому что огромный пласт знаний передается живыми людьми друг-другу. Это очень ценный навык для коммандной работы.
Проводя интервью видел много людей, которые вообще не в состоянии сформулировать, что они хотят сделать и как будут решать задачу - единственное, на что они способны, это молча написать код.
Сразу видно, человек с олимпиадным програмимрованием не знаком.
ну, так-то участник как офлайн так и онлайн соревнований. в одной региональной даже в своё время даже второе место занял.
На олимпиадах их обычно нельзя использовать.
поэтому и написал "вместо". обычно явных запретов на это нет, но проблема всплывает чаще всего из-за необходимости знать архитектуру машины, которая проверяет решения и необходимости добавить что-нибудь к флагам сборки. в С++ 26 simd появился в стандартной библиотеке и если этот язык будет разрешен в конкретных контестах, то по каким религиозным соображением это стоит запрещать? Та же история с asm вставками.
Самое пристижное и популярное соревнование - ICPC - командное.
Ну так на нём свет клином не сошёлся. CodeForces и LeetCode проводят постоянные периодические контесты - туда командой не воткнуться обычно. Некоторые олимпиады используют формат командных очков, когда все члены команды решают все задачи и командные очки за отправленные решения суммируются в командный зачёт для глобального ранжирования команд. Так что большинство олимпиадных соревнований - персональные, а формат командных хакатонов скорее исключение для более глобальных соревнований.
объяснять свое решение и понимать чужие
это не сказать чтобы титаническая задача. в командном зачёте и без этого обычно брейнсторм случается о подходах, если коммуникация разрешается.
Проводя интервью видел много людей, которые вообще не в состоянии сформулировать, что они хотят сделать и как будут решать задачу
Если человек никогда не участвовал в командных тренировках, то откуда браться навыку коммуницирования? Многие могут решать задачи только методом проб и ошибок, а не каким-то глубоким планированием, большинство не способны держать в голове всю цепочку взаимосвязей, поэтому начинают делать наброски и решают вопросы по мере их поступления, кто-то просто с социальной тревожностью и попытки начать объяснять загоняют их в паническую петлю из-за страха сказать что-нибудь "не то" - возможности и бэкграунд у людей разные, Спортивное программирование в этом плане ортогонально конретно этой проблеме с коммуницированием.
ну, так-то участник как офлайн так и онлайн соревнований. в одной региональной даже в своё время даже второе место занял.
Видимо, только в школе? И на сборы вы никакие не ездили? Или вы, даже участвуя в коммандных соревнованиях, решили, что они никак не помогают работать в комманде?
в С++ 26 simd появился в стандартной библиотеке и если этот язык будет разрешен в конкретных контестах, то по каким религиозным соображением это стоит запрещать?
Да хотябы чтобы не париться с выставленем таймлимита. Ибо цель контеста проверять алгоритмы а не микрооптимизации под конкретную архитектуру. И чтобы все было более менее честно для других языков, ведь если какое-нибудь медленное O(n^2) c simd оптимизациями в C++ пройдет, а на Java сможет только O(n log n), то это будет не честно.
Оно и asm уже более менее забанено во многих местах:
Certain C++ features are not allowed: SSE intrinsics, inline assembly, clock(), changing compiler settings (using pragmas, attributes). Detection of this features is best effort and will trigger manual grading.
Далее:
Ну так на нём свет клином не сошёлся. CodeForces и LeetCode проводят постоянные периодические контесты
Тем не менее, если заниматья этим серьезно, то придется разбираться в чужом коде, читать разборы и общатся с людьми. Нет, могут быть отдельные саванты, которым просто от природы все знания уже даны, но эти исключения мы рассматривать особо не будем.
Если человек никогда не участвовал в командных тренировках, то откуда браться навыку коммуницирования? Многие могут решать задачи только методом проб и ошибок, а не каким-то глубоким планированием, большинство не способны держать в голове всю цепочку взаимосвязей
Отличная иллюстрация, почему успешная олимпиадная карьера практически гарантирует, что у человека будут основные необходимые навыки, чтобы быть отличным программистом. Потому что там "методом проб и ошибок", "не каким-то глубоким планированием" многого не добъешься.
кто-то просто с социальной тревожностью и попытки начать объяснять загоняют их в паническую петлю из-за страха сказать что-нибудь "не то"
По моему опыту даже последние интроверты и откровенные аутисты как раз с радостью говорят о том, что им интересно. И вот спортивным программированием обычно занимаются те, кому это интересно. И о коде и задачах эти "загоняемые в паническую петлю" могут разговаривать бесконечно без страха "сказать что-нибудь не то". Это же не обсуждение романтических отношений в офисе, а математика, где нельзя, даже перепутав знак или ошибившись в арифметике, нарушить какой-то этикет.
Спортивное программирование в этом плане ортогонально конретно этой проблеме с коммуницированием.
На высоком уровне и во многих популярных соревнованиях требуются навыки коммуникации. Давайте сойдемся на том, что это не гарант идеальных командных навыков для всех, кто хоть раз в жизни к этому прикоснулся, но командная работа там не такое уж и исключение.
Видимо, только в школе? И на сборы вы никакие не ездили?
В школе у про программирование знал ровно один человек, да и тот на бэйсике. Офлайн был на паре олимпиад, но одна какая-то мелкая местная и вообще не помню про что было, вторая - областная олимпиада среди околопрофильных СУЗов. От нашего учебного заведения просто пару человек участников было, все зачеты были персональными и всего на событие прибыло человек 15-20 может быть. Никаких сборов не было как сущности. Просто сразу везли на событие. И такой формат обычно проще и дешевле хостить и повторять.
Ну и ещё раз - на ICPC свет клином не сошёлся и его правила не единственный формат проведения олимпиад по программированию. И большинство подобных событий нацеливается именно на персональное ранжирование, а не командный зачёт.
Тем не менее, если заниматья этим серьезно, то придется разбираться в чужом коде, читать разборы и общатся с людьми.
Несомненно, что придётся читать и писать много кода. А с людьми это как повезёт. Как и с обычным программированием. Это не что-то уникальное только для спортивного программирования.
По моему опыту даже последние интроверты и откровенные аутисты как раз с радостью говорят о том, что им интересно.
Не могу сказать, что встречал много подобных людей живьем, не говоря уже о проведении каких-либо интервью с оными - я же правильно понимаю что речь изначально шла о техническом интервью при приеме?
даже перепутав знак или ошибившись в арифметике, нарушить какой-то этикет.
зато можно назвать делитель делимым и спутать интервьювера делением на ноль невпопад. Интервью для многих довольно стрессовое событие и невротиков в мире тоже немало.
популярных соревнованиях
ключевое слово - популярных. есть ещё непопулярные и люди там тоже участвуют. те же школьные межклассы, например.
но командная работа там не такое уж и исключение.
я не утверждал о некой исключительности командной работы на таких событиях - просто их меньше по сравнению с общим количеством событий.
Хотел бы повидать этот знаменитый "неподдерживаемый" код, которым корпораты так шеймят спортсменов и противопоставляют ему свою SOLID'ную писанину...
Сам участвовал в олимпиадах, и вполне себе понимаю зависть к победителям, а заодно и желание обесценить их достижения в стиле "ну и что, что он выжал лежа 200 кг, в жизни это не пригождается, главное какой ты человек!"
Ну и вот, в итоге карьера в нашей айтишечке удалась, ты за счет удачи, дружеских/родственных связей сидишь такой на должности, прости Госсподи, сеньора-лида, и нанимаешь себе людей (а я собеседовал и не только себе, но и еще для кучи смежников собеседовал, потому что некому было).
Рядом, как водится, сидит HRочка из анекдота "я отсекаю всех кто читал Танненбаума, у них слабые софты", и дает мудрые советы, хотя еще вчера ей доверяли только кофе приносить.
И приходит к тебе такой вот выскочка спортсмен-олимпиадник (который в алгоритмах уделает тебя как Бог черепаху), и от тебя зависит, возьмут ли его! Вот и наступило время расплаты за унижения на той олимпиаде 20 лет назад!
Вот поэтому у вас вместо тестовых заданий устная проверка зубрения того самого заплесневелого SOLID, и прочие отвлеченные разговоры, по результатам которых будет максимально субъективная оценка "кандидат проявил низкие командные качества", "не впишется в копр. культуру" и т.п.
Спортивное и промышленное программирование родственны ровно так же, как родственны спринт и марафон.
10 задач на 5 часов - это короткие задачи. А в бизнесе часто приходится решать задачи длинные, от недели и до месяца. Совершенно иной объем кода, сущностей и взаимосвязей между ними, которые нужно удержать в голове. Да и объем бизнес-логики и разных условий там может быть несравнимо больше.
Плюс, если речь идет о какой-то действительно большой системе из огромного количества модулей, будет еще длинный список нефункциональных требований. Плюс надо постоянно думать про интеграцию в систему, соблюдение общей архитектуры и т.д. и т.п.
Ну и не забывать что потом кому-то (может вам а может и нет) через год-два-три (а то и более) придется это все дорабатывать потому что что-то где-то поменяется в бизнес-процессах (например). И этот кто-то (а может и вы через три года) должен ваш код легко понять и быстро понять где и что надо поменять в соответствии с новыми требованиями.
Я далек от того, чтобы считать "олимпиадников" непригодными к бизнес-разработке (хотя был случай именно такого - блестящий олимпиадник, но бизнес не тянул - ему просто становилось скучно и наступало "временное выгорание"), но это, все-таки, "две большие разницы...
10 задач на 5 часов - это короткие задачи. А в бизнесе часто приходится решать задачи длинные, от недели и до месяца
Но на соревнованиях обычно задачи сложные и их надо уметь разбивать на части и планировать решение. С этим навыком и длинные задачи отлично разбиваются на маленькие и уже без разницы, проект на 3 года или на месяц.
Совершенно иной объем кода, сущностей и взаимосвязей между ними, которые нужно удержать в голове.
Почему вы думаете, что человек, который может удержать в голове десятки структур данных, математических моделей и алгоритмов нужных для решения задач, не сможет удержать в голове "сущности и взаимосвязи между ними". Это один и тот же отлично развиваемый олимпиадами навык.
как родственны спринт и марафон.
Это ложная аналогия. Так получилось, что человеческому телу для взрывной скорости и экстремально длительной интенсивной работы нужны разные настройки. Именно для экстремально длительной интенсивной работы, а не просто для длительной. Ходить весь день по городу даже посредственный спринтер сможет гораздо легче среднестатистического человека, ибо он в форме. И работа в индустрии - не марафон (если у вас не пермаментный кранч с 16-часовыми рабочими днями). Это длительная но вовсе не сверх-интенсивная мыслительная работа.
Так что аналогия тут скорее, надо пешим курьером весь день разносить письма по городу. Иногда придется убегать от собак. Спринтеры тут - идеальные кандидаты.
И вообще, совершенно не очевидно, что точно так же мозгу для длительного медленного думания над бизнес задачей и интенсивным думанием в течении 5 часов над 10ю задачами, нужны какие-то разные навыки. 5-ти часовые контесты почти не отличаются от 8-ми часового рабочего дня, только в бизнесе можно пойти кофе попить, пообедать и расслабиться немного. Прямо халява какая-то. Память олимпиады развивают отлично. Способность удерживать кучу критериев и условий в голове - тоже. Иные задачи просто прочитать и осознать сложнее чем некоторые целые проекты в бизнесе. Ах да, еще внимание к деталям и вообще способность прочитать технический текст.
Если вы про то, что "решил задачу - выгрузил все про нее из памяти" на контесте, то в бизнесе все примерно так же. Вы когда какую-то фичу пишите, вы не держите в голове все про фичу, которую вы писали 2 месяца назад. Вы все время решаете одну маленькую задачу: разбить проект на подзадачи, написать вот эту фичу, исправить вон тот баг. В контекст свой вы не "загружаете" весь большой проект, а лишь маленькую релевантную часть. Что-то про другие части вы по мере надомности вспомните, но так же и на олимпиадах надо постоянно вспоминать что-то про подводные камни в подобных задачах.
С этим навыком и длинные задачи отлично разбиваются на маленькие и уже без разницы, проект на 3 года или на месяц.
Вообще-то разница есть. И в бизнесе логика бывает достаточно сложной. А на нее еще накладываются требования по эффективности... Причем, в заранее не можете сказать хватит вам простого решения или нет. Может быть хватит (время выполнения задачи укладывается в отведенное временное окно и нагрузка на процессор не превышает предельных для одного задания величин). А может и нет и надо начинать все сначала и придумывать что-то иное.
Или вот такое. Чтобы разработать API надо сначала провести некий набор тестов чтобы понять насколько оно будет лучше уже существующего. Потом перерыть огромное количество документации. Потом спроектировать API исходя из типичных предполагаемых сценариев его использования. И только потом уже садиться писать.
Почему вы думаете, что человек, который может удержать в голове десятки структур данных, математических моделей и алгоритмов нужных для решения задач, не сможет удержать в голове "сущности и взаимосвязи между ними". Это один и тот же отлично развиваемый олимпиадами навык.
Ну хотя бы потому что все вами перечисленное тоже нужно держать в голове. Плюс понимание (хотя бы базовое) сути бизнес-процессов. Плюс набор нефункциональных требований. Плюс набор типичных сценариев использования того что вы пишете (без этого удобный контракт вам не создать). Это очень большое количество разнородной информации.
И работа в индустрии - не марафон
Увы, но марафон. У меня была задача, которая (в целом) длилась пять лет. Там было и проектирование БД (десяток таблиц, несколько десятков индексов) и огромное количество кода только на первом этапе и потом еще огромное количество доработок уже существующего кода для интеграции всего этого в систему. И это все на фоне того что попутно приходилось и другие задачи тоже делать. Ссылка выше (про адреса) - это лишь один маленький кусочек всего этого добра (там, кстати, решение пришло чуть не во сне - утром проснулся и вдруг понял как надо, т.е. задача все равно крутится где-то в фоне, так что это именно марафон).
Я не говорю о перекладывании джйсонов - те задачи можно вообще не думая решать, но у меня таких не бывает.
И, кстати, марафонец в среднем всегда бежит медленнее спринтера. Но там нужна выносливость а не взрывная сила.
В контекст свой вы не "загружаете" весь большой проект, а лишь маленькую релевантную часть
Увы, но нет. Приходится держать в голове именно весть проект, иначе потом столкнетесь с тем, что чтобы очередной кусочек пазла лег на свое место, надо возвращаться на пару-тройку месяцев назад и править что-то там. Что тянет за собой правки на всем протяжении того, что уже сделано.
Если я не продумал при проектировании БД ее структуру до конца (что зачем и с чем связано и что мне понадобится еще), то на определенном этапе обязательно начнется лютый костылинг.
Уж поверьте человеку, который в разработке (профессионально) с 91-го года.
Я немного потерял, в чем суть противоречия. В том, что олимпиадные задачи - это не рабочие задачи? Ну так да, это факт. Вроде все (подавляющее большинство) с этим согласны.
Если дальше проводить спортивные аналогии, то хоккеисты ходят в зал, крутят велосипед, бегают кроссы - это вообще не то, чем они занимаются в "работе" на площадке. Но эта разминка помогает им держать себя к форме.
Так и с олимпиадами. Какой-то опыт участия помогает прокачать те самые "мышцы" в голове, которые потом могут быть полезны в работе. И не потому, что там будут точно такие же задачи, а потому что там будут какие-то похожие базовые нагрузки, требования.
Все верно.
Я всего лишь говорил о том, что в бизнесовой разработке много такого, чего нет в олимпиадной. И, повторюсь, я встречал одного блестящего олимпиадника, который не мог работать в бизнесе. Ну не получалось у него месяцами держать концентрацию на одной большой задаче - ему просто было это скучно, много рутины.
Даже когда вы ее декомпозируете на много мелких (а это происходит всегда - все программирование есть декомпозиция большого невозможного на много мелких реализуемых), это будет много тесно взаимосвязанных между собой задач - решая первую вам уже надо в голове держать все что будет решаться потом.
Плюс когда ваша задаче есть развитие и дополнение большой и давно работающей системы, вам приходится заботиться о корректной интеграции - чтобы не дай бог не порушить то, что уже работает.
И коль было угодно сравнивать спринтера-олимпиадника с курьером-бизнес-разработчиком, то извольте. У олимпиадника есть старт и финиш и задача быстрее от старта до финиша добежать. А у курьера есть список заказов. Ему еще надо маршрут построить, решить "задачу коммивояжера" прежде чем приступить к выполнению собственно основной задачи.
Я всего лишь говорил о том, что в бизнесовой разработке много такого, чего нет в олимпиадной.
Согласен. Но я почему-то воспринял ваш комментарий и аналогии скорее как "олимпиадные навыки противоречат бизнесу. Ну в крайнем случае вообще перпендикулярны". Ибо спринтер - плохой марафонец с большой вероятностью и как быстро он бегает стометровку никак ему не поможет на дистанциях в 40 км.
Возможно мы тут вообще друг другу одну и ту же позицию доказываем.
Именно так - навыки спринта в марафоне бесполезны. Там не нужна быстрая мышечная реакция и взрывная сила. Зато там нужна выносливость и умение распределять усилия, нужна стратегия.
Я в детстве немного конькобежным занимался. И знаете что больше всего устает на длинных дистанциях (10км - 25 кругов)? Не ноги. Спина.
Вообще, на длинных дистанциях голова устает быстрее (от монотонности) чем тело. В этом плане спортивное ориентирование бегать (а там 10-15км набегать запросто) проще чем ту же дистанцию кругами по стадиону намотать - там голова постоянно занята.
В бизнес-разработке это выгорание. Если приходится долго заниматься однотипными рутинными задачами. Приходится и с этим бороться. И, повторюсь опять, попадаются хорошие олимпиадники, которые на это органически не способны.
Общее тут только физическая форма. Применительно к разработке - "алгоритмы и структуры данных". Но это должен знать любой приличный разработчик, не только олимпиадник.
Ну не получалось у него месяцами держать концентрацию на одной большой задаче - ему просто было это скучно, много рутины.
На моей практике, это слабо связано с олимпиадами. Просто есть такие люди, которые больше по ресёрчу — они не могут долго в рутину. Среди них есть как олимпиадники, так и много тех, кто олимпиады не трогал. Поэтому выскажу гипотезу, что это просто нерепрезентативная выборка.
Напрямую с олимпиадами не связано, конечно. Но. Олимпиаднику это не мешает, а продуктовому разработчику очень.
Не очень понимаю, почему олимпиаднику это не мешает. На моём опыте, когда людей с исследовательским характером ставят на рутину, они очень быстро выгорают, независимо от наличия олимпиадного опыта.
Или я Вас неправильно понял?
Я про то, что неприятие рутины для олимпиады не проблема. Там ее нет. В отличии от бизнесовой разработки.
Все к тому, что самый блестящий олимпиадник в бизнесе может хорошо себя показать, а может и наоборот. Потому что это очень разные вещи.
У меня складывается впечатление, что Вы подразумеваете мысль "если человек олимпиадник, то он ничего кроме олимпиад не делал".
Разумеется, принимать человека на работу исключительно по его успехам в олимпиадах — затея не очень хорошая. Но абсолютно аналогично не очень хорошая затея смотреть исключительно на технические навыки. Можно сказать аналогичную фразу
Все к тому, что человек с блестящими навыками программирования в бизнесе может хорошо себя показать, а может и наоборот. Потому что это очень разные вещи.
Разумеется при приёме на работу нужно также смотреть на социальные особенности человека (и вроде как почти во всех внятных местах смотрят)
Речь скорее о том, что опыт в олимпиадах — это однозначный плюс, как ещё один технический навык. На умение работать с рутиной такой опыт не влияет ни положительно ни отрицательно — на это влияют другие, не связанные особенности характера.
И эти же самые особенности характера часто встречаются у любых технически сильных кандидатов.
У меня складывается впечатление, что Вы подразумеваете мысль "если человек олимпиадник, то он ничего кроме олимпиад не делал".
Совершенно нет.
Разумеется, принимать человека на работу исключительно по его успехам в олимпиадах — затея не очень хорошая.
Вот именно это я и имел ввиду. Успехи на олимпиадах для бизнеса не дают ничего.
Речь скорее о том, что опыт в олимпиадах — это однозначный плюс, как ещё один технический навык
Ага. Только для бизнеса бесполезный. Равно как, например, призовые места в соревнованиях по тяжелой атлетике. Или умение разгадывать кроссворды.
И эти же самые особенности характера часто встречаются у любых технически сильных кандидатов.
Вот именно.
Бизнес разный бывает. В гугле/яндексе есть департаменты, разрабатывающие новые технологии, в high-frequency trading часто берут исключительно по успехам на олимпиадах. Кроме бизнеса бывает еще опен-сорс и research-проекты, для которых олимпиадный опыт более релевантен, чем бизнес-опыт. Конечно, таких мест в процентном соотношении мало, но туда трудно пробиться без олимпиадного опыта.
Абсолютно согласен.
Я не считаю что олимпиадный опыт влияет собственно на качество кода - это как раз быстро дрессируется в бизнесе.
Но вот что именно олимпиадные навыки мало что дают для бизнеса - это да.
Да и не только в этих департаментах "разрабатывающих новые технологии". И не только в гугле/яндексе. Прям олимпиадные задачи встречаются много где. Гораздо чаще, чем люди думают. Ошибочная оценка возникает потому, что такие задачи большинством просто не распознаются алгоритмическими вообще.
Вон, те же задачи на литкоде очень часто в виде "сделайте вот это". И можно тупо перевести с человеческого на язык программирования не очень задействуя мозг довольно часто.
У программистов обычно задача - запилить фичу, исправить баг. Они в голове состоявляют план "вот надо сделать вот так и так" и делают наивное медленное тупое решение, или вообще думают "а не, так не получится сделать, давайте поменяем фичу". Перед ними не стоит алгоритмической задачи, они ее придумывают уже как решение и даже не задумываются, что тут, оказывается, надо еще что-то решать и можно эти ваши алгоритмы использовать.
Ага. Только для бизнеса бесполезный.
Я не уверен, что Вы здесь имеете ввиду под "бизнесом". Но если говорить с точки зрения подбора разработчиков, то хорошие технические навыки (в том числе опыт в олимпиадах) довольно важны и полезны с точки зрения продуктивности (разумеется при условии что они как работники нормальные — по это само собой разумеется)
Вот тут не соглашусь. Олимпиады - это не собраться раз в несколько месяцев на 5 часов, порешать задачи и все. Это надо месяцами учить разные темы. Это надо тренироваться - решать задачи почти каждый день. Это концентрация на одной теме месяцами а то и годами.
Это надо месяцами учить разные темы. Это надо тренироваться - решать задачи почти каждый день. Это концентрация на одной теме месяцами а то и годами.
На какой "одной теме"? Разработке? Так любой разработчик на этой теме всю жизнь сконцентрирован.
Еще раз. Олимпиадник концентрируется на короткое время на небольшой изолированной задаче. Бизнес-разработчик концентрируется длительное время на большой задаче и должен держать в голове десятки тысяч строк кода. Плюс смотреть шире чем написано в ТЗ, думать об интеграции. Плюс еще в бизнес-логику общую вникать (которая, опять же, в ТЗ не прописана полностью).
Еще раз. Олимпиадник концентрируется на короткое время на небольшой изолированной задаче. Бизнес-разработчик концентрируется длительное время на большой задаче и должен держать в голове десятки тысяч строк кода.
Наверное, тут имеется ввиду, что олимпиадник концентрируется на короткое время на олимпиаде. Я как олимпиадник концентрируюсь на длительное время на большой задаче (от года и более) в работе. Я ж всё таки понимаю, что это разные задачи.
Но, например, мне как олимпиаднику, на каком-то интуитивном уровне понятно, почему стоит использовать HashSet в некоторых местах, не допускать проблем N+1 запроса на ровном месте, как устроен индекс в БД и порядок полей в нём важен.
Но, например, мне как олимпиаднику, на каком-то интуитивном уровне понятно, почему стоит использовать HashSet в некоторых местах, не допускать проблем N+1 запроса на ровном месте, как устроен индекс в БД и порядок полей в нём важен.
Не поверите, но я ни разу к олимпиадам и близко не подходил, но все это для меня тоже очевидно. Это какие-то настолько тривиальные вещи что без понимания их вообще в разработку не надо.
Я больше скажу - без понимания таких вещей как где использовать список с автосортировкой (и накладными расходами в виде динамического выделения памяти), а где сортированный массив, где нужно блочное чтение из БД, а где оно только ухудшит ситуацию, где выгоднее работать со скулем (и как правильно строить запросы), а где быстрее через прямой доступ по индексу и еще много чего чисто платформенного, у нас есть риск просто не пройти нагрузочное тестирование и получить возврат на доработку.
Да зря вы так, охотно поверю. Я встречал много людей, который приобрели эти знания и опыт другим путём. Мой рассказ о том, что этот опыт можно получить и через Олимпиады тоже.
Возможно, процесс разработки и качество продукта у вас таковы, что не допускают других решений. Я же видел множество обратных примеров. А порой, даже сложно аргументировать, почему хэшсет будет лучше массива, потому что это никак не отражается на пользователе, бизнесе. Но лично для меня такие микро-оптимизации на всех уровнях потом складываются в более устойчивое решение.
Не знаю, опять повторюсь, что от меня ускользает суть спора. Но какое-то сомнительное отношение к бывшим олимпиадникам всё таки чувствую, о чем изначально и писал.
Моя позиция такова - олимпиадник по определению не плюс и не минус. Просто параллельно. Я уже приводил пример - нельзя утверждать что человек хорошо пробежит марафон потому что он отлично бегает спринт.
Вряд ли на олимпиадах дают чужой код 3-5 летней давности и ставят задачу поправить дефект, возникающий при каком-то редком стечении входных данных. А в бизнесе это обычное дело.
Олимпиаднику (если он не работал в бизнесе) может быть непривычно работать с длинными объемными задачами со значительной долей рутинного кода.
Вряд ли на олимпиадах выставляется длинный список нефункциональных требований, обусловленных особенностями архитектуры данной конкретной системы.
Чисто технические навыки, связанные с алгоритмами и структурами могут быть приобретены не только на олимпиадах.
Так что, повторюсь, для меня (человека, занимающего техлидскую позицию) олимпиадный опыт не значит ровным счетом ничего.
Хе. У меня задача, которая длится уже более 15 лет и продолжает развиваться. И в рамках этого проекта периодически выстреливают именно олимпиадные случаи, когда нужно решить быстро, при отсутствии полной информации, не обязательно насовсем (а дать время марафонцам успеть сделать хорошо, пока олимпиец-спринтер держит место), аврально, в стрессе, не всегда в комфортных условиях. И это не мы такие, это сфера деятельности такая с ее моделью финансирования и заказов.
Причем, в заранее не можете сказать хватит вам простого решения или нет.
На самом деле, зачастую прикинуть как раз можно. По крайней мере в таких условиях, когда есть простые и конкретные ограничения, как в Вашем примере. И как раз этот навык олимпиады очень хорошо тренируют.
P.S. кстати говоря, хотя я понимаю, что задача с адресами уже была рассказана с учётом решения, но чисто по описанию и объёмам данных там сразу напрашивается классический инвертированный индекс. Вы, я так понял, пришли к похожему решению, но без слияний по бинпоиску. (к сожалению, не был готов пробираться через терминологию, чтобы понять решение по нормальному)
Как вы себе представляеете "индекс" который будет определять вхождение набора слов в фразу без учета дублированя этих слов и порядка их следования во фразе. Т.е. условно говоря фразы
"один два три три четыре" и "четыре два один два"
являются совпадением.
А
"один два три три четыре" и "четыре два один два пять"
не являются.
На самом деле, это решается через "витрины". Где все адреса хранятся в разбитом на слова виде. Это отдельная задача, которую надо решить до того как начнете решать основную. Т.е. надо сделать таблицы витрины (три штуки) + написать модуль ведения - раскладка по таблицам (добавление/удаление/изменение).
Дальше надо написать модуль поддержки этой витрины - если произошли какие-то изменения в таблице адресов, то витрина должна автоматически сразу актуализироваться. Это еще одна задача.
В этом и отличие - на олимпиаде вы решаете отдельную задачу, которая ни к чему не привязана, в бизнесе вы интегрируете новый функционал в большую работающую систему. И должны заботится о том, чтобы он не нарушил работу системы в целом.
Как вы себе представляеете "индекс"
"Инвертированный индекс" — это вполне себе стандартная структура данных для решения подобных задач, тут не вопрос того, как я себе это представляю.
В данном случае это что-то в таком стиле: разбиваем каждый адрес на слова(уже после нормализации), и строим для каждого слова сортированный список клиентов, у которых данное слово входит в адрес.
Дальше, если мы хотим например найти клиентов у которых в адресе встречаются w1 и w2, мы находим соответствующие списки клиентов и пересекаем их — это делается за линейное время от размера результата (по модулю логарифмов). Аналогично для поиска
слов можно объединить списки за,
, где
есть размер результата.
Как строить и где хранить этот индекс — это отдельный вопрос. Можно его материализовать в бд (например в виде таблицы (word, client_id)). Можно материализовать в как отдельную структуру на диске. Вообще говоря, можно даже попробовать собрать этот индекс в памяти, прямо во время сверки — там не.
Подход к построению индекса сильно зависит от среды. Доступной памяти, возможностей организации структур данных, возможность итерации по бд и прочего. Тут Вы сами знаете лучше.
Дальше надо написать модуль поддержки этой витрины - [...]
В этом и отличие - на олимпиаде вы решаете отдельную задачу, которая ни к чему не привязана, [...]
Я прекрасно понимаю связанные сложности с поддержанием витрин и в целом жизненным циклом программных продуктов. И о том, что разработка отличается от олимпиады.
Но во-первых, про инвертированный индекс я писал несколько в отрыве от истории с олимпиадами.
А во-вторых, не вижу причин, почему олимпиадники должны в среднем (или обязательно) плохо справляться с задачами разработки. Ну кроме истории с ресёрчем, про которую говорили в другой ветке — но она мешает не только олимпиадникам.
В данном случае это что-то в таком стиле: разбиваем каждый адрес на слова(уже после нормализации), и строим для каждого слова сортированный список клиентов, у которых данное слово входит в адрес.
Ну оно сразу так и делалось. Это и есть "витрина". Три таблицы
ID клиента
ID адреса в витрине
ID элемента (слова)
Элемент (слово)
ID адреса в витрине
ID элемента (слова)
Номер слова в адресе
Это для адресов клиентов (там чуть сложнее на самом деле т.к. есть разделение на типы клиентов - ФЛ/ЮЛ и типы адресов - 5 типов для ФЛ и 3 типа для ЮЛ)
Для адресов субъектов чуть проще, там нет нужды в витрине, там есть только "ключевое слово" - элемент адреса субъекта который реже всего встречается в витрине адресов клиентов (в таблице связей адрес-элемент). Это нужно для повышения селективности первичной выборки - она идет как раз по ключевому слову.
Дальше можно все сделать одним скулевым запросом, но работает очень долго. Сложнее, но быстрее писать это используя прямой доступ к БД по индексам.
Берем ключевое слово адреса субъекта и находим его ID в витрине (таблица элементов адреса) адресов клиентов. Если его там нет - все, совпадений точно не будет.
Если ID есть - составляем массив уникальных ID остальных элементов адреса субъекта.
По ID ключевого слова делаем первичную выборку - составляем массив ID адресов клиентов в которые входит ключевое слово (по таблице связей адрес-элемент). В реальности там может быть до 500-600 тысяч элементов.
Дальше идем по массиву ID элементов адреса субъекта и для каждого проходим по массиву ID адресов клиентов проверяя наличие записи ID адреса клиента - ID элемента адреса субъекта. Вот это делается без чтения самой записи, просто проверкой ее наличия в индексе - это намного быстрее. Если записи в индексе нет - удаляем элемент из массива (т.е. на каждом "обороте" внешнего цикла внутренний становится короче).
На выходе в массиве остаются только те ID адресов клиентов куда входят все элементы адреса субъекта.
Но дело в том, что этот алгоритм в реализации сложнее чем один скулевый запрос. И в том, что для режима работа по дельте (когда совпадения ищутся не для всех, а только для тех, кто менялся за прошедшие сутки) время работы скулевого запроса удовлетворяет заказчика (укладывается в заданное временное окно). Поэтому вот так... Дельты обрабатываются одним алгоритмом, полная выборка - другим (это две разные задачи).
А во-вторых, не вижу причин, почему олимпиадники должны в среднем (или обязательно) плохо справляться с задачами разработки. Ну кроме истории с ресёрчем, про которую говорили в другой ветке — но она мешает не только олимпиадникам.
Моя мысль в другом. Олимпиада и бизнес суть разные вещи. Разные подходы. И то, что человек блестящий олимпиадник, практически никаких преимуществ в бизнесе ему не дает. Как и наоборот. Отличный бизнесовый разработчик не будет иметь никаких преимуществ в олимпиаде.
Разница прежде всего в том, что олимпиадник всегда сконцентрирован на одной конкретной задаче. А бизнесовый разработчик всегда рассматривает задачу как часть большой системы (вот у нас только на центральном сервере несколько десятков тысяч программных объектов так или иначе между собой взаимодействующих, пара десятков тысяч таблиц с которыми мы работаем, и это не считая интеграций с внешними системами через веб-сервисы и очереди). Поэтому получая ТЗ на новый модуль всегда надо понимать с какими объемами данных он будет работать, какая будет плотность вызовов, какие типичные сценарии использования предполагаются - все это влияет на выбор деталей реализации. И все это, как правило, выходит за скобки постановки задачи - это то, о чем хороший разработчик должен думать сам прежде чем хвататься за клавиатуру.
Олимпиада и бизнес суть разные вещи. Разные подходы. И то, что человек блестящий олимпиадник, практически никаких преимуществ в бизнесе ему не дает
Ну вот я выше привёл пример того, как известным в узких кругах алгоритмах можно было бы сразу наметить план решения. Поэтому какие-то преимущества всё же даёт.
получая ТЗ на новый модуль всегда надо понимать с какими объемами данных он будет работать, какая будет плотность вызовов, какие типичные сценарии использования предполагаются - все это влияет на выбор деталей реализации.
Хороший олимпиадник сходу задаётся этими же вопросами. Более того, зачастую олимпиадники задают даже более тонкие вопросы, т.к. сразу могут подобрать варианты решения.
P.S. разумеется на реализацию этих решений могут уйти дни-недели-месяцы. Но в среднем хорошие олимпиадники не испытывают проблем с длительными задачами...
Мне понравилась ваша аналогия про спорт и бегунов. Я в своей статье приводил аналогию со спортом, но, видимо, недостаточно хорошо получилось. Глубже не стал расписывать, чтобы не было слишком занудно. А у вас получилось достаточно хорошо.
Господин олимпиадник победитель, успокойся уже.
Просто все вокруг завидуют твоему величию и силе, поэтому что то пытаются мямлить про задачи бизнеса, различность процессов и тп.
А сияние нимба над головой режет глаза унылым корпоративным крудошлепам.
Спортивное программирование действительно прививает определенный стиль кода, в основном выраженный в коротких непонятных называниях переменных. Потому что надо побыстрее решить задачу и потом этот код никто уже никогда поддерживать не будет.
Но от этой привычки можно избавиться буквально за пару недель при наличии код-ревью в процессе разработки.
Еще добавлю, что оно дает математическую базу и алгоритмическое мышление, которые потом отлично помогают с индустриальной работой. То самое умение формализовать задачу, выстроить решение и доказать его хотя бы самому себе. И когда вам встретится "олимпиадная" задача, вы ее вообще распознаете и сможете решить или хотя бы понять как искать решение.
Программисты не любят стресс, аврал, сверхсрочные задачи, ограниченность ресурсов. А это все встречается в работе. И способ понять, как ты себя поведешь в такой ситуации - такие соревнования. Сам участвовал, на работе помогает именно психологически.
Говорят, спортивное программирование портит код. Почему я с этим не согласен