Советы для начинающего 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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU