Блог пользователя a_kabdygali

Автор a_kabdygali, история, 7 лет назад, По-русски

Привет всем. Начал задумываться о будущей профессии, ведь оплачиваемой профессии спортивного программиста не существует) Возникло пару вопросов, буду благодарен всем кто поделится знаниями и опытом. Возможно некоторые вопросы не корректны и/или слишком личные, прошу проигнорить таковые)

1.) На какой должности спортивному программисту будет легче всего проявить свои лучшие качества и навыки?

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

3.) Учась в университете, на каком курсе лучше подавать на интерншипы и расскажите о своем опыте интерншипов. Какие были требования? Где стажировались?

Спасибо всем за внимание :3

  • Проголосовать: нравится
  • +66
  • Проголосовать: не нравится

»
7 лет назад, # |
  Проголосовать: нравится +24 Проголосовать: не нравится

ведь оплачиваемой профессии спортивного программиста не существует)
А чем по вашему наши великолепные тренеры на жизнь зарабатывают?))

  • »
    »
    7 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    я и не писал что нету профессии тренера по спортивному программированию

»
7 лет назад, # |
  Проголосовать: нравится +54 Проголосовать: не нравится

Проходил мимо (с) и решил поделиться опытом одного моего близкого друга, как он перешёл из спортивного программирования в бытовое. Он дал своё согласие на изложение. Первое, что хочу отметить, это то, что на момент этого перехода он не входил в Топ-N рейтинга в какой-либо категории СП.

Был 2007 год. Не без ущемлённого собственного эго, он сдал первую сессию в Рижском Политехникуме и понял, что этот ВУЗ не подходит. Слишком уж явно там внушали, что студент — это никто. И пошёл работать в местную контору, делающую аутсорсинг разных Enterprise решений на шведских друзей. ЗП попросил смешеую, но и знаний Java-технологий особых не было. Их это устраивало, и его тоже. Первое задание, освоить Java. За неделю он освоил басик-навыки, пройдя обучающий материал на сайте Sun (в последствии был съеден Oracle). В принципе, особых тонкостей не было, ООП он уже знал по C++, поэтому основной упор был на хорошие практики (tm) и стиль написания кода. Да, о хороших практиках. У него они, почему-то не ассоциировались с чем-то хорошим, а скорее, наоборот. Возможно, это из-за того, что они, по его мнению, противоречили принципам KISS (Keep it simple, stupid). А принципы KISS — это верх совершенства. В любом случае, ретроспективно, он сейчас осознаёт, что критическое мышление ему не всегда помогало, особенно на начальных порах работы в конторе.

Первым реальным заданием ему дали чинить баги в полуготовой системе. Багов было много, около 500, а времени — мало. В принципе, на момент его подключения к проекту, оставался месяц до сдачи. Но клиент был "постоянный", мог и подождать, и бюджет нарастить... Он до сих пор помнит один такой баг, где автор кода перепутал булевы операции || и &&. Починить просто, а найти — попробуй в такой куче кода. Да, о куче кода. В бытовых проектах всегда будет куча кода. И ещё, 80% бытовых проектов — это поддержка/допиливание имеющегося продукта. Также хочется отметить, что ему было трудно с коллегами, т. к. он считал себя изначально круче их. С этим надо бороться методом самовоспитания, что он и сделал, но это было не просто. Даже если все вокруг занимаются какими-то глупыми дизайн паттернами (он эти паттерны до сих пор считает чем-то глупым), и творят простейшие баги, это — коллеги и у них, наверняка, есть навыки, по которым они лучше. Короче, СП дало ему ложное убеждение, что алгоритмы — это верх совершенства в индустрии программирования.

А теперь отвечу по пунктам.

1) Изучите рынок труда по вашему городу. Часто те позиции, на которых СП может себя проявить (data mining etc.) довольно ограничены, не все компании имеют кучу вакансий по ним. Как правило, сейчас в топе мобильная и веб-разработка. Некоторые счастливчики из моих знакомых работают над in-memory базами, но это — стартап со всеми вытекающими, и скорее исключение. Но даже в веб-разработке (если это, конечно, не страничка-визитка) базовые навыки, полученные на олимпиадах, помогают значительно.

2) Поиск по интернету решений из серии "валится библиотека X с сообщением Y", отладка, чтение чужого кода, общение с коллегами (не каждый код читаем, часто быстрее для всех спросить, чем самому выяснять, что имел ввиду автор). Отчёты о проделанной работе (сколько часов делал что).

3) У нас на 2 курсе Латвийского Университета была официально пол года практика. Стажировался в первой попавшейся конторе с сайта объявлений. Умения Java было достаточно, чтобы попасть и получить ставку в дополнение к практике.

»
7 лет назад, # |
  Проголосовать: нравится +18 Проголосовать: не нравится

Я считаю, что идеальное будущее спортивного программиста это решить нерешенную задачу и заработать на этом хорошие деньги. Как например описано вот тут:

http://codeforces.com/blog/entry/45024

Можете прочитать ответы на вопросы:

Чем занимаются олимпиадники после того, как оканчивают учебу?

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

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

В частности Российская компания AIM Tech даже сотрудничает с CodeForces и проводит соревнования:

http://codeforces.com/aimtech2016

Вот ещё одна компания, которая занимается HFT, сотрудничает с CodeForces:

http://codeforces.com/wunderfund2016

Из зарубежных компаний специализирующихся на HFT могу назвать Jane Street. Туда крайне сложно попасть, насколько я знаю, там работают очень сильные олимпиадники. Они тоже любят нанимать людей, кто лучше всего решает логические задачи:

https://www.janestreet.com/puzzles/

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

Настоятельно рекомендую избегать работы в посредственных компаниях по мере возможности. Особенно там, где много так называемых enterprise Java программистов. Там культура анти-олимпиадная и у людей совсем другой менталитет.

Так же не рекомендую ограничиватся своим городом и страной. Хороших компаний в мире достаточно мало, фактически единицы. В основном работа среднего программиста в посредственной компании это boilerplate coding.

О себе: 32 года, работал в Узбекистане, РФ, Швеции и на текущий момент в Нидерландах. Видел всякого (в том числе и дно), стремлюсь описанным выше целям. У вас опыт спортивного программирования лучше, чем мой, так что считаю, что вам вполне реально начать в internship в каком нибудь Google или Jane Street.

  • »
    »
    7 лет назад, # ^ |
      Проголосовать: нравится +18 Проголосовать: не нравится

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

    • »
      »
      »
      7 лет назад, # ^ |
        Проголосовать: нравится +13 Проголосовать: не нравится

      Спасибо за информацию!

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

»
7 лет назад, # |
  Проголосовать: нравится -37 Проголосовать: не нравится

типичная задача из спортивного программирования: сгенерировать все tidy numbers < 10^18 (из прошедшей квалификации к GCJ, если что), сохранить их в отсортированном массиве и искать нужное бинпоиском

типичная задача из промышленного программирования: сгенерировать все tidy numbers < 10^N, задействовав все ядра автоматически поднимаемого инстанса AWS, сохранить полученные данные в кластере из M машин и отвечать на запросы, минимизируя трафик между ними (также обязательно применить машинное обучение хотя бы на одном из этапов)

  • »
    »
    7 лет назад, # ^ |
      Проголосовать: нравится +2 Проголосовать: не нравится

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

    • »
      »
      »
      7 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

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

      • »
        »
        »
        »
        7 лет назад, # ^ |
          Проголосовать: нравится +26 Проголосовать: не нравится

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

»
7 лет назад, # |
  Проголосовать: нравится +24 Проголосовать: не нравится

Ну, как ни странно, спортивное программирование — это тоже программирование, но имеющее некоторые особенности:

  1. Программы здесь обычно достаточно маленькие.
  2. Программы пишутся с целью быть один раз запущенными на наборе тестов и пройти его.
  3. Читать код будут в крайнем случае два человека из твоей команды.
  4. Обрабатываемые данные помещаются в оперативку одного десктопного компьютера десятилетней давности.
  5. Данные всегда корректны в рамках условия (по крайней мере, обратное считается отклонением от нормы).

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

Но если ты будешь писать код для продакшна, то там как раз становятся важными следующие аспекты:

  1. Кода будет скорее всего много, и писать его будут несколько человек. Поэтому нужно с одной стороны декомпозировать систему на модули и устанавливать контракт взаимодействия между ними (чтобы твои коллеги могли полагаться на наличие такого-то модуля с таким-то интерфейсом).
  2. Жизненный цикл ПО зачастую длится годами или даже десятилетиями (см. Win32 API, созданный для Windows 95 и используемый по сей день). За это время многое меняется, и поэтому нужно уметь понимать, какие части программы останутся неизменными в течение длительного времени, а какие потенциально будут изменены/заменены/выкинуты, и проектировать архитектуру в соответствии с этим.
  3. Если ты разрабатываешь какой-либо массовый софт, то нужно быть готовым, что он будет выполняться на огромном зоопарке устройств, версий операционных систем и в присутствии различного окружения.
  4. Обрабатывать придется не только корректные данные, но и ошибочные или поврежденные (в том числе злонамеренно).
  5. Зачастую приходится заранее рассчитывать на будущее масштабирование продукта (на большее количество пользователей, на больший объем данных и т.п.).

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

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

Вскоре после того, как я получил бакалаврский диплом, меня пригласили работать в зарождавшийся в тот момент стартап Виктора Шабурова, где я продержался 7 месяцев, после чего меня оттуда выгнали (я чувствовал себя не в своей тарелке, несколько наплевательски относился к работе и вступал в конфликты с руководством). И да, значительного профессионального роста я тоже не получил. Про все это тоже когда-нибудь напишу подробнее.

На нынешнем месте (в Positive Technologies) я работаю C++-программистом уже 8 месяцев, и здесь с профессиональным ростом как раз все получилось очень хорошо. Что я заметил: чтобы расти профессионально, важно проявлять инициативу и перетягивать на тебя те задачи, в ходе решения которых ты изучишь много нового. Т.е. быть прилежным исполнителем — недостаточно.

Прошу прощения за немного сумбурный текст. Появятся свежие мысли — напишу еще.