Как старик-гуманитарий в IT ходил

Салют! Собственно, уже давно я думал, что именно напишу в этом посте и напишу ли я его вообще. Так уж получилось, что в разные периоды последних двух лет я по-разному оценивал свои шансы получить должность Java-разработчика: от "рано или поздно — обязательно" до "мне в IT ничего не светит". Тем не менее, прошло почти ровно два года с момента моей регистрации на JavaRush'е. Пару месяцев назад я получил первый оффер, чуть позже — второй, а затем и вышел на новую работу. Истории успеха мне неплохо помогали во время прохождения курса, так что решил накидать свою. Так как курс проходил в 18'м году, некоторая информация может быть неактуальной. Сразу скажу, что текста будет много, т.к. постараюсь и про обучение рассказать, и про поиски работы (требования, отклики, ТЗ, собеседования и прочее). Также напишу пару общих советов, которые помогли лично мне и могут помочь другим. Кратко о себе: 32 года, 10 лет опыта в менеджменте и продажах, гуманитарное образование и абсолютно никакого технического бэкграунда. Несколько лет назад пробовал зайти в C++, потом в Python — ничего, кроме головной боли, не получил. Следовательно, талантливым разработчиком меня назвать сложно: скорее наоборот.

ЭТАП 1. Обучение

К JavaRush пришёл осознанно: адекватный помесячный прайс, четкая структура материала, много практики и наличие собственного коммьюнити. С первым пунктом всё понятно, а учить язык без структуры довольно сложно, и такое обучение наверняка обеспечит человека серьёзными пробелами в Java Core. Опыт собеседований и ТЗ показывает, что спрашивать по "кору" могут всё: от побитового сдвига и приведения дженериков до IO и сериализации. Практика — мастхэв; я до сих пор половину вещей могу понять и запомнить, только если написал их сам. Ну и коммьюнити: решил задачу — похвастайся в комментариях; не решил — добро пожаловать в вопросы, но готовое решение тебе, скорее всего, никто не даст. А к пользовательским статьям на свободные темы я возвращался и уже после окончания курса, там много годноты для старта (особенно первый опыт с фреймворками на пошаговых примерах + вопросы к собеседованиям). В целом за полученную базу я этому проекту благодарен, но не стал бы опираться только на JavaRush — тот же Шилдт лучше всего заходит "внахлёст" на изучаемую тему, и зачастую раскрывает некоторые моменты. Про задания, которые иногда идут вперёд теории и заставляют гуглить — тут уже много в отзывах говорили. Для меня это скорее плюс, чем минус — и не факт, что сейчас ситуация обстоит так же, как в момент моей учёбы. Сразу совет тем, кто, как и я, заходит в Java "с чистого листа": на каком-то этапе вам может стать скучно или тяжело:

1. Всем с нуля тяжело, до конца курса доходит, дай бог, 5% человек. Ваша задача — попасть в их число.

2. У меня интерес проявился через месяц-два, когда задания стали посложнее и поинтереснее. Перетерпите.

3. Главное — еженедельный прогресс. После двух недель отдыха возвращаться уже сложно, а писать каждый день несколько месяцев подряд не каждый сможет. Дайте себе норму в часах на неделю — например, 15. Вы можете кодить по 1.5 часа каждый будний день и еще 3-4 часа на обоих выходных, или можете отдохнуть пару вечеров, но "выходная норма" увеличится. Таким образом, график получится гибким, но регулярным. Конечно, потом можно будет мерить работу задачами и проектами, но на уровне синтаксиса и ядра — сойдут и часы.

В целом, на прохождение курса (до доступа к стажировке) у меня ушло около 5 месяцев, притом что я мог себе позволить и отпуск, и краткие перерывы; опять же, работа пятидневкой оставляла свободными только выходные и будние вечера с 22 до 00. Так что при более свободном графике или более жёстком учебном режиме можно справиться существенно раньше. Дальше я планировал попасть на стажировку, но в итоге не срослось.

ЭТАП 2. Cамообразование

Итак, на стажировку я не попал: оставил всего пару дней на ТЗ до конца набора в группу и не успел разобраться с требованиями — слишком много незнакомых слов навалилось. Т.к. ещё три месяца ждать уже не хотелось, решил дальше сам. Благо, по всем популярным фреймворкам есть гайды и видеоуроки. Следующие несколько месяцев разбирался со Spring MVC, Spring Boot + Data, Spring Security, Hibernate, jUnit, Maven, Git, РСУБД, осваивал SQL и старался собирать всё это в единое целое. Через полгода у меня были проекты, на которые сейчас страшно взглянуть, но я получил практический опыт использования "взрослых" фреймворков и гитхаб, который можно было показывать по запросу потенциального работодателя. Советы:

1. Чем раньше узнаете про .gitignore — тем лучше. ;)

2. Многие гайды включают в себя сразу несколько фреймворков; пользуйтесь этим и добавляйте своё. Написали интернет-магазин на Maven + Spring Boot + Data — добавьте авторизацию, юнит тесты и логирование.

3. Для web-проектов можно брать из сети бесплатные frontend-шаблоны — с ними приятнее работать, они лучше выглядят скриншотами в README на гите. Заодно сможете вспомнить HTML и CSS — наверняка захочется поправить стили и вёрстку.

Самый простой способ составить себе такой план развития — пробежаться по HH по вакансиям Junior\Middle Java Developer и посмотреть, какие именно технологии и фреймворки указывают чаще всего. Выписать, придумать под них ТЗ, поставить себе сроки на реализацию. Хотя, возможно, если бы я начал с местной стажировки, не пришлось бы тратить несколько месяцев на домашние проекты.

Чего мне не хватило (потом обжёгся на интервью)

1. Алгоритмы. Чтобы избежать моих ошибок, сразу рекомендую короткую книжку на русском "Грокаем алгоритмы". Что такое сложность алгоритмов, из чего она складывается, почему недостаточно quicksort, введение в теорию графов — всё там и максимально понятным языком.

2. Коллекции "под капотом". Не помню, было ли это на JavaRush, но полезно узнать, как работает HashMap.get() или почему HashSet не гарантирует сохранение порядка элементов. Опять же — какие коллекции потокобезопасны и почему.

3. SQL. Нужен, как минимум, до JOIN'ов — какие есть, как работают, способность написать SELECT на две таблицы на бумаге на лету. Рекомендую www.sql-ex.ru: за день-два выведет вас на нужный уровень.

4. Spring Core: а какие есть аннотации, а что такое контекст, а как создаются бины, а какой Bean Scope потокобезопасен, а как решить взаимный инжект — всё вопросы с собеседований. Как вернуть страницу, как вернуть JSON и т.д. Я сейчас читаю "Spring 5 для профессионалов" на русском, но вообще рекомендуют "Spring in Action".

ЭТАП 3. Поиск работы

Собственно, за первые пару-тройку месяцев после выполнения домашних проектов я отправил около 30 откликов на всевозможные Junior\Trainee вакансии (через HH, LinkedIn, кадровые агенства), с околонулевыми результатами. Ориентировался только на вакансии без опыта, честно указывал знакомый мне стек и писал про свою высокую обучаемость в сопроводительных письмах. Итог — два звонка (один из которых сразу закончился на моём pre-intermediate английском), ТЗ прислали ещё две компании, "встреча" была одна, и то я там в одиночестве решал на листочке задачи на алгоритмы, после чего HR просто унесла бумаги и "мы вам позвоним". Пробовал попасть на пару стажировок (неоплачиваемых и условно-оплачиваемых): ТЗ сделал, но не прошёл дальше финального собеса; зато теперь могу сказать, что стажёров точно набирают T-Systems, ЦФТ, Andersen и EPAM (по ним смешанные отзывы, решайте сами). Как по мне — неплохой способ войти в сферу, если есть возможность несколько месяцев посидеть без дохода и не умереть=) В общем, после такого опыта я несколько приуныл, и всю историю с поисками поставил на паузу почти на полгода — продолжил работать по прошлому профилю, писал какие-то приложения просто ради фана, но даже на гит особо не выкладывал. Пока не встретился с одним знакомым, которому между делом и рассказал о неудачах с вакансиями: он на тот момент уже работал миддл-разработчиком, но начинал так же — с самостоятельного обучения. Знакомый дал мне пару рекомендаций, которыми пользовался сам и которые очень сильно помогли мне с поиском работы в дальнейшем. Следовать им или нет — решать вам, т.к. они, в каком-то плане, не совсем честные. Итак, дальше цитаты:

• любым способом обеспечь себе в резюме 6+ месяцев коммерческого опыта: стажировки, выпускные проекты, фриланс, удалёнка — всё, что угодно. Это сильно поможет на этапе первичного отсева резюме HR-ом;

• убери из резюме слово Junior и ожидаемую зарплату; оставь просто Java Developer, а по деньгам обсуждай индивидуально с каждой компанией;

• старайся, чтобы HR называла "вилку" предлагаемой ЗП раньше, чем ты назовешь свои ожидания. Если компания предлагает 80-120к, а ты ищешь от 40к, часть подборщиков будет относиться к тебе пренебрежительно;

• откликайся на всё вакансии, подходящие тебе по стеку, даже если там требуется коммерческий опыт 1-3 года.

После того, как я выполнил все эти рекомендации, ситуация с поиском значительно улучшилась. Во-первых, из примерно 12 новых откликов половина почти сразу закончилась либо встречей, либо скайпом, либо ТЗ (что уже сильно отличалось от игнора в прошлые месяцы). Во-вторых, начали писать HR-ы, которым я не откликался — в мессенджеры, в почту, в линкедин. В-третьих, требования коммерческого опыта оказались действительно не слишком строгими — многие компании были готовы общаться с кандидатом, не попадающим в указанный диапазон 1-3 года корпоративной практики. Как итог — одно предложение на джуна, одно — на миддла с испытательным сроком. Всего поиски заняли два месяца. Советы:

1. Укажите в резюме весь стек языков, технологий и фреймворков, с которымы вы работали.

2. Зарегистрируйтесь на LinkedIn — там правда много HR-ов разных компаний. Тщательно заполните профиль — по сути, это тоже ваше резюме. Для развития сети контактов добавляйте релевантных вашему профилю LION'ов, они принимают запросы от всех пользователей.

3. Попробуйте себя в бесплатных тестах по Java — их часто дают на бумаге перед собеседованием на Junior. Лучше подготовится заранее.

Пара слов о собеседованиях

1. Всегда спрашивают по коллекциям: какие есть, чем отличаются, когда лучше использовать.

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

3. Почти всегда по многопоточности — что использовали в работе, ключевые слова, методы, знакомы ли с util.concurrent.

4. Часто по работе с памятью — куча, стек, а будут ли равны эти строки, а эти объекты, почему.

5. Иногда по алгоритмам — какие знаете, какая сложность, почему, сможете ли написать алгоритм сейчас.

6. Иногда по паттернам — какие знаете, какие используете, напишите синглтон или фабрику.

7. Иногда по SQL — виды JOIN'ов, что такое транзакция, как провести её на JDBC, напишите короткий запрос.

На самом деле, всё очень сильно зависит от компании: кто-то не задаёт ни единого вопроса по Java Core, но 40 минут гоняет по фреймворкам и SQL; кто-то вообще не использует в работе популярные фреймворки и спрашивает только по алгоритмам, типам, коллекциям и памяти. Примерно половина встреч начиналась с тестов — иногда на русском, иногда на английском языке (20-30 вопросов на 20-30 минут); обычно вопросы уровня "вот код, запустится он или нет, и если нет, то на какой строке" или "вот несколько объектов, будут ли они равны после N операций". Пара слов о ТЗ: 70% компаний, начинающих общение, кидали мне ТЗ до или после встречи. Обычно, на выполнение даётся от пары дней до недели, но чаще всего сроки можно немного двигать. В качестве ТЗ может быть что угодно. Вот примеры, которые делал я:

• страница бизнес-контактов Salesforce-профиля с редактированием и добавлением новых записей;

• симуляция лифта в многоэтажном здании на Spring State Machine с управлением через консоль;

• Android-приложение на LibGDX библиотеке с посимвольным выводом текста при нажатии кнопки;

• REST имитация каршэринга, с добавлением клиентов по HTTP-запросу и возвращением JSON;

• задача на сортировку неориентированного графа через свободную ячейку;

• поиск равнобедренных треугольников по координатам из файла;

• рефакторинг готового кода с использованием Stream API;

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

• гонка потоков с записью результатов в файл.

Иногда методы с расчётами просят покрыть юнит-тестами, а методы запросов — интеграционными тестами. Советы:

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

2. Проверяйте ваш код на эффективность — мне как-то отказали, потому что я, в числе прочего, использовал PrintStream вместо BufferedWriter.

3. Планируйте время выполнения с запасом на 50% — лучше раньше начать и закончить, чем в восемь утра дедлайна делать git push.

Вот, всё, что хотел — вроде написал. Самое главное — вода камень точит. Нельзя много-много писать на Java, потом долго-долго искать работу, и в итоге ни к чему не прийти. Если уж 30-летний гуманитарий вытянул — у вас тем более получится. Главное — не бояться первых звонков, ТЗ и интервью: после каждого провального раза я гарантированно что-то для себя узнавал и подтягивал — чем дольше, тем увереннее себя чувствуешь. Если где-то получилось сумбурно или встретятся ошибки — заранее извиняюсь, пишите, поправлю. Надеюсь, хоть кому-то мой опыт поможет =)