Комментарии 20
Почему в условии задачи указан пункт "answer[i] == i (as a string) if none of the above conditions are true", но ни одно из предложенных решений его не выполняет?
А init1 вообще одну ветку потерял.
Это еще можно списать на невнимательность, но в итоге выглядит так, как будто автору поставили конкретную задачу, а он потратил полдня на решение совсем другой (добавление потерянного условия вместе с затратами на операции вывода на экран или в файл вполне могут сделать выигрыш в производительности несущественным). Кажется, сеньорский подход предполагается немного не таким.
В каком месте - там и 3 и 5 и 15 чекается же?
А что потеряно в init1 ?
UPD: видимо поинт был в else if
if (i % 3 == 0){ sb.append("Fizz"); }
if (i % 5 == 0){ sb.append("Buzz"); }
if (!sb.isEmpty()){ rez.add(sb.toString()); }
Спасибо за коммент. Мы не трэекаем это условие. Смысл поста не в этом. Я поправил условие.
Было бы интересно в init5 printFizzBuzz сделать как Function<Integer, String>
Во втором варианте выяснили, что избавление от "%" дает прирост, но в последующих сделано по-старому. Выкинута распечатка собственно чисел. Из оригинальной статьи не взята куча идей - например, разворачивание цикла в 15 элементов в одну общую склейку строки. В Java есть аналоги reserve() для строк/контейнеров, чтобы избегать реаллокации? Частый вызов функций для числодробилок может оказаться заметно затратным - возможно, стоит сравнить функциональный стиль с императивным. Аллокации в памяти внутри функций тоже прилично съедают, даже если компилитор соптимизировал переменные внутри циклов.
Как правильно проходить задачки на собеседование.
"Идите на***" вот универсальный ответ. После чего идём искать нормальных людей которые проводят собеседование, а не решение задачек. Всегда пользуюсь этим методом, никогда не было проблем.
Ну вы молодцы конечно, массив 1-based!
Есть одна проблема с Senior Edition
Все же должность сениора предполагает знание контекста:
- где и как код будет выполняться
- есть ли требования к окружению, оборудованию
- архитектура проекта, кто будет его обслуживать и т.д.
- иными словами - каковы приоритетные требования к этому коду
Например, если это, задача для редко используемого билд скрипта, с которым вероятно будут работать случайные люди - его приоритет понятность.
А в обычных условиях требование "максимальная производительность" обычно не ставится, особенно в ущерб читаемости. Этого требует ограниченный набор сущностей, например драйвера устройств, библиотеки для высокопроизводительных вычислений или фоновые системные утилиты.
Вполне вероятно, что самое важное на собеседовании к такой задаче будет как раз беседа об этом (чтобы показать, как вы мыслите и подходите к решению такой задачи) плюс довольно простая реализация алгоритма (потому что требование для собеседования без требований - быстро, просто и узнать требования).
Да поддерживаю. Я как то по умолчанию это в голове прокрутил и не подумал о том, что это стоит писать. Было как раз более интересно посмотреть на различные бэнчмарки посмотреть =)
Да, это сочное соревнование программистов, но у меня в последнее время другие приоритеты - Я упарываюсь по архитектуре.
Причем не высокопарно, по паттернам (от этого многих коллег наоборот приходится лечить), а в практическом смысле - какие приемы хороши и плохи, какие сохраняются между проектами и воспроизводятся разными разработчиками, когда классические рекомендации хороши, а когда - весьма вредны и т.д.
В результате возникла следующая идея: осознав проблемы конкатенации строк, я решил оптимизировать процесс и сэкономить время, что привело к созданию следующей реализации
Где в init0 конкатенация? там же просто добавление элементов в массив. (так же как и в init1 rez.add(sb.toString()))
Самым интересным тут было бы разобраться, почему в варианте 3 происходит более чем 20-кратное улучшение. Я бы при 4-х нитях ожидал улучшение в 4 раза (ну, если проц 4 нити тянет) минус накладные расходы.
Метод init3 работает некорректно, так как он недетерминированный - результаты выполнения потоков объединяются в неопределенном порядке. Из-за этого результат метода init3 может отличаться от результатов других методов. В данном случае необходима другая логика объединения результатов.
Проблема. Сеньор это уже не алгоритмы. Это уже
1. Спектр технологий.
2. Построение и сопровождение продукта с нуля.
3. Работа с людьми.
Именно поэтому споры и ненависть про алгоритмы. Именно поэтому сеньор ~3 года это очень смешно. Именно поэтому побеседовать сеньора не умеет 99% собеседующих. На реальной задаче сеньора на ту же оптимизацию ложится не столько параметр ее мат. эффективности, сколько параметры сроков, кадров и пресловутое бизнес-велью.
И да. 99% соискателей сеньорской должности не умеют в построение апи. Этому литкод, хакерранк и олимпиады не учат.
FizzBuzz for Senior