Java interview questions

Рубрика: Java, Работа | 14 March 2008, 09:53 | juriy

Поскольку набор соискателей на ближайшее обозримое будущее в мою команду завершен (насколько успешно – покажет время) я решил опубликовать список вопросов (в этой заметке, первые 50), которые я задаю соискателю для оценки его знаний Core Java. Думаю, этот список может быть полезен при оценке собственного уровня или для подготовки к другим интервью.
Кроме того, всех приглашаю поделиться вопросами, которые задавали сами или на которые приходилось отвечать.

Кстати, на нашем блоге уже были заметки про Java вопросы.

Ответы на спорные вопросы принимаются в комментариях.

1. Что такое класс Object? Какие в нем есть методы?
2. Что такое метод equals(). Чем он отличается от операции ==.
3. Если вы хотите переопределить equals(), какие условия должны удовлетворяться для переопределенного метода?
4. Если equals() переопределен, есть ли какие-либо другие методы, которые следует переопределить?
5. Для чего нужен метод hashCode()?
6. Какая связь между hashCode и equals?
7. Каким образом реализованы методы hashCode и equals в классе Object?
8. Что будет, если переопределить equals не переопределяя hashCode? Какие могут возникнуть проблемы?
9. Есть ли какие-либо рекомендации о том, какие поля следует использовать при подсчете hashCode?
10. Как вы думаете, будут ли какие-то проблемы, если у объекта, который используется в качестве ключа в hashMap изменится поле, которое участвует в определении hashCode?

11. Какие модификаторы доступа в Java вы знаете?
12. Какой из модификаторов более строгий: protected или package-private?
13. Если у класса-родителя есть метод, объявленный как private, может ли наследник расширить его видимость? А если protected? А сузить видимость?
14. Что означает ключевое слово final?
15. Имеет ли смысл объявлять метод private final?
16. Какие особенности инициализации final переменных?
17. Что будет, если единственный конструктор класса объявлен как final?

18. Что означает ключевое поле static?
19. К каким конструкциям Java применим модификатор static?
20. Что будет, если в static блоке кода возникнет исключительная ситуация?
21. Можно ли перегрузить static метод?
22. Что такое статический класс, какие особенности его использования?
23. Какие особенности инициализации final static переменных?

24. Какие типы классов бывают в java (вложенные… и.т.д.)
25. Каким образом из вложенного класса получить доступ к полю внешнего класса.
26. Какие особенности создания вложенных классов: простых и статических.
27. Каким образом можно обратиться к локальной переменной метода из анонимного класса, объявленного в теле этого метода? Есть ли каке-нибудь ограничения для такой переменной?

28. Какие вы знаете способы запустить некоторое действие в отдельном потоке?
29. Какие вы знаете способы прекратить выполнение потока?
30. Какие ключевые слова Java, связанные с многопоточностью Вы знаете?
31. Для чего используется ключевое слово syhcronized?
32. Есть некоторый метод, который исполняет операцию i++. Переменная i типа int. Предполагается, что код будет исполнятся в многопоточной среде. Следует ли синхронизировать блок?
33. Что служит в качестве mutex, если метод объявлен synchronized?
34. Можно ли вызвать в разных потоках два synchronized метода одного и того же объекта?
35. Что используется в качестве mutex, если метод объявлен static synchronized? Можно ли создавать новые экземпляры класса, пока выполняется static synchronized метод?
36. Объясните, что такое deadlock? Приведите пример кода, который демонстрирует deadlock.
37. Для чего используется ключевое слово volatile?
38. Какие особенности использования метода wait? При каких условиях поток может выйти из режима ожидания?
39. Предположим в методе run возник RuntimeException, который не был пойман. Что случится с потоком? Есть ли способ узнать о том, что Exception произошел (не заключая все тело run в блок try-catch)? Есть ли способ восстановить работу потока после того как это произошло?
40. Какие стандартные инструменты Java вы бы использовали для реализации пула потоков?

41. Какие виды исключений в Java вы знаете, чем они отличаются?
42. Назовите несколько классов из вершины иерархии исключений в Java.
43. Что такое Error? В каком случае используется Error. Приведите пример Error’а.
44. Какая конструкция используется в Java для обработки исключений?
45. Возможно ли использование блока try-finally (без catch)?
46. Предположим, есть блок try-finally. В блоке try возникло исключение и выполнение переместилось в блок finally. В блоке finally тоже возникло исключение. Какое из двух исключений “выпадет” из блока try-finally? Что случится со вторым исключением?
47. Всегда ли исполняется блок finally?
48. Могли бы вы придумать ситуацию, когда блок finally не будет выполнен?
49. Предположим, есть метод, который может выбросить IOException и FileNotFoundException в какой последовательности должны идти блоки catch? Сколько блоков catch будет выполнено?
50. Предположим вам необходимо создать свой собственный класс Exception. Какими мотивами вы будете руководствоваться при выборе типа исключения: checked/unchecked?

Комментариев: 79

79 Responses to “Java interview questions”

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

  1. Farcaller

    47. Нет
    48. Конечно. Когда в эклипсе открываешь встроенный броузер, JVM падает по SIGSEGV :)

    J/W, не считая такого момента finally отрабатывает всегда?

  2. juriy

    При System.exit() в блоке try или catch у finally шансов нет. В других случаях – выполнится. Конечно, если к примеру, не прервать выполнение нажатием reset :-) Тогда JVM ничего не гарантирует :-)

  3. Chabster

    Хи-хи.
    25. Каким образом из вложенного класса получить доступ к полю внешнего класса.

    Честно говоря, если бы мне подряд задавали подобные вопросы, я бы на 8-м поблагодарил, встал и ушел.

    Это зависит от людей, которых вы ищете. Если пионеров, знающих ключевые слова, то эти вопросы подходят. Если нужен талантливый разработчик, то всякую ерунду пропускают, а вопрос 46 выглядят вот так:
    “Как по вашему компилятор транслирует конструкцию try-finally в промежуточный код?”. Этот вопрос неявно содержит в себе 5 вопросов из этого списка и очень важный аспект – креативность мышления, чего, к сожалению, у большинства java-dev’ов нет. А если бы чувак упомянул в ответе SEH, то я бы больше вопросов и не задавал.

  4. juriy

    1. Вопросы задаются не всегда подряд и только до того момента, пока соискатель не начинает спотыкаться, когда становится ясно, что человек не знает более глубоких аспектов. Тогда переходим на другую тему.

    2. По поводу вопроса 46 – это не трансляция в промежуточный код, это _обычные_ для _middle_ разработчика знания JLS. Если человек не знает, отчего в finally плохо писать throws – значит он потенциально совершит ошибку в проекте.

    3. Это вопросы только по Core Java, есть еще масса других блоков в интервью. Естественно, что задаются не все 50 вопросов подряд. Если человек держится уверенно, можно перескакивать через некоторые вопросы и двигаться дальше.

    4. Талантливый разработчик, который не знает платформу с которой работает – IMHO обуза для проекта. Я таких очень боюсь. Senior Developer должен знать свои инструменты. Причем знать отлично. Senior должен знать не только, как _нужно_ делать, но и как _не нужно_ делать и _почему_ так делать не нужно.

    5. Элементарный вопрос: 38, про метод wait. Никто полностью не ответил. А ведь это основа многопоточности. О какой “сеньористости” после этого может идти речь?

    Для справки: сам себя я оцениваю, как хорошего middle разработчика.

  5. Chabster

    Если талантливый разработчик не знает платформу сегодня, то он знает ее завтра, а послезавтра знает еще больше. Я же сказал, что, судя по вопросам, вы ищете инертного кодера. А талантливый на 48-й вопрос придумает ответ, который не придумают 99.9% Senior Java Developer, и подразумевается, что если он знает ТАКОЕ, то незнание какой-то ерунды (которая отловится на первом же ревью кода) не является минусом.

  6. juriy

    Chabster, то есть талантливый разработчик он везде талантливый разработчик. Если он читает в стихах Design Patterns и до этого писал на Pascal – берем его в команду, походу научится?

    Я согласен, что люди умеют учиться. Если бы у меня был бесконечный бюджет и время выполнения проекта, я бы _вообще_ не задавал бы вопросов по поводу _любых_ технологий. А еще лучше, взял-бы талантливого школьника старших классов и за лет 10-12 у меня был-бы хороший Senior.

    Увы, это не так. И объяснять заказчику, что команда из 4-х человек работает как полноценных два потому что “ребята походу учат платформу и пока-что делают много глупых ошибок” я бы не рискнул.

    Core Java – лишь малая часть интервью. Вопросы по ООП тоже задаются, и по Design Patterns, и по юнит тестированию (если человек с ним знаком) и даже про дизайн-по-контракту и AOP. В заметке только вопросы по Java.

    И еще, от разработчика не требуется _абсолютное_ знание. Достаточно _хорошего_ понимания платформы.

    Кстати, Chabster, приведи пример вопросов, которые ты задал бы соискателю?

  7. Chabster

    666. Как по вашему компилятор транслирует конструкцию try-finally в промежуточный код?

    Хоть кто-нибудь дайте ответ на этот вопрос. Желательно два.

  8. Vadim Voituk

    Chabster: У тебя есть все шансы дать ответ первым, тем самым просветить окружающих :)
    А твое нежелание отвечать на эти вопросы связано не с тем, что они чего-то там не отражают (это ты себе отмазку придумал), а банальной ленью и нежеланием напрягать мозги/память.
    Потому как ты ходишь на собеседования вразвалочку, и скорее с целью пообщаться чем это собеседование пройти :)

    P.S. Тем не менее, если ты читал спецификацию языка (а ты когда утверждал) – ты должен на большиснтво этих вопросов ответить не особо задумываясь.

  9. Chabster

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

  10. Olostan

    Тут есть действительно две стороны медали:
    С одной стороны если нужен именно хороший девелопер, который будет принимать участие не только в механическом наборе кода и реализации простых тасков, а и в построении архитектуры системы, принимать решения по использованию паттернов, проводить код-ревью и находить “питфоллы” и “болтнеки”, а не просто ходячий ЯваДок, которые знает наизусть все сигнатуры всех методов – тогда действительно многие вопросы могут остаться без ответа.

    Почему? Одна из причин, к примеру, если человек последние пару лет работал плотно в одном каком-то направлении и активно использовал определённые технологии и практики. Тогда более общие вопросы или вопросы по внутренностям того, с чем он не работал могут поставить в тупик, и создать плохую репутацию. И хотя человек сможет без проблем за очень короткое время переключится на другие технологии, и очень быстро вникнуть, этого человека не возьмут, посчитая его “слабоватым для синьёра”.

    Как бы ЯваДок есть одно, а умение кодить соверщенно другое. Да и гугл есть всегда под рукой.

    К примеру, хотя я и не могу сходу ответить на некоторые из этих вопросов, но могу поставить некоторые другие, на которые многие из “синьёров” сходу тоже не смогут ответить.

    К примеру, есть довольно серьёзные прокты, где просто из-за архитектуры просто не нужно использовать переопределение equals. И я бы поспорил о том, действительно ли это “коравая” возможность, которую должны использовать все и везде.

    Вот и получается, что элементарные, с точки зрения интервьювера, который работает в своём направлении уже давно, вопросы превращаются в уже углублённые для девелопера, не менее опытного, но работающего в другом направлении.

    Но с другой стороны, когда выставляются эстимейты, в них чаще всего не учитывается, сколько нужно девелоперу на ознакомление. И не знание некоторых элементарных вещей может сделать из тривиальной задачи, на которую выделялось очень мало времени задачей, для которой нужно “гугление”.

    В общем, моё мнение: нельзя быть категоричным. И если кандидат не отвечает на простейшие, с точки зрения интервьювера, вопросы, то не стоит сразу откидывать резюме с меткой “ламмер, годящийся в лучем случае на джуниора”

  11. Chabster

    Кстати, Юра, вопросы в стиле “Какие особенности у XXX” считаю абсолютно неграмотными. То же самое с “Какими мотивами вы будете руководствоваться при выборе типа исключения: checked/unchecked?”.

    IMHO, подобные собеседования я бы просто заменил на тесты :). По ним можно четко сказать, в каких областях человек силен.

    И еще, очень бы хотелось прочитать полный ответ на 27 вопрос. Ну, а 666 – для талантов.

  12. Anton Naumov

    и я вставлю свои два цента. во-первых, спасибо за систематизацию, это очень важно. во-вторых, список ИМХО избыточен. а именно, вопросы 1, 7, 9, 37 лишние. объясню, почему я так считаю. моя позиция родилась в далеком 2002 году, когда меня на интервью в одной большой и славной, но уже не существующей харьковской конторе попросили назвать все параметры функции CreateWindow. лично я считаю, что программист должен думать про реализацию, алгоритмику, функциональность, читабельность, оптимальность, bugfree и crash avoid своего кода, а количество методов, параметров, название функций классов и пакетов всегда есть в JavaDoc/MSDN. и этот мусор (поверьте, справочная информация в 99,9% случаев мусор) в голове стоит держать только один раз — при сдаче сертификационного экзамена. точно также, как private, protected, public, default (package-private) модификаторы — это фундаментальные вещи, вопрос на инкапсуляцию, а volatile и trancient — догматика. может быть я ошибаюсь, но за 8 лет коммерческого программирования я использовал trancient четыре раза, а volatile никогда.
    2Olostan, во многом согласен. и только один вопрос, а почему эстимэйты не учитывают время на исследование? может быть нужно обучить менеджмент правильно работать с заказчиком? Вы автоматически не учитываете один из главных потенциальных рисков разработки — время, потраченное на поиск workaround для не тривиального использования известной технлогии. это случается в 7 случаях из 10, т.е. 70% вероятность срабатывания риска. не кажется ли Вам такая позиция немного самонадеяной?
    2Chabster, если Вы мне назовете хотя бы три причины, почему мне должно захотеться отвечать на Ваши вопросы, то я, так и быть, поищу на него ответ, а может быть и два. до тех пор напомню, что мы не на собеседовании, а Вы не работодатель в данной ситуации. хотя я всего-лишь “не креативный” Java девелопер, надо полагать что C# разработчики один креативней другого? я просто счастлив за индустрию.
    p.s. я не отвечу сходу на 50-70% вопросов. судя по всему я в вашу команду не подхожу :)

  13. Chabster

    Выше яркий пример стиля мышления java-дева: придумывать не буду, поищу-ка в rt.jar, а если не найду, то попрошу заказчика назвать три причины, почему это нужно придумать.

    ЗЫ: Антон, не нужно язвить. Без обид.

  14. Chabster

    FYI, когда просят “назвать все параметры функции CreateWindow”, то хотят определить сколько в арсенале реального времени работы с инструментарием, а не наличие общего представления, полученного из книжек или статей. Ибо если ты пишешь “Опыт WinAPI: 3 года”, то аргументы CreateWindow должен помнить, как отченаш.

  15. Anton Naumov

    2Chabster, повторяю еще раз, Вы не заказчик и не работодатель, мое рабочее время стоит дорого, мое свободное время безценно. не вижу причин тратить свое свободное время на размышления или поиски ответа на какой-то вопрос, который лично мне не интересен. это о трех причинах.
    теперь о язвить, Вам не кажется, что Вы сами строите диалог таким образом, что ирония — это тот минимум, который может себе позволить воспитанный человек в публичной дискуссии? обратите внимание, Вы так или иначе уже трижды умудрились оскорбительно отозваться о моей профессии. безусловно, это Ваше право, но какой реакции Вы ожидаете?
    и последнее, мне все-равно, что хотят определить, задавая вопросы на количество методов и параметров. на текущий момент я уже могу себе позволить поблагодарить и выйти с интерью. я таких вещей не запоминаю. никогда. справочная информация хранится в справочнике, а не у меня в голове. и еще, кому я должен помнить параметры CreateWindow? или методы класса Object? это как-то поможет мне быть более эффективным? а может быть просто интервьюер не способен придумать вопрос по существу?

  16. Anton Naumov

    да, еще раз прочитал вопросы, нет вопросов на Collection. мои стандартные такие:
    51. в JavaAPI есть три реализации динамического массива: ArrayList, LinkedList и Vector. зачем столько?
    52. тоже про HashMap, LinkedHashMap и Hashtable.
    53. в чем принципиальное отличие Set и List?
    54. возможны ли ситуации, когда необходимо применять класс Vector/Hashtable? если да, то какие? и каковы причины применения именно этих классов?

  17. Kefir

    Большинство вопросов для разработчиков занимающихся промышленной разработкой вообще проблем не должны представлять. Вот с вайтом я действительно в ступоре был, не часто я многопоточностью пользуюсь, а если и пользуюсь, то java.util.concurrent решает половину проблем (Неее… не надо думать что я ваче ниче не знаю, к многопоточности я очень осторожно отношусь, но если что-то надо сделать раз в полгода, то, естественно все забывается).

    По мне так следующая модель подбора будет лучшей:
    1. Задается вопрос как человек оценивает свои знания:
    – плохо
    – удовлетворительно
    – хорошо
    – отлично
    2.

    Если человек говорит “отлично” – начинаем над ним стебаться изо всех сил. Потому как на “отлично” знают единицы.

    Если “хорошо” – максимум пару вопросов для проверки, посерьезней, чем ваши.

    Если “удовлетворительно” – один из ваших 50 вопросов. Если не отвечает, то не удовлетворительно.

    Если “плохо” – пытаемся поднять человека в его же глазах, может он себя недооценивает.

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

  18. Chabster

    Кстати, на вопрос о CreateWindow можно ответить, даже не запоминая точной сигнатуры. Достаточно вспомнить, что у каждого окна есть
    1) класс
    2) заголовок
    3) стиль
    4) координаты
    5) родитель
    6) меню или id

    Итого, я перечеслил 9 параметров из 11.

    Так что, даже такой тупой вопрос нормального человека в ступор не загонит.

  19. Traut

    ну, ни одного интересного :) все 50 – классика. поспрашивали бы про JMM чтоль :)

  20. Андрей

    Очень классный и полезный топик! Был бы брагодарен за список вопросов про АОП, ООП, юнит тестирование и разные J2EE.
    На беглый взгляд по приведенному списку на мой взгляд есть такие вот недостатки:
    20% про hashCode и equals(не многовато ли)
    Действительно как то не хватает вопросов про коллекции, IO/NIO, reflection, RMI, Security, java.sql, javax.xml, пару вопросов про типы данных.
    Конечно же маст би какие нибудь алгоритмические вопросы(но это наверное вне тематики данной секции).
    Кстати, вот за всю свою программистскую карьеру ниразу не заюзал wait() и смежные вещи(всегда synhronize как то хватало). Может это всетаки нишевой

  21. Андрей

    вопрос?

  22. Juriy

    Немного отлучился от основного обсуждения, поскольку компьютера под рукой не было.

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

    Еще раз хочу уточнить один нюанс, поскольку многие явно неправильно восприняли этот список. Это вопросы по знанию платформы Java. И только. Вопросы из этого списка составляют только меньшую часть интервью.

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

    Еще раз подчеркну свое собственное мнение: если разработчик затрудняется ответить на большинство вопросов о core Java, это свидетельствует о недостатке коммерческого опыта.

  23. Vadim Voituk

    Согласен по поводу того, что слишком много про hashCode & equals. IMHO не часто приходится их переопределять.

  24. Злой

    Когда гугл доступен каждому, на всех собеседованиях на все вопросы нужно отвечать “Это есть в документации или в гугле”. Проблема заключается в том, что интервьюверы, уверен, сами не знают правильных ответов на свои же вопросы. А пострадает от этого лишь кандидат.

  25. Juriy

    2 Злой:

    Отвечать можно, никто не спорит, только до offer’а, будьте уверены, дело не дойдет с такими ответами. Очно на собеседовании погуглить никто соискателю не даст.
    Злой, что означает “пострадает кандидат”, вы про хрупкую кандидатскую психику? “Страдает” зачастую компания. Поверьте, найти нужного специалиста куда сложнее чем найти работу. И если человека недооценили по каким-то причинам, это проблема компании.

    >> Проблема заключается в том, что интервьюверы, уверен, сами не знают правильных ответов на свои же вопросы.

    Я не собираюсь бить себя пяткой в грудь и доказывать “а вот я!”. Более того, я не вижу в этом никакой проблемы. Вы считаете, что принимать на работу соискателя _обязательно_ должен человек более квалифицированный в техническом плане? Я правильно вас понял?

  26. Злой

    Если собеседование техническое – да, максимально квалифицированный и зрелый годами. Или автоматизированное тестирование.

    Человеческие качества в плане командного поведения должен и обязан выяснять HR. Уже не раз видел, как интервьювер, пацан полнейший, говорит “он мне не понравился”, и хорошего специалиста на работу не берут.

    Надеюсь, процесс трудоустройства в нашей стране хоть когда-то дойдет до уровня цивилизованных стран, где за отсутствие ответа на резюме просто подадут в суд.

  27. Juriy

    >> Надеюсь, процесс трудоустройства в нашей стране хоть когда-то дойдет до уровня цивилизованных стран, где за отсутствие ответа на резюме просто подадут в суд.

    … и при этой “цивилизованности” работу будут все чаще получать представители расовых, сексуальных или религиозных меньшинств, достаточно наглые для того, чтобы подать в суд на работодателя.

    Оффтопик:
    Знаете анекдот в тему:

    Работает маленькая компания, 4 работника: девушка, пожилой мужчина, негр и молодой европеец. Дела идут не очень, и шефу нужно сократить штат, уволить одного человека.

    - Если уволишь меня, – говорит девушка, – подам в суд за ущемления по половому признаку.
    - А если меня, – говорит пенсионер, – иск за нарушение прав престарелых.
    - А я черный, меня увольнять вообще нельзя, расовая дискриминация.

    И все внимательно посмотрели на белого европейца.

    - Мне кажется, что я гей, – скромно ответил тот.

    Назад к топику:
    >> максимально квалифицированный и зрелый годами
    Максимально квалифицированный не означает “более квалифицированный, чем соискатель”. Как прикажите поступать в таком случае? Кто должен страдать?

  28. Anton Naumov

    2Злой,
    про собеседования, у соискателя такое положение, никто его не обязан взять на работу. соискатель просто пришел предложить свои услуги. я, как представитель работодателя, в праве этому соискателю отказать. без объяснения причин.
    про “зрелый годами”, суббординация и выслуга лет — это в армию. и я тоже не беру на работу человека, который мне не нравится, будь он трижды семи пядей во лбу. даже после того, как HR выяснил все командные качества.
    про трудоустройство, до такого, уже я надеюсь, не дойдет. хотя… подать в суд Вы можете уже сегодня, а выиграть — есть хотябы Штатовская статистика? думаю, что даже там очень не много прецедентов удовлетворения таких исков.
    и резюмируя, Ваша логика подразумевает, что соискателя работодатель обязан взять на работу, а это не так. такая логика чаще всего присуща людям, которые начали карьеру в конце 2001-начале 2002го.

  29. Злой

    Juriy, думаю, в таком случае соискатель должен искать более высокооплачиваемую должность.

    Ваша, Anton Naumov, логика, очевидно, присуща людям, которые свою карьеру уже закончили? Вы где-то выше писали “Вы не заказчик и не работодатель”. Поэтому, меня мало интересует Ваша практика собеседований. Вы в праве думать, резюмировать и т.д., только делайте это за себя.

  30. Juriy

    Окей, в сторону флейм:

    Есть команда из нескольких разработчиков, которая работает над проектом. Необходимо нанять еще одного, который должен быть более квалифицированным чем любой из работающих разработчиков. К примеру, нанимается человек на роль Lead Developer или Architect. Бюджет есть. Как быть в таком случае?
    Следуя вашей логике, нанять такого человека попросту невозможно, поскольку ни один из уже работающих людей не знает всех ответов на те вопросы, которые следовало бы задать соискателю.

  31. Chabster

    Кстати, по-поводу тестов на компе. Я всегда к ним относился негативно и скептически. Но, когда меня посадили за тест, состоящий из 250 вопросов по фреймворку, я набрал где-то 87%. В конце программа выдала отчет, разбила мои знания\незнания по областям. И, к своему удивлению, я увидел, что результат вполне адекватен.

    ЗЫ: Мне потом признались, что я – второй на памяти человек, набравший более 50%.

  32. Злой

    Juriy, а RD зачем существует? В СССР – “начальник отдела разработки”.

    Тем более, что собеседования на такие должности акцентирует внимание не на техническую часть.

    Если бюджет есть, то умный соискатель прикинет все за и против. За хорошие деньги, вероятнее всего, согласится.

  33. Anton Naumov

    2Злой, я всегда думаю и делаю выводы за себя и для себя. насчет Вас я выводы сделал. с Вами не интересно, тем более что Вы наверняка знаете хуже кого аноним. будьте здоровы.

  34. sergey

    Очень “изобретательно” – вопросы как-то очень похожи на вопросы из сановского экзамена. Может проще требовать от кандидатов наличия сановского сертификата Java Programmer?
    И время и бюджет сэкономите на собеседовании. Знаю немало весьма посредественных разработчиков весьма успешно ответивших на подобные вопросы и получивших сертификат. Если уж ищите опытных разработчиков, то лучше задавать вопросы типа “объясните систему загрузки классов в J2SE – parent delegation model”. Или же погонять по фрейворкам и библиотекам. В наше время одной явой не обойдешься. Грош цена разрабтчику на яве не умеющему обращаться с Ant, Velocity, Apache Commons или java.util.concurrent.

  35. Juriy

    Сергей,

    действительно, ничего “изобретательного” тут нет, все вопросы стандартные, на авторство я не претендую. В действительности, вопросы на сановском экзамене, если вы заметили, носят характер “multiple choice”, тут же вопросы задаются для того чтобы “разговорить кандидата”. Так что с этим доводом я не соглашусь.

    Требовать наличие SCJP(D) – не имеет смысла, сразу отсекается огромный пласт достойных разработчиков, которые попросту не захотели тратить $200 на очередной сертификат.

    Одной Java, естественно, недостаточно, если вы внимательно читали заметку то наверняка обратили внимание что вопросы служат для оценки знаний Core Java, а не кандидата вцелом.

  36. sergey

    Тогда согласен. Хочу так же заметить для других комментаторов, что вопросы не архи-сложные и в принципе, поработав на яве пару лет, любой должен на них без проблем ответить независимо от области в которой он работает.
    Интересно, как выглядят остальные вопросы – не по Core Java: По ООП, организации кода, классов, методов. Просто я сам провожу интервью на фирме, где я работаю (правда работаю я не в Украине а в Германии – собственно про SCJP поэтому я и спросил – по инерции – у немцев сертификации довольно популярны и это позволяет экономить время на вопросах типа Core Java, но как Вы и заметили, наличие SCJP не означает, что кандидат действительно крут).

  37. Anton Naumov

    2sergey,
    следуя Вашей логике, мне как-раз грош цена, ибо с Velocity и java.util.concurrent я таки не работал. хотя нет, с Velocity приходилось, совсем не много. и я, о ужас, за 5 лет так и не научился отвечать на все перечисленные вопросы. судя по всему, в Германии мне работы не сыскать. ушел пить йад и убивать себя ап стену… ладно, в сторону флейм.
    скажите, а Вам на работу нужен человек, который будет код писать, отвественно относится к поставленной задаче, легко изучать новые технологии или ходячий справочник по Java? ибо в моей практике случился однажды молодой человек, который отлично знал язык и имел живейший ум… таких проблем, которые он привносил в разработку не созадвал ни один из подчиненных мне студентов.

  38. Mike

    Антон, Ваши убеждения наводят меня на мысль что Вы с большой вероятностью просто не умеете работать с людьми с большим опытом и не знаете как использовать эти знания и кругозор наработанный годами. Иногда довольно страшно разговаривать с 30-летним сопляком поставленным руководить отделом, который начинает спрашивать профессионала о том что такое класс Object. Хотя конечно эти самоуверенные молодые люди становятся такими в отечественных компаниях не по своей вине а из-за отсутствия внятной кадровой политики.

  39. Chabster

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

  40. Sanders

    Нашел еще один вариант когда не выполнится finally. В потоке демоне завершение выполнения происходит мгновенно и вполне вероятно что finally не выполнится

  41. Juriy

    Кстати, о извращенных вопросах на интервью: меня на одном из свежих собеседований на тим-лида попросили рассказать, как работает QuickSort и BinarySort. Так что, если будете интервью проходить – учтите и этот вопрос (тем более что оба алгоритма простые и посмотреть, что за ними стоит труда не составит).

  42. Olostan

    Честно говоря имхо стоит знать основные отличия методов сортировок (разница в сложности, затратах), чем конкретную реализацию алгоритмов, которая гуглиться для любого языка за минуту.

  43. Vadim Voituk

    Olostan,
    Гуглиться – оно то да. Но хотелось бы, чтоб кандидат понимал что скрывается за словосочетаниями “QuickSort” или “Сортировка Хора”.

  44. Juriy

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

  45. Chabster

    Пытаюсь уже 3-й раз отписаться от каментов и не могу.

  46. Olostan

    Juriy отлично высказался. Подчеркну, что можно понимать что скрывается за этими словосочетаниями, понимать особенности алгоритмов, но не помнить конкретной реализации.

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

    Конечно можно привести контр-примеры, когда по специфике проекта требуется знание реализации алгоритмов (например, реализация какой-то своей СУБД, где будут с нуля писаться реализации оптимизированных алгоритмов под конкретные), но это довольно редкие случае, и в общем случае для реализации стандартных бизнес-задач важно умение выбрать и _использовать_ алгоритм, а не _реализовывать_ его.

  47. Storm

    Перечитал комментарии.
    Имя трехгодичный опыт разработки UI приложений под Windows соглашусь с Антоном.
    Заучивать список параметров функции CreateWindow может только окончательно “двинутый” человек, который никогда не слышал об IDE и по старинке пишет в блокноте, компилируя код из командной строки.
    Потому-что нормальный разработчик старется оптимизировать рабочий процесс, используя IDE с автодополнением (как минимум)…
    Хороший разработчик не будет вникать в детали имплементации алгоритма внутри “черного ящика”. Ему достаточно знать предназначение и особенности использования такого “ящика”, чтобы аргументированно и успешно применять его в своем проекте.

  48. Anton Naumov

    надо же, ожила тема :) господа Искатели, мои поздравления, не многие могут похвастаться топиком, актуальным в течении года.
    2Storm, я благодарен Вам за поддержку, хотя мы рискуем снова начать кормить троллей “разработчиков с большим опытом” (ТМ). но одновременно у меня есть несколько возражений. для начала — Вы совершенно точно прочли мою мысль относительно параметров. я считаю подобную информацию излишней или не обязательной для запоминания. с другой стороны, что касается алгоритмов работы “ящика” тут не все так просто. разумеется самое главное, это “аргументированно и успешно применять алгоритм в работе” — тут Вы снова правы, но каким образом Вы собираетесь его аргументированно применять, не понимая принципов работы? по-моему не достаточно знать только назначение, нужно понимать принципы работы алгоритма, его сильные и слабые стороны. как в случае с ArrayList и LinkedList

  49. fever

    я джуниор, была я недавно на 2 собеседованиях, на одном из них вопросы как раз из этого списка были:) и про volatile спрашивали. вывод: видимо когда я буду пересказывать учебник по java, будет все просто отлично:))) И вапше я считаю так, человек помнит только то, что сам лично сделал, а не просто об этом прочитал, к примеру, до соб-я я читала что надо переопределять метод equals, но не запомнила в каких случаях, и помню что есть еще методы которые надо переопределять, но не помню какие именно, да потому что мне ни разу не пришлось их переопределять (да эти методы мне нафиг не нужны вапше-то), и я не думаю что остальные люди от меня сильно отличаются, это как мышечная память, если вы работали с переопределениями этих методов, то вы это запомните на всю жизнь, или по крайней мере будете помнить, ну может не на все 100%.

    зы, и не только в программировании просят отвечать на такие вопросы, в др. сферах встречается тож самое, я вам так скажу, от такого работодателя надо бежать, лучше сразу)))
    в соответствии ТК РФ работодатель должен аргументированно отказать каждому соискателю, а т.к. слово к делу не пришьешь, значит он должен сделать это письменно! если вместо вас взяли человека, как вы считаете по квалификации ниже вашей вы можете судиться, суд признает вашу правоту, фирма должна взять вас на работу, тот факт что вы не вышли рожей и просто тупо не понравились, такая отмазка не катит! но в нашей стране не принято отстаивать свои права, потому что в последующем вас просто никуда не возьмут, и придя однажды на работу вам просто могут сказать: мы в ваших услугах больше не нуждаемся – так один раз сказали моему знакомому программисту. Я являюсь специалистом в области ТК РФ, бывшая профессия:)

  50. Alex

    2 fever.
    По поводу переопределения equals…
    Попробуйте разобраться как работает поиск по хеш коду, например в HashMap, и вопрос отпадет сам собой.
    Качество кода улучшиться и прийдет небольшое просветление…
    Потом попробуйте разобраться как работает substring у класса String, тоже очень забавно…
    В конце-концов это просто интересно.
    Удачи!

  51. Павел

    Спасибо за 50 вопросов! Стало ясно что многого не знаю. А вед жо этого был в плену высокого мнения о себе :)

  52. SergioK

    Вопрос про переоределить equal – дурацкий пару лет назад знал ответ счас не помню ,будет надо минут за 15-20 вспомню , про finally – тоже глупо спрашивать , будут сомнения поставлю System.out.print(“??”). и увижу что он не выполняется, Что используется в качестве mutex впервые слышу про этот mutex , наверно плохой специалист,

    глупость в том что можно не знать жаву , но выучить вопросы к интевью, тот у кого больше знакомых на интервью ходит имеет лучшие шансы того и берем :lol:.

    еще нет ни одного вопроса про Swing , про работу с файлами(потоками)

  53. Евгений

    Вопросы хорошие – видимо содраны глава за главой с какого нибудь учебника. Для девелопера, который будет набивать код по указке – самое оно, хотя volatile тут – имхо перебор.

  54. wolfroma

    2 all
    В этом интервью есть хорошие/сложные вопросы, я смог ответить на большинство сходу, над другими даже не стал думать, в топку их – главное знать принцип. При этом я знаю замечательных специалистов которые не смогу ответить и на половину вопросов, хотя им можно доверить выполнение ну очень большой задачи, чуть ли не треть проекта и сделают хорошо. Поэтому как правильно говорили, знание учебника по java не самое главное. Также считаю что на собеседовании обязательно должен присутствовать разработчик с большим опытом разработки, собственно этот человек и должен проверить на знание принципов а не конкретных вещей. Конечно не стоит брать человека который не имеет понятия о Java, но и нельзя подходить формально к этим вопросам. Конечно, то что у интервьюора меньше опыта влияет, но не сильно, так как в любой ситуации можно от кандидата попросить объяснить свою позицию в том или ином вопросе. Знаете, есть пословица – рыбак рыбака видит издалека.

  55. vk

    я просто умиляюсь с коментариев к этой теме. у некоторых интервьюверов явно пробелемы с психикой /
    могу с увереностью сказать что я с ходу ответил бы на 20-40% всех вопросов, если немного подумать то возможно на 50-60 не больше. при том что у меня 3,5 года бизнес разработки и общий стаж на на жава свыше 7 лет /
    по личному опыту могу сказать что очень часто интервьюверы это менеджера и тим лиды. а это еще не делает из них хороших девелоперов (и пусть у них будет 100кг томов за плечами, но они со временем они все меньше занимаются кодингом и все больше менеджментом и архитектурой). ошибки делают _все_, лично я говнокод видел в испольнении не только сеньеров но и более _квалифицированых специалистов_. потому что одновременно помнить о всех нюансах/проблемах невозможно. хороший дев всегда будет писать код с минимальным количеством ошибок которые легко выявить вовремя 1го тестирования. а если важен перфоманс/мультипоточность или же есть риск ошибки с реализацией чего-то крайне важного то можно потратить пол дня на изучение вопроса(или даже выходные, пусть за счет своего времени с целью повышения квалификации) и больше не возвращатся к нему

  56. SergioK

    Брать нужно прежде всего програмиста,т,е, того кто понимает основные принципы , много средность она и в С++ и жаве одинаковая, оптимизация кода , грамотная работа с памятью , знание ООD, человек владеющий этим на любом другом языке через неделю будет писать и на жаве ,
    вопросы тут явно для начинающего кодера, закончившего трехмесячные курсы ,

  57. Juriy

    Надо всё же сказать пару слов в защиту своей заметки.

    Меня умиляют последние два коммента :) Господа, вы можете иметь хоть 10 лет работы в Java и при этом не знать платформу, или знать её плохо.
    Вообще странный подход “вопросы плохие, потому что я не могу на них ответить, а ведь я уже всё знаю”, значит знаете не всё.
    Про переход с C++ на java – порадовало. Может быть, senior c++ developer за пару недель сможет стать middle java. Но Senior не станет, потому что не знает инструмента с которым работает. Не знает доступных ему API и будет изобретать велосипеды.

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

    Вот ещё несколько вопросов по Java, которые я бы задавал:
    - Что такое memory barrier
    - Что означает отношение “happens-before” в java, каким образом можно “организовать” чтобы два события находились в отношении “happens before” (окей, про этот happens before человек может и не знать, но обязан объяснить, каким образом изменения, сделанные в одном потоке, становятся видимыми остальным)
    - Зачем в java 5 появился пакет java.util.concurrent? Что мешало и датьше пользоваться synchronized, wait … и.т.п. В качестве подсказки, что такое CAS.
    - Что означает понятие “reentrant” lock, что было-бы, если бы локи не были reentrant. За компанию можно поговорить про ReadWriteLock.
    - Описать принцип работы CountDownLatch, привести практический пример, где можно его использовать.
    - Рассказать про Executor’ы и описать, какие задачи можно решать при помощи ThreadPoolExecutor.
    - Описать стратегию обработки InterruptedException. Что такое флаг interrupted, зачем он нужен.

    По коллекциям.
    - Несколько вопросов, чтобы понять, знает ли человек устройство Hash-коллекций изнутри. Или для него это полный blackbox (что само по себе не очень плохо, но знание нюансов – всегда плюс). Как правило это помогают выявить вопросы про неправильные связки eq-hashCode
    - Пару вопросов на понимание алгоритмов, которые используются, к примеру, “какая сложность добавления элемента в TreeMap?”
    - Отличный вопрос, стянутый с DOU – “предположим, вам нужно написать свою, очень простую, реализацию HashMap, расскажите, как вы это будете делать”

    По JVM –
    - Какое условие завершения работы JVM
    - Что такое generation’ы

    По инфраструктурно-около-Java-шным
    - Предположим, в приложении, где запущено 1000 потоков, несколько вошли в состояние Deadlock, каким образом будете выявлять и исправлять ошибку
    - Приложение на третий день работы падает с OutOfMemory – что делать, чтобы выявить и устранить leak.

  58. Olostan

    Полностью согласен с тем, с тем, что даже 15+ летний стаж J2EE разработки не гарантирует _хорошего_ знания JVM (и, иногда и J2EE).

    Недавно я работал “техническим экспертом” – фактически нужно было оценивать реальные знания кандидатов. За день у меня было от 3 до 10 кандидатов.

    И реально бывали случаи, когда судя по резюме опыт в 5-6 крупных компаниях в сумме 15-20 лет, учился в НовоСибе. Начал с Core Java и просто офигел – ни знания элементарных коллекций, синхронизации потоков, JDBC, JPA и т.д. Зато в течении 5 минут мог травить какие сложные бизнес проэкты у него были, сколько миллионов записей в базе и т.д.

    Так что опыт хоть и важен, но не ключевой.

    ПС. На правах рекламы: если есть кто-то, кому интересно поработать “техническим экспертом” – пишите olostan в гмейле. Работа очень не пыльная и довольно интересная – общатся нужно с русскими, американцами, китайцами, индусами – в общем хороший шанс повысить communication skills :)) Да и темы для общения от J2EE/.NET/C++ до ETL/SAS/DW.

  59. SergioK

    Юра,
    Програмист, не кодировщик С/С++ , так же как и Cobol или
    RPG, станет Senior очень быстро , так как Java API есть
    всего лишь “более удобная и упрощенная версия” того с чем он давно знаком,
    если он занимался средами там, то тут у него займет 2 дня на ознакомления с “синтаксисом”, важна не платформа а знание предмета, у меня когда начинал работать с Java, освоение оаботы c GUI, DB, файловой системой и JSP заняло
    чуть больше недели, тем более когда перед глазами был готовый жава код, вопросы про memory barrier,happends before, hash map любой

  60. SergioK

    сишник и даще майнфремщик знает так как вы можете только мечтать :lol, даже если он про жаву никогда не слышал, конкретный API в крайнем случае ему можно и посказать,
    80% из добавленных вами вопросов OS+ алгоритмы,а посему это С а жава всего лишь кросс платформ реализация, и не стоит
    преувиличивать “знания синтаксиса”

    позиция о который вы говорите это не девелопер это скорее SE со знанием JAVA, т,е , нечто уровнем повыше,
    Т,е знания конкретно Java не критично,

    еще стоит добавить вопросы про Link List, методы сортировки, и оптимизацию DB ,Design Patterns ,
    еще может быть вопрос , как реализовать множественное наследование, в чем проблема перегрузки функций

    Если же у вас работа под заказчика – тогда вовсем другое,
    спрашивайте про API и те вопросы что и 3 года назад,

    P.S . недавно начал вспоминать давно забытый С/С++, качество программ и понимание Java выросло в разы,
    На серьезную разработку не знающих machine oriented langauges,хотя бы базово, просто бы не брал,

    IMHO

    IMHO.

  61. Дима

    А кто тут больше 3к у.е. получает будучи в Киеве?

  62. Juriy

    Дима, а вы из налоговой будете? :) Если серьезно, то киевские зарплаты уместнее обсуждать на developers.org.ua – там есть несколько веток, где люди обсуждают именно эту тему.

  63. Дима

    Я хотел провести параллель между этими вопросами и зп =). Лично мое мнение – нужно спрашивать что-то вроде – “реализуй сортировку пузырьком” или “реализуй быструю сортировку”. Все остальное – пыль в глаза.

  64. Sergio

    Дима,
    реализация сортировки лежит в гугле, из там 6 видов,

  65. Evgeniy

    Дима,
    реалии украинского рынка ИТ в секторе аутсорса таковы, что вам не совсем обязательно быть “сочным девелопером” для получения зп в 3к, вы сможете себя продать за такую сумму будучи девелопером поскромнее, тем более когда вендору позарез нужно по контракту набрать ~600 инженеров на новый проект

  66. Скептик

    Из своего опыта могу сказать, что у меня глубокое отвращение и к стилю проведения интервью сегодня, и к их содержанию – т.е. вопросам. Компании нанимают не людей, создающих продукт, а работников к конвейеру. Поверьте мне, не знание наизусть даже 30 -40 % ответов на подобные вопросы не говорит, что человек создаст плохой код. Вообще, может ктото привести правила написания идеального кода, ради которого стараются интервьюеры?
    Абсолютно не учитывается индивидуальная реакция человека – на ряд вопросов я задумаюсь просто потому, что хочу проанализировать какие подвохи, какие алтернативы и пр. С точки зрения интервьера. это уже преступление. Отвечать нада наперед. как он вопос еще не задал))
    Методы церковно приходской школы живут и жить будут..успехов.

  67. Скептик

    Комментарий к Olostan
    February 18th, 2011 at 3:43 pm

    Лично я предпочел бы работать с человеком который “Зато в течении 5 минут мог травить какие сложные бизнес проэкты у него были, сколько миллионов записей в базе и т.д.” ? если конечно, он реально эти вещи делал. А не с отличником, который зайчил наизусть ответы и знает синтаксис даже во сне.
    Вообще сказать, трудно сделать ошибки в синтаксисе, netbeans сам ее покажет и пососетует как исправить. и сатсh нужные подтянет, и много другого разумного сделает.
    Так может пора от синтаксиса перейти к содержанию продуктов?

  68. Juriy

    Забавно, прошло уже почти 4 года, а тема всё ещё актуальна. К сожалению, я не смогу добавить к словам Скептика ничего нового: человек, который работал много и старательно apriori знает синтаксис. Кстати, большая часть вопросов касается не синтаксиса, а правил языка. Простите, но не верю, что человек, который ворочал миллионами записей не сможет описать в какой последовательности будут отрабатывать блоки catch.
    А вот в обратную сторону может сработать. Человек, который много сидит на Хабре и регулярно читает DZone или InfoQ, сможет сорить buzzword’ами довольно долго. Если человек отказывается отвечать на вопросы такого плана, это значит, что он будет перебирать задачами и на проекте, а это уж точно никому не нужно.

    P.S. Неделю назад я сам проходил интервью на High-Load проект. Угадайте, с какого вопроса оно началось? Правильно: “Какие методы есть в Object”. Закончили вопросами о том, какие “assembly instructions” генерируются для прохождения memory barrier’ов (я не мог продолжать разговр на этом уровне достаточно долго). А вы тут жалуетесь, что вас синтаксис заставляют учить.

    P.P.S. Кстати, если кому интересно лезть в такие дебри – тут вот есть на InfoQ статейка :))) http://www.infoq.com/articles/memory_barriers_jvm_concurrency

  69. Skeptic

    Juriy, если вы осознанно шли на это интервью и работали в данной области- это нормальные вопросы. Ведь одни физики изуают механику, другие квантовые взаимодействия.
    Но вы же не станете доказывать что без знания нюансов memory barrier’ов девелопер не может написать почтвый клени, клиент БД или свинговое приложение ?
    И что доказывают например стандартные задачи из тестов -что выведет этот код ….. – ровным счетом ничего.

  70. Olostan

    Кстати да, на протяжении всех 4 лет постоянно приходят новые ответы :) Живучая таки тема.

    Юрий, вот что я скажу – если бы на вопрос “какие методы..” человек не перечислял методы, а просто сказал “что-то для сравнения, хеширования да синхронизации” – я бы посчитал этот ответ вполне таким полным.

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

  71. Juriy

    +1, я это и имел в виду.

  72. r

    Ага, тема очень живучая) Потому как очень актуальная! Мне кажется независимо от опыта и практических знаний нужно знать ответы на вопросы представленные в этом списке и вопросы которые были дополнены позже. Знание ответов на эти вопросы – это кругозор разработчика, а значит умение ориентироваться в них(я про специфичные вещи, такие как мультипроцессорное программирование). Не всегда же корпорэйт java это спринг и стратс. А кругозор как минимум говорит о заинтересованности разработчика к изучению специфики платформы, а значит ему будет интересно копать, разбираться и дальше развиваться в этом направлении.

  73. hedjuo

    Во-первых, спасибо топикстартеру за материал. Мне он очень помогает в самоподготовке к собесу на позицию Junior Java Dev. Во-вторых, хочу высказать своё ИМХО и задать вопрос.
    Я считаю что, core Java надо знать чтоб от зубов отскакивало(без фанатизма конечно). Потому что как было выше сказано ЯП это всего лишь инструмент для программиста и чем лучше ты его знаешь тем в первую очередь тебе самому будет больше пользы. Ведь при решении бизнес-задач ты используешь тот самый инструмент и если ты плохо знаешь его, то ты сначала тратишь время на изучение дополнительных/новых фич(для себя) этого инструмента или занимаешься фелосипедо-строением, а это для бизнеса не есть гуд. Также считаю что OCA\OCP Java Dev must have, но не надо этим кичиться на собесах.
    Товарищи, как вы думаете если я отвечу хотя бы на 70-80% вопросов правильно или что-то более менее внятное по теме, этого должно хватить на Junior’a? Топикстартер, а какие ещё вопросы по core Java ты бы мне задал на собеседовании?
    И на последок вопрос со *, который мне задали на собесе.
    В HotSpot JVM объявление класса как final(если это действительно необходимо) влияет на производительность? Если да, то как?
    Кто-нибудь из опытных ответит сходу? :-)

  74. Olostan

    Такое чувсво, что этот пост будет подниматься вечно :) Интересно, для какой версии java писались вопросы…

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

  75. Juriy

    Слово final еще используется для создания immutable классов (во многопоточной среде). Если на _полях_ класса нету слова final, то нет гарантии “безопасной публикации” объекта. Проще говоря, без слова final другой поток может увидеть наполовину сконструированный объект.

    Если это касается final на классе – это гарантирует что его наследник не поломает immutable-дизайна.

    А насчёт заметки – невероятно живучая, согласен.

    Про дополнительные вопросы – сложно сходу придумать вопросы на Junior, OCJP-сертификация содержит массу вопросов базового уровня. Наверняка предложил бы написать какой-нибудь код и найти очевидные ошибки в чужом коде (небольшой фрагмент без извратов).

    В интервью на Java Junior важно уловить – интересно ли человеку учиться и развиваться дальше. Java разработчики – долгосрочная инвестиция :)

  76. sergioK

    Juriy ,

    Что такое Java Junior ? например человек работал 5 лет
    на С++ он Junior ? или на С#, или для вас такой кандидат н
    отличаеться от того что закончил 5-6 месячные курсы и не знает, а он еще не может знать чем отличаеться arrayList,
    от LinkList,
    Я в свое время переходил на Яву имеея 5 лет опыта,програмирования и было ощущение что нужно знать на память конкретные классы,(а в гугле их нельзя посмотреть??),
    а понимание основных принципов,не зависимых от языка, как бы не важны,

  77. Alexander

    Olostan
    Для использования локальной переменной во внутреннем/анонимном классе, объект надо объявить final

Leave a Reply