Что должен знать Middle Java Developer (Backend)?

Добрый день, как вы думаете, что надо знать на middle уровень по backend java. На данный момент считаю:
— надо хорошо разобраться в многопоточности
— nio
— Углубленно прошариться с Redis и какой то очередью( например RabbitMQ)
— и с виртуальной машиной(тюнинг, снятие дампов и т.д),
— более менее понимать что происходит под капотом у Spring.
— Более глубоко разобраться с какой популярной реляционной СУБД(как работают индексы под капотом, триггеры, виды локов на таблицу, уровни изолированности транзакций и т.д.)
— пощупать какой то NoSQL
— пощупать новые для себя фреймворки и понять какие задачи они решают (Akka, Vert.x)
— реализовать самому какое то приложение на микросервисной архитектуре, разобраться что такое Docker и с чем его едят, попытаться самому развернуть ELK стек и писать туда логи

Хотелось бы услышать ваше мнение, чтобы подкорректировать или дополнить мой список

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как ни странно около-hard и частично soft-skills наиболее важны:
— хороший английский
— сюда же — проводил ли сам демо, общался ли непосредственно с кастомером, если да — уже огромный плюс.
— умение прекрасно рассказать о прошлых проектах, где между строк подать себя как грамотного исполнителя с небольшой инициативой. Пример: «Не сидел на багфиксе, а вызвался добровольцем поднять процент регрессии на %%, в процессе нашел n дефектов, которые успешно преодолел». Ну ты понел...в рассказе о себе ты всегда должен подавать себя победителем. Этот пункт чуть ли не самый важный из всех. Твой рассказ о себе должен по макс. вписываться в текст вакансии, поэтому нужно делать акцент на важных для работодателя вещах. А менее значимые упускать или упоминать вскользь
— знание Git, SVN, Maven, Gradle, Jenkins, JIRA, Tomcat, JBoss и прочая инфраструктура
— прекрасные знания IDE
— уметь видеть паттерны в коде и должно быть понимание где их использовать, где уже не надо
— будут давать кейсы: «У тебя 2 таска и 3 дня и ты оба не успеешь, что ты будешь делать?»
— некофликтность и коммуникабельность важны как и умение отвечать на идиотские вопросы не взрываясь при этом, будут прямо или косвенно проверять.
— умение вести переписку на англ, хоть щас в тренде и informal-стиль, но умение написать короткий note или email важно.

По технологиям все те же вопросы что и у джунов, ничего не поменялось. Я бы не советовал копать куда ты копаешь. Щупал — ну круто конечно, молодец что не ржавеешь, но такое лучше в резюме не писать.

Вывод: больше софт-скилов и акцента на себя как работника, чем копания в технологиях.

если бы я подбирал людей в команду, я бы не смотрел на знания конкретных технологий типа вышеупомянутых (ибо это может оказаться нафиг не нужно в конкретном проекте, к тому же они меняются и устаревают достаточно быстро).
-общая адекватность, способность и желание учиться и развиваться
-проблем солвин и комьюникейшн скиллс. умение решать проблемы в широком смысле. как технические, так и с людьми. если чего-то не знаешь — спрашивай, обращайся за помощью, не ковыряйся самостоятельно если не можешь решить проблему быстро, или не знаешь с какой стороны начать.
-умение писать качественный, хорошо сопровождаемый и покрываемый юнит тестами код
а если более конкретно
-пишет код который легко тестировать, в котором зависимости легко подменить мок-объектами
-следует принципам SOLID и Clean Code (не до религиозного фанатизма но с разумной достаточностью)
-не оставляет огромные закоментированные куски кода
-умеет пользоваться абстрактными классами и интерфейсами, агрегацией и композицией, для разбития приложения на небольшие по объему классы/модули. не запихивает over 900 строк в один класс/метод который делает все сразу и много
-не создает «толстые» интерфейсы с кучей ненужных потомками методов которые все равно нужно переопределять
-не создает больших дублирующихся кусков кода методом копи-паста
-не занимается преждевременной оптимизацией , по крайней мере до тех пор пока не выявлены узкие места перформанс тестами
-не изобретает «велосипедов» для функционала который уже есть в широко известных и хорошо протестированных библиотеках (apache commons, guava и тд, не говоря про стандартные библиотеки Java)

вы удивитесь как много «синьоров» с большим опытом пишут нечто монстроуозное и непригодное к повторному использованию
я бы предпочел сильного джуниора или миддла , знающего или способного впитать культуру хорошего кодинга, чем иметь синьора с дурными привычками которого невозможно перевоспитать

понимать 3 главный концепта: костылирование, инкостыляцию и поликостылизм )))

1. Написати FizzBuzz.
2. Написати обхід дерева рекурсивно та не-рекурсивно.
3. Не тупити та вміти швидко вчитися. Друге тільки на випробувальному терміні можна перевірити.
4. Якісь конкретні знання які треба під конкретний проект — тут не вгадаєш, комусь треба RDBMS, комусь (як мені наприклад) не треба взагалі, зате треба NoSQL.
5. Бути нормальною людиною.
6. Вміти нормально розповісти чим займався раніше.

и сортировка пузырьком )))))))

вот вы шутите, а 80% кандидатов путают ее с сортировкой вставкой. а еще процентов 5% не могут написать. так что не так тут все и весело :(

Класс, чел сравнил хешмапы на которых весь интернет работает с какой то лажовой O(n^2) сортировкой.

Что должен знать Middle Java Developer (Backend)?
Хешмапы еще, хешмапы!
и сортировка пузырьком )))))))
с какой то лажовой O(n^2) сортировкой.
Для заведомо небольших последовательностей это самое эффективное решение.

«Самое эффективное»? Покажите ваши исследования потом будем разговаривать.

Пускай не пузырьковая, но сортировка вставкой (тоже n^2) часто используется как оптимальная для маленьких последовательностей и/или как сортировка минимальных подпоследовадельностей в более сложных алгоритмах сортировки.

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

В різних компаніях власне розуміння градацій джун/мідл/сіньор. Хочете себе оцінити? Як на мене, я завжди буду джуном.

Михаил, возможно половину из этого Вы вообще никогда не будите использовать: все завистит от конкретного проекта. А то, что Вы написали у нас могут как на джуна так и на сеньера спросить )

Підписатись на коментарі