В этой части обсудим вопросы в комментариях и поговорим о двух популярных фреймворках: Spring и Hibernate.
Вопросы придумывал не я, и оценивать их качество без конкретного контекста имеет мало смысла. Практически каждый из них прозвучал в общей сложности больше двух раз за все время прохождения собеседований. Какие-то были в разных вариантах, но с одним подтекстом.
а) Куда возьмут, туда пойду. Чем быстрее начну получать опыт, параллельно подтягивая недостающие знания, тем лучше.
б) Куда пойду, туда возьмут. Плюсы очевидны. Среди минусов — больше времени на подготовку. В некоторых случаях — значительно больше.
Первая стратегия сильно доминирует и давно себя зарекомендовала. Не всем нравятся сложные цели, и не каждому они под силу. У кого-то семья, домашние заботы, сторонние занятия и банально некогда выкладываться на 150%. Да и, говоря на чистоту, стратегия трудоустройства в нетоповые компании имеет мало минусов. Ну попадется вам как-бы-сеньор в наставники, поделаете некоторое время ерундовые задачи исключительно на умение серфить Stack Overflow. Зато уже с зарплатой, опыт какой-никакой в копилку капает, и свободного времени для самообразования больше.
Вторая стратегия гораздо консервативнее: меньше свободных часов в сутках при подготовке, значительно меньше их же в рабочем дне на первых порах. Но ускорение на старте профессионального развития более качественное и, чаще всего, выше зарплата.
Судя по комментариям к первой части, очень мало кто придерживается второй стратегии. Очень мало кто даже рассматривает ее как один из вариантов. Но это не хорошо и не плохо, берем ношу по себе.
Техлидов хантят месяцами и цепляются за хорошего, как за спасательный круг. И, как я подозреваю, о хешмапах на собеседованиях их не спрашивают. С джунами все более печально: компаний в среднестатистическом городе (не мегаполисе), готовых взять стажера/джуна, — раз-два и обчелся. А ездить в поисках по городам на начальном этапе карьеры — не всегда позволительная роскошь. Сидеть без работы, естественно, тоже.
Поэтому о TreeMap, LinkedHashMap, работе кучи, стека, синхронизированных коллекций и прочей мало применяемой скуке можно и не знать. Идти туда, где прямым текстом в вакансии указано: «Об алгоритмах не спрашиваем». При этом помнить, что не спрашивают чаще всего там, где нет большой конкуренции за место: если начнут много спрашивать, не из кого будет выбирать.
Кстати, утверждение о необходимости соответствовать при высокой конкуренции одинаково верно для всех уровней. Егор Бугаенко в недавнем интервью рассказывал, что на собеседовании в Amazon ему давали алгоритмические задачи (архитектору с более чем 20-летним опытом), которые он решать отказался. Собеседование он не прошел. А взяли кого-то, кто наверняка уступает в качестве профильных знаний, но подготовился лучше и изучил потенциальные вопросы. И кому, скажите, от этого хуже?
Потеряно время на переписку, минимальную подготовку, посещение офиса — стресс до и осадок в виде неприятного ощущения после. И если архитекторам все дороги открыты («куда пойду, туда возьмут» в большинстве случаев), то у джунов ставки в несколько раз выше: только что было три шанса устроиться на хорошую позицию в родном городе, а вот их осталось уже два. Пора начинать собирать чемоданы.
Выбирайте стратегию обдуманно и слушайте только близких вам по мировоззрению и духу людей. «Не каждый совет ценен, но каждый озвучен неспроста».
Приступим к темам и вопросам.
Обо всем перечисленном могу сказать одно: все приходит с опытом. Я остановился на следующем подходе: выбрать один-два модуля Spring для детального изучения, а в остальных разобраться поверхностно. Под детальным изучением подразумевается изучение реальных примеров на гите, за которым следует собственная реализация практической задачи с запоминанием или записью используемых в процессе аннотаций.
На сайте Spring есть очень неплохая документация с описанием всех внутренностей и популярные примеры реализации определенного функционала.
Обычно, когда на собеседовании дело доходит до Spring, происходит примерно следующий диалог:
О чем меня спрашивали часто: core, data, mvc.
Чуть реже — boot, security.
О чем не спросили ни разу за все время: aop, test.
Это статистические данные, не более.
Разделение по уровням джуновости достаточно условное.
Недоджун (он же претендент на стажировку) и младший джун — поверхностные знания о модулях спринга и какой за что отвечает. Изучить их работу на практике и предоставленные возможности конфигурации.
Крепкий джун — спринговый код и конфиги смущать не должны. Видим аннотацию и понимаем, что она из конкретного модуля и нужна для таких-то целей, и какие шаги необходимо предпринять, если понадобится изменить определенную логику.
Дальше вперемешку немного вопросов, связанных с перечисленными темами (только те, которые повторялись):
Вопросы:
dou.ua
Вопросы в комментариях
О происхождении вопросов для подготовки
Все они были заданы мне или моим коллегам на собеседованиях на позицию Junior/Middle людьми с уровнем Middle/Senior/Lead. Проекты: два крупных банка, сотовый оператор, внутренние квалификационные собеседования.Вопросы придумывал не я, и оценивать их качество без конкретного контекста имеет мало смысла. Практически каждый из них прозвучал в общей сложности больше двух раз за все время прохождения собеседований. Какие-то были в разных вариантах, но с одним подтекстом.
Зачем джуну знать про <любая технология или принцип>?
Один из уроков, который можно вынести из первой части: очевидные вещи очевидны не для всех. Ответ на любой из вопросов для подготовки не нужно знать как daily basis. Его нужно знать, чтобы обойти конкурентов на позицию в хорошей компании. Даже если память плохая и через время забывается большинство изученного материала, то перед собеседованием имеет смысл эти знания освежить.Выбор стратегии при подготовке
В девелопменте можно выделить две основные стратегии поиска работы:а) Куда возьмут, туда пойду. Чем быстрее начну получать опыт, параллельно подтягивая недостающие знания, тем лучше.
б) Куда пойду, туда возьмут. Плюсы очевидны. Среди минусов — больше времени на подготовку. В некоторых случаях — значительно больше.
Первая стратегия сильно доминирует и давно себя зарекомендовала. Не всем нравятся сложные цели, и не каждому они под силу. У кого-то семья, домашние заботы, сторонние занятия и банально некогда выкладываться на 150%. Да и, говоря на чистоту, стратегия трудоустройства в нетоповые компании имеет мало минусов. Ну попадется вам как-бы-сеньор в наставники, поделаете некоторое время ерундовые задачи исключительно на умение серфить Stack Overflow. Зато уже с зарплатой, опыт какой-никакой в копилку капает, и свободного времени для самообразования больше.
Вторая стратегия гораздо консервативнее: меньше свободных часов в сутках при подготовке, значительно меньше их же в рабочем дне на первых порах. Но ускорение на старте профессионального развития более качественное и, чаще всего, выше зарплата.
Судя по комментариям к первой части, очень мало кто придерживается второй стратегии. Очень мало кто даже рассматривает ее как один из вариантов. Но это не хорошо и не плохо, берем ношу по себе.
«Что дозволено Юпитеру, не дозволено быку»
Техлиды и сеньоры не обязаны знать ответы на все вопросы для джуна. Они больше не конкурируют с полусотней других претендентов на место, каждый из которых решает элементарные задачи и запинается на неэлементарных. А тот претендент, который не запнулся, просто видел похожую задачу на днях и плавает в других темах.Техлидов хантят месяцами и цепляются за хорошего, как за спасательный круг. И, как я подозреваю, о хешмапах на собеседованиях их не спрашивают. С джунами все более печально: компаний в среднестатистическом городе (не мегаполисе), готовых взять стажера/джуна, — раз-два и обчелся. А ездить в поисках по городам на начальном этапе карьеры — не всегда позволительная роскошь. Сидеть без работы, естественно, тоже.
Претендуешь — соответствуй
Компании с интересными проектами, крутой командой и высокими зарплатами имеют право требовать знание не только каких-то паттернов разработки, но и алгоритмов, логических задач, синтаксиса — да чего угодно.Поэтому о TreeMap, LinkedHashMap, работе кучи, стека, синхронизированных коллекций и прочей мало применяемой скуке можно и не знать. Идти туда, где прямым текстом в вакансии указано: «Об алгоритмах не спрашиваем». При этом помнить, что не спрашивают чаще всего там, где нет большой конкуренции за место: если начнут много спрашивать, не из кого будет выбирать.
Кстати, утверждение о необходимости соответствовать при высокой конкуренции одинаково верно для всех уровней. Егор Бугаенко в недавнем интервью рассказывал, что на собеседовании в Amazon ему давали алгоритмические задачи (архитектору с более чем 20-летним опытом), которые он решать отказался. Собеседование он не прошел. А взяли кого-то, кто наверняка уступает в качестве профильных знаний, но подготовился лучше и изучил потенциальные вопросы. И кому, скажите, от этого хуже?
Потеряно время на переписку, минимальную подготовку, посещение офиса — стресс до и осадок в виде неприятного ощущения после. И если архитекторам все дороги открыты («куда пойду, туда возьмут» в большинстве случаев), то у джунов ставки в несколько раз выше: только что было три шанса устроиться на хорошую позицию в родном городе, а вот их осталось уже два. Пора начинать собирать чемоданы.
Выбирайте стратегию обдуманно и слушайте только близких вам по мировоззрению и духу людей. «Не каждый совет ценен, но каждый озвучен неспроста».
Приступим к темам и вопросам.
Spring
Фреймворк, без знания основ которого вас практически никуда не возьмут. Пугает на старте всех, кто никогда его не видел, и чаще всего из-за непонимания его основных целей и механизмов работы. Это и неудивительно: на просторах интернета пересекаются тонны как совсем свежей, так и безнадежно устаревшей информации. А возможность сконфигурировать один и тот же механизм работы несколькими абсолютно разными способами еще больше усложняет изучение.Обо всем перечисленном могу сказать одно: все приходит с опытом. Я остановился на следующем подходе: выбрать один-два модуля Spring для детального изучения, а в остальных разобраться поверхностно. Под детальным изучением подразумевается изучение реальных примеров на гите, за которым следует собственная реализация практической задачи с запоминанием или записью используемых в процессе аннотаций.
На сайте Spring есть очень неплохая документация с описанием всех внутренностей и популярные примеры реализации определенного функционала.
Обычно, когда на собеседовании дело доходит до Spring, происходит примерно следующий диалог:
- Из Spring с чем-то работали?
- Да, изучал вот это и вот то.
- Хорошо, давайте немного поговорим на эти темы.
О чем меня спрашивали часто: 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.
- Расскажите о стратегиях наследования сущностей.
- Если внутри сущности есть коллекции, подгружаются ли они по умолчанию?
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua