Вітаю всіх учнів Java, а також професіоналів. Можливо моя історія для когось буде прикладом, як робити треба, а для когось — як робити не треба. На дворі 19.10.2021, і сьогодні я пройшов випробувальний термін (3 місяці) як Java middle developer у великій компанії. Раніше досвіду розробки Java не було. До 04.06.2020 про Java я нічого не знав. Коли мене взяли на джавіста, я пообіцяв, що якщо пройду випробувальний термін, напишу історію успіху. Ця стаття буде розбита на дві логічні частини :, але в якій можна отримати знання про кар'єру). Становлення джавістом (глави 6-9 - вивчення Java, співбесіди, пристрій на роботу, перший реальний досвід). <h3>Глава 1. Економіст</h3> Щоб зрозуміти, з яким рівнем знань я прийшов на JavaRush, треба дати біографічну довідку про себе. 2013, листопад, 8 ранку. Я сиджу в кав'ярні на Таганці та повторюю SQL інструкції. За годину маю співбесіду на позицію провідного економіста фінансового департаменту банку. Це єдина співбесіда, на яку мене запитабо, і треба вистрілити на всі 100%. Заради нього прилетів із Петербурга, і зупинився у родичів на кухні, щоб не витрачати і так невеликі накопичення. Проходить 30 хвабон, млинці з шинкою та сиром з'їдені і треба рухатися до заповітної мрії. Але аж трясе. А якщо провалю співбесіду? Гаразд, була не була. Заходжу до банку, отримую перепустку, чекаю на тих, хто розмовляє в кімнаті для переговорів. Час триває дуже довго. Заходить чоловік років 35 і жінка того ж віку. Вони видаються і просять розповісти про себе: — Юрію, дуже приємно. Мені 21 рік, я навчаюсь заочно в університеті в Петербурзі, працював 3 місяці операціоністом у банку. Зрозумів, що це не те, заради чого я навчався, став дивитися ринок вакансій і побачив, що в Москві економісти мають вимоги мови SQL. Ось вивчив, сходив на курси (Адміністрування MS SQL — що було, на те й пішов) і ви мене покликали. Вони розповідають про компанію, про те, що вони займаються (більшість слів незрозуміло), після чого просять виконати тест. У тесті 3 питання з SQL: 1. Дано таблицю, витягніть всі записи з id = 10. 2. Дано дві таблиці, з'єднайте їх і виведіть по стовпцю з кожної. 3. Згрупуйте відділи та дайте кількість співробітників по кожному відділу. З гріхом навпіл я пишу ці запити. Після цього відбувається обговорення моїх очікувань від роботи. І мені кажуть чарівну фразу: «Дякую за співбесіду, ми вам передзвонимо». Минає тиждень, і мені пропонують вийти до них на роботу. Ейфорія, шок, радість! І на які гроші: 70 тис. рублів на руки! Та я багатієм буду! Приїжджаю до Москви, влаштовуюсь, винаймаю кімнату в центрі. Перші дні у ейфорії. Через днів 10 починається усвідомлення: а я куди прийшов? Я взагалі нічого не розумію! Мені потрібно було складати управлінську звітність у всьому банку щомісяця. Звичайно, для мене це було тим самим, що і для тебе, шановний читачу. Терміни МБК, свопи, аллокація витрат, кістки та інше я сприймав як заклинання латиною. Принагідно мені потрібно було освоювати технічну сторону питання: MS Access (вся звітність робилася там через VBA), MS SQL (як нове сховище, натомість Access), Oracle (який спочатку назвав Оракул, викликавши істерику у програмістів). І раптом я починаю розуміти, що технічна сторона мені набагато цікавіша. Ідуть спроби складання складних запитів (в результаті база даних висне від моїх скриптів, і розлючені адміністратори бігають, щоб зрозуміти, хто це зробив). Але основна робота — фінанси, які просто починають дратувати. Через півтора місяці я пишу заяву на звільнення, тому що не можу дати жодного результату (а від мене на нього не особливо й чекали, чесно кажучи). Начальник фінансового департаменту рве його й каже: "хреном не майся". За місяць знову пишу заяву, і начальник, що охерів від такого нахабства, який згодом став головою правління банку, підписує з крайнім подивом: хлопцеві 21 рік, без вищої освіти, дали і зп, і довіру, а він ось так поводиться. Причини звільнення були ще в двох факторах: начальниці, на зарозумілість якої я не міг реагувати спокійно, і незручному стільці, від якого в мене почала боліти спина. Це дуже смішно, але такий мотив. Звільняючись, я думав, що зараз як ще більше влаштуюся. Але не тут було. <h3>Глава 2. 70 співбесід</h3>Вийшовши з банку, я вдихнув на повні груди. "Ща так влаштуюся, всі очманіють". Співбесіди призначені були, зарплати на них були вищими, і начебто не треба буде займатися звітністю. Проходить 4 співбесіди, і ніхто мене не бере. 5, 6 співбесіда - те саме. Я жив з дівчиною в орендованій кімнаті, і вона влаштувалася на роботу і могла закрити мою відсутність доходів. Але я ще не здогадувався, як довго не матимуть доходів. Я ходив на співбесіди (вакансії а-ля аналітик), і питали в основному SQL і VBA. Для тих, хто не знає, VBA — мова програмування в Excel, Access та інших продуктах MS Office. Проходить 10 співбесід – нічого. 20, 30 - нічого. Усіх бентежить відсутність досвіду та вищої освіти (що для мене видається дрібницею). 40 співбесід, і починає просякувати розпач. У період 55-60 співбесід починаю вивчати 1С. Дівчина, яка вже стала дружиною, просить поїхати до Пітера, бо там хоч би є своє житло. І на 70 співбесіді мене запрошують 1C-адміністратором баз даних (з перспективою стати 1C-розробником) у невелику компанію у промзоні Санкт-Петербурга за 50 000 руб. Ось це кар'єрне зростання! <h3>Глава 3. Повернення легенди</h3>Дивлячись у вікно маршрутки (корпоративного транспорту) на сіру пітерську промзону, і добираючись годину сорок на один кінець, я зрозумів, що так жити не можна. Інтерес до 1С зник при першому ж дотику самописної системи. Потрібен був план. І він дозрів: вечорами вивчав SQL, і принагідно моніторив усіма відомий сайт вакансій. Остаточним тригером до звільнення стала ситуація: гендиректор не захотів відпускати у заплановану відпустку, хоча вже було куплено квитки. Після відпустки пишу заяву та знову розсилаю резюме на московські вакансії. Вкотре мені пропонують пройти співбесіду у великому банку до МСК. Знову приїжджаю до родичів на кухню та їду на співбесіду. Коли hr написав адресау, я не повірив своїм очам - це була будівля, в якому я мріяв працювати (у момент мого минулого проживання у Москві воно тільки будувалося). Посада називалася головним спеціалістом супроводу інформаційних систем. Заходжу в офіс, мене зустрічає чоловік років 30 у модному піджаку та джинсах. Піднімаємось на 15 поверх, і коли я побачив панораму міста, аж дух захопило: усі сталінські висотки було видно. Уся стилістика будівлі була дуже сучасною: у кабінеті начальника були холодильники для вина, модні акваріуми, картина із голою жінкою у чорно-білому стилі. Це викликало "Вау" ефект. Розмова з начальником відбувалася не так, як це було зазвичай: хвабон 40 розповідав він про те, що відбувається у банку. Я нічого не розумів, але хитав головою. Коли я питав: а коли мене почнете питати? Він не звертав уваги. Вкотре, на моє запитання "коли технічне інтерв'ю?" , була отримана відповідь "так ми тебе і так беремо, не впораєшся, звільнимо". Сказано було з усмішкою, і я зрозумів, що все, мрія знову стала дійсністю! <h3>Глава 4. Пошук себе в IT</h3>Прийшовши на нове місце, я зрозумів, чому мене взяли відразу. Опишу типовий портрет співробітника відділу: середній вік 55 років, москвич, освіта МДУ, робота при оборонному НДІ за радянських часів, і перехід у 90-ті в банківську сферу, працює тут уже років 20. Половина чоловіків, половина жінок. Вони вступали в повний дисонанс із навколишніми інтер'єрами. Займалися підтримкою програм формування звітності для бухгалтерії. Природно, це було на древніх скриптах VBA і SQL, написаними розробниками наприкінці 90-х, початку 2000-х. Йшов 2015, а автоматизація була через MS Access. Тобто виглядало вкрай убого. Але був нюанс - вони давали те, що хотів замовник (бухгалтерія). Причому точно у термін та у необхідному вигляді. Як це працювало, знали тільки вони, і навіть Онотоле не уявляв усієї заплутаності їхніх розробок. І будь-який IT-керівник, навіть за найбільшого бажання, не зміг би їх звільнити — головний бухгалтер ішов у правління банку і відстоював будь-якого співробітника, який обслуговує інтереси бухгалтерії. Керівник хотів, щоб я виконав роль троянського коня: вивчив усі їхні напрацювання, а потім мігрував дані до нової системи. Тоді старих співробітників можна звільнити, а мене перевести на нову систему. Спочатку я вникав у їхні процеси та дивився код на VBA. Поступово навчився читати код VBA. За рік уже вмів писати сам код. Типове завдання: дана база даних, витягти з неї дані, і покласти в Excel у певному форматі. Тепер, як казав Задорнов, наберіть повітря в груди: вся звітність відділу (а це 50 щоденних, 20 щомісячних звітів!) запускалася вручну! Карле, ти розумієш, що люди щодня змінюють дати на +1 руками у 50 звітах! Сидять, чекають на результат одного звіту 1-10 хвабон, і запускають інший! Причому щоденні звіти треба запускати у певний час, і не дай боже ти запізнишся! Мало того, що роблять звіти, вони запускають руками процедури в базі даних, не використовуючи змінні! Т. е. замість використання змінної @startDate = '2015-01-01' вони будуть в 20 місцях міняти одну й ту саму дату руками! Подивившись на все це, я почав вивчати Python, і разом із VBA, SQL і Task scheduler автоматизував все це за два роки. Не тільки автоматизував, а й прискорив безліч звітів: якщо відмовитись від MS Access + VBA у бік MS SQL + TSQL, можна досягти збільшення продуктивності багаторазово. Мій рекорд - прискорення створення звіту в100разів! Але колеги були вкрай незадоволені такими автоматизаціями, тому я був оголошений ворогом народу (вони хотіли спокійно сидіти до пенсії). Час минав, і міграція даних відбувалася успішно. Керівник мене цінував дуже сильно: якщо на початку кар'єри я приходив о 8-й ранку на роботу, то через деякий час міг приходити в будь-який час до 12:00, постійне підвищення зарплати та посади, оплата роботи у вихідні більш ніж у подвійному розмірі, таксі до вдома якщо затримувався на роботі, мобільний зв'язок, коротше кажучи – еліта! <h3>Глава 5. Золота клітка</h3>Раптом, через 3,5 роки, приходить нове ІТ-керівництво, говорять про те, що та система, на яку я мігрував дані, більше не потрібна. А стара система залишиться. Мій керівник йде нагору кар'єрними сходами і пропонує мені перейти в більш прогресивний відділ. На зустрічі з начальником прогресивного відділу я розумію, що стек технологій цього відділу невідомий для мене: Oracle, .net, C#, Linux тощо + Антипатія до потенційного начальника. Свого керівника я повідомляю, що мені прогресивний відділ не цікавий, і він благополучно про мене забуває. І тут постає питання: що робити далі? Дохід вже був пристойний, Junior dev мене на таку зарплату не візьмуть. Подумавши про свої навички, зрозумів, що треба йти у машинне навчання. Все було цікаво до першого зіткнення з матстатистикою, яка викликала лише огиду в інституті. Все, ступор на півроку! Минав час, і якось, прогулюючись, задумався про сайт, де б відображалися хороші ресторани на карті Москви. Почалося вивчення HTML, CSS, JS. Витратив 3 місяці на вивчення, знань для створення повноцінного сайту не було, але можна було повправлятися на роботі. Народилася ідея: створити портал для бухгалтерів, щоб вони могли завантажувати за кнопкою будь-який звіт собі. На створення порталу пішло 2 місяці, і світ з'явився web-додаток SPA (Single page application) на React js з бекендом у вигляді Node.js. Бек смикав SQL скрипти (про фреймворки типу Hibernate я не знав), запускав Python і зберігав додаткову інформацію в MongoDb (наприклад, про користувачів сайту). Зовні сайт виглядав дуже пристойно (bootstrap 4, модна анімація). Досі пишаюся цим проектом. Але коли я показав свій код web-розробникам банку, вони очманіли. ЖОДНОГО СВОГО КЛАСУ! Тільки функції, лише хардкор! Мене похвалабо, сказавши, що потрібно ще багато вчитися для становлення Middle full-stack developer. Намагався влаштуватися аналітиком, але особливо пропозицій не було. Думаю: була не була, виставлю резюме full-stack developer. Пішли дзвінки, але на співбесідах пролітав як фанера над Парижем: наприклад, не знав, що таке HashMap, HashSet і навіщо вони потрібні. Про ООП, Паттерни програмування, алгоритми, тестування, Git не було жодного поняття. Згадав давно забуті сорому від незнання елементарних речей. Несподівано приходить оффер на роботу керівником напряму клієнтської аналітики у фінансову компанію. За тиждень до закриття країни через пандемію. Влаштувався у фінансову компанію, але було двояке відчуття: з одного боку гріла висока зарплата, з іншого — розвитку з технічного боку буде щонайменше. Пройшов тиждень після влаштування і ввели віддалений режим роботи. Оскільки неробочі дні не поширювалися на фінсектор, ми працювали у звичайному режимі. Новий начальник виявився дуже божевільною людиною: пропонував ширяти фейсбук, створювати свої нейромережі для вивчення клієнтів (без data scientist у штаті). Новим співробітникам пропонував вивчити Python за тиждень тощо. Неоплачувані вихідні стали нормою. Звільнятися було безглуздо: куди ти влаштуєшся в пандемію? Але терпець урвався через 2 місяці, коли оголосабо, що премій квартальних не буде. Нюанс у тому, що коли домовлялися про зарплату, в момент устрою, hr говорив, що зарплата ділиться на оклад (60%) та квартальну премію (40%), яку платять завжди. Стало зрозуміло, що зроблено неправильний вибір, треба починати шукати нову роботу. <h3>Глава 6. Початок освоювання Java</h3>Одним прекрасним травневим днем мені приходить запрошення на співбесіду щодо вакансії "Розробник". Компанії зі страхової сфери потрібна людина, яка розроблятиме страхові продукти. Досвід у програмуванні потрібен, але оскільки це "унікальна" розробка компанії, то немає потреби у конкретній мові. Також необхідний Git та інше. Призначив співбесіду через два дні, а сам вивчав ази Git у вільний час. У момент співбесіди мене запитували Python, JS, Git, SQL. На все я відповів, окрім поняття "перевантаження методу", і мене запитабо працювати через 2 тижні. Виявилося, що компанія давно купила систему. написану на Java (front і back), за допомогою якої можна створювати бізнес-процеси, не знаючи мови програмування (а точніше використовуючи вбудовану мову програмування Jelly). Звучить непогано, але насправді все перекрутабо. Ліричний відступ: будь-яка технологія має свою епоху і свій масштаб. Робити всю звітність у 2000 році тільки в Excel – круто. Робити те саме в 2021 — не дуже. Сайт компанії на чистому HTML 1999 — круто, 2021 — ні. Так ось технологія, яку використовувала компанія на момент її створення (2005 рік), була дуже крута — Java відповідала і за сервер, і за клієнтську частину (так звані Java servlet pages). При цьому частина якщо ви створюєте новий бізнес-процес (у якого свій UI), то він зберігається всередині БД, а не в коді у файлі. Щоб зрозуміти, як це незручно, уявіть, що ви пишете в Intellij idea Java-код, зберігаєте його в базі даних, а потім. коли ви хочете запустити ваш код, то ядро програми йде до бази даних і зчитує звідти ваш код. Відповідно, повноцінно налагодити вашу програму ви не можете. Родзинка №1: коли ви захочете передати код на тестовий стенд, вам потрібно створити Так ось технологія, яку використовувала компанія на момент її створення (2005 рік), була дуже крута — Java відповідала і за сервер, і за клієнтську частину (так звані Java servlet pages). При цьому частина якщо ви створюєте новий бізнес-процес (у якого свій UI), то він зберігається всередині БД, а не в коді у файлі. Щоб зрозуміти, як це незручно, уявіть, що ви пишете в Intellij idea Java-код, зберігаєте його в базі даних, а потім. коли ви хочете запустити ваш код, то ядро програми йде до бази даних і зчитує звідти ваш код. Відповідно, повноцінно налагодити вашу програму ви не можете. Родзинка №1: коли ви захочете передати код на тестовий стенд, вам потрібно створити Так ось технологія, яку використовувала компанія на момент її створення (2005 рік), була дуже крута — Java відповідала і за сервер, і за клієнтську частину (так звані Java servlet pages). При цьому частина якщо ви створюєте новий бізнес-процес (у якого свій UI), то він зберігається всередині БД, а не в коді у файлі. Щоб зрозуміти, як це незручно, уявіть, що ви пишете в Intellij idea Java-код, зберігаєте його в базі даних, а потім. коли ви хочете запустити ваш код, то ядро програми йде до бази даних і зчитує звідти ваш код. Відповідно, повноцінно налагодити вашу програму ви не можете. Родзинка №1: коли ви захочете передати код на тестовий стенд, вам потрібно створити При цьому частина якщо ви створюєте новий бізнес-процес (у якого свій UI), то він зберігається всередині БД, а не в коді у файлі. Щоб зрозуміти, як це незручно, уявіть, що ви пишете в Intellij idea Java-код, зберігаєте його в базі даних, а потім. коли ви хочете запустити ваш код, то ядро програми йде до бази даних і зчитує звідти ваш код. Відповідно, повноцінно налагодити вашу програму ви не можете. Родзинка №1: коли ви захочете передати код на тестовий стенд, вам потрібно створити При цьому частина якщо ви створюєте новий бізнес-процес (у якого свій UI), то він зберігається всередині БД, а не в коді у файлі. Щоб зрозуміти, як це незручно, уявіть, що ви пишете в Intellij idea Java-код, зберігаєте його в базі даних, а потім. коли ви хочете запустити ваш код, то ядро програми йде до бази даних і зчитує звідти ваш код. Відповідно, повноцінно налагодити вашу програму ви не можете. Родзинка №1: коли ви захочете передати код на тестовий стенд, вам потрібно створити повноцінно налагодити вашу програму ви не можете. Родзинка №1: коли ви захочете передати код на тестовий стенд, вам потрібно створити повноцінно налагодити вашу програму ви не можете. Родзинка №1: коли ви захочете передати код на тестовий стенд, вам потрібно створитиSQL скриптвсередині якого буде ваш код. Неприємно, але терпимо? Родзинка №2: База даних складається з більш як 200 таблиць, які між собою мають зв'язки. Значить, вам треба знати, в які таблиці кидати ваш код і які сутності треба створювати в інших таблицях. На виході виходить SQL скрипт із довжиною ~ 1000 рядків. Ось це вже точно бридко. Стережіться legacy. Коротше кажучи, зрозумівши, що все це крутиться на Java, я пішов на JavaRush (нарешті дійшли до тематики сайту!). Червень-липень 2020 року. Перші 10 рівнів були закриті швидко (може місяць), бо нічого принципово нового не було. Далі швидкість уповільнювалася. Липень-Жовтень 2020 року. Закриті 10-20 рівні. Жовтень-березень 2021 року. Закриті 20-30 рівні. Тепер починається найцікавіше: у березні 2021 року я почав дивитися вакансії з Java і зрозумів, що там дуже багато незнайомих слів. Якийсь Spring, SpringBoot, Hibernate, JUnit. Накупивши відеокурсів на відомому сайті, я лише краєчком пальця торкнувся Spring і подумав, що тепер я все вмію та можу. Після цього на очі мені потрапабо курс TopJava Григорія Кисліна. На його сайті можна спробувати виконати тестове завдання, і якщо впораєтеся, можна брати курс. У цьому курсі ви створюєте повноцінний web-додаток і навіть розміщуєте його в інтернеті. За ці гроші вам будуть робити review (перегляд коду досвідченішим програмістом), давати зворотний зв'язок та підказувати у разі проблем. Я дійшов до 3 хати та кинув. Причина проста: тебе дуже багато вимагають, але ніяких знань не дають. Вимоги до виконання будинку дуже заплутані. Інформація подається вкрай розривчасто. На мою суб'єктивну думку, цей курс потрібен вже досить досвідченим розробникам, які прийшли з інших схожих мов. Бо у його курсі практично немає пояснень технологій, які він просить використати. Також потрібно добре знати Git (все вирушає на твій особистий репозиторій). Наприкінці квітня 2021 року розміщую резюме Java-розробник (з бажаною зарплатою рівня middle+), в якому вказую, що на останньому місці роботи програмував на Java (брехав). У той же день надходить відгук у банк на позицію Java-розробника. <h3>Глава 7. Співбесіди з Java та відточування скіла</h3>Отже, який був план? Мені потрібно влаштуватися на хорошу зарплату, бо вже звик жити на чималий дохід + кредити. Отже, junior позиції мені не підходять. Потрібно влаштуватися middle. Але хто мене візьме без досвіду? Рішення прийшло само собою: у моїй трудовій написано, що я рік працював як розробник і ще 4 роки – експерт у IT-відділі на минулому місці. Значить, скажу, що рік розробляв Java. А якщо питатимуть про новинки, скажу, що там стара Java (7) була, нічого не підтримувала. Перед першим співбесідою (віддаленим) я хвилювався. Досвіду немає, знань замало, а прошу дуже багато грошей. Думаю: пофіг, негативний досвід теж досвід. Зв'язуюсь по скайпу і мене співбесідують два начальники відділу. Від чого мені стало ще стрімкіше. Почалися питання: ООП, пристрій HashMap, стрими, структури даних, що таке Spring, Hibernate, AOP. І якщо до Sping було більш-менш непогано, то на Spring посипався остаточно. Мене запитують: як же ви розробляли на Spring, якщо ви його до ладу не знаєте? Я: так скопіював, вставив, працює і на тому спасибі. Ця відповідь їх потішила. Потім спитали про SQL, у якому я як риба у воді. Далі був Git та питання про rebase, cherry-pick (які я теж не знав) і завершабо про JS, тому що він у мене був вказаний у резюме. Там теж був повний провал, бо питали про ОПЗ JS. За результатами співбесіди стало зрозуміло, що знання не комільфо, тож на цю вакансію не пройду. Увечері hr пише, що моя кандидатура схвалена і мене готові покликати. Я аж бургером у Макдональдсі подавився. Зрадів, але через 3 дні hr повідомив: обрали іншого кандидата. Вперше на моїй практиці відбулося відкликання оффера. Після першої співбесіди з Java активізувався: взяв курс (і пройшов повністю!) з Git від Colt Steele на всьому відомому сайті з продажу відеокурсів. Це перевернуло моє сприйняття Git. Далі пройдено (геніальний) курс від Заура Трегулова по Spring + Hibernate. Схема навчання: дивлюся як у відео, роблю те саме на своєму комп'ютері, але змінні і класи називаю інакше, щоб не тупо копіювати чужий код. Всі напрацювання кидаю на свій Github (тим самим практикую Git). Ішла середина травня та почалися дзвінки від hr. Почали призначати співбесіди один за одним. Багато запрошень довелося скасувати з таких причин: hr не читали опис мого резюме та запрошували на позицію senior. Також варто згадати окрему касту hr: ті, хто плутають Java з JavaScript. Тож у назві свого резюме написав Middle Java developer. <h3>Глава 8. Список типових питань і як проходить співбесіди</h3>Став ходити на соцзабезі і поступово сформувався пул основних питань на middle. Обов'язково: 0. ОВП — визначення, розповісти про кожний принцип ОПП (+дати приклад із реального життя). 1. Equals і hashcode - який між ними контракт (зв'язок)? 2. HashMap - як зрозуміти, в який кошик потрапить об'єкт, що таке колізія, в якій структурі даних відбувається зберігання даних усередині HashMap, стандартний розмір, як збільшується кількість кошиків. 3. Stream - які види операцій, у чому між ними різниця, навести приклад з кожного виду операцій. 4. String pool, Integer pool – що це? 5. Heap, stack - що це, у чому різниця? 6. Відмінності між Runnable, Thread, Future. 7. Volatile, атомарність. 8. Solid, Kiss, Dry - визначення, приклади з реального життя. 9. Модифікатори доступу Java. 10. У чому різниця між абстрактним класом та інтерфейсом. Чи може бути приватний інтерфейс? 11. Функціональні інтерфейси. 12. Перерахувати всі методи Object та розповісти, навіщо вони потрібні. Особливості методу clone. 13. Що таке серіалізація та десеріалізація. 14. Try catch with resources - описати, що це, розповісти за інтерфейсом Closeable. 15. Відмінності між Final, finally, finalize? 16. Перевантаження, перевизначення методу – відмінність. 17. Чому String зробив immutable, розповісти про StringBuilder і StringBuffer. 18. Що таке тимчасова складність О(1), складність пам'яті. 19. Структури даних: розповісти про map, set, queue, deque, list та їх реалізацію в Java (treeMap, hashSet, hashMap, arrayList, linkedList, priorityQueue, blockingQueue), описати складність (гірша, середня, краща) вставки, пошуку, видалення елемента у кожній структурі. 20. Примітивні типи даних Java. Навіщо потрібний кожен із них. 21. Види помилок. Checked та unchecked exceptions. 22. Що таке JVM, JRE, JDK? 23. З якими збирачами працювали? Maven – життєвий цикл складання. 24. Spring - Визначення Ioc, Di, життєвий цикл бина, контекст, інструкції @Bean, @Configuration, @Autowired, @Advice, @Aspect, @Service, @Repository. 25. Generics - визначення, що таке обмеження знизу та зверху? 26. Патерни програмування - хоча б Singleton (готовність розповісти, чому це іноді антипаттерн) + Builder, Adapter, Factory, Decorator, Proxt. Бажано: 26. Тестування – види тестів, з яким бібліотеками (JUnit) працювали. Що таке Mock, Stab, Spy? 27. Spring boot - навіщо потрібен, готовність в режимі онлайн зробити SpringBoot додаток. 28. Hibernate - навіщо потрібен, Entity, join column, lazy vs eager завантаження, рівні кешування (hard). 29. Spring rest - навіщо потрібен, як зробити @post, @get ендпоінти. Як рахувати параметри/тіло запиту? Як віддати у json форматі? 30. Структури даних – дерева, їхні види. 31. Алгоритми - види сортувань. Крім Java можуть запитати: 1.(Обов'язково!) Git - навіщо потрібен, операції merge, rebase, cherry-pick, push, pull, commit, log, checkout, branch, reset, revert, refresh. 2.SQL - вміння написати запит: об'єднати дві таблиці в одну (inner join, left join). 3.Бази даних - 3 нормальні форми, індекси (навіщо потрібні, види), primary key, foreign key Як проходить типова віддалена співбесіда: hr скидає посилання на зум (Skype, Google Meeting). До певного часу ви підключаєтесь і там знаходиться від 1 до 3 осіб (технічний експерт, начальник, hr). В особливо наполегливих випадках до 8 осіб. Спочатку розповідаєте про себе, потім технічна частина, потім розповідь про вакансію та прощання (говорять, коли з вами зв'яжуться або як далі будуть етапи). Під час прощання можна попросити дати зворотний зв'язок із знаннями. Я так питав: "Можете сказати, під час моїх відповідей, де у вас різануло слух?". Багато хто відповідає, але будьте готові отримати відмову. На співбесіді оцінюють: 1. Ваше вміння висловлювати думку та знання російської мови (знаю випадок, коли кандидату відмовабо через погане знання російської мови). 2. Попередній досвід (можуть ретельно запитувати, чим ви займалися на минулій роботі). 3. Адекватна реакція в момент натиску на вас (була одна співбесіда, коли люди почали зневажливо розмовляти: ігнорувати мої відповіді, намагатися вселити свої позиції та інше. Співбесіду я закінчив через 15 хвабон після початку, а вони: це ж було стрес-інтерв'ю! ) 4. Рівень ваших знань. Тут зупинюся докладніше. Знання визначень на тему — це лише 10% від того, що очікується від вас. Необхідно розуміти, як це працює (хоч би верхньорівнево). Готовність пояснити, у який момент розробки ви оберете те чи інше рішення. Це набагато важливіше, ніж точність вашого визначення. Розберу цю тезу на двох прикладах. Перший приклад: на співбесіді мене запитували про HashMap, і я давав визначення: "це така структура даних, яка зберігає в собі зв'язки ключ і значення". Тоді співрозмовник питав: а в чому на відміну від TreeMap? Відповідь: відмінність у тому, що HashMap хешує ключ, і за рахунок хешування відбувається швидкий доступ. Співрозмовник відразу просив розповісти внутрішній пристрій HashMap, заразом запитає про hashCode і equals. І буде заглиблюватися, поки не задовольнитися відповіддю або ви не зупинитесь. Відповідати правильно про HashMap я навчився тільки через 2 місяці співбесід та курсу структур даних на hexlet. Другий приклад: концепція SOLID. Просять дати визначення, яке я завчив. Але щойно справа стосувалася реальних прикладів із життя — починалися проблеми. на співбесіді мене питали про HashMap, і я давав визначення: "це така структура даних, яка зберігає в собі зв'язки ключ і значення". Тоді співрозмовник питав: а в чому на відміну від TreeMap? Відповідь: відмінність у тому, що HashMap хешує ключ, і за рахунок хешування відбувається швидкий доступ. Співрозмовник відразу просив розповісти внутрішній пристрій HashMap, заразом запитає про hashCode і equals. І буде заглиблюватися, поки не задовольнитися відповіддю або ви не зупинитесь. Відповідати правильно про HashMap я навчився тільки через 2 місяці співбесід та курсу структур даних на hexlet. Другий приклад: концепція SOLID. Просять дати визначення, яке я завчив. Але щойно справа стосувалася реальних прикладів із життя — починалися проблеми. на співбесіді мене питали про HashMap, і я давав визначення: "це така структура даних, яка зберігає в собі зв'язки ключ і значення". Тоді співрозмовник питав: а в чому на відміну від TreeMap? Відповідь: відмінність у тому, що HashMap хешує ключ, і за рахунок хешування відбувається швидкий доступ. Співрозмовник відразу просив розповісти внутрішній пристрій HashMap, заразом запитає про hashCode і equals. І буде заглиблюватися, поки не задовольнитися відповіддю або ви не зупинитесь. Відповідати правильно про HashMap я навчився тільки через 2 місяці співбесід та курсу структур даних на hexlet. Другий приклад: концепція SOLID. Просять дати визначення, яке я завчив. Але щойно справа стосувалася реальних прикладів із життя — починалися проблеми. яка зберігає у собі зв'язки ключ і значення». Тоді співрозмовник питав: а в чому на відміну від TreeMap? Відповідь: відмінність у тому, що HashMap хешує ключ, і за рахунок хешування відбувається швидкий доступ. Співрозмовник відразу просив розповісти внутрішній пристрій HashMap, заразом запитає про hashCode і equals. І буде заглиблюватися, поки не задовольнитися відповіддю або ви не зупинитесь. Відповідати правильно про HashMap я навчився тільки через 2 місяці співбесід та курсу структур даних на hexlet. Другий приклад: концепція SOLID. Просять дати визначення, яке я завчив. Але щойно справа стосувалася реальних прикладів із життя — починалися проблеми. яка зберігає у собі зв'язки ключ і значення». Тоді співрозмовник питав: а в чому на відміну від TreeMap? Відповідь: відмінність у тому, що HashMap хешує ключ, і за рахунок хешування відбувається швидкий доступ. Співрозмовник відразу просив розповісти внутрішній пристрій HashMap, заразом запитає про hashCode і equals. І буде заглиблюватися, поки не задовольнитися відповіддю або ви не зупинитесь. Відповідати правильно про HashMap я навчився тільки через 2 місяці співбесід та курсу структур даних на hexlet. Другий приклад: концепція SOLID. Просять дати визначення, яке я завчив. Але щойно справа стосувалася реальних прикладів із життя — починалися проблеми. Співрозмовник відразу просив розповісти внутрішній пристрій HashMap, заразом запитає про hashCode і equals. І буде заглиблюватися, поки не задовольнитися відповіддю або ви не зупинитесь. Відповідати правильно про HashMap я навчився тільки через 2 місяці співбесід та курсу структур даних на hexlet. Другий приклад: концепція SOLID. Просять дати визначення, яке я завчив. Але щойно справа стосувалася реальних прикладів із життя — починалися проблеми. Співрозмовник відразу просив розповісти внутрішній пристрій HashMap, заразом запитає про hashCode і equals. І буде заглиблюватися, поки не задовольнитися відповіддю або ви не зупинитесь. Відповідати правильно про HashMap я навчився тільки через 2 місяці співбесід та курсу структур даних на hexlet. Другий приклад: концепція SOLID. Просять дати визначення, яке я завчив. Але щойно справа стосувалася реальних прикладів із життя — починалися проблеми. Увага!Якщо не знаєте, то не варто вигадувати, а скажіть так: я не знаю цієї теми, але можу припустити, що це так працює. Багатьох технічних експертів бісить, коли людина несе брехню з таким виглядом, ніби вона розуміється на темі. 5. Рівень вашого ентузіазму під час обговорення вакансії. Від вас чекають, що ви зацікавлені і ставитимете питання щодо вакансії (тільки не висмоктані з пальця). 6. Іноді гумор (тільки у тему) та спільні інтереси допомагають налагодити вам комунікацію. Не соромтеся говорити про свої захоплення, можливо, співрозмовник теж любить Доту/футбол/фентезі. А це плюс вам як кандидату. Знаю випадки, коли спільність інтересів заплющила очі інтерв'юера на слабку технічну підготовку (Ти ж нормальний хлопець, ми тебе навчимо). <h3>Глава 9. Пристрій на роботу, бойове хрещення</h3> Співбесіди були з кінця квітня до середини липня. Від перших співбесід було соромно, поступово ситуація виправлялася до прийнятної. Вивчення частих питань і зворотний давали себе знати. Перші 25 співбесід були безрезультатними. Після цього розпочиналися моменти розпачу. Відчуття: а якщо мене на таку зарплату, в принципі, не візьмуть? Аж раптом почало вистрілювати: за тиждень три компанії дали пропозиції. Вибрав я компанію, специфіку якої я знав, плюс там була хороша зарплата та можливість працювати віддалено. На співбесіді мене мені поставабо приблизно 30 питань щодо Java core та Spring, на 97% з яких я відповів правильно. Після цього було спілкування з вищим начальством і через 1.5 тижнів я влаштувався до них. Насамперед, прийшовши на будь-яку роботу, ти починаєш отримувати доступи до всіх необхідних систем та встановлювати потрібні тобі інструменти. На це пішло півтора тижні, і мені дали перше завдання: змінити статичний текст у класі. Коли я відкрив проект, мені погано: багато модулів усередині одного проекту, багато класів, тести та інше. У цей момент я загубився, але мені допоміг другий розробник, який втягнув мене у справи. Баг був виправлений за 10 хвабон, закомічений у Git, зроблений pull request (запит на злиття двох гілок, де інші розробники перевіряють твій код), після чого влитий в основну гілку. Виявилося, що все не так складно. До першого повноцінного завдання... У момент планування завдань на наступні два тижні мені сказали: ти робитимеш інтеграцію з іншою системою, яка знаходиться на OpenShift. Тут стало по-справжньому страшно: OpenShift це цілий кластер технологій: Docker, Kubernetes, Linux та інше. Холодний піт пробіг спиною: ну ось і попрацював джавістом. Одразу після наради зателефонував розробнику, який мене заспокоїв: адаптери до цієї системи написані, і достатньо імпортувати до свого проекту певні класи, після чого я зможу спокійно використовувати інтеграцію. Знову стало весело, до того моменту, як розробник показав типову інтеграцію: я побачив понад 20 класів, створених для схожої інтеграції. Причому були помічені небачені до цього анотації @ Value, @ Builder, @ NoArgs Constructor, @ Getter, @ Sl4f - це виявився проект Lombook (читати в інтернеті). Коли розробник мені пояснював, як робити, я намагався записати зв'язки всіх класів і взагалі нічого не в'язалося в голові. Найсоромнішим моментом виявилося незнання Intellij Idea: як шукати глобально за проектом, рефакторинг коду та інше. Взявшись за завдання, я зрозумів, навіщо потрібний ООП: для такої кількості коду потрібен поділ на класи; методи, які не використовуються поза класом, треба оголошувати private, щоб випадково не запустити їх в іншому класі, і т.д. і ви не зможете скомпілювати свій проект, поки не виправите помилки (наприклад, зайві прогалини, назви змінних з великих літер, занадто короткі назва змінних). Після перемоги над CheckStyle я відправив свій код на рев'ю старшим розробникам і протягом тижня виправляв свої косяки. Взагалі мені дуже пощастило, що в моїй команді у мене склалися добрі стосунки з другим розробником, який пояснив багато речей. Через місяць після влаштування мою першу інтеграцію було запущено на Інтеграційно-Функціональному стенді (тестується робота всіх додатків разом), і там все запрацювало! Перемога! Наступним завданням стало створення класу, який дозволяв би приховувати дані ключа в json. Наприклад: є json {text:"JavaRush"} -> обробка -> {text:"****Rush"}. Тут є дві складності: може бути вкладеність {text:{mytext:"JavaRush"}}, і що більш неприємне - вкладеність усередині масиву: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"} ] } (Звичайно треба приховати все text.mytext). Вирішення цієї проблеми виявилося досить складним, але я це зробив! Тут другий розробник каже: покривай це напрацювання тестами. В очах читалося подив. Так я познайомився з бібліотекою JUnit у бою. Суть модульного тестування: у вас є вхідні дані, прокидає їх в метод, і порівнюєте отримані дані з правильним результатом (створюєте змінну з правильним результатом). Під свою бібліотеку написав 11 випадків, у яких перевірив, що не падає програма з NullPointException, правильно приховує дані з будь-яким типом вкладеності. Після реалізації цього завдання мені дали нову інтеграцію, особливість якої була така: потрібно було експортувати Spring Bean із зовнішньої бібліотеки. Я став постійним клієнтом сайту Stack OverFlow. Одного разу навіть відповів офіційний розробник Spring. Після реалізації цієї інтеграції мій випробувальний термін добіг кінця. Начальник привітав мене з проходженням випробувального терміну, і я почав писати цю статтю.
