Волна взаимопомощи (java)⁠⁠1

Добрый день. Спасибо за интересный список, каждый вопрос можно часами рассказывать :) Давайте вкратце пробежимся по пунктам:

1. Все зависит от того что вам нужно. Поскорей вкатиться в разработку? С вашим набором знаний (как мне кажется) достаточно быстренько прочитать pivotal (https://media.oiipdf.com/pdf/6cb8195f-2fca-4953-b644-b963510...), сделать pet-project. Маленько пробежаться по базовым алгоритмам/структурам данных и да, выучить методы класса Object.

Вообще есть неплохой список вопросов:

https://jsehelper.blogspot.com/2016/01/blog-post_59.html

Но я бы оттуда вычеркнул связь про JMX и ответы давал бы более развернутыми, нежели те, что есть на сайтах.

2. Зависит от того что вы хотите. Чаще всего нереляционные бд используются в стартапах где джуны особо не нужны. Где-то была популярна монго, но они и поступили не особо красиво, да и документные базы (ИМХО) УГ, ориентированное на то что люди на JS-е привыкли работать с json-ми и хотят их видеть везде, включая БД.

Как долгие хранилища используется Кассандра - на то чтобы писать много, а доставать почти никогда.

Если вам хочется что-то дополнительно изучить - из личных предпочтений и если вам хочется я бы посоветовал обратить внимание на key-value хранилища аля redis/hazelcast/apache ignite, до сих пор находятся фанатики которые кричат о том что SQL мертво и будущее только за распределенными кешами :)

Так же много где за последние 5 лет накручивали elasticsearch поверх чего-то, можно так же порыть в этом направлении.

Вообще как джуну я не рекомендую в это погружаться и провести первый проект с постгресом/ораклом, но за спрос не бьют :)

3. Вообще есть приятная книжка clean architecture, которая дает очень много теоретических знаний которые очень сложно применить практически :) Но ее точно стоит прочитать для расширения кругозора. Вообще изучите rest архитектуру, изучите как работают очереди, JMS, AMQP, можете поковырять кафку. Из этого всего сконцентрироваться рекомендовал бы именно на ресте, т.к. остальное крайне специфично и разнится от проекта к проекту.

4. Не смотря на то что люди рекомендуют коммитить в опен сорс (и это правда круто, учитывая что этим можно козырять на собесах) - я рекомендую воздержаться и вести свой pet-project. Придумайте тему и начните ее развивать. Если будут идеи - можете скинуть сюда и, аккуратно, подберем вам стек под необходимую задачу

5. Уровень ЗП критически важен, но, в последнее время, я в последнее время больше смотрю на стек (интересно/не интересно), бизнес-процессы (начиная с вопроса о том какие скрам активности проводятся/в каком режиме работаем), смотрите на команду, пообщайтесь с собеседующим, спросите его про CI/CD процессы, про периодичность релизных циклов и какие проблемные задачи стояли перед командой в последнее время, попросить пояснить почему в системе было сделано то или иное техническое решение. Документацию же вам никто не даст почитать при приеме на работу.

6. Очень специфично для каждого проекта. В хорошем проекте я вижу это так:

BA собирают требования и пишут success criteria, после чего обсуждают с командой разработки и уточняют тех детали (содержимое сущностей, эндпоинты).

Разрабочики предоставляют API через какой-нибудь плагин сваггера, по которому можно всегда свериться/дополнить/проверить рабочие эндпоинты (с кратким пояснением для нестандартных операций)

Граничные кейсы описываются тестировщиками и, к сожалению, обычно устанавливаются уже as-is после написания кода. В зависимости от критичности для заказчика (например для денежных переводов) могут проговариваться BA заранее, а могут быть "ну как сделали так и будет" при малой необходимости. Обычно норм разрабы уточнят по этим кейсам при покрытии юнит тестами и быстро дадут необходимое объяснение