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

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

В першій частині циклу ми розглянули важливість складання плану навчання, питання по Java Core і роботі з БД. У цій частині обговоримо питання в коментарях і поговоримо про двох популярних фреймворках: Spring і Hibernate.

Питання в коментарях

Про походження питань для підготовки

Всі вони були задані мені або моїм колегам на співбесідах на позицію Junior/Middle людьми з рівнем Middle/Senior/Lead. Проекти: два великих банку, стільниковий оператор, внутрішні кваліфікаційні співбесіди.

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

Навіщо джуну знати про <будь-яка технологія або принцип>?

Один з уроків, який можна винести з першої частини: очевидні речі є очевидними не для всіх. Відповідь на кожне з запитань для підготовки не потрібно знати як daily basis. Його потрібно знати, щоб обійти конкурентів на позицію в хорошій компанії. Навіть якщо пам'ять погана і через час забувається більшість вивченого матеріалу, то перед співбесідою має сенс ці знання освіжити.

Вибір стратегії при підготовці

В девелопменті можна виділити дві основні стратегії пошуку роботи:

а) Куди візьмуть, туди піду. Чим швидше почну отримувати досвід, паралельно підтягуючи відсутні знання, тим краще.
б) Куди піду, туди візьмуть. Плюси очевидні. Серед мінусів — більше часу на підготовку. В деяких випадках — значно більше.

Перша стратегія сильно домінує і давно себе зарекомендувала. Не всім подобаються складні цілі, і не кожному вони під силу. У кого-то сім'я, домашні турботи, сторонні заняття і банально колись викладатися на 150%. Та й, кажучи на чистоту, стратегія працевлаштування в нетоповые компанії має мало мінусів. Ну попадеться вам як-би-сеньйор в наставники, поробите деякий час ерундовое завдання виключно на вміння серфити Stack Overflow. Зате вже з зарплатою, досвід якої-ніякої в скарбничку капає, і вільного часу для самоосвіти більше.

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

«Що дозволено Юпітеру, не дозволено бику»

Техлиды і сеньйори не зобов'язані знати відповіді на всі питання для джуна. Вони більше не конкурують з півсотнею інших претендентів на місце, кожен з яких вирішує елементарні завдання і затинається на неелементарні. А той претендент, який не затнувся, просто бачив схожу задачу днями і плаває в інших темах.

Техлидов хантят місяцями і чіпляються за гарного, як за рятувальний круг. І, як я підозрюю, про хешмапах на співбесідах їх не питають. З джунами все більш сумно: компаній в середньостатистичному місті (не мегаполісі), готових взяти стажиста/джуна, — раз-два та й усе. А їздити в пошуках по містам на початковому етапі кар'єри — не завжди дозволена розкіш. Сидіти без роботи, природно, теж.

Претендуєш — відповідай

Компанії з цікавими проектами, крутий командою і високими зарплатами мають право вимагати знання не тільки якихось патернів розробки, але і алгоритмів, логічних завдань, синтаксису — та чого завгодно.

Тому про TreeMap, LinkedHashMap, роботі купи, стека, синхронізованих колекцій та іншої мало застосовуваної нудьзі можна і не знати. Йти туди, де прямим текстом у вакансії зазначено: «Про алгоритм не питаємо». При цьому пам'ятати, що не запитують найчастіше там, де немає великої конкуренції за місце: якщо почнуть багато питати не буде з кого вибирати.

До речі, твердження про необхідність відповідати за високої конкуренції однаково вірно для всіх рівнів. Єгор Бугаєнко в недавньому інтерв'ю розповідав , що на співбесіді в Amazon йому давали алгоритмічні задачі (архітекторові з більш ніж 20-річним досвідом), які він відмовився вирішувати. Співбесіда він не пройшов. А взяли когось, хто напевно поступається в якості профільних знань, але підготувався краще і вивчив потенційні питання. І кому, скажіть, від цього гірше?

Втрачено час на листування, мінімальну підготовку, відвідування офісу — стрес до і осад у вигляді неприємного відчуття після. І якщо архітекторам всі дороги відкриті («куди піду, туди візьмуть» в більшості випадків), то у джунов ставки в кілька разів вище: тільки що було три шанси влаштуватися на хорошу позицію в рідному місті, а ось їх залишилось вже два. Пора починати збирати валізи.

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

Приступимо до тем і питань.

Spring

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

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

На сайті Spring є дуже непогана документація з описом всіх нутрощів і популярні приклади реалізації певного функціоналу.

Зазвичай, коли на співбесіді справа доходить до Spring, відбувається приблизно такий діалог:

З Spring з чим працювали?
Так, вивчав ось це і ось те.
Добре, давайте трохи поговоримо на ці теми.

Іноді будуть питати прямо: чи знаєте, наприклад, Spring Data? Якщо знаєте на достатньому для обговорення рівні, вважайте, що пощастило. Якщо немає, завжди можна чесно сказати, що розумієте їх суть і необхідність використання, бачили приклади коду, але самостійного застосування не було. І заздалегідь подбати про те, щоб це було правдою: подивитися і поверхнево вникнути в роботу будь-якого спрингового модуля доведеться в будь-якому випадку. Питання тільки в тому, наскільки глибоко.

Про що мене часто запитували:core data, mvc.
Трохи рідше— boot, security.
Про що не запитали ні разу за весь час:aop, test.
Це статистичні дані, не більше.

Поділ за рівнями джуновости досить умовне.

Недоджун (він же претендент на стажування) і молодший джун — поверхневі знання про модулях спринга і будь за що відповідає. Вивчити їх роботу на практиці і надані можливості конфігурації.

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

Далі упереміш небагато питань, пов'язаних з перерахованими темами (тільки ті, які повторювалися):

Опишіть механізм dependency injection простими словами.
Як працює модуль спринга <такий>, який флоу виконання (що куди заходить і як обробляється в процесі)?
Як створюється контекст? Який порядок ініціалізації в контексті?
Які знаєте різні способи конфігурації біна? Дефолтний скоуп біна? Які взагалі скоупы бувають? Для чого вони використовуються?
Яка різниця між BeanFactory і FactoryBean?
Розкажіть про autowired-анотації. Є поле, позначене autowired, як Spring знаходить бін і инжектит, який алгоритм? Що, якщо реалізацій інтерфейсу дві? Можна вішати autowired на кілька конструкторів?
Для чого потрібен @PostConstruct? Що виконається раніше — @PostConstruct або конструктор?
Анотація @Transactional, що знаєте про неї? Які в неї параметри? На що її можна повісити? Який патерн використовується як основа (проксі)? Опишіть вимоги до методу, на який хочемо повісити цю анотацію.
Дефолтні property у Spring boot: для чого вони, де конфігуруються?
Який патерн використовується в основі spring security (chain of responsibility у вигляді ланцюжка фільтрів)?
Перелічіть види авторизації в Spring security. За що відповідає анотація @Preauthorize?

Hibernate

Спочатку я хотів об'єднати теми Spring і Hibernate в одну, але в підсумку вирішив не створювати хаос у відносно структурованому підході. Після студіювання статей про те, що це за фреймворк і які його функції, обов'язково погуглите різницю між JPA, Spring Data JPA і Hibernate. І обов'язково зрозумійте її, це сильно спростить процес розуміння взаємодії Spring і Hibernate.

Питання:

Як Hibernate формує запити? Що таке фетчинг, батчинг?
В яких станах може бути entity? Розкажіть трохи про них.
Кеш запитів — розкажіть про всіх рівнях.
Коли виникає lazy initialization exception?
Розкажіть про відому в Hibernate проблемі N+1 select.
Розкажіть про стратегії спадкування сутностей.
Якщо всередині суті є колекції, завантажуються вони за замовчуванням?

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

P. S. Дякую всім, хто дочитав. Значить, хоч якась користь, але буде. У третій частині постараюся розкрити всі теми.

Ілюстрація Дарини Скульской

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

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

SEO Блог