Wan-Derer

1 или 2.

Алгоритмы брать не надо. Седжвик вообще писал не про Java а только про алгоритмы.
У него - целое семейство книг такого вида. Сначала Алгоритмы на С. Потом на C++ И потом Java. Он по сути портировал исходники. Какой толк вам в таком портировании?

А Хорстман, Эккель - вполне себе норм.

"Java. Библиотека профессионала", Хорстманн.

Минусы:

1.Буду медленно развиваться как профессионал и поверхностно погружаться в темы.

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

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

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

3.Знакомые опытные ребята говорят, что фулстек джунов не существет и это вообще треш.

Все так, но позиция есть и оффер есть, значит что-то там делать можно.

4.Из-за того, что я не технарь и будет много разных технологий, придется очень много овертаймить ближайший год.

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

5.Перманентный стресс, от скорости работы с разными технологиями+общение на английском(при учете что никогда не общался на английском). Только читал+видосы смотрел+переписывался.

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

6.Переезд в другой город, + если завалю испыт или сам захочу уйти, надо будет возвращаться в свой город.

Если молод, нет семьи и ребенка, то какие проблемы на три месяца сделать себе эксперимент?

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

А для чего ты вообще искал новую работу и получал оффер? Хотел работать сразу на двух?

Считай, что тебе сильно повезло. Джуна да ещё и на такой бэкграунд...
Будешь дураком, если откажешься

Судя по обозначенным минусам - вы уже для себя всё решили.

Я бы посоветовал, тк это первый опыт, всётаки сходить на испытательный, а если все беспокойства оправдаются - со спокойной душой уйти

Зарплата - 500 долларов до испыта, 700 - после.

Есть неиллюзорный шанс, что:
1. К долларам это ни разу не привязано
2. После испытательного так и останется 500.

Дело в том, что позвали меня на позицию Full-stack(junior). Если бы это был фулстек веб(нода+реакт), допустим, скорее всего я бы согласился.

Но тут надо разбираться с любыми технологиями, которые нужны заказчику(компания аутсорс). Мне сразу сказали, что надо будет и с мобилками работать и уметь деплоить и с кубернетисом работать.

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

Так же из-за специфики работы, пм будет общаться с заказчиком, но будут очень частые случаи, когда надо будет созваниваться с заказчикам, уточнять какие-то моменты + презентовать продукт по результатам работы.

Это норма для небольших компаний.

3.Знакомые опытные ребята говорят, что фулстек джунов не существет и это вообще треш.

Фулстек сеньоров тоже)
Если хочешь жёстко по хардам прокачиваться, то надо более узко специализироваться.

через несколько месяцев будет происходить пересмотр квалификации

Спросите у тех кто будет делать пересмотр.

Для повышения внутри аутсорсинговой (не продуктовой) комании на самом деле тебе ни ООП ни PHP не надо.
Надо просто спросить у твоего line-manager или ресурсного-менеджера какой план
твоего роста. И какие вопросы будут звучать на assesment. В обычном ассесменте нет ничего
сложного. Собирается комиссия из 3х и более человек. И с тобой просто беседуют. Узнают
твой опыт. Прошлые проекты. Задают вопросы по уровню квалификации. В составе комисси
обычно есть твой тех-лид. Обычно к ассесменту тебя хорошо знают. И у тебя есть характеристика.

По поводу твоей продуктовой компании. Здесь сложно что либо сказать но ты не должен распыляться
на всякое там ООП и прочее. Это никому не надо. Нужно готовиться только к релевантным вещам
которые есть в компании. Например - компания использует Laravel? Пройди сертификацию.
Это будет более полезный бонус чем безсмысленная философия про эти инкапсуляции и прочее.

Вообще ООП - это страшный моветон и им принято мучать джунов при поступлении.

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

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

Если же в проекте нет денег для того, чтобы платить своим сотрудникам больше, то вряд ли пересмотр случится, как бы ты не старался (понятно что исключения могут быть, но..)

Думаю, вам будет интересна эта статья, где решается похожая задача:
Yandex Planner. Как планировать вычислительные мощности
И доклад:
Дефрагментация вычислительных ресурсов кластера

Ещё можно посмотреть, как работает шедулер в k8s:
https://habr.com/ru/companies/flant/articles/335552/
https://kubernetes.io/docs/concepts/scheduling-evi...

cmd

for /l %%x in (1, 1, 999999) do echo %%x>>d:\Out.txt

Вопрос некорректный, различий не может быть, так как прототипы - разновидность ООП.

Отличие с классами есть:
Прототипное программирование # Сравнение с класс-о...

В языках, основанных на понятии «класс», все объекты разделены на два основных типа — классы и экземпляры. Класс определяет структуру и функциональность (поведение), одинаковую для всех экземпляров данного класса. Экземпляр является носителем данных — то есть обладает состоянием, меняющимся в соответствии с поведением, заданным классом.

Сторонники прототипного программирования часто утверждают, что языки, основанные на классах, приводят к излишней концентрации на таксономии классов и на отношениях между ними. В противоположность этому, прототипирование заостряет внимание на поведении некоторого (небольшого) количества «образцов», которые затем классифицируются как «базовые» объекты и используются для создания других объектов. Многие прототип-ориентированные системы поддерживают изменение прототипов во время выполнения программы, тогда как лишь небольшая часть класс-ориентированных систем (например, Smalltalk, Ruby) позволяет динамически изменять классы.

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

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

Для верности можно взять Axiom JDK, он сертифицирован ФСТЭК, точно никто не придирëтся.