Подход "накинем ещё памяти и ещё пару ядер сверху" не будет работать вечно. Если, конечно, не делать систему, которая в целом развиваться не собирается
Нельзя просто взять и сказать, что при подходе N нужна технология M. Каждую ситуацию нужно рассматривать по отдельности и не сгребать под один подход все приложения. Не просто так существует несколько типов брокеров сообщений (Kafka, Rabbit, IBM MQ) или несколько реализаций RPC. Каждый имеет где-то выйгрыш, где-то проигрыш
Вопрос более обширный и слово "алгоритмы" выбрано как "один из". Работадатель должен спрашивать в глубь чего-либо. Да хоть структуры данных, хоть фреймворк. Даже про интерфейс Map можно говорить всёсобеседование. Основная реализация, потокобезопасноть, использование Map другими структурами и т.д. Это показывает насколько человек готов погружаться в то, чем он сейчас занимается, на сколько это ему интересно. Для работодателя - это, грубо говоря, ресурс, который он может с сотрудника получить. А обязан или не обязан это, конечно, дело каждого. Вопрос про сложности найма тоже достаточно обширный, данная статья, к сожалению, не раскрыла эту тему. Может в следующей напишу
Мы стараемся проводить рефакторинг кода каждые полгода, и всегда видим случайно или специально допущенные "алгоритмические" ошибки. Тут квадрат лишний, тут вообще всю коллекцию перебираем со вложенными сущностями (декартово произведение). И статья про то, что мы могли их и не увидеть. И в силу юного возраста, я просто надеюсь, что глаз начнет сразу замечать такие вещи
Да вы правы, справочная информация не нужна. Но как и описано в статье, работодатель в "идеальном мире" должен не спрашивать: "знаешь ли ты этот алгоритм?", а спрашивать: "а можно ли этот алгоритм применить вот в этой задаче". Тут уже половина начинает сыпаться, т.к. не могут применить справочную информацию к нестандартной ситуации
Даже такую простую задачу как вычисление простых чисел от 1 до N можно решить несколькими способами. В голову прямо сейчас приходит сделать этот процесс не ленивым, т.е. посчитать при старте приложения все числа ограниченные типом (int в Java, например) и возвращать уже его. Можно тут же и поговорить о трейдоффах в виде используемой памяти и т.д.
Информация
В рейтинге
Не участвует
Зарегистрирован
Активность
Специализация
Бэкенд разработчик, Архитектор программного обеспечения
.
Подход "накинем ещё памяти и ещё пару ядер сверху" не будет работать вечно. Если, конечно, не делать систему, которая в целом развиваться не собирается
А ей выплатили двойной оклад?)
"Больше всех в колхозе работала лошадь, но председателем она так и не стала"
Нельзя просто взять и сказать, что при подходе N нужна технология M. Каждую ситуацию нужно рассматривать по отдельности и не сгребать под один подход все приложения. Не просто так существует несколько типов брокеров сообщений (Kafka, Rabbit, IBM MQ) или несколько реализаций RPC. Каждый имеет где-то выйгрыш, где-то проигрыш
Вопрос более обширный и слово "алгоритмы" выбрано как "один из". Работадатель должен спрашивать в глубь чего-либо. Да хоть структуры данных, хоть фреймворк. Даже про интерфейс Map можно говорить всёсобеседование. Основная реализация, потокобезопасноть, использование Map другими структурами и т.д. Это показывает насколько человек готов погружаться в то, чем он сейчас занимается, на сколько это ему интересно. Для работодателя - это, грубо говоря, ресурс, который он может с сотрудника получить. А обязан или не обязан это, конечно, дело каждого. Вопрос про сложности найма тоже достаточно обширный, данная статья, к сожалению, не раскрыла эту тему. Может в следующей напишу
Хватит, а потом скажут примени тут алгоритм N. А он никогда такого не делал, только книжку читал
Мы стараемся проводить рефакторинг кода каждые полгода, и всегда видим случайно или специально допущенные "алгоритмические" ошибки. Тут квадрат лишний, тут вообще всю коллекцию перебираем со вложенными сущностями (декартово произведение). И статья про то, что мы могли их и не увидеть. И в силу юного возраста, я просто надеюсь, что глаз начнет сразу замечать такие вещи
Да вы правы, справочная информация не нужна. Но как и описано в статье, работодатель в "идеальном мире" должен не спрашивать: "знаешь ли ты этот алгоритм?", а спрашивать: "а можно ли этот алгоритм применить вот в этой задаче". Тут уже половина начинает сыпаться, т.к. не могут применить справочную информацию к нестандартной ситуации
Даже такую простую задачу как вычисление простых чисел от 1 до N можно решить несколькими способами. В голову прямо сейчас приходит сделать этот процесс не ленивым, т.е. посчитать при старте приложения все числа ограниченные типом (int в Java, например) и возвращать уже его. Можно тут же и поговорить о трейдоффах в виде используемой памяти и т.д.