Ага, отрицательно. Чего же тогда Google просто мощным пылесосом собирает всех толковых олимпиадников прям со студенческой скамьи, а бывает что и раньше? Кроме того, проводит одно из самых крупных подобных мероприятий на протяжении уже десяти лет (и довольно агрессивно хайрит на нем).
Отрицательная корреляция, вероятно, получается из-за того выборку составляют именно сотрудники Google. И выводы Норвига могут быть верны только для этой группы. Автор топика популистски пытается сдвинуть акцент на программирование вообще, что в корне неверная интерполяция.
Кроме того:
Есть мнение, что кандидат-неолимпиадник, который решит их задачи на структуры данных, эффективную обработку и алгоритмы правда талантливее кандидата-олимпиадника, если тот покажет схожий результат. Ведь в самом деле, второй на протяжении нескольких лет тренируется решать задачки именно на алгоритмы, а в работе требуется более широкий скиллсет.
Есть мнение, что часто Google нанимает overskilled сотрудников для того объема в том числе рутинной работы, что есть в компании. Вероятно, победители контестов правда к ней меньше склонны.
Возможны спецэффекты вида, что массово олимпиадники появились в большей степени не так давно и многие из них еще молоды и не полностью раскрыли свой потенциал. Вероятно, средний сотрудник неолимпиадник старше и чаще занимает позицию повыше (middle vs junior).
Да и вообще, это мнение далеко не разделяется всюду в компании:
Александр Мангилёв:
Я техникал лид команды отвечающей за кластеризацию бизнесов в Гугле. Учился программировать исключительно учавствуя в олимпиадах (и ни чем кроме олимпиад не занимаясь). Благодаря навыкам полученным в олимпиадах я заметно лучше большинства моих коллег умею придумыать различные эвристики (что очень полезно на практике!). И пишу принципиально более эффективный (и мне кажется, что и более понятный тоже) код если требуются нетривиальные алгоритмы. Мечтаю о красном кодере в команде… Под зарез нужен человек, которому можно просто сказать: «Придумай как это сделать классно» — и что бы он был способен сам придумать классное решение и потом его закодить вообще без моего вмешательства. Полный текст.
Павел Наливайко:
I work for a Search Quality team at Google. We absolutely love hiring winners from programming competitions. Whether they will develop into a high performing engineers or not depends entirely on them, but they definitely posses the raw talents and skills to become one [...] But there aren't too many places where you can get a very relevant background to work in Search Quality anyway. As a team lead, I'd be happy to hire a less experienced contest winner, teach him and help to develop into a star performer. And there are many successful examples (some of them were mentioned in this thread couple of times already ;) Полный текст.
Bartholomew «Ruberik» Furrow:
The conclusion this article offers is drawn from a badly flawed study from over a decade ago, which Google decided neither to publish nor to use the conclusions from. Полный текст.
Ну вот идет финал и на первом-втором месте уверенно держится alberist, у которого стратегия (тадам!) на Питоне (http://russianaicup.ru/profile/alberist/strategies). Ну вот к чему был этот необоснованный скепсис?
Спасибо за фидбек. Отвечу как один из организаторов.
В самом деле избавиться от get_ в именах методов в пакете для ruby нормальная идея, но эту мысль мало кто высказывал (только вы?) и не на официальном сайте (либо в комментариях, либо через форму связи с администрацией, либо послав pull request), а в промопосте здесь. Занимаясь улучшениями системы и поддержкой по множественному фидбеку на официальном сайте во время беты, ваш комментарий здесь просто не был во время замечен и рассмотрен. Отсутствие предложений пофиксить это от нескольких участников намекает, что это не сильно востребованное улучшение.
Отмечу, что и сейчас все довольно единообразно: все методы начинаются с глагола, а то что без — это ридеры атрибутов. Есть еще тонкость, что подобная правка ломает обратную совместимость — поэтому правильным решением наверное было бы оставить лапшу из двух вариантов, что тоже не выглядит элегантно. К сожалению, практика некоторого неединообразия в именовании характерна даже для стандартных библиотек большинства языков.
Ваш пулл реквест с rakefile-ом ломает кроссплатформенность, автоматизируя тривиальные вещи: архивация файликов в директории и запуск двух команд. Мне кажется любой программист пишет подобный скрипт для себя за минуту-другую под свой процесс разработки и настроенное окружение.
Таково требование юристов. На самом деле подобный пункт есть практически во всех программистских конкурсах: Russian Code Cup, Facebook Hacker Cup, Google Code Jam и прочих. Дело в том, что выдать приз несовершеннолетнему участнику значительно сложнее.
Информация о требовании к возрасту была опубликована одновременно с началом конкурса и содержится в первом же абзаце правил. Кроме того, эта информация дублируется еще в нескольких местах, например на странице редактирования профиля пользователя (рядом с элементом формы о возрасте). В прошлом году были те же требования и изменений вокруг их визуализации не было.
Есть такой трюк. Если надо бинпоиском поискать в массиве длине n, то можно разбить его на sqrt(n) блоков по sqrt(n) элементов. Затем бинпоиском за log(sqrt(n)) подыскать нужный блок и в нём вторым бинпоиском за log(sqrt(2)) найти элемент. В сумме получается всё тот же log(n), но попаданий в кэш значительно больше, т.к. каждый раз ищем на довольно коротком массиве длины sqrt(n).
Другая проблема. Если набрать < вместо <<, то программа компилируется, но не будет работать. А вот если перепутать и набрать cin вместо cout, то в неподготовленного обучаемого g++ плюёт почти 8 килобайт ошибок.
Как раз в Turbo Pascal был накрутейший error handling. Подсвечивается строчка кода, туда ставится курсор, сообщение об ошибке почти всегда простое и понятное. Меньше возможность сделать опечатку и чтобы программа при этом продолжала компилироваться или делать вид, что работает.
Еще момент. В Turbo Pascal по умолчанию был режим проверки на выходы за границы массивов. В C++ же наверняка a[10], а потом 1-индексация от 1..10 не будут приводить к падению программы. У обучаемых, конечно, будет мнение: работает, значит правильно, значит ошибки нет. Да, а в TP7 программа бы аварийно остановилась с подсветкой нужной строки кода и сообщением, что в ней произошел выход за границы.
Утилита Local Runner была доступна и в прошлом году с самого начала. Конечно, улучшения по просьбам участников вносились регулярно. Мне кажется, прислушиваться к пожеланиям сообщества — это неплохо.
В этом году всё стало еще лучше: все улучшения прошлого года мигрировали в этот год, многое было внедрено заранее по мотивам записей в issue tracker, к началу бета теста была удобная инфраструктура для участия. Большой рывок — вытащили наружу причины падения стратегий.
На самом деле такое определение видимости довольно удачно — текущие бои показывают, что сражения не перерастают в позиционную борьбу в стиле «кто высунулся, тот труп». Кажется, что в топе находятся в меру агрессивные стратегии с нетривиальным поведением.
Турнир этого года и прошлогодний сильно различаются. Повторяться не хотелось. Мы уже получили довольно много положительных отзывов — думаю, своего участника игра нашла. На самом деле рутины и здесь не так много, а простора для выбора стратегии не меньше чем было в танках.
Что значит обратная? Перевернутая? Так как вроде как запись бесконечна, то невозможно указать даже цифру, с которой она начинается. Если имеется ввиду запись, в которой все цифры поменяны так 0<->9, 1<->8, ..., 4<->5, то вроде опять ответ «нет». Так как если бы такое было, то потом в этой обратной записи встретилась обратная к ней, то есть прямая. Выше уже показал, что прямая запись не содержится.
Только с позиции 0. Предположим, существует вхождение с позиции d (d > 0). Тогда легко заметить, что 0-ой символ строки равен d-ому, 2d-ому, 3d-ому и так далее. Аналогично 1-ый равен (d+1)-ому, (d+2)-ому и т.д. Вообще, все символы с одинаковым остатком при делении на d совпадают. То есть запись имеет период длины d, следовательно, π может быть представлено дробью вида (первые d цифр)/(9999.9). Короче, показали, что π — это рациональное число, что неправда.
Дайте ссылку вида codeforces.ru/contest/71/submission/3516879 (нажмите в решеточку на попапе с исходником) А сейчас еще надо догадаться, что за задача, и на каком тесте возникают проблемы.
В данном случае вы можете просто опубликовать ссылку на свое решение, а мы все вместе на него посмотрим и поймем в чем дело. Но повторюсь, эквивалентная реализация на Python вполне может отставать от С++ в 5-20 раз.
Да, конечно. Наличие внутренних вершин степени более 2 делает задачу значительно содержательнее. Полагаю, без динамического программирования здесь не обойтись.
Отрицательная корреляция, вероятно, получается из-за того выборку составляют именно сотрудники Google. И выводы Норвига могут быть верны только для этой группы. Автор топика популистски пытается сдвинуть акцент на программирование вообще, что в корне неверная интерполяция.
Кроме того:
Да и вообще, это мнение далеко не разделяется всюду в компании:
В самом деле избавиться от get_ в именах методов в пакете для ruby нормальная идея, но эту мысль мало кто высказывал (только вы?) и не на официальном сайте (либо в комментариях, либо через форму связи с администрацией, либо послав pull request), а в промопосте здесь. Занимаясь улучшениями системы и поддержкой по множественному фидбеку на официальном сайте во время беты, ваш комментарий здесь просто не был во время замечен и рассмотрен. Отсутствие предложений пофиксить это от нескольких участников намекает, что это не сильно востребованное улучшение.
Отмечу, что и сейчас все довольно единообразно: все методы начинаются с глагола, а то что без — это ридеры атрибутов. Есть еще тонкость, что подобная правка ломает обратную совместимость — поэтому правильным решением наверное было бы оставить лапшу из двух вариантов, что тоже не выглядит элегантно. К сожалению, практика некоторого неединообразия в именовании характерна даже для стандартных библиотек большинства языков.
Ваш пулл реквест с rakefile-ом ломает кроссплатформенность, автоматизируя тривиальные вещи: архивация файликов в директории и запуск двух команд. Мне кажется любой программист пишет подобный скрипт для себя за минуту-другую под свой процесс разработки и настроенное окружение.
Таково требование юристов. На самом деле подобный пункт есть практически во всех программистских конкурсах: Russian Code Cup, Facebook Hacker Cup, Google Code Jam и прочих. Дело в том, что выдать приз несовершеннолетнему участнику значительно сложнее.
Информация о требовании к возрасту была опубликована одновременно с началом конкурса и содержится в первом же абзаце правил. Кроме того, эта информация дублируется еще в нескольких местах, например на странице редактирования профиля пользователя (рядом с элементом формы о возрасте). В прошлом году были те же требования и изменений вокруг их визуализации не было.
Как раз в Turbo Pascal был накрутейший error handling. Подсвечивается строчка кода, туда ставится курсор, сообщение об ошибке почти всегда простое и понятное. Меньше возможность сделать опечатку и чтобы программа при этом продолжала компилироваться или делать вид, что работает.
Еще момент. В Turbo Pascal по умолчанию был режим проверки на выходы за границы массивов. В C++ же наверняка a[10], а потом 1-индексация от 1..10 не будут приводить к падению программы. У обучаемых, конечно, будет мнение: работает, значит правильно, значит ошибки нет. Да, а в TP7 программа бы аварийно остановилась с подсветкой нужной строки кода и сообщением, что в ней произошел выход за границы.
В этом году всё стало еще лучше: все улучшения прошлого года мигрировали в этот год, многое было внедрено заранее по мотивам записей в issue tracker, к началу бета теста была удобная инфраструктура для участия. Большой рывок — вытащили наружу причины падения стратегий.
На самом деле такое определение видимости довольно удачно — текущие бои показывают, что сражения не перерастают в позиционную борьбу в стиле «кто высунулся, тот труп». Кажется, что в топе находятся в меру агрессивные стратегии с нетривиальным поведением.
Турнир этого года и прошлогодний сильно различаются. Повторяться не хотелось. Мы уже получили довольно много положительных отзывов — думаю, своего участника игра нашла. На самом деле рутины и здесь не так много, а простора для выбора стратегии не меньше чем было в танках.
Большая проблема с производительностью — такой код работает за O(n^2). Кстати, можно вспомнить аналогичный пример из мира С: