index0h

Живете вы в Украине, или нет - роли не играет. Вы не там задаете свой вопрос.
Самое точное, что можно сказать: вас будут ожидать задачи, связанные с python.
Точнее можно узнать только у организатора олимпиады.

Зачем?
Улучшает ли это читабельность? Не улучшает.
Возможно дело в произвлдительности? Вы ее просто растрачиваете на беготню по массиву.
Может кода меньше? Опять nope.

писать конвертеры такого кода на другие языки и удобно мониторить их изменение.

Зачем в принципе их писать?

UPD

Как автоматически транслировать любой готовый алгоритм с любого ЯП на любой другой ЯП без ущерба для скорости работы алгоритма?

Никак, буквально никак. Потому что:

1. Способы работы с памятью и оптимизации производительности разные.
2. Конструкции, используемые в конкретных языках для конкретных алгоритмов отличаются.
3. Отличаются стандартные библиотеки, как следствие алгоритм, который вы хотите транслировать с одного языка может быть в стандартной библиотеке другого.

Даже, если вы спросите: а дайте ка взглянуть на ваш код - вы же понимаете, что получите красивый участок.

Можете задать такой вопрос. Программистов можно условно разделить на три категории по тому, что им нравится:
* Исполнитель - его радует результат, максимально быстро и чтоб работало.
* Гик - ему интересно попробовать всякие моднявые штуки, только вышла новая либа - он хочет ее заюзать.
* Головолом - ему интересны сложные крупные задачи, там где надо посидеть, по медитировать.
Собсно вопрос: какого человека по этим категориям вы ищите?
Чаще всего идет микс из двух, если говорят все три важны одинаково - интервьюеру глубоко фиолетово. Если при этом интервьюером является технический специалист - это очень плохой знак.
Так же можете спросить, кто по этой шкале есть в команде. Если команда состоит из одного типа программистов - это очень плохо.

Что касается качества кода: спросите про используемые соглашения, критерии на код ревью и покрытость тестами

Допустим я хочу понять, почему один метод перебора массива эффективнее другого.

Знание разных языков не даст вам понимания, что такое O и понимания теории алгоритмов.

Безусловно, я могу замерять скорость и просто использовать самый быстрый.

Самый быстрый - это уровень железа, всякие языки описания аппаратуры для ПЛИС, ассемблеры и т.д. Без должной подготовки вы даже сложно использовать не сможете.
За скоростью стоит гнаться только в случае, когда это критичная задача для бизнеса, более того оптимизация за счет алгоритма иногда не имеет смысла.
Пример: у вас небольшой сайтец, на каком-нить хостинге за полтора бакса в месяц. Под Новый год сайтец не справляется. Правильный вариант в такой ситуации - это переехать на хостинг за два-три бакса в месяц, а потом в случае чего вернуться обратно.

Какой язык полезно выучить для понимания современных языков программирования?

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

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

https://gist.github.com/

Собственно php и любой другой язык подключается под сто раз внутри разметки. Зачем?

чего вдруг 100 раз? 1 раз интерпретатор запустился, выполнил документа, забросил данные в opcache и в следующий раз уже с оперативки вытащит.
Затем, что php так спроектирован, и для такого использования он хорош.

Какой жанр игр самый сложный в создании?

Немного переформулирую: какого цвета машины самые быстрые?

Я спросил почему не выживач? Он ответил что выживачи говно

Конструктивненько))

Rogue-like или выживалка?

Зависит от ТЗ. Вот пример: игра в крестики-нолики, казалось бы, что может быть проще? Но управление через Kinnect, а визуализация - через Oculus Rift, конечно же мультплеер, рейтинги, онлайн общение игроков и т.д. Ну что, простая игра получается?))

И вообще какой жанр самый сложный по созданию и какой самый лёгкий?

Все зависит от ТЗ.

Как определить свой уровень программирования?

Как правильно проверять работоспособность продукта?

Тестировать:
unit - обычно пишет программист на свой же код, все зависимости мокаются, чаще всего по белому ящику. При покрытии 95+% добрых 3/4 вашего кода - это тесты.
functional - тоже, обычно пишет программист, но уже с задействованием внешних сервисов, например БД. Тут главное не переборщить, функциональные тесты пишутся быстрее, но они на порядки медленнее, чем юнит тесты.
appearance - чаще пишут QA, иногда проводят мануально, цель - быстро понять, что продукт в принципе работает и ничего критичного не поломали
regration - чаще пишут QA, и проводят мануально - это полная проварка того, что продукт работает согласно ТЗ.

Какая общая схема?

1. Написал код по таске
2. Покрыл тестами
3. Отправил на код ревью
4. Сделал исправления, если нужно
5. Залил в рабочую ветку

Можно ли как то автоматизировать это?

Во многом - да, конечно, берете и пишете тесты.

Как проверить продукт на 100% работоспособность?

Покрыть тестами все возможные неполадки вашего продукта. Но, до всех вы не додумаетесь, и не защититесь от них, так что 100% - это довольно эфимерная цифра. Например, как вы гарантируете, что продукт будет работоспособен, если все ДЦ, в которых он размещен разом выйдут из строя?))

Что все ошибки обрабатываются правильно, что на 100% не будет исключений в коде.

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

Выбор технологий - это результат анализа и исследований по тех. заданию.
Например проекты, завязанные на событийную модель вероятно легко будут писаться и поддерживаться на ноде. Проекты, завязанные на ms - на с#. Проекты, которые будут очень динамично развиваться - вероятно на пыхе поддерживать будет проще всего, и т.д.
Не последним вопросом является популярность, например вы решили писать на эрланге, потом ваш инженер уволился и оказалось, что он единственный специалист по этому языку в вашем городе.

Стоит ли читать старые книги по ***?

NO. Пока вы изучите старое - текущее новое может устареть, а старое выйти из обихода.

За день-два можно сделать POC (prof of concept) версию, "по говну" так сказать. Задача подобного - это не реальная работа под нагрузками, а скорее исследование, как в принципе писать такие штуки.

forever := make(chan bool)
<-forever

DevOps - специалист широкого профиля. Объединяющий в себе Dev, Sysadmin и QA. Из за того, что направление очень широкое в каждой компании в devops можно вложить все что угодно. У одних это будет ansible+docker+php+jenkins+... у других - java+chef+oracle+solaris+... у третьих - еще что-то.