Многопоточность в реальных проектах

Этой статьёй я не собираюсь "разрушать легенды" (опровергать что-либо целиком и полностью), а лишь опишу то, что я видел своими глазами и щупал своими руками за свою недолгую карьеру.

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

- работать намного сложнее, чем учиться?

- будет ли у меня время освоиться с проектом?

- что, если я буду "тупить" вместо того, чтобы щёлкать задачи как орешки?

Иногда попадаются вопросы по конкретным технологиям и фрэймворкам. Одним из таких вопросов был следующий:

Хочется верить, что проекты, на которых я работал, были достаточно большими для того, чтобы я мог ответить на этот вопрос. В любом случае, буду писать только о том, с чем имел дело.

Самописной многопоточности (многопоточного кода, написанного исключительно с использованием java core и java concurrency) в тех проектах, которые я видел, практически не было. Если где-то она и была, то от неё спешили избавиться. На всех виденных мной проектах "боялись" многопоточности, считали её чем-то вроде стабильного источника heizenbugs. 

В основном, на проектах использовались исключительно многопоточные средства, встроенные в фрэймворки (например, в Spring), которые работали под капотом и не требовали вмешательства разработчика.
Отсюда, возможно, проистекает любовь собеседующих к вопросам о многопоточности на технических интервью:
- т.к. на практике с ней никто почти не работает, то и знания о ней у всех довольно скудные, стандартные;
- людям интересно поговорить об этом диковинном зверьке, с которым мало кому из них приходилось встречаться в диких условиях.

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

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

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

Самую сложную задачу по многопоточности я попытался реализовать в одном из двух тестовых заданий, которые писал за всю карьеру. Напрямую от меня не требовали применять многопоточность. Просто, захотелось самому сделать всё красиво в стиле highload, low latency и супер-пупер-multithreading. Я был молод и вдохновлён разговором с интервьюером. ))
Но т.к. я начал реализацию задачи не с того конца, то забуксовал (не хватило времени доделать) и не смог сдать задачу в завершённом виде.

Про тестовые задания

Делать или не делать тестовые задания?

Вопрос интересный и не такой однозначный.

 

С одной стороны, если я ищу оплачиваемую работу, то зачем мне делать её бесплатно? Есть github, есть собеседование, есть тестовые задачки в стиле java quiz на пару минут подумать - смотрите, спрашивайте, что интересно. В конце концов, есть испытательный срок: целых три месяца компания может совершенно законно проверять, как разработчик справляется со своими обязанностями. Ситуация: вот тебе задание дней на семь - десять, а потом приходи на собеседование, поговорим, посмотрим на тебя, - как-то не вдохновляет на трудовые подвиги.

 

С другой стороны, если тестовое задание дают после успешного прохождения всех устных технических собеседований, время, потраченное на тестовое задание, оплачивается, само задание занимает часа четыре, у меня руки "чешутся" что-нибудь покодить, кроме работы, и компания в любом случае (понравилось им решение или нет), даёт обратную связь, то почему бы и не сделать?

 

Я выполнял тестовое задание всего 2 раза. 

В первый раз, HR компании пропал с горизонта как прошлогодний снег. После этого я зарёкся делать тестовые задания и всегда отказывался от дальнейшей борьбы за вакансию, если мне предлагали его сделать. Особенно, если это предлагала малоизвестная компания как билет на техническое собеседование.

Во второй раз, получил в код-ревью ровно то, что сам написал в своём сопроводительном письме к коду (я там честно расписал все недостатки своего решения). Недостатков было много, т.к. задание было не из простых (решение должно было быть production ready) и двух выходных ночей на его достойное выполнение мне не хватило. В сопроводительном письме я попросил посмотреть архитектуру приложения, качество кода и тестов. Но, видимо, рецензенту было проще скопировать из моего сопроводительного письма перечень недостатков. А, м.б. у него, как и у меня, тоже был дефицит времени. ))
 

Получается, что сейчас у меня счёт 2-0 в пользу негативного опыта выполнения тестовых заданий. Возможно, кому-то повезёт больше.

Некоторые мысли про собеседования

Собеседование - это такая штука, которую программисту придётся учиться проходить.
Почему придётся - это понятно: чтобы найти работу.
Почему именно "учиться проходить"? Потому что собеседование это не работа и не программирование, это отдельный вид общественных отношений, со своими правилами, условностями и ожидаемым от всех участников поведением. И изучать всё это придётся отдельно.
Мой совет: не поленись погуглить и почитать умные статьи умных людей о том, как нужно вести себя до, во время и после собеседований, что нужно говорить, как одеваться и т.д.
Также нелишним будет погуглить и почитать "вопросы на собеседовании java, spring, hibernate".
Каждый раз, когда я икал работу, я заново повторял:
- все пазлеры ("коварные" вопросы по java, spring, hibernate),
- IO, NIO,
- пузырьковую и быструю сортировки (другие если и спрашивали, то только название и О-нотацию),
- уровни изоляции транзаций в PostgreSQL.

Ничего из этого ни на одной из работ сам не писал - использовал то, что есть в java, spring, hibernate.
Всё, что повторял перед собеседованиями, быстро забывалось за ненадобностью.
Можно взять любого программиста, который не повторял хотя бы ближайшие пару месяцев все те вещи, которые он не использует в работе, и проэкзаменовать его по ним. Результат будет таким же.
Для меня до сих пор загадка, как люди могут по году готовиться к собеседованию в FAANG и при этом через год после обеседования помнить то, с чего они начали свою подготовку (многие из них в приватных беседах признаются, что на самом деле, не помнят).

Считаешь, что повторять всё это для собеседования и спрашивать об этом на собеседовании - бессмысленно, бесполезно и никому не нужно? И тебя это расстраивает?
Зря расстраиваешься. Собеседование - это устоявшаяся штука. И, как я уже писал выше, со своими условностями и ожидаемым поведением. От кандидата ожидают, что он бдет соответствовать сложившемуся представлению о кандидате. Кандидат знает, каким его хотят видеть и, зная правила игры, может в обозримом будущем гарантированно найти себе работу. Все счастливы, процесс собеседования идёт как по маслу.

Есть куча статей в интернете: как проверить навыки спеца при приёме на работу. Общий приблизительный ответ: в условиях ограниченных ресурсов, практически никак. Кандидат может быть:

- олимпиадником, не знающим ни одного фреймворка и пишущим велосипеды и работающий, но неподдерживаемый код;

- свичером, который поверхностно знает фреймворки и паттерны;

- самозванцем, за которого кто-то решил тестовое, и, которому через наушник диктуют правильные ответы.

На сладкое: представь себе, что у тебя свой стартап и тебе нужно нанять прогеров. Не "рок-звёзд", но и не секретарей-машинисток.
Что ты будешь у них спрашивать на собеседовании?
Да всё то же: сколько корзин в HashMap по умолчанию. )) Вот и остаётся работодателям только задавать кандидатам одни и те же шаблонные вопросы.

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

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

Не думаю, что знание этих вещей (ответов на шаблонные вопросы) может достоверно показать: хороший программист пришёл на собеседование или плохой. Можно только понять:
- программист пришёл на работу или просто тот, кто решил на авось попробовать устроиться программистом,
- готовился кандидат к собеседованию или нет,
- как быстро начнёт искать новую работу. Например, если у кандидата при словах "алгоритм", "МЛ" и др. загораются глаза и "отскакивают от зубов" доказательства О-нотаций, градиентные спуски и т.д., а в работе это применяться не будет, то есть вероятность, что новую работу он начнёт искать очень скоро. 😏

Есть также мнение, что "опытных чуваков" на собеседованиях не спрашивают о количестве корзин в HashMap, а просто с ними беседуют.
Так то ж опытные чуваки. Скорее всего, их в таком случае каким-то другим способом проверяют:

- репозиторий на гитхабе,
- активность в соцсетях разработчиков,
- отзывы коллег и т.д.,
- на "простой" беседе могут спросить о последнем проекте, принятых архитектурных решениях и о причинах их принятия. Думаю, программер с небольшим опытом сразу "засыпется" на таких вопросах. Тогда ему будут задавать вопросы по HashMap. ) 

Если всё устоялось, идёт по накатанной, то почему же у кандидатов возникают сложности с собеседованиями?
У меня возникают сложности потому, что со временем я начинаю писать код так же, как говорить: на автомате, не особо задумываясь о правилах языка. Например, пишешь ты хорошие и правильные программы потому что когда-то где-то усвоил, что так писать ПРАВИЛЬНО. А тут приходишь на собеседование и тебя спрашивают: а как писать НЕПРАВИЛЬНО? А затем следом: а почему так будет ПРАВИЛЬНО, а вот так - НЕПРАВИЛЬНО? И, если ты до этого нигде не читал, почему нужно писать так, а не по-другому, никогда не писал НЕПРАВИЛЬНО и не обжигался на этом, то ответить на такой вопрос будет очень сложно.
Один из реальных примеров: на курсе, где я учился, ментор часто повторял, что Singleton - это антипаттерн. Спроси любого выпускника из курса того времени, они будут свято уверены, что Singleton - это антипаттерн, но объяснить, почему они так считают, не смогут.

В этих ваших интернетах есть две интересные точки зрения о том, нужно ли ходить на собеседования без намерения получить работу:
1) так делать нужно, чтобы поддерживать у себя в актуальном состоянии навык прохождения собеседований;
2) так делать нельзя, т.к. тем самым ты "обманываешь" HR-ов и работодателей, отнимаешь их рабочее время, потому что проходишь собеседование без цели трудоустроиться.
Иногда мне кажется, что обе эти "точки зрения" придуманы одними и теми же людьми с целью создания хайпа и привлечения внимания.

Я придерживаюсь третьей точки зрения: делать так, как тебе нужно. Хочешь потренироваться перед собеседованием в компанию А, т.к. хочешь работать там, только там и нигде больше? Пройди несколько тренировочных (для тебя тренировочных) собеседований в компании X, Y, Z.

Если тебе пофиг где работать, лишь бы была здоровая атмосфера в коллективе и платили вовремя. Тогда нет смысла проходить собеседования ради собеседований. Собеседоваться только с целью найти работу. А свободное время потратить с большей пользой. 

И напоследок, пара интересных случаев из моего опыта прохождения собеседований:

Полная аудитория желающих пособеседоваться в иностранную компанию. Сидим. Выходит чел. Спрашивает на английском:

- Кто знает java?
Половина народу подняли руки.
Второй вопрос:
- Из джавистов, кто скалу знает?
Подняли руки человек 5.
- Из последних поднявших руки, кто Хаскел знает?
Поднял руку один.
- You are hired! - кричит HR, бросается к этому чуваку и вцепляется в него мёртвой хваткой. ))
Поржали, пожрали нахаляву и разошлись. )  

Я с двумя офферами на руках просто по фану собеседовался 5 часов в Сбере и 4 часа в Люксофте. )

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

В Сбере меня спрашивали вообще всё, что смогли вспомнить. Через часа 3 один из "гестаповцев" вышел и вернулся с распечатанными java-пазлами на листочке. Заставили их решать. На пятом часу я им сказал, что голова уже опустошена и дальше я не соображаю, и, вообще, скоро магазины закроются, а у меня дома кот голодный. На том и разошлись. Через полгода они позвонили, поздравили с прохождением тех.интервью и пригласили на встречу с боссом. Я отказался. 

Некоторые мысли о том, как и где учиться программированию

Моё мнение - минимум, 2 - 3 часа  (в идеале - 4 часа) ежедневно. Без выходных. Никакой жизни вне учёбы: походов в кино, на природу, друзей, девушек и т.п. Читать книги и статьи. Смотреть видео и решать задачи. С ментором, с большим количеством задач, их проверкой ментором и с обязательной обратной связью (разбором ошибок).
Иностранный язык можно выучить за пол года - год, учась по 1 часу в день.
Программирование и того проще освоить, т.к. всё преподносится на родном языке и язык программирования - это, в отличие от разговорного иностранного языка, сплошная логика, которая в нас "встроена" с рождения. Нужно только тренировать её, как мышцы.
Поэтому 4 часа на учёбу ежедневно - это то, что называется, отлично.
В ВУЗе, дай бог, чтоб 4 часа в неделю изучали программирование.
Рассуждения о том, что 4 часа учёбы ежедневно - это малоэффективно похожи на рассуждения о том, что:
-  4 часа в день заниматься спортом - это малоэффективно,
- или, что разговаривать на английском по 4 часа в день - это тоже малоэффективно.

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

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

Главное - не потерять эти самые часы даром: не слушать музон, не смотреть развлекательное видео и не читать книжки или Интернеты не по учёбе.
Я езжу стоя в метро каждый день по 45 минут в каждую сторону (на работу и с работы). За это время Успеваю почитать книжку по програмированию, посмотреть заранее загруженное учебное видео или потренировать английский в приложении.

Главное в учёбе - это поставить цель и каждый день идти к ней небольшими шагами.

В сообществе часто задают вопросы:
Можно ли отдыхать от учёбы (делать длительные перерывы)?
Себя не обмануть. Если перерыв в учёбе нужен, то так или иначе его придётся сделать. Только нужно быть готовым к тому, что после отдыха будет сложнее продолжить, т.к. некоторые вещи забудутся. 

Что лучше: самому выстрадать решение задачи или попросить помощи у коллег?

Лучше вообще не тупить, а, если самому непонятно, то сразу открывать SOF (Stack Overflow), учебники, статьи, чужой GitHub, javadoc и т.д. и смотреть, как надо делать.
Есть даже целое направление обучения - code-kata: смотришь и повторяешь, а где-то в пути приходит понимание.

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

Помогают ли в учёбе конференции?

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

Не помню, где прочитал умную мысль: "...Многие выступления на конференциях охватывают доказательство концепций, а не реальные сценарии. " 

Поможет ли в учёбе телеграм-канал/форум/что-то ещё?

Можно попробовать найти в таком источнике ответ на конкретный узкий вопрос, но для более широкого изучения и понимания предмета, польза таких источников сомнительна.
Залез я как-то в один телеграм-канал по тематике "профи в спринге". Ну, думаю, почитаю умные мысли неглупых людей. Но, исходя из содержания канала, сложилось впечатление, что там собрались люди, изучающие спринг "виртуально", исключительно методом "научного тыка" и пытающиеся изучить его  раньше основ java.
Все разговоры в канале были примерно следующего содержания: "а где мне указать properties?", "а как их прочитать", "а что будет, если у меня будет 2 класса конфигурации?", "а как отправить пост-запрос?" и т.д.
Какие курсы лучше?
Не попробуешь, не узнаешь. На одном курсе всё кривенько-косенько и иногда заводит в тупик неспособность ментора грамотно писать по-русски и выражать свои мысли. Но, в то же время, и цена у такого курса более-менее человечная, и все выпускники курса, в течение 8 - 12 месяцев с момента начала курса находят, себе работу программистами, и сообщество учащихся и выпускников там вполне себе здоровое.

На другом курсе: и цена космическая, и преподаватели все исключительные (судя по рекламе) и контент весь выверенный, синхронизированный и автоматизированны. Но, что-то не слышно отзывов от успешных учеников...На одном из митапов моему коллеге очень известная компания, продающая курсы задорого, предложили стать преподавателем на одном из их курсов. Он согласился, но при этом сказал мне, что теперь ему придётся в ускоренном темпе изучить тему курса почти с нуля.
Поэтому при выборе курса обращай внимание не на рекламу и известность или "крутизну" курсов, а на следующее:
- цена - зачем переплачивать?
- наличие материалов, объясняющих предмет - по книжкам можно учиться и без курсов,
- программа курса включает в себя те технологии, которые перечислены в подавляющем количестве вакансий - зачем платить за то, что будет невостребовано, или, чтобы остаться в глазах работодателя недоучкой? Открываем программу курса и ищем там: java, spring, spring boot, hibernate, postgreSQL, git и т.д. по списку технологий из вакансий,
- наличие большого количества практических задач - как иначе освоить "карате", если не спаринговаться?
- проверка задач ментором и наличие обратной связи - без этого учёба может сильно подзатянуться или завести не в ту степь. Одним из показателей этого является то, что ментор готов ответить на твои вопросы в течение дня, а не через месяц или непонятно, когда. Никаких: ответит менеджер, секретарь или кто-то ещё. Только ментор. Всё просто: если у ментора нет времени ответить на твои вопросы сейчас, то у него не будет времени и на проверку твоих задач во время учёбы,
- наличие сообщества сокурсников - там подскажут и покажут то, на что у ментора может не хватить времени и сил, чтобы по сотне раз объяснять каждому (напимер, как настроить ИДЕ). Со временем ты также научишься получать кайф от дачи ответов на те же "глупые" вопросы новых учеников, какие раньше задавал сам. Это поднимент твою мотивацию и придаст уверенности в собственных знаниях,
- наличие положительных отзывов реальных учеников, которым ты можешь написать и задать все интересующие тебя вопросы о курсе - все мы знаем, что можно нанять школьника, который под копирку напишет хвалебный отзыв, но не сможет ответить ни на один практический вопрос об учёбе, т.к. он смутно может себе представить то, что только что расхваливал.

Ну, и главное: программирование - это не про деньги. Это про увлечение. Если нужны только деньги, то программирование может разочаровать тебя тем, сколько сил и времени тебе придётся вложить в то, чтобы научиться программировать и начать этим зарабатывать. В програмирование идут те, кому это нравится. На вопрос "почему ты решил изучать программирование" такие люди отвечают: "мне всегда нравилось...", "я всегда хотел...", "я со школы увлекался...".
У тебя может получиться обмануть ментора, сокурсников и работодателя, когда ты будешь говорить, что увлечён программированием, но обмануть себя не получится и это чревато... ))

Как достичь цели

Несколько полезных для начинающих разработчиков статей:
Как разработчику понять, что он готов искать первую работу
Как 65 разработчиков-новичков без опыта в программировании получили свою первую работу
Как найти первую работу в IT: план действий для начинающих
Как разработчику-самоучке найти первую работу
Как стать Java разработчиком за 1,5 года
Поиск первой работы: советы разработчику
Первая работа в IT: получаем должность без опыта
Как научиться программировать с нуля и найти первую работу. Большой FAQ от Reddit
Мои странные правила, благодаря которым я получил работу

В статьях много и несколько туманно пишут о том, что можно изложить в трёх пунктах:

1. Составь план. 
Любой. Пусть он будет самым общим, без конкретных цифр. Лишь бы он был реальным и следование ему вело тебя к цели.

2. Следуй плану.
Без активных действий с твоей стороны - никак. Под лежачий камень вода не течёт. Путь в тысячу лье начинается с одного шага. И т.д. Не будешь следовать плану, не сможешь его выполнить.
Есть одна притчу про один шаг вперёд и два шага назад. Так вот, каждый день, когда ты следуешь плану - это шаг вперёд к твоей цели. Каждый день, который ты не следовал плану - это два шага назад.
Если при следовании плану ты понимаешь, что нужно скорректировать план - это нормально. Корректируй и следуй ему дальше. Главное при этом - видеть свою цель и понимать, что корректировка плана не отдаляет тебя от цели.

3. Учись.
Учись всегда и везде тому, что нужно для выполнения твоего плана и его корректровки. Постоянная практика - часть учёбы. Без практики, изучение только теории малоэффективно. Если цель - изучить язык программирования, то решай задачи, пиши мини-проекты. Чем больше практики, тем лучше.

В интернете много описано историй успеха. Но почти нигде не пишут про истории неуспеха, хотя их гораздо больше. Причины неуспеха - это нарушение, минимум, одного из перечисленных выше пунктов. Кто-то нарушает их сознательно - понял, что цель, которую он себе наметил, ему больше не интересна, и отказывается от неё. Кто-то делает это неосознанно - переоценивает свои способности или последствия отступления от плана и т.п.

Должен ли я читать книги?

Оно мне вообще надо - читать книги?
Конечно надо! На собеседованиях постоянно просят наизусть декламировать отдельные определения или даже целые главы из "Чистого кода", "Чистой архитектуры", книг "Банды Четырёх" и других классических трудов.
Шучу.
Ну, кому ещё это может понадобиться, кроме преподавателей-теоретиков в вузе? Хотя, у меня пару раз на собеседованиях придирались к неточным формулировкам.
Так что, не боись теории, но и "булки не расслабляй".


Как быть, если я читаю эти талмуды, читаю... , но вся эта книжная "галиматья" не лезет мне в голову?
Значит, ещё не время для книг. Сначала читай то, что помогает тебе усваивать новую информацию легче. Потом, когда усвоишь основы, берись за книги. Так ты сможешь:
- по статьям - быстрее понять то, что хочешь,
- по книгам - углубить и расширить знания.
Со временем сам придёшь к книгам, т.к. заметишь, что в статьях пишут очень поверхностно и только об основах-основ (так называемые, хелло-ворлды).
Если сразу книги не заходят, то не нужно читать их через силу. Иди к ним постепенно: от простого к сложному.

А зачем?..
Так надо. Поверь, эффект от чтения книг есть. Даже, если напрямую ты не будешь использовать в работе всё то, что написано в книге, то, по крайней мере, будешь иметь ориентиры для ответов на вопросы:
- где искать,
- что такое хорошо и что такое плохо,
- и почему плохо - это плохо, а хорошо - это хорошо (если, вдруг, понадобится обосновать).

Книги - и всё, этого достаточно?
Нет. Книги - это теория. Иногда, в книге на 600 страниц может быть поверхностно рассмотрен только один какой-нибудь вопрос. Для получения ответа на вопрос "как это использовать" нужно читать документацию. Книга - это чуть более подробный и широкий, чем статья, обзор технологии. Или что-то вроде сборника статей на одну тему.
Искать то, как использовать те или иные аспекты определённой технологии, лучше всего в официальной документации по этой технологии. Если она есть.

А что читать?
Вот тут обсуждается список книг, которые должен прочитать каждый программист.
Если коротко, то это:

1. The Pragmatic Programmer by David Thomas & Andrew Hunt (67% recommended)
2. Clean Code by Robert C. Martin (66% recommended)
3. Code Complete by Steve McConnell (42% recommended)
4. Refactoring by Martin Fowler (35% recommended)
5. Head First Design Patterns by Eric Freeman / Bert Bates / Kathy Sierra / Elisabeth Robson (29.4% recommended)
6. The Mythical Man-Month by Frederick P. Brooks Jr (27.9% recommended)
7. The Clean Coder by Robert Martin (27.9% recommended)
8. Working Effectively with Legacy Code by Michael Feathers (26.4% recommended)
9. Design Patterns by by Erich Gamma / Richard Helm / Ralph Johnson / John Vlissides (25% recommended)
10. Cracking the Coding Interview by Gayle Laakmann McDowell (22% recommended)
11. Soft Skills by John Sonmez (22% recommended)
12. Don’t Make Me Think by Steve Krug (19.1% recommended)
13. Code by Charles Petzold (19.1% recommended)
14. Introduction to Algorithms by Thomas H. Cormen / Charles E. Leiserson / Ronald L. Rivest / Clifford Stein (17.6% recommended)
15. Peopleware by Tom DeMarco & Tim Lister (17.6% recommended)
16. Programming Pearls by Jon Bentley (16.1% recommended)
17. Patterns of Enterprise Application Architecture by Martin Fowler (14.7% recommended)
18. Structure and Interpretation of Computer Programs by Harold Abelson / Gerald Jay Sussman / Julie Sussman (13.2% recommended)
19. The Art of Computer Programming by Donald E. Knuth(10.2% recommended)
20. Domain-Driven Design by Eric Evans (10.2% recommended)
21. Coders at Work by Peter Seibel (10.2% recommended)
22. Rapid Development by Steve McConnell (8.8% recommended)
23. The Self-Taught Programmer by Cory Althoff (8.8% recommended)
24. Algorithms by Robert Sedgewick & Kevin Wayne (8.8% recommended)
25. Continuous Delivery by Jez Humble & David Farley (8.8% recommended)

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

Кто я: junior, middle, senior?

Если меня спрашивают, какого уровня я разработчик, что мне ответить? 
Во времена моей молодости была популярной реклама одного безалкогольного напитка: "Имидж - ничто, жажда - всё". Этой фразой можно ответить на часть вопроса в том смысле, что неважно, как меня назовут (на какую должность примут на работу), хоть пряником, главное - сколько мне за это будут платить.
Понятие уровня разработчика - относительное. В одной компании можно числиться несколько лет синьором и получать ХХХ рублей в месяц, а потом перейти в другую компанию на должность джуна и получать 2 х ХХХ рублей в месяц.
Обычно, вопрос о том, к какому уровню ты себя относишь, задают HR-ы в тот момент, когда приходит пора обсудить размер зарплаты, или начинающие программисты, когда неуверены в своих силах и хотят найти себе ментора или понять, насколько их знания широки и глубоки. Для HR-ов это имеет значение потому, что они привязывают такой уровень к размеру зарплаты и прочим "плюшкам", предоставляемым компанией в зависимости от уровня. Для начинающих программистов уровень имеет значение потому, что они, по причине своей неопытности, считают этот уровень синонимом знаний и опыта.
Приведу пример.
Когда я в первый раз искал работу программистом, было у меня несколько собеседований, по итогам которых интервьюеры сразу давали обратную связь. Обычно, такие собеседования проводились с участием технических (разработчики, тех.лиды) и нетехнических (HR, менеджер) специалистов. Когда HR/менеджер в конце собеседования задавал техническому специалисту вопрос, какого я уровня как  разработчик, те, иногда задумавшись на пару секунд, иногда сразу, отвечали "крепкий/средний middle". Мне это льстило, т.к. к тому времени я только окончил курс java-разработчика, был неопытным и считал, что я, скорее всего, junior. Все же должны начинать с junior-а!
Позже, когда я искал своё следующее место работы, мне так же по результатам собеседований иногда говорили, что я "крепкий/средний middle". Я обижался, т.к. постоянно много учился, читал книги, статьи и смотрел обучающие видео по программированию. Поэтому такого просто не могло быть, чтобы мои навыки и знания не сдвинулись ни на шаг с места под названием "крепкий/средний middle" и я не стал хотя бы "младшим senior-ом" или кем-то вроде того.
Позже я понял, что звание/должность - это вопрос, скорее, денежный, чем реально отражающий знания и опыт программиста. В каждой организации есть свой бюджет и своя тарифная сетка. И звание "middle" или "senior" означает лишь, что компания готова тебе платить XXX или YYY рублей в месяц и это не всегда зависит от твоих знаний ил опыта. Это как кодовые фразы, которыми обмениваются нетехнический (НТС) и технический (ТС) специалисты:
НТС: "Кандидат хочет ХХХ рублей в месяц. Мы потянем?"
ТС: "Бюджет трещит по швам. Попробуй поторговаться?"
Конечно, же речь в этом случае может идти не только о деньгах, но и об опыте, знаниях, личных качествах кандидата.
Поэтому теперь мои собственные давние переживания по поводу того, как меня называют, кажутся мне смешными.

Всё это хорошо, но что ответить, если меня спрашивают, какого уровня я разработчик?
Зависит от ситуации. Статьи (в основном, зарубежные) по поиску работы рекомендуют отвечать витиевато и завуалировано. Но общий смысл сводится к тому, чтобы донести до интервьюера мысль, что для тебя значение имеет не звание, а должностные обязанности, размер зарплаты и другие бонусы компании.

Если я без опыта, то вакансии с какой зарплатой мне искать?

Формула, проверенная поколениями программистов:
Зарплата = сумма расходов в месяц + ещё не менее 30%

Только нужно помнить, что "расходы в месяц" - это не только расходы на метро, 2 кг. гречки и 3 десятка яиц.
Да-да, были энтузиасты, которые считали, что вполне себе реально первые год - полтора поработать в Москве на зарплату в 25 - 30 т.р. в месяц и только потом искать работу с более высокой зарплатой.
Поверь, это не так.  На такую зарплату ты долго не протянешь.Поэтому "сумма расходов в месяц" - это размер расходов, которые ежемесячно несёт обычный средний работник в том городе, где тебе предстоит работать. Они включают в себя:
- проезд,
- питание,
- лекарства,
- одежду,
- обувь,
- и другие подобные расходы на тебя и членов твоей семьи (семья - на первом месте).
С размером таких расходов проще всего определиться тем, кто уже работает и знает, сколько его семья тратит в месяц.
Для тех, кто никогда не работал и не знает - спросить у мамки/папки/друзей. )

30% - это нередвиденные расходы. А они всегда будут. К тому же, в чём смысл идти работать на зарплату, которая покроет только минимальные потребности и не позволит, например, сводить детей в кино, а жену - в театр?

Почему не стоит соглашаться на меньшее?
Зачем? Какой в этом смысл? Мы ж не биороботы, предназначенные только для того, чтобы за наш счёт хорошо жил кто-то другой?
Проводя большую часть сознательной жини на работе, мы должны иметь возможность чем-то это компенсировать. Для кого-то это будет возможность играть влюбимые игры, для кого-то путешествовать, заниматься спортом, ходить на культурные меропрития.

Авторы книг и статей, посвящённых торгам о зарплате, сходятся в одном мнении: всегда нужно пробовать торговаться по зарплате. Каждые 10_000 руб. в месяц, бороться за которые ты не стал, в течение года превратяться в 120_000 руб... Всегда помни об этом.

Рыночные отношения

Рынок труда - это слова, обозначающие не только сферу отношений, входя в которую одни люди становтся работниками, другие - работодателями.
Исходя из буквального значения слова, рынок - это также место, где торгуются. Работники и работодатели торгуются относительно стоимости и качества работы.

Рынок - это продавец с товаром и покупатель с деньгами. Отсюда вытекают следующие правила выхода на рынок труда для работника:
- быть конкурентоспособным,
- соответстввать ожиданиям рынка, предоставлять товар (работу), соответствующий требованиям покупателя (работодателя),
- устанавливать на свой товар соответствующую ему цену.

Быть конкурентоспособным.
Это значит: иметь знания и опыт, которые помогут лучше выделиться среди остальных кандидатов. Знания - это результат учёбы в любом виде (самостоятельно, с ментором, на курсах, в ВУЗе, на практике). Опыт - это не то, сколько лет ты просидел на работе с 9 до 18. Это то, какие проблемы ты умеешь решать.
Знать фреймворк - это одно. Уметь с его помощью решать конкретные проблемы - это немного другое. Отсюда, основной способ повысить свою конкурентоспособность - изучать нужные рынку технологиии и писать на них свои мини-проекты.

Соответствие ожиданиям рынка.
Почти никому не нужно будет твоё умение написать код на Бэйсике.

И очень многие захотят нанять тебя, если ты знаешь Java.

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

Устанавливать на свой товар адекватную цену.
Это сложный процесс, в ходе которого возникает много дополнительных вопросов:

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

Как понять, что мой товар - этот, про который везде пишут и говорят, что он стоит ХХХ рублей в месяц?
Только практическим путём: ходить на собеседования, получать предложения о работе, торговаться.

А что, если с моим товаром всё хорошо, но мне предлагают за него на YYY рублей в месяц меньше?
Торговаться.
Теме торгов я посвящу одну из следующих статей.

Шуточная лямбда

public class HowToBecomeProgrammer {
    public static void main(String[] args) {
        JavaDeveloper developer = Arrays.stream(someMan) 
            .filter(c -> !"kishka tonka".equals(c.getProperty()))
            .map(JavaDeveloperCourse::createDeveloper)
            .findFirst()
            .orElseThrow(() -> new RuntimeException("YOU ARE NOT READY YET")); 

    } 

}