Про зарплатные торги

Читал как-то про один из способов поиска работников на минимальную зарплату:
1) дают объявление с нормальной зарпатой по рынку,
2) собеседуют кучу желающих, выбирают лучших, всем говорят: "перезвоним",
3) дают новое объявление с зарплатой на 25-30-50% ниже, чем в прошлом объявлении,
4) повторяют п.п.2-3 до тех пор, пока на указанную в объявлении зарплату уже никто не откликается,
5) звонят тем, кто пришёл до п.4 и приглашают на работу.

 

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

 

Отсюда, главное правило в торгах по зарплате:  хочешь зарабатывать хорошо, не соглашайся на плохую зарплату.

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

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

Почему этот способ работает? Потому что торги по зарплате - это процесс согласования цены обмена знаний и опыта работника на деньги. Чем больше знаний и опыта, тем больше денег они стоят.

Иногда начинающие разработчики говорят: "Мне предлагают минималку"...
Думаю, что там, где предлагают мало возможны следующие ситуации:
1) Работодатель жадный. IT - это сфера, в которой деньги делают "из воздуха". Точнее, из электричества. Причём, их можно почти в одинаковых объёмах делать, что в столице, что на окраине. Главное - правильно наладить процесс.
Так вот, если работодатель, делая большую прибыль, не желает хорошо платить тем, кто ему эту прибыль обеспечивает, то пусть он сам на себя и работает. А мы найдём того, кто готов будет заплатить справедливую цену.
2) Работодатель бедный. Смотри пункт 1. Если работодатель не умеет получать прибыль, достаточную для того, чтобы самому иметь дома золотой унитаз и работникам нормально платить, то зачем он такой хороший нам нужен, а мы - ему? Кончится тем, что либо его бизнес так и будет "висеть на краю пропасти", либо обанкротится. Чем это грозит нам? Потеряем время, денег не заработаем, опыта не наберёмся, не получим удовлетворения от того, что занимаемся любимым делом.
3) Работодатель глупый. Это когда и деньги есть и вроде бы их не жалко, но: "средняя зарплата по городу - 25 т.р. в мес. Значит, и разработчикам надо платить столько. А то, глядишь, ещё пацаны засмеют". В итоге, все грамотные кадры где? Там, где платят. А на глупого работодателя работает кто? Те, кому деваться некуда, те, у кого есть побочный доход, или те, кого не взяли туда, где нормально платят. Чем грозит нам работа на глупого работодателя? Денег не заработаем, время потеряем, умных наставников у него не найдём и опыт не приобретём, не получим удовлетворения от того, что занимаемся любимым делом.

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

Собеседовался я как-то в один "крупный федеральный банк". Прошёл в общей сложности 5 или 6 собеседований. Почти на каждом из них меня спрашивали о зарплатных ожиданиях, я озвучивал среднюю ставку и собеседующие радостно заверяли меня, что банк может платить даже больше, чем я прошу. После финального собеседования с каким-то крупным начальником я получил предложение о работе с зарплатой на 20% ниже той, что мне пять раз согласовали на собеседованиях. Когда спросил у HR о причине, мне ответили следующее: "У нас ребята работают по 5 лет и получают меньше, чем вы запросили. Если мы будем платить вам столько, сколько вы просите, ребята обидятся". 

 

Ну, что тут скажешь, кроме того, что в этом банке я не работаю и на письма его HR-ов с тех пор отвечаю вежливым отказом?

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

 

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

Среди перечисленных "юморных" вакансий интересна вакансия с "Зарплата белая" (оклад + премия). Я с 20 лет в сказки не верю. Мне всё равно, какого "цвета" зарплата: "серая" или "белая" и нет дела до "печенек" (премии, кофе-чаи-сыры, ДМС и т.п.). Интересует только, сколько денег я положу себе в карман за месяц. Не спорю: лучше, когда "Зарплата полностью белая" и ты на 100% уверен, что за месяц работы тебе должны заплатить ту сумму, о которой ты договорился, т.к. она указанна трудовом договоре. Однако, если самая "белая" и "пушистая" предлагает мне зарплату в виде 40% оклад и 60% премии, то я начинаю думать о ней в самых мрачных тонах.

 

Почему? Всё очень просто: в таком случае, по закону, мне обязаны будут заплатить 40% (оклад) и не обязаны будут платить оставшиеся 60% премии. По закону, платить или не платить премию - это на усмотрение работодателя. Чтобы заплатить премию, директор должен каждый месяц издавать отдельный приказ. Чтобы не платить премию, никаких приказов издавать не нужно. Достаточно не издать приказ о выплате премии. Я начинаю чувствовать себя неуютно, если то, будет моя семья в следующем месяце кушать или нет, будет зависеть от чьего-то усмотрения.

 

На одном из интернет-ресурсов видел такую шпаргалку для HR-ов при обсуждении с кандидатом зарплатных ожиданий. Если кандидат сказал, что на текущем месте зарабатывает 100, а на новом хочет зарабатывать 200, то задайте ему 2 вопроса:
1) почему ты решил, что ты сейчас стоишь не 100, а 200?
2) если ты, действительно, стоишь 200 то почему тебе на текущем месте платят всего 100?"

Думаю, если HR задаёт такие вопросы, то, в зависимости от контекста, возможны два варианта:

- это звоночек в пользу того, что с такой компанией дела иметь не стоит ни сейчас, ни в будущем;

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

 

Когда говорить о желаемом размере зарплаты? 

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

 

Я считаю, что это всё мистификация довольно простого процесса торгов:

- я знаю, сколько я хочу зарабатывать;

- компания знает, сколько она может заплатить;

- я озвучиваю цену своим знаниям;

- если компания готова нести такие расходы, она продолжает процесс собеседования;

- если компании я не по карману, мы расходимся как в море корабли.

Точка.

 

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

 

Да, ты можешь запросить меньше, чем компания могла бы тебе предложить сама. Но точно так же и компания может предложить тебе меньше, чем ты хочешь. И что тогда? Торговаться как на базаре, до последнего? Лично мне это не очень нравится.

Поэтому правила торгов у меня такие:

- не стесняться озвучивать желаемую зарплату;

- зарплата в полном объёме прописывается в трудовом договоре;

- зарплата не делится на оклад и премии. Если работодатель желает платить премии - это на его усмотрение, в дополнение к зарплате.

Вопросы потенциальному работодателю

О том, что нужно разработчику спросить у работодателя, есть тонны материалов, которые радостно выдаёт google по самому простому запросу.

Главное, о чём нужно помнить при поиске работы, это:

1) Нужно определиться с тем, что лично для тебя является важным и существенным в будущей работе. Для меня существенными моментами являются:

- зарплата и премии (размер, из каких частей состоит, сроки и условия их выплаты);

- отпуска (общее количество дней отпуска за год, какой длительности отпуск в компании "принято" брать за раз, какие могут быть препятствия для ухода в отпуск);

- условия на рабочем месте, в столовой, уборной;

- техника на рабочем месте (стационарник, ноутбук, тонкий клиент; какие: процессор, оперативная память, жёсткий диск, операционная система, на которой нужно будет работать; можно ли всё настраивать самому под себя или исключительно через системного администратора; насколько легко можно будет проапгрейдить рабочее место и "железо" и т.д.);

- технологии, с которыми нужно будет работать;

- принято ли в компании писать тесты на свой код;

- как и кем ставятся задачи;

- как и перед кем отчитываться о выполнении задач (метрики производительности);

- каких результатов от меня ждут на испытательном сроке;

- какого сорта яблоки подают на завтрак (шутка )) ).

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

2) Необходимо составить для себя список вопросов к потенциальному работодателю, по ответам на которые, можно будет судить о том, соответствует ли компания твоим ожиданиям или нет.

3) Есть перечень "запретных" вопросов, которые на первый взгляд кажутся обычными, но на которые собеседующие реагируют несколько "болезненно". Если озвучить такой вопрос, то можно потерять пару баллов в глазах работодателя.
Например, если задавать слишком много вопросов о том, как оформляется больничный, в каком размере выплачивается зарплата за то время, пока ты находишься на больничном и т.д. в том же духе, работодатель может насторожиться и решить, что ты ищешь не место, где можно будет плодотворно трудиться во благо Компании, а место, где ты хочешь наиболее выгодно для себя много болеть или "болеть".

4) Не стесняться задавать вопросы до подписания трудового договора. Лучше выяснить все важные для себя моменты заранее, а не через неделю после выхода на работу.

5) Задавать вопросы можно (а иногда - нужно) не напрямую, а обходными путями. Например, вопрос о том, есть ли в уборной туалетная бумага и мыло для рук или нужно приходить со своими, может быть воспринят как некорректный и ты можешь потерять несколько набранных очков или даже все. Поэтому правильнее будет просто спросить, где туалет и посмотреть всё самому.

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

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

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

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

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

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

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

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

Самописной многопоточности (многопоточного кода, написанного исключительно с использованием 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 руб... Всегда помни об этом.