Як старий гуманітарій в 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. Самоосвіта

Отже, на стажування я не потрапив: залишив лише кілька днів на ТЗ до кінця набору до групи і не встиг розібратися з вимогами — надто багато незнайомих слів напало. Т.к. ще три місяці чекати вже не хотілося, вирішив далі сам. Благо, за всіма популярними фреймворками є гайди та відеоуроки. Наступні кілька місяців розбирався зі 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-річний гуманітарій витягнув — тим більше вийде. Головне — не боятися перших дзвінків, ТЗ та інтерв'ю: після кожного провального разу я гарантовано щось для себе впізнавав і підтягував — що довше, то впевненіше почуваєшся. Якщо десь вийшло сумбурно чи зустрінуться помилки — заздалегідь перепрошую, пишіть, поправлю. Сподіваюся, хоч комусь мій досвід допоможе =)