Как стать автором
Обновить

Комментарии 14

Очень качественная подборка.

P.S. И где Вас такие вопросы спрашивали?
Спасибо.
Это сборная солянка по Москве. Все спрашивают плюс-минус эти вопросы. Глубина обсуждения может отличаться.

У меня смешанные чувства. С одной стороны это очень полезный список вопросов, стоить из них довольно глубокие. С другой стороны знание ответов на эти вопросы ничего не говорит об умении писать и отлаживать код. Статья хорошая, но мысли о собеседованиях грустные.

Не всегда и везде нужно только уметь писать и отлаживать код.
Но список вопросов мне понравился. Он охватывает много областей и хорошо скажется на кругозоре.
К CAP-теореме ещё стоит добавить BASE.
И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
Кругозор — это вообще-то не совсем список тем, которые вы знаете. Хотя бы потому, что всегда может попасться тема, которой тут нет. И знать все просто невозможно.

>И обязательно контейнеризацию/Docker и оркестрацию/Kubernetes.
Ну вот кому обязательно? Вот я скажем знаю кое-что о докере, и совсем немного о Kubernetes. И мне это ну совершенно не мешает быть Java разработчиком (правда, я не понимаю этого смешного для меня префикса Backend-, потому что он неявно сводит всю разработку к вебу, или хотя бы предполагает, что есть еще и фронтенд (что в общем случае не так). Точно так же можно в принципе сказать про почти любой из вопросов. Т.е. можно быть отличным разработчиком — и не знать половины из того, что тут было перечислено. За ненадобностью, а не потому что квалификация низкая. Но взамен при этом знать еще десяток другой тем, которые тут не были упомянуты.
Технически современное интервью состоит из нескольких секций. Обычно здесь в Долине преполагается, что вопросы поднятые ТС появляются после сессии кодирования. Т.е. предполагается, что кандидат уверенно может зашарить экран и решить задачи средней сложности с leetcode.com или hakerrank.com.
В данной части собеседования решается довольно важный и насущный вопрос как человек себя ведет в ситуации когда надо подтвердить стандарное 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
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории