Comments 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)

Я так и не понял чем сервисы о личаются от микросервисов.


Интересные там "минусы" микросервисов. Например "умение работать при условии что что-то отвалилось".


Вопросы про ломбок (как кстати и многие другие) звучат в духе "а вы знаете что будет если пописать в ядерный реактор?"


Про паттерны написано адекватней всего т.к просто дана ссылка без рассуждений на тему. Тоже самое касается "отличий процесса от потока" (кстати чё там серьезно можно ответить кроме разной памяти?). Это реально кто-то спрашивает?
К слову в заметке написано следующее
"Процесс подвержен диспетчеризации. Он определяет порядок выполнения одной или нескольких программ, при этом выполнение может перекрываться другими процессами. Каждый процесс имеет состояние выполнения и приоритет диспетчеризации."
А потоки другими потоками прерываться не могут, приоритетов у них нет? И что тут вообще имеется ввиду под прерыванием? И что значит "других программ".


Про моки и заглушки это сильно конечно утверждать что что-то там "используется только для".


Что такое REST это вообще не вопрос. Если приспичило то можно спросить как бы выглядел API для чего-то там.


Что такое полиморфизм? Это уже не смешно даже. Надо ещё спросить что такое действительные числа.


Как работает докер это вопрос про устройство ядра Линукс иначе надо ответить "нажал кнопку и он включился".


Про локи в бд кстати нормально написано, я понятия не имел что там такое оптимистичные или писисистичные, но идея там судя по описание ничем не отличается от обычных RW локов многопоточного программирования.


P.S. На JAVA писал пол год(года 3 назад) на спринге и хибернейте с ломбоком (до этого только с++ и без классических БД). Ни одного вопроса про хибернейт не смог бы ответить. Никаких проблем при этом на работе не возникало. В связи с чем есть сомнения в адекватности подобных собеседований.

Привет! Спасибо, что упомянул меня! Насчёт абзаца


Самая лайтовая и, возможно, притянутая за уши причина не использовать Lombok — плагин постоянно отваливается с выходом новой версии IDEA. А если отваливается плагин, то работа летит коту под хвост. Но это уже уходит в прошлое! С версии 2020.3 Lombok-плагин будет поставляться вместе с IDEA.

Теперь всё изменится — теперь разработка Lombok плагина под крылом JetBrains и мы будем тестировать его на совместимость с новыми версиями идейки :)

Хорошее доказательство преобладания отучившихся на двухмесячных курсах в рядах интервьюирующих.

В части первой хотя бы по базовому API более или менее вменяемый набор, но в этой части вообще тихий ужас. В мире существуют только Spring и Hibernate, а так же REST, ASID, SOLID и ещё несколько легко запоминаемых слов без всякого смысла внутри. Ну и ещё микросервисы, а как без них? В нашем сезоне уже немодно всё остальное. Из всего JEE вспоминают лишь о том, что там можно встретить такого зверя, который называется «сервлет». И всё, больше там ничего нет. Хотя логично, мода ведь должна двигаться вперёд. И это я ещё про БД не начал говорить. А там, между прочим, интервьюирующие ожидают беспроблемную изоляцию с помощью магического слова Serializable. Ну пусть ожидают, ведь и правда — количество ошибок в коде такое, что косяки в данных из-за непонимания работы БД уже никого не интересуют. Правда «в облаках» вообще нет RDBMS, так что можно педалировать скорость освоения новых технологий — прочитали и тут же забыли, ведь мы уже движемся в облака! И это если вообще читали. А ещё странно, почему облака не в моде в этом обзоре. Непорядок! Про БД уже забыли, а в облака ещё не встряли. Зато на интервью щёки наверняка надувают.

Но что печальнее всего — в нашем сезоне совершенно не в моде задавать вопросы на понимание сути происходящего. Только определения и придуманные какими-то модниками аббревиатуры. И ещё совсем немного API, много ведь нельзя — самим-то интервьюирующим как это всё звапомнить?
Я бы еще добавил, что часто в дезайн сесси хотелось бы услышать от кандидата знание об общих принципах разработки. Главный спойлер видимо здесь сайт с двенадцать факторов разработки программ
12factor.net
Only those users with full accounts are able to leave comments. Log in, please.