Кофе-брейк #181. Почему интервью с Java-разработчиками одинаковы. Что такое конфликты классов Java и как их устранять

Почему интервью с Java-разработчиками одинаковы

Источник: Vlad Mykol Автор этой статьи делится личным опытом и дает несколько полезных рекомендаций по подготовке к собеседованию на позицию Java-разработчика. Когда я искал работу, мне пришлось пройти несколько собеседований. Хотя интервьюеры задавали мне вопросы о том, с чем я раньше никогда не работал, мне показалось, что большинство из этих вопросов были одинаковыми. Вскоре я заметил закономерность при прохождении собеседований, что дало мне возможность лучше подготовиться для следующих интервью.

Вопросы теории

Большинство собеседований, на которых я был, так или иначе состояли из проверки теоретических знаний по Java. Это неотъемлемая часть интервью с разработчиком ПО. К счастью, в интернете есть множество материалов по самым популярным вопросам. Вот, например, репозиторий на GitHub, где собраны сотни вопросов и ответов по Java. Почитав несколько ресурсов, я понял, что просто сбор материала никуда меня не приведет. Поэтому я составил список самых популярных вопросов, на которые сам написал ответы. Некоторые вопросы были довольно сложными, и мне приходилось гуглить, чтобы найти правильный ответ, но при этом я всегда старался написать собственное решение, а не просто копировать его откуда-то. Вот список наиболее частых вопросов, которые мне задавали. Без ответов, конечно. Они помогут только в том случае, если вы найдете их сами. Иначе вы забудете об этом сразу после прочтения:

• Расскажите о новых возможностях Java 17 по сравнению с Java 11. Какие новые функции вы использовали? Как вы думаете, чего не хватает в Java?
• Как справиться с утечкой памяти? Как делать при ошибке deadlock? Вы когда-нибудь решали такие проблемы? Какие конкретные инструменты вы считаете полезными в ​​​​Java Core?
• Какие структуры данных вы знаете? Структуры данных в целом и их реализация в Java. Значение Big(O). Их внутренняя работа. Различия между реализациями коллекций.
• Рефакторинг и паттерны. Интервьюер может спросить вас о шаблонах (паттернах) проектирования Java и/или попросить вас провести рефакторинг части кода и предложить решения для конкретной задачи, где вы можете применить эти шаблоны.
• Существует ли функциональное программирование на Java? Вопросы о знании лямбда, потоков и функциональных интерфейсов. Интервьюер также может попросить вас написать код с использованием этих методов.
• Параллелизм. Знаете ли вы, что такое проблема производителя-потребителя (producer-consumer problem) и как ее решить? Что такое монитор объекта, синхронизаторы, блокировки и исполнители?

Мой подход заключался в том, чтобы дать полный ответ на эти вопросы. Когда интервьюер спрашивал у меня что-то, я старался все максимально рассказать, чтобы интервьюеру не нужно было задавать мне уточняющие вопросы. Иногда это даже спасало меня от вопросов, которых я не знал.

Проблемы кодирования

В наше время недостаточно рассказать о том, что вы умеете. Нужно показать это, особенно если вы разработчик программного обеспечения. Будьте готовы написать код без вашей любимой IDE, дополнений кода и StackOverflow. Да, это сложно. Но почти во всех моих собеседованиях была проверка навыков программирования. Вероятно, я был готов к этому, потому что ранее нашел этот список задач по кодированию. Он мне очень помог, поэтому я его очень рекомендую.

Системное проектирование

Не во всех собеседованиях есть этап проектирования системы, но в большинстве крупных компаний он вполне может быть. Я помню свой самый первый вопрос по проектированию системы, когда я даже не знал, что это означает. Если у вас тоже проблемы с системным проектированием, то это как раз одна из тем книги "System Design Interview – An insider's guide". Даже если вы пока не готовитесь к собеседованию при приеме на работу, я рекомендую ее все же прочитать.

Участие в гонке

Как только я обрел некоторую уверенность, я попросил друга провести со мной первое пробное интервью. Честно говоря, я выглядел растерянным, когда он начал задавать мне вопросы по Java, поэтому я был рад, что интервьюером был мой друг. Я понял, что говорить о том, что вы знаете, сложнее, чем просто знать это где-то у себя в голове. Тем не менее, после подготовки по теории и практике я все же чувствовал себя напряженным перед тем, как пойти на настоящее собеседование. Я слышал много историй от своих друзей, как они провалили первое интервью и после этого были готовы принять любое предложение о работе, лишь бы только больше не подвергаться такому стрессу. Я знал, что могу работать лучше, поэтому пообещал себе пройти не менее десяти собеседований, прежде чем выберу место, где хочу работать. Я начинал с низкорейтинговых компаний, где не боялся быть отвергнутым. Это помогло мне обрести уверенность перед действительно сложными интервью.

Подводим итоги

Каждое собеседование с разработчиком программного обеспечения на Java, которое я проходил, было похоже друг на друга. В каждом из них был типичный перечень вопросов:

• основные вопросы по теории Java;
• решение проблемы с кодом;
• вопросы проектирования системы высокого уровня;
• общие и поведенческие вопросы.

Бесстрашно проходить собеседование при приеме на работу — это навык, который вам придется получить, и который, скорее всего, вы никогда не будете использовать в своей повседневной работе. Однако без него не обойтись. Вскоре моя тяжелая работа по подготовке к интервью была вознаграждена. Я нашел хорошую работу, которая мне нравится, и уже успешно начинаю забывать “как сортировать массив с помощью рекурсивного алгоритма сортировки слиянием”. Надеюсь, моя история поможет вам при подготовке к собеседованию. Удачи!

Что такое конфликты классов Java и как их устранять

Источник: Medium Содержание этой публикации посвящено конфликтам между классами Java и способам решения этой проблемы. Итак, что же это такое? Когда среда выполнения Java встречает ссылку на класс, она ищет его определение во всех файлах jar на своем пути к классам. В идеальном мире она найдет ровно один такой класс и все будет хорошо. Но к сожалению, в большинстве сложных проектов так почти никогда не бывает.

Корень всех зол

Основная причина этой проблемы заключается в том, что Java определяет свое пространство имен с точки зрения пакетов и классов. Названия jar вообще не учитываются. То есть, если два разных jar-файла предоставляют одно и то же имя класса с одним и тем же именем пакета, то, кто из них будет выбран, зависит только от того, какой jar-файл просматривается первым во время поиска пути к классам.

Выявление конфликта между классами

В большинстве случаев вы можете понять, что у вас есть конфликт классов, когда вы видите ошибку типа java.lang.NoSuchMethodError:. Она означает, что во время компиляции метод существует, но во время выполнения Java не может его найти. В основном это происходит, когда Java загружает другой класс с тем же именем (и пакетом), и этот класс не имеет нужного метода. Следующий шаг — выяснить, какие jar-файлы передают конфликтующий класс. Есть пара способов это определить:

• Если вы используете IDE, все jar-файлы зависимостей должны присутствовать как часть текущего проекта. Затем поиск по классу должен показать вам jar, содержащие этот класс.
• Или вы можете использовать mvn dependency:copy-dependencies для копирования всех jar-зависимостей в каталог. Затем нужно просто перебрать все jar и просмотреть содержимое их файлов.

Возможные решения

1. Если вы используете maven для создания одного большого jar-файла и видите конфликты классов в уже созданном jar, то перемещение определения желаемой зависимости в начало списка зависимостей гарантирует, что maven выберет класс из желаемой зависимости. Когда он увидит то же имя класса в другой зависимости, maven пропустит добавление его в создаваемый jar.
2. Если одна из входных зависимостей (которая содержит определение конфликтующего класса) сама по себе является созданным вами jar-файлом, то используйте плагин maven shadow для изменения имени пакета класса.