Поради для початківця Java розробника. Підготовка до співбесіди — частина 3 - SEO Blog - все про пошукову оптимізацію та веб розробку українською.

Поради для початківця Java розробника. Підготовка до співбесіди — частина 3

Після обговорення найбільш поширених питань з основ Java в першій частині і двом популярним фреймворкам у другій частині статті, розберемо, що залишилися, але не менш важливі інструменти і технології.

Алгоритми

Основна тема на співбесідах за кордоном користується у нас набагато меншою популярністю. Про підготовку до закордонним співбесід на позицію розробника написано десятки книг і сотні статей, в яких левову частку займає саме постановка алгоритмічного мислення і розбір популярних завдань. У нас, на щастя, великої необхідності в студіюванні сайтів на кшталт leetcode.com немає. В іншому випадку час підготовки до співбесіди збільшилася б як мінімум удвічі. Втім, жодне співбесіду без подібних питань не обходиться все одно.

У кожного собеседующего є свій список «вдалих» завдань для перевірки здатності послідовно і структуровано мислити. Іноді досить абсурдних і мало застосовні до реальних ситуацій. І якщо повеселивший багатьох питання з попередньої частини статті про різницю BeanFactory і FactoryBean в спринге має хоч якийсь, нехай і віддалений, практичний сенс, то особисто мені складно зрозуміти сенс питання про паличку, яку ми розламуємо в двох місцях на три частини, і пошук ймовірності складання трикутника з цих частин. Але мислення собеседующих несповідимі, тому будемо за традицією відштовхуватися від статистичних даних за заданими питань.

Що часто запитують:

Що таке складність алгоритму? Практичний варіант: порівняйте складність двох рішень однієї задачі.

Питання, без якого не обійдеться жодне співбесіду, тому зупинимося на ньому трохи докладніше. Важливо пам'ятати, що крім складності по часу виконання є також складність витрачається пам'яті. І не забувайте запитувати собеседующего, чи вона важлива в даному випадку. Це дає умовний плюс в кошик претендента. А також те, що основних позначень складності, як функції залежності обсягу обчислень від розміру вхідних даних, буває кілька (tilde, big-O, big-theta, big-omega). Але запитують найчастіше або про середній випадок або про верхню межу виконання — розрахунок для найгіршого випадку. І який варіант цікавить собеседующего теж потрібно уточнювати відразу.

Які знаєте сортування, які використовуються в стандартних механізми Java?

Питання про QuickSort і TimSort, і їх застосування. Швидке сортування бажано вміти реалізувати в найпростішому варіанті для саморозвитку.

Бінарний пошук. Мастхев, елементарний алгоритм, багато хто питає. Складність знати обов'язково, так само як і вміти пояснити, чому вона така.
Структури даних в Java, які вміють сортувати під капотом. Для чого найчастіше використовуються? Всередині, як відбувається сортування? При якому умови об'єкти, покладені всередину, будуть відсортовані правильно?
Чому іноді вибір гіршою за складністю сортування вигідніше?

З метою перевірити загальноосвітній рівень можуть запитати про бінарне дерево, двійкову купу, графи. У 90% випадків завжди поверхово: що це таке, де використовуються, які бувають. Також підозріло часто дають завдання на сортування підрахунком.

В цілому, на мою особисту думку, поглиблені курси з алгоритмам не потрібні за винятком окремих випадків. Перерахованих вище знань, як базових, досить.

Патерни проектування

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

Питати люблять про поділ патернів на категорії, для кожної з яких зазвичай просять назвати 2-3 відомих патерну і розповісти про них. Є сайт для вивчення основ на абстрактних прикладах. Я не дуже добре ставлюся до абстрактних прикладів після своєї першої книги Head First Design Patterns, але refactoring guru непогано пояснює теоретичні аспекти та необхідність використання того чи іншого шаблону. Практику ж можна паралельно переглядати ось тут . Хороший ресурс для додавання в закладки і поступового вивчення після працевлаштування.

Якщо терміни підтискають, то ось невеликий список на вивчення по кожній категорії:

породжують: фабричний метод, абстрактна фабрика, білдер, сінглтон;
структурні: фасад, проксі, декоратор;
поведінкові: шаблонний метод, спостерігач, стратегія;
додатково (але не менш важливо): DAO, repository, MVC.

З GRASP-патернів можна ознайомитися з Low Coupling та High Cohesion як основоположними принципами. Тим більше, що на відміну від GoF, їх можна інтуїтивно зрозуміти після першого ж прочитання.

Системи контролю версій

Вивчення VCS (на прикладі Git) дуже рекомендую робити на практиці за принципом «прочитав — виконав — перевірив результат». На перших порах достатньо буде вивчити список основних команд і для чого вони потрібні: push (з опціями), pull, fetch, commit, merge, rebase, squash, revert. Після перевірки на практиці питання на кшталт «як скасувати кілька комітів» або «як зібрати кілька комітів в один» повинні перестати турбувати. Хоча останні запитують вже від рівня міцного джуна і вище. Тоді ж запитають про Git workflow або життєвий цикл розробки. Недоджуну достатньо розуміти загальні принципи спільної роботи з кодом і вміти підтягувати чужі зміни, коммитить свої і робити merge. Інше рекомендую вивчати вже після працевлаштування.

Складання проекту

Найпопулярніші збирачі сьогодні: Maven і Gradle. Другим скористатися на реальному проекті мені так і не довелося, тому все подальше буде ставитися до мавену.

Складання доводиться здійснювати часто, але практично завжди це стандартний набір з 2-3 команд. Тому занурюватися в нетрі документації і виписувати нюанси складання на початкових етапах кар'єри я б не рекомендував.

Що хочуть почути на співбесіді:

Що взагалі таке процес складання проекту на Java? Для чого потрібна збірка? Що маємо на виході?
За що відповідає pom.xml і яка його структура?
Як організована зборка многомодульных проектів?
Назвіть стандартні життєві цикли мавена і кілька фаз, які до них ставляться.
Як мавен вирішує проблеми з транзитивными залежностями?

Веб-технології

Java, як мова для розробки server-side додатків, не може бути відділений від веба. Тому основи веб-технологій запитають завжди:

Що таке HTTP? які у нього альтернативи?
Які є HTTP-запити? (назвати 4 основних буде достатньо) Яка між ними різниця? Улюблений питання у всіх: чим GET відрізняється від POST?
Що таке REST? які особливості RESTful-сервісів знаєте? Про SOAP сьогодні практично не питають.
Назвіть пару контейнерів для запуску веб-додатків на Java. Що вони з себе представляють? Для порівняння можна розглянути популярні Tomcat і Jetty.

Тестування

Вимоги до тестування дуже сильно відрізняються від проекту до проекту. Десь поділяють принципи TDD, десь виділяють час тільки на мінімальне покриття тестами чинності пріоритетів з іншим завданням. Бізнесу видніше (майже сарказм). Знати заздалегідь, як буде на наступному вашому проекті не можна, тому зосередимося на базових моментах. Найпоширеніші для тестування фреймворки на сьогодні: JUnit для юніт-тестів і Mockito для імплементації заглушок. Обидва елементарно підключаються до проекту і гранично прості в питанні розуміння необхідності їх використання.

Часто запитують:

Які види тестування знаєте і чим вони відрізняються? Розробнику досить назвати модульне, інтеграційне і функціональне. Якщо назвете навантажувальне, то необхідно заздалегідь подивитися в бік такого інструменту, як JMeter, щоб було що відповідати на додаткові питання без серйозного занурення в тему.
Основні анотації у JUnit (test, before, after, beforeClass, afterClass, ignore) та їх особливості.
Чим відрізняється Mock від Spy мокито? Наведіть приклад використання першого і другого (міцний джун+).
Що, якщо очікуємо від методу викинутого виключення? Що, якщо метод не повинен виконуватися довше певної кількості часу?
Які модифікатори доступу у тестових методів у JUnit?

У міцного джуна можуть також запитати про параметризированное/категоризированное тестування (@RunWith анотація). Або про нюанси тестування методів, які звертаються до БД.

Логування

Тема маленька, великий практичний сенс. Присутній на будь-якому проекті, запитують дуже часто. З важливого можу порекомендувати запам'ятати рівні логування:

ALL Логируются всі повідомлення
TRACE Дрібне повідомлення при налагодженні
DEBUG Важливі повідомлення при налагодженні
INFO Просто повідомлення
WARN Попередження
ERROR Помилка
FATAL Фатальна помилка

Якщо виставити рівень логування в WARN, то все менш важливі, ніж WARN повідомлення, будуть відкинуті (TRACE, DEBUG, INFO). Якщо потрібно настроїти, щоб якісь логи писалися в файл, налаштовується за допомогою Appenders.

Дебаг

На жаль, величезна кількість претендентів на позицію джуна сильно недооцінюють значимість такого інструменту розробника, як відладчик. А рівень володіння дебагом у середньостатистичного стажиста лежить у площині «ви знаєте, я зазвичай просто додаю System.out, щоб подивитися значення змінної». І дуже мало, де пишуть, що джун за фактом проводить за налагодженням і пошуком помилок не набагато менше часу, ніж за розробкою. Звідси рекомендація: обов'язково розібратися в дебаге.

На прикладі IntelliJ IDEA: знати, які функції в режимі налагодження виконують F7, F8, F9. Як переглянути вміст оброблюваної колекції в конкретний момент виконання. Як змінити значення, яке передається в метод прямо в момент налагодження. Спробуйте все це на практиці: немає нічого складного, а практичної користі дуже багато.

Методології розробки

Так як працювати розробнику доводиться в команді, то і взаємодію всередині неї завжди організовано у вигляді конкретного системного підходу. Сьогодні балом править Agile — набір гнучких принципів, на основі яких будуються популярні методології. Досить знати дві найпоширеніші з них: Scrum і Kanban.

Scrum заснований на поділі всього процесу на ітерації, де в кінці кожної команда готова надати результуючу демо-версію продукту з новим готовим функціоналом.

У Kanban в основі візуалізація процесу виконання завдань у вигляді трьох колонок таблиці: To do, Doing, Done. Основна ідея — зменшувати кількість запланованих завдань (куди вже банальніше) і поступово переміщати їх з колонки «To do» у «Done». Дуже підходить для проектів, що знаходяться в стадії підтримки, де основний функціонал вже розроблений і залишилися мінімальні доопрацювання і багфиксинг.

У кожної з методологій багато своїх термінів і нюансів, але я не впевнений, що джуну це необхідно. Знайомитися з ними набагато цікавіше в процесі роботи, тому сильно заглиблюватися в теорію не рекомендую.

Підготовка та процес співбесіди

Перерахованих профільних знань буде достатньо для того, щоб упевнено триматися на будь-якій співбесіді на позицію Junior Java Developer.

З мого особистого досвіду, на позицію Middle вони теж не особливо відрізняються за складністю. Головне — розуміти, що мідла від джуна відрізняє кількість коду, який він сам писав і бачив. Мідл ставить на порядок менше питань в процесі роботи, швидше «гравець» у проект, швидше розбирається у внутрішніх залежностях. Якщо ви вважаєте, що подучите трохи більше і можна спробувати себе на позицію мідла, трохи прикрасивши досвід в резюме, то це не так. І навіть якщо вдасться пройти співбесіду, то випробувальний термін все покаже як є. Крім підтягування теоретичних навичок, на позицію мідла «з нуля» (з точки зору досвіду продакшену) можна стрибнути тільки у випадку роботи над опенсорс проектами та самостійного вивчення практичних нюансів. Доведеться пережити етап, коли кожен перший ваш комміт в опенсорс будуть відхиляти як неякісний або незначний.

На Junior-позицію дуже часто дають тестові завдання. Найчастіше, щоб побачити, як у вашому коді, буде організовано взаємодію між класами і яка логіка куди буде винесена. І вже потім подивляться на виконання програмою необхідних функцій. Для деяких завдань не зайвим також буде наявність тестів.

На джава-форумах і каналах іноді просять оцінити структуру готового домашнього проекту, щоб зрозуміти, наскільки все погано/добре. Я вважаю це хорошим підходом. Також непогана книга для розуміння таких основ — Thinking in Java Эккеля.

Процес співбесіди не відрізняється від такого на будь-яку іншу роботу. Програмісти люблять ловити на неточності, ставлячи питання з практичної площини, якщо конкретна теорія починає кульгати. Це іноді створює дуже корисну для здобувача дискусію.

Один із якісних рад, який я отримав на початковому етапі своєї кар'єри — самому вести розмову на ту тему, в якій розбираєшся. І не давати тим самим привід собеседующему постійно задавати ритм і напрям розмови.

У такої стратегії є наслідок: якщо ви вирішили блиснути якимось маловідомим терміном, то в переважній більшості випадків готуйтеся про нього розповісти. Адже ваш інтерв'юер пройшов той самий шлях навчання і приблизно знає, в чому ви розбираєтеся добре на конкретному етапі свого розвитку, а в чомусь не дуже.

На питання переважно давати розгорнуті відповіді, так як перевіряються також навички комунікації. Найчастіше, перед вами сидить людина, з яким ви будете працювати в одній команді. І спілкуватися, і відповідати вже на схожі питання, але за проектом. Цей чоловік приглядається, як це буде виглядати на щоденній основі. Тому даний пункт досить важливий.

Також не варто бути категоричним у відповідях. Можливо JavaScript, який ви випадково згадали в не дуже доброму світлі, несподівано використовується на проекті і стане вирішальним фактором, який зіграє роль в ухваленні рішення по вашому працевлаштуванню.

Якщо після співбесіди у вас залишилися питання, то обов'язково задавайте їх. Наприклад, на якій стадії розробки знаходиться проект в даний момент? Які технології варто підтягнути до виходу на роботу? У ейчара можна запитати про умови відпусток і лікарняних, передбачуваний кар'єрне зростання в компанії, через який період відбувається перегляд зарплати. Природно, будучи джуном, сильно торгуватися на цей рахунок не вийде, але з відповідей можна зрозуміти ставлення компанії до своїх працівників і прийняти правильний вибір.

На завершення

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

Дорогу здолає той, хто йде. Удачі!

При виникненні питань, поспілкуватися зі мною можна в телеграме: @liohamitec

Опубліковано: 12/11/19 @ 11:00
Розділ Різне

SEO Блог