Комментарии 14
P.S. И где Вас такие вопросы спрашивали?
У меня смешанные чувства. С одной стороны это очень полезный список вопросов, стоить из них довольно глубокие. С другой стороны знание ответов на эти вопросы ничего не говорит об умении писать и отлаживать код. Статья хорошая, но мысли о собеседованиях грустные.
Но список вопросов мне понравился. Он охватывает много областей и хорошо скажется на кругозоре.
К CAP-теореме ещё стоит добавить BASE.
И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
>И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
Ну вот кому обязательно? Вот я скажем знаю кое-что о докере, и совсем немного о Kubernetes. И мне это ну совершенно не мешает быть Java разработчиком (правда, я не понимаю этого смешного для меня префикса Backend-, потому что он неявно сводит всю разработку к вебу, или хотя бы предполагает, что есть еще и фронтенд (что в общем случае не так). Точно так же можно в принципе сказать про почти любой из вопросов. Т.е. можно быть отличным разработчиком — и не знать половины из того, что тут было перечислено. За ненадобностью, а не потому что квалификация низкая. Но взамен при этом знать еще десяток другой тем, которые тут не были упомянуты.
В данной части собеседования решается довольно важный и насущный вопрос как человек себя ведет в ситуации когда надо подтвердить стандарное definition of ready или definition of done. Понятно всему этому можно научить довольно быстро и кодин сессия значительно важнее чем общий подход к формулировкам. Но тем не менее хотелось бы знать в состоянии человек аппелировать к базовым понятиям разработки.
К слову сказать я не вижу проблем в том, чтоб со мной работал глухонемой (персонально я даже скорее всего за, чем против) для меня важно, чтоб человек понимал общий тренд и как это выглядит на проекте и готов был если что подучить сходу. Как раз эта часть интервью и предполагает понять как у кандидата с этим вцелом.
Большая часть при необходимости гуглится легко, меньшая зависит от того кто с чем работал. И ничто из этого не показывает умеет ли человек код писать.
Спрашивать определения каких-то терминов на собеседовании — так себе идея, по-моему. Чай не экзамен.
Например, куб масштабирование. Красивый термин. И что? Гораздо полезнее напрямую спросить, знает ли кандидат про репликацию и шардинг.
Или вот стабы vs моки. Это вообще зависит от библиотеки — я видел кучу вариантов взаимозаменяемого использования spy/stub/mock в разных инструментах.
Про 50. Lombok
фича onX — у неё интересный синтаксис (@__ правда только для Java 7)
On javac8 and up, you add an underscore after onMethod, onParam, or onConstructor.
Впрочем, вы предупредили об этом в предпоследнем абзаце. :)
В 8-11 джаве тоже присутствует, с немного видоизменённым синтаксисом. Возможно, даже вплоть до 14, но я не проверял. Я в 95% случаях использую её как @AllArgsConstructor(onConstructor_ = @Autowired
.
Спасибо за подборку вопросов, мне стало понятнее, в каких местах мне стоит подтянуть матчасть. (Во всех. Но где-то больше, а где-то сильно меньше. :D)
Привет! Спасибо, что упомянул меня! Насчёт абзаца
Самая лайтовая и, возможно, притянутая за уши причина не использовать Lombok — плагин постоянно отваливается с выходом новой версии IDEA. А если отваливается плагин, то работа летит коту под хвост. Но это уже уходит в прошлое! С версии 2020.3 Lombok-плагин будет поставляться вместе с IDEA.
Теперь всё изменится — теперь разработка Lombok плагина под крылом JetBrains и мы будем тестировать его на совместимость с новыми версиями идейки :)
В части первой хотя бы по базовому API более или менее вменяемый набор, но в этой части вообще тихий ужас. В мире существуют только Spring и Hibernate, а так же REST, ASID, SOLID и ещё несколько легко запоминаемых слов без всякого смысла внутри. Ну и ещё микросервисы, а как без них? В нашем сезоне уже немодно всё остальное. Из всего JEE вспоминают лишь о том, что там можно встретить такого зверя, который называется «сервлет». И всё, больше там ничего нет. Хотя логично, мода ведь должна двигаться вперёд. И это я ещё про БД не начал говорить. А там, между прочим, интервьюирующие ожидают беспроблемную изоляцию с помощью магического слова Serializable. Ну пусть ожидают, ведь и правда — количество ошибок в коде такое, что косяки в данных из-за непонимания работы БД уже никого не интересуют. Правда «в облаках» вообще нет RDBMS, так что можно педалировать скорость освоения новых технологий — прочитали и тут же забыли, ведь мы уже движемся в облака! И это если вообще читали. А ещё странно, почему облака не в моде в этом обзоре. Непорядок! Про БД уже забыли, а в облака ещё не встряли. Зато на интервью щёки наверняка надувают.
Но что печальнее всего — в нашем сезоне совершенно не в моде задавать вопросы на понимание сути происходящего. Только определения и придуманные какими-то модниками аббревиатуры. И ещё совсем немного API, много ведь нельзя — самим-то интервьюирующим как это всё звапомнить?
12factor.net
Еще в дополнение github.com/enhorse/java-interview
Собеседование Backend-Java-разработчика: вопросы и где искать ответы. Часть 2