Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как успешно пройти собеседование на Java-разработчика. Советы интервьюеров

Interview image via Shutterstock.

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

Первое, на что стоит обратить внимание соискателю, — это его внешний вид. Как ни крути, но «встречают по одёжке». Поэтому следует заранее позаботиться о том, чтобы выглядеть чисто и опрятно. Возможно, такой совет кому-то покажется странным из-за своей чрезмерной очевидности. Но не секрет, что некоторые программисты часто пренебрегают своим внешним видом.

Теория

Что касается технической части собеседования на позицию Java-разработчика (не важно, джуниора, миддла или синьора), то к ней нужно основательно подготовиться. Скорее всего, вам зададут так называемые «50 вопросов Java», касающиеся синтаксиса и семантики Java. Ответы на эти вопросы спрашивают как у разработчиков с впечатляющим стажем, так и у новичков в этой отрасли. Часто опытные программисты гнушаются повторением этих вопросов, а иногда даже критикуют их использование на собеседованиях. И в итоге проявляют себя не в лучшем свете, когда не могут уверенно ответить на самые простые из них, особенно на фоне новичков, досконально разобравшихся в данном перечне и с легкостью дающих ответ по любому пункту.

Пока соискатель не окажется на месте интервьюера, он не поймет, почему задают эти вопросы. Объяснение же здесь простое. IT-компания заинтересована нанимать лучших специалистов, несмотря на то, что весь багаж их знаний и опыта может и не понадобиться для поставленных задач. Хорошему программисту компания с легким сердцем будет платить высокую зарплату. Плохой же работник может «аукнуться» компании в дополнительную сумму денег, а также усилий и времени, которые другие разработчики потратят на исправление его ошибок. Поэтому компании важно определить реальный уровень кандидата. И эта ответственность ложится на плечи интервьюера. Те, кто проводили собеседования, знают, что совсем нелегко за пару часов понять реальную квалификацию совершенно незнакомого человека. Конечно, соискатель может «зазубрить» ответы, но поскольку собеседования проводят опытные специалисты, то им ничего не стоит задать уточняющие вопросы, которые позволят установить истинную компетенцию кандидата. Поэтому действительно важно разобраться во всех технических нюансах.

Но самый лучший способ углубить свои знания — это изучить материалы по подготовке к сертификации Oracle. А в идеале, конечно, еще и сдать соответствующие экзамены. Наличие сертификатов будет несомненным плюсом как для опытных разработчиков, так и для новичков. Если вы на собеседовании докажете, что вы — действительно хороший специалист, то IT-компания без раздумий сделает вам выгодное предложение.

Как ни странно, но кандидатов на позицию Java-разработчика спрашивают также и по SQL. Но в данном случае от вас не потребуют чрезвычайно глубоких знаний на уровне DBA. Вероятнее всего, вам зададут вопросы по синтаксису и семантике. Например, попросят решить простую задачку — скажем, сджойнить пару таблиц. А также могут спросить о видах индексов в базах данных и уровнях изоляции в транзакциях. Для подготовки к этим вопросам может быть достаточно прочтения нескольких статей в англоязычной Вики.

Еще одна часть технических вопросов связана с фреймворками. Но их обычно задают для позиции миддл и синьор. Интервьюеров чаще всего интересуют фреймворки Spring и Hibernate, поскольку они используются в подавляющем большинстве проектов. Поэтому если вы хотите хорошо показать себя на собеседовании, стоит освежить знания. Это касается и тех фреймворков, которые вы использовали в последних проектах, указанных в вашем резюме. Вас наверняка попросят раскрыть детали, связанные с их использованием. Например, если вы работали с Hadoop, то ожидается, что вы сможете рассказать как минимум о концепции map-reduce.

Практика и мотивация

Что касается практической части собеседования, то здесь вам дадут задание написать простую программку. Например, перевернуть связный список или распечатать все элементы дерева. И здесь важен следующий момент: когда вы приступаете к выполнению задания, главное — не делайте это молча. Потому что интервьюер хочет понять ваш подход к решению задач. Важно продемонстрировать ход своих мыслей. Даже если вы не знаете решения, то не теряйтесь, а начинайте рассуждать вслух. Слыша ваши рассуждения, интервьюер сможет дать вам подсказку, которая натолкнет вас на правильное решение. Помните, что собеседование — это не экзамен, где требуется однозначный ответ. Здесь главное — показать, что вы знаете свое дело и умеете искать решения проблем.

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

Не стоит засиживаться на одном проекте более двух лет. Время не стоит на месте: технологии развиваются, появляются новые подходы в разработке. А если вы работаете над одним и тем же проектом на протяжении нескольких лет, то ваши знания устаревают и теряют ценность. И, в конечном счете, ваша рыночная стоимость как специалиста падает. Чтобы сменить проект, совсем не обязательно покидать нынешнюю IT-компанию: можно перейти на другой проект и внутри нее.

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

Самый же лучший способ научиться успешно проходить собеседования — это самому стать интервьюером :)

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Вот почему такие статьи не пишут те люди, которые реально проводят интервью — сеньйоры, лиды, архитекторы, а кто-то другой не-программист с их слов?! Смысл совершенно теряется и вымывается.

Кратко: сейчас бешеный спрос на Java-программистов, который превышает предложение в разы, и поэтому компании должны быть заинтересованы в мотивации и найме к себе, а не занимать позицию советской продавщицы, которую мы видим в топике. По факту берут почти всех кто хоть как-то соответствует. На собеседовании не надо врать техническим чувакам, можно использовать нейтральные формулировки, но доносить суть. Не говорить, что обожаете перманентный багфикс на JSP-ах если в реале это не так. И спрашивать что реально важно, а не дежурные бестолковые вопросы собеседований «сколько лет работает ваша фирма и что производит?»

Могу поспорить с 90% содержания но не буду, выделю только то, с чем особенно не согласен:

Первое, на что стоит обратить внимание соискателю, — это его внешний вид.
Совершенно неправда, сейчас все ходят неформально и на внешний вид мало кто смотри. Этот коммент кагбэ подтверждает, что HR пофиг кого нанимать: dou.ua/...c/11675/#581040
Еще одна часть технических вопросов связана с фреймворками. Но их обычно задают для позиции миддл и синьор.
Джуниор — это младший разработчик. Разработчик! Тот, кто решает производственные задачи. А как он их будет решать, если проект на Spring, Hibernate, а он не знает? О_о Есть такая категория как trainee, которые несколько месяцев обучаются, но даже от них требуют базовые знания языка и хоть какой-то опыт в фреймворках.
Например, перевернуть связный список или распечатать все элементы дерева.
Такое могут сделать 3 программиста из 100. Потому что мало кто пишет деревья с нуля, а использует уже готовые структуры, которые встроены в язык. Это может и наше упущение, но таковы реалии.
Иногда Java-программисты посещают собеседования из «спортивного» интереса, а не из надобности. И если у такого разработчика интервьюер поинтересуется, почему он хочет покинуть текущий проект, а в ответ услышит, что на текущем проекте того все устраивает, то вероятность получить джоб оффер резко падает.
А вам не кажется, что при такой ситуации на рынке, когда миддлов / senior-ов просто разрывают на части с предложением 5-15-50 вакансий на человека компания должна обращать внимание на мотивацию? Разработчики ходят на такие скрининговые собеседования, потому что иначе вилку просто не узнать, ведь (сюрприз-сюрприз) HR-ы ее не говорят. И поэтому время 3-4-х человек тратится впустую и ради чего?
Но самый лучший способ углубить свои знания — это изучить материалы по подготовке к сертификации Oracle.
Совершенно некритично. Вон тут на DOU есть несколько безработных держателей этих сертификатов. Так что видимо дело в чем-то другом.

Что реально происходит и важно на собеседовании :
0) На Java developer-а крайне важен английский, просто необходим. Будет у вас высокий, вас будут звать куда угодно, даже с низкими знаниями, если средний — то норм, если плохой уровень — работы по найму (не фриланс) вы не найдете.
1) Реально спрашивают по коллекциям и потокам, на каждом собеседовании есть вопрос по HashMap-у, всегда есть вопросы по СУБД, подзапросы, индексы.
2) Оценивают адекватность кандидата, как он реагирует на вопросы, в т.ч. примитивные, готов ли переписать код. Готов ли признать свою ошибку. Чаще всего это происходит в мягкой форме.
3) Оценивают предыдущий опыт и глубину мышления, почему так, а не иначе, одобряют любые инициативы, даже провальные: подключил библиотеку, чтобы автоматизировать конвертацию объектов, в результате свалил билд из-за транзитивных депенденси — это гораздо лучше чем безыинициативно сидеть на попе и играть в теннис.
4) Тесты очень важны для проекта и для заказчиков, поэтому JUnit, Mockito, PowerMock, EasyMock все вместе или по отдельности — must have
5) Косвенно оценивают кофликтность по отзывам к предыдущей команде и работодателю, тут надо сгладить острые углы и вести себя как дипломат, подчеркивать конструктив и не давать негативу выныривать наружу.
6) Обязательно оценивают ЧСВ, оно должно быть в пределах 0,9-1,5, но over 9001 и не выбиваться за эти пределы.

Может быть напишу топик-опровержение, но по срокам точно не знаю.

Мне наверное надо написать свою статью как нужно и как не нужно проводить собеседования
Я был на многих собеседованиях в своей жизни, и сам проводил тоже.
Нередко собеседование превращается в словесную пытку для кандидата, когда его методично заваливают вопросами до тех пор, пока он на чем-нибудь не срежется. Аааа! радуется интервьювер и у него начинают блестеть глаза. Воот! ты этого не знаешь!
Таким хочется сказать — вы человека хотите нанять, или поиздеваться? Или им премию дают за то что занизили человеку оффер, и «сэкономили» деньги компании? Я бы это мог понять если бы интервью проводил владелец компании, но чаще всего это не так.

Никогда не задаю вопросы которые я считаю «плохими».

-плохие вопросы для собеседования — которые ты либо знаешь , либо не знаешь.
причем даже если не знаешь, ты узнаешь это за 5 секунд, умея пользоваться интернетом

-хорошие вопросы для собеседования — те которые позволяют использовать логику для того чтобы прийти к правильному ответу

для собеседования нужно знать:
-Java Core
-Spring
-Hibernate
-любой один из веб фреймворков (Struts, SpringMVC, etc )
-что-нибудь про веб-сервисы (REST и SOAP)
-какой-нибудь SQL и теорию рел.баз (Oracle,Postgres, MySQL)
-что-нибудь из xml-related (XSD, XPath, XQuery) . я бы даже поставил это на первое место, ибо Enterprise Java это программирование на XML на 80% :-)
-опционно — что нибудь про Javascript/HTML/CSS/Angular/JQuery. но я этого не знаю и мне это не мешает (надеюсь мой работодатель это не читает :-) )

беда Java собеседований в том что в Java огромное количество фреймворков.
ВСЕ знать невозможно (да и не нужно). на многие тривиальные вопросы ответ моментально находится в документации. Не нужно требовать от человека быть ходячим справочником по любому API.

приведу пример тупых и бесполезных вопросов на собеседованиях
-перечислите ВСЕ методы в интерфейсе/классе ZZZ
программисты, разбалованные средствами IDE типа Eclipse и IDEA , отвыкли помнить наизусть имена методов. поставил точку — и вот тебе подсказка. Так сейчас все работают и никто не пишет код по памяти в Notepad-е. см выше

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

-как создать составной первичный ключ в Hibernate.
ну делал я составной ключ. загуглил как, сделал, и через год забыл. это не та вещь которую ты делаешь каждый день . вроде бы называется key-property, не помню, надо будет — найду

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

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

хорошие вопросы для собеседований
-алгоритмические (понимание O-нотации, рациональный выбор алгоритма и типа коллекции)

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

-вопросы связанные с проектированием
наследование vs агрегация, интерфейсы vs абстрактные классы, достоинства и недостатки наследования, применение паттернов проектирования в конкретных ситуациях

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

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

Добавлю еще мысли про тестовое задание
Некоторые компании дают тестовое задание — написать код. Я к этому отношусь положительно и считаю что в этом намного больше пользы чем в вопросах про всякие экзотические нюансы языка.
Бывают разные варианты — на бумаге, на доске, в электронной форме (в расшаренном через скайп или гугль док документе)
или тестовое задание в оффлайн которое нужно прислать по емейлу в ограниченное время

-тестовое задание не должно требовать много времени. максимум 15-30 минут для онлайн интервью, 1 час для оффлайн интервью
-к тестовому заданию на бумаге/доске не нужно требовать 100% соблюдение синтаксиса языка.
достаточно псевдокода похожего на Java
-тестовые задания в оффлайне должны быть написаны на компилирующемся без ошибок коде, и обязательно с тест кейсами в виде JUnit , в том числе проверяющими и негативные варианты (ошибки в исходных данных).
-хорошо поставленная задача должна предполагать не единственный вариант решения.

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

Ну вот я уже 3 месяца как начинающий Java middle dev.

Прошел 5 собеседований до того как получил работу на Java. Собеседования бывают разные, но в среднем можно выделить ключевые вопросы:
1) коллекции — как глубоко зависит от интервьювера.
2) многопоточность — всегда говорил что практики не было, но на базовые вопросы мог ответить.
3) Singleton !!! — мне понравилась статейка habrahabr.ru/post/129494
4) IoC, MVC
5) Hibernate
6) SQL — заджойни 2 таблицы, что такое праймари кей.

Вообще все очень зависит от интервьюверов. В Epam я бы 2 раза на собеседовании на позицию мидла на 2 разных проекта. Прекрасно понимаю что был тогда не готов, но хочу выразить огромное спасибо ребятам которые меня собеседовали. Даже когда я после 15 минут сказал «Я вижу что явно не подхожу, давайте я просто не буду отнимать у вас время» — мне сказали «сиди пока» и еще минут 30-40 продолжали инвервью, а в конце сказали что учить и куда двигаться.

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

В третьем «лидере рынка» на позицию джуна, добродушный мужчина 55 лет отроду спрашивал меня подробно обо всех уровнях кеша Хибернейта с просьбой привести пример. Но не спрашивал о маппинге, транзакциях, критериях и резюмировал «ну Хибернейта вы не знаете».

В результате джоб оффер я получил после 5-минутного технического собеседования на котором спросили: Расскажи с чем работал и что за проекты были. Знаешь что такое IoC? — да. с Хибернейтом работал? — да. Что такое REST знаешь? — да. Расскажи как запрос от пользователя в твоем проекте попадает в хибернейт? — По RESTу через маппинг, который прописан в контроллерах, в слой сервисов, в DAO и оттуда в Хибернейт. С Javascript работал — нет — ну ничего будешь бэкэндом заниматься.
А все почему? Им срочно нужен был dev, который сможет работать. В результате они взяли еще одного дева со знаниями около моих.

Пожалели ли они что взяли нас? сомневаюсь, т.к. проект успешно закончил первую фазу, перешел во вторую. Кастомер доволен, ПМ тоже. Я месяц назад отшутился что у нас все тащит тимлид, на что получил от него же ответ: «Ты внимательно посмотри какие участки вы тащите без моего вмешательства. Да первую неделю было тяжело, а сейчас не уменьшай своих заслуг»

Резюмируя могу процитировать своего очень опытного друга: «Ездуй по собеседованиям и где-то попадется тебе интервью, где тебе зададут 10 вопросов, на которые ты идеально ответишь».

103 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Если про теорию, то еще способ — протестировать себя на этом списке «327 вопроса на собеседование Java Developer»

Сейчас как раз прохожу собеседования и информация будет полезна. Логические задачки с шариками до сих пор дают. И задачку про перевернуть список тоже давали. Тем более писать ее на бумажке и еще при этом проверяют все условия, чтобы все работало, т.е. у меня мозг должен работать как компилятор. Написать я ее напишу, но не в таких условиях.

не скажу на счет Джава, но чтобы успешно пройти интервью ПХП разработчика хорошо бы знать ПХП. Может и с Джава также :)

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

Хорошее правило встретилось кажется у Гандапаса довольно универсальное: «Если в окружающей тебя компании ты самый умный — вероятнее всего это не твоя компания».

Мне наверное надо написать свою статью как нужно и как не нужно проводить собеседования
Я был на многих собеседованиях в своей жизни, и сам проводил тоже.
Нередко собеседование превращается в словесную пытку для кандидата, когда его методично заваливают вопросами до тех пор, пока он на чем-нибудь не срежется. Аааа! радуется интервьювер и у него начинают блестеть глаза. Воот! ты этого не знаешь!
Таким хочется сказать — вы человека хотите нанять, или поиздеваться? Или им премию дают за то что занизили человеку оффер, и «сэкономили» деньги компании? Я бы это мог понять если бы интервью проводил владелец компании, но чаще всего это не так.

Никогда не задаю вопросы которые я считаю «плохими».

-плохие вопросы для собеседования — которые ты либо знаешь , либо не знаешь.
причем даже если не знаешь, ты узнаешь это за 5 секунд, умея пользоваться интернетом

-хорошие вопросы для собеседования — те которые позволяют использовать логику для того чтобы прийти к правильному ответу

для собеседования нужно знать:
-Java Core
-Spring
-Hibernate
-любой один из веб фреймворков (Struts, SpringMVC, etc )
-что-нибудь про веб-сервисы (REST и SOAP)
-какой-нибудь SQL и теорию рел.баз (Oracle,Postgres, MySQL)
-что-нибудь из xml-related (XSD, XPath, XQuery) . я бы даже поставил это на первое место, ибо Enterprise Java это программирование на XML на 80% :-)
-опционно — что нибудь про Javascript/HTML/CSS/Angular/JQuery. но я этого не знаю и мне это не мешает (надеюсь мой работодатель это не читает :-) )

беда Java собеседований в том что в Java огромное количество фреймворков.
ВСЕ знать невозможно (да и не нужно). на многие тривиальные вопросы ответ моментально находится в документации. Не нужно требовать от человека быть ходячим справочником по любому API.

приведу пример тупых и бесполезных вопросов на собеседованиях
-перечислите ВСЕ методы в интерфейсе/классе ZZZ
программисты, разбалованные средствами IDE типа Eclipse и IDEA , отвыкли помнить наизусть имена методов. поставил точку — и вот тебе подсказка. Так сейчас все работают и никто не пишет код по памяти в Notepad-е. см выше

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

-как создать составной первичный ключ в Hibernate.
ну делал я составной ключ. загуглил как, сделал, и через год забыл. это не та вещь которую ты делаешь каждый день . вроде бы называется key-property, не помню, надо будет — найду

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

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

хорошие вопросы для собеседований
-алгоритмические (понимание O-нотации, рациональный выбор алгоритма и типа коллекции)

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

-вопросы связанные с проектированием
наследование vs агрегация, интерфейсы vs абстрактные классы, достоинства и недостатки наследования, применение паттернов проектирования в конкретных ситуациях

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

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

Добавлю еще мысли про тестовое задание
Некоторые компании дают тестовое задание — написать код. Я к этому отношусь положительно и считаю что в этом намного больше пользы чем в вопросах про всякие экзотические нюансы языка.
Бывают разные варианты — на бумаге, на доске, в электронной форме (в расшаренном через скайп или гугль док документе)
или тестовое задание в оффлайн которое нужно прислать по емейлу в ограниченное время

-тестовое задание не должно требовать много времени. максимум 15-30 минут для онлайн интервью, 1 час для оффлайн интервью
-к тестовому заданию на бумаге/доске не нужно требовать 100% соблюдение синтаксиса языка.
достаточно псевдокода похожего на Java
-тестовые задания в оффлайне должны быть написаны на компилирующемся без ошибок коде, и обязательно с тест кейсами в виде JUnit , в том числе проверяющими и негативные варианты (ошибки в исходных данных).
-хорошо поставленная задача должна предполагать не единственный вариант решения.

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

Коментар порушує правила спільноти і видалений модераторами.

Часто опытные программисты гнушаются повторением этих вопросов, а иногда даже критикуют их использование на собеседованиях. И в итоге проявляют себя не в лучшем свете, когда не могут уверенно ответить на самые простые из них, особенно на фоне новичков, досконально разобравшихся в данном перечне и с легкостью дающих ответ по любому пункту.
Если на вашем собеседовании опытные программисты выглядят хуже новичков, то у вас какая-то проблема с головой, наверное.
особенно на фоне новичков, досконально разобравшихся в данном перечне и с легкостью дающих ответ по любому пункту
 У нас в универе был препод по схемотехнике и его любимой фразой была: «На любой вопрос — любой ответ!», потому что мало кто шарил в схемотехнике и на сдаче лабораторных рассказывали несусветную ересь на уровне черной магии и слухов.

Собеседовался как-то в компании из восточной европы, вопросы были несколько иного толка.
А именно:
— структуры данных на которых построены коллекции (массивы, связные списки, бинарные деревья, устройство HashMap, устройство TreeMap, влияние compareTo на мапы и т.п.);
— Юникод (UTF-8 vs UTF-16, суррогатные пары и т.п.);
— многопоточность и Java Memory Model (включая вопроси вроде можно ли засинхронизировать запись и чтение в обычную переменную если перед ними или после них идут запись/чтение в/из volatile переменной), хотя практически не задавали вопросов про коллекции из java.util.concurrent;
— протокол HTTP.

Никакого синтаксиса и всякой ерунды из Оракловских экзаменов в духе «а компилируется ли такая байда вообще». Никаких фреймворков вообще и в принципе никаких разговоров о решениях с которыми работал ранее (будь то фреймворки, апликешн сервера, какие-нибудь тулзы, СУБД и т.д.). Никакого SQL. И даже никаких паттернов. Никаких общих вопросов типа «где вы видите себя через 5 лет» или «чем вам приглянулась наша компания».

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

Это было не совсем первое собеседование (точнее совсем не первое — некоторые разговоры «за жизнь» проводила до этого рекрутинговая компания, которая на меня и вышла). Для отсева у них тестовые задания.

Вопросы были вполне технические, в принципе, просто упор больший на теорию нежели на какие-то конкретные решения.

Видимо они стараются нанимать больше «как гугл» чем «как индусы» — считают, что если человек освоил фундаментальные знания, то с каким-нибудь барахлом софтовым разберется точно, а если не освоил — то не важно что он там колупал какие-то сервлет контейнеры и говнокодил с базами данных (образно выражаясь).

Есть 1001 замечание, но начну с любимой темы:

Первое, на что стоит обратить внимание соискателю, — это его внешний вид.
Поэтому если вы хотите хорошо показать себя на собеседовании, стоит освежить знания.
Зачем это все?
Если человек не опрятный, зачем ему приводить себя в порядок ради собеседования? Ведь после собеседования будет ИС и совсем не факт что он сможете долго притворятся.
Если человек не помнит какой-то особенности (или чего хуже какого-то часто используемого поведения) фреймворка, зачем «освежать знания» __для собеседования__? Помним же про ИС.
.
На собеседование нужно идти в наиболее обычном для кандидата состоянии. Задача поиска работы — это найти место где будет комфортно и продуктивно тратить где-то треть своей жизни.
Если человек не помнит какой-то особенности (или чего хуже какого-то часто используемого поведения) фреймворка, зачем «освежать знания» __для собеседования__?
Приведу пример не из Java мира. Например ты работаешь с MySQL и много лет используешь движок InnoDB потому что нужны транзакции, внешние ключи. Что там творится в MyISAM — аболютно не волнует. Какой будет первый вопрос на собеседовании по MySQL? Сравните MyISAM и InnoDB. На то чтобы освежить знания по вопросу нужно 2-3 минуты.
Какой будет первый вопрос на собеседовании по MySQL? Сравните MyISAM и InnoDB.
Ответ без подготовки: В InnoDB есть транзакции в MyISAM нет.
Если не требуется глубокое знание MySQL (на уровне БДА), то этого ответа вполне хватит. Если требуется, то
Помним же про ИС.
и 2-3 минуты не помогут.
Ответ без подготовки: В InnoDB есть транзакции в MyISAM нет.
Я б сказал этого ответа мало даже на миддла. Хотя для не бекендной java возможно и вполне достаточно.
и 2-3 минуты не помогут.
Помогут, если действительно знал, но забыл по ненадобности :)
Помогут, если действительно знал, но забыл по ненадобности :)
Я б сказал этого ответа мало даже на миддла
Ну тогда получаетсо что был мидлом, но стал джуном/трейни «по ненадобности» :)
Снова же, если контора не считает что кандидат способен достаточно быстро восстановить свои знания или получить те которых нет, то вы просто не получаете оффер. Дальше одно из двух:
1) Выводы сделаны только на основании вопроса «Сравните MyISAM и InnoDB». Тогда вам повезло, вы не попали в контору к сказочным фантазерам.
2) Помимо MyISAM и InnoDB вы не ответили еще на Х вопросов и вам таки не хватает навыков. Тогда вы, даже проскочив собеседование, не пройдете ИС и просто потеряете 1-3 месяца своего ОР.

Теория игр же. Пять программистов одинакового уровня идут на собеседование. Четыре идут в состоянии «надо быть собой», а один готовится и причесывается. У кого больше шансов получить оффер?

Получить offer можно, но если прикидываться тем, кем он не является в реале, то можно вылететь на ИС с epic fail-ом.

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

Если они выше меня на голову, то освежение знаний не спасёт; а если мы равны, то пускай выберут меня :)
А сделать так чтобы вы были выше на голову, такое вы рассматривали :)

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

Поэтому я предпочту быть специалистом в том, в чем хочу/надо. Быть на голову выше всех во всем все равно не получится.

Я всегда шел на вакансии, которые были выше моего текущего уровня.
Лично меня это очень стимулирует.
Идти на свой текущий уровень мне не очень интересно.
Может я и не прав, но полет нормальный :-)

Теория игр же. Пять программистов одинакового уровня идут на собеседование. Четыре идут в состоянии «надо быть собой», а один готовится и причесывается. У кого больше шансов получить оффер?
Таки да, теория игр. Пять _контор_ одинакового уровня _приглашают_ на собеседование. Четыре ожидают причесанности, а одина понимает что люди бывают разные. У кого больше шансов что их оффер примут? :)
.
А если серьезно, то прочитайте сообщение, на которое отвечали, до конца.
.
UPD. И что-то мне кажетсо что таки не «теория игр».
Поясните, пожалуйста, как эта ситуация моделируется в теории игр.

У той, которая больше денег даст.
Прочитал. Отвечал именно на него. Освежение знаний подразумевает, что вы предмет знаете, но детали подзатерлись за ненадобностью.
Если во время собеседования поймете, что контора хочет видеть вас в галстуке каждый день, то это повод записать это в минус конторе и учесть при принятии оффера.
Но это всё детали. Общая идея прежняя — к собеседованию готовится необходимо.

У той, которая больше денег даст.
Так они же все «одинакового уровня». Получаетсо что не одинакового? Кстати, возращаясь к вашему примеру, выберут того кто запросит меньше денег, а не того кто причешетсо :)

Нет же. Ведь я причесался и повторил про ключи в MyISAM. Теперь с точки зрения фирмы я лучше конкурентов :)

Нет же. Ведь я причесался и повторил про ключи в MyISAM. Теперь с точки зрения фирмы я лучше конкурентов :)
Да же. Потому что за некоторую сумму конторе не так уж и важно что вы не причесались, та и в БД на проекте все таблицы ИнноДБ :)

А это уже пускай контора решает — сэкономить или взять лучшего. Oba varianta реальны.

Поясните, пожалуйста, как эта ситуация моделируется в теории игр.
Есть одинаковые претенденты на вакансию «синьор джава тыжпрограммист». Пять штук. Они идут на собеседование в компанию. Компании надо выбрать лучшего. Кто лучший — компания не знает и строит стратегию определения лучшего («собеседование» + надо понравиться HR и директору).

Изначально шансы получить оффера у всех пяти =20%, но если я причесываюсь и повторяю про ключи в MyISAM, то я улучшаю свои шансы относительно других игроков, предполагая, что они используют базовую стратегию «иду на собеседование таким, какой я есть».

Я вообще заметил, что в Украине в говноконторах собеседования неоправданно замороченные. Причем, когда я работал в такой конторе, то и сам их так проводил.
По второй части — подготовка и опрятность ни разу не уменьшают ваших прочих достоинств, а вот помочь могут. Вы этого не опровергли (не факт, что собирались, впрочем). Я, впрочем, никого готовиться не заставляю, но считаю подготовку логичным шагом.

Кстати, я тоже заметил что менее солидные конторы как-то заморачиваются на всякий бред на собеседованиях. По типу логических задачек в духе «Подсчитайте количество парикмахеров в Чикаго» или «Найдите площадь фигуры за два подхода». В нормальных, уважающих себя компаниях, ни разу такого не помню.
Хотя, нет. Как-то в 2007-м в GlobalLogic одна HR’ша дала логическую задачку в духе «У вас есть весы и две груды шариков одной массы. Но один из этих шариков весит меньше, а выглядит как все. Как найти этот шарик в два (или сколько там их было) подхода, используя весы?». Но я прощаю её, потому что это был лихой 2007-й (мы выживали как могли), и она девушка))

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

Да нифига)
Доказательство Ф. Дж. Дайсона, например, не так уже и очевидно..
ega-math.narod.ru/Quant/Shestpl.htm#note2

Наверное, имеется ввиду заправленная рубашка, начищенные ботинки :D
И чтоб не очень помятый вид (а-ля домашний засальзень)

Как правило большое количество сложных вопросов призвано приуменьшить ЧСВ и, если повезет, понизить лесенка грейда на 1, например взять миддла на должность джуна, с senior-ами такое естественно не прокатывает. Это нельзя назвать явным плюсом или минусом, просто таковы маленькие продуктовые компании.

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

Если человек не опрятный, зачем ему приводить себя в порядок ради собеседования? Ведь после собеседования будет ИС и совсем не факт что он сможете долго притворятся.
Есть весьма значимая вероятность, что человеку понравится быть опрятным и приводить себя в порядок на регулярной основе, а не только ради собеседования. Во многих случаях люди относятся к этому весьма положительно — опрятному внешнему виду, опрятному коду, комментариям в коде и в коммитах в репозитарий, к периодическому поиску лучших практик. Теоретически, кандидат, способный продемонстрировать свою способность быть опрятным ради собеседования подает определенные надежды быть или хотя бы стать опрятным во всех остальных отношениях как на период испытательного срока так и далее. От кандидата же неопрятного даже ради собеседования ожидать этого «на регулярной основе» скорее не стоит, чем наоборот.

Ну вот я уже 3 месяца как начинающий Java middle dev.

Прошел 5 собеседований до того как получил работу на Java. Собеседования бывают разные, но в среднем можно выделить ключевые вопросы:
1) коллекции — как глубоко зависит от интервьювера.
2) многопоточность — всегда говорил что практики не было, но на базовые вопросы мог ответить.
3) Singleton !!! — мне понравилась статейка habrahabr.ru/post/129494
4) IoC, MVC
5) Hibernate
6) SQL — заджойни 2 таблицы, что такое праймари кей.

Вообще все очень зависит от интервьюверов. В Epam я бы 2 раза на собеседовании на позицию мидла на 2 разных проекта. Прекрасно понимаю что был тогда не готов, но хочу выразить огромное спасибо ребятам которые меня собеседовали. Даже когда я после 15 минут сказал «Я вижу что явно не подхожу, давайте я просто не буду отнимать у вас время» — мне сказали «сиди пока» и еще минут 30-40 продолжали инвервью, а в конце сказали что учить и куда двигаться.

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

В третьем «лидере рынка» на позицию джуна, добродушный мужчина 55 лет отроду спрашивал меня подробно обо всех уровнях кеша Хибернейта с просьбой привести пример. Но не спрашивал о маппинге, транзакциях, критериях и резюмировал «ну Хибернейта вы не знаете».

В результате джоб оффер я получил после 5-минутного технического собеседования на котором спросили: Расскажи с чем работал и что за проекты были. Знаешь что такое IoC? — да. с Хибернейтом работал? — да. Что такое REST знаешь? — да. Расскажи как запрос от пользователя в твоем проекте попадает в хибернейт? — По RESTу через маппинг, который прописан в контроллерах, в слой сервисов, в DAO и оттуда в Хибернейт. С Javascript работал — нет — ну ничего будешь бэкэндом заниматься.
А все почему? Им срочно нужен был dev, который сможет работать. В результате они взяли еще одного дева со знаниями около моих.

Пожалели ли они что взяли нас? сомневаюсь, т.к. проект успешно закончил первую фазу, перешел во вторую. Кастомер доволен, ПМ тоже. Я месяц назад отшутился что у нас все тащит тимлид, на что получил от него же ответ: «Ты внимательно посмотри какие участки вы тащите без моего вмешательства. Да первую неделю было тяжело, а сейчас не уменьшай своих заслуг»

Резюмируя могу процитировать своего очень опытного друга: «Ездуй по собеседованиям и где-то попадется тебе интервью, где тебе зададут 10 вопросов, на которые ты идеально ответишь».

Спасибо, интересно!
Сам был пока что на 5-ти собеседках:
Первое честно провалил (нервы и все с этим связанное:)
На втором мне честно сказали, что без опыта и профильного образования не возьмут, хотя зачем звали..?
Третье и самое успешное пока:) — Прошел техническое( даже два), и не прошел у директора (вот уж странно?!)
На четвертом получил тестовое, делать не стал т.к. «компания» не очень внушала доверие (3-х комнатная квартира с интерьером из начала 90-х) А может и зря...?!
На пятом снова услышал, что нет опыта, но можно попробовать на QA. Жду технического собеседования.
Вот такие нынче реалии... печальные! Опыт... опыт... Дайте уже кто-то опыт :)

Вот именно!!!! Если человек нужен на работу — его берут на работу, если нет — проводят собеседования!!!

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

Но не секрет, что некоторые программисты часто пренебрегают своим внешним видом.

Что не мешает отдаваться им на 1-2 раза)
dou.ua/...ms/topic/11394

Вот почему такие статьи не пишут те люди, которые реально проводят интервью — сеньйоры, лиды, архитекторы, а кто-то другой не-программист с их слов?! Смысл совершенно теряется и вымывается.

Кратко: сейчас бешеный спрос на Java-программистов, который превышает предложение в разы, и поэтому компании должны быть заинтересованы в мотивации и найме к себе, а не занимать позицию советской продавщицы, которую мы видим в топике. По факту берут почти всех кто хоть как-то соответствует. На собеседовании не надо врать техническим чувакам, можно использовать нейтральные формулировки, но доносить суть. Не говорить, что обожаете перманентный багфикс на JSP-ах если в реале это не так. И спрашивать что реально важно, а не дежурные бестолковые вопросы собеседований «сколько лет работает ваша фирма и что производит?»

Могу поспорить с 90% содержания но не буду, выделю только то, с чем особенно не согласен:

Первое, на что стоит обратить внимание соискателю, — это его внешний вид.
Совершенно неправда, сейчас все ходят неформально и на внешний вид мало кто смотри. Этот коммент кагбэ подтверждает, что HR пофиг кого нанимать: dou.ua/...c/11675/#581040
Еще одна часть технических вопросов связана с фреймворками. Но их обычно задают для позиции миддл и синьор.
Джуниор — это младший разработчик. Разработчик! Тот, кто решает производственные задачи. А как он их будет решать, если проект на Spring, Hibernate, а он не знает? О_о Есть такая категория как trainee, которые несколько месяцев обучаются, но даже от них требуют базовые знания языка и хоть какой-то опыт в фреймворках.
Например, перевернуть связный список или распечатать все элементы дерева.
Такое могут сделать 3 программиста из 100. Потому что мало кто пишет деревья с нуля, а использует уже готовые структуры, которые встроены в язык. Это может и наше упущение, но таковы реалии.
Иногда Java-программисты посещают собеседования из «спортивного» интереса, а не из надобности. И если у такого разработчика интервьюер поинтересуется, почему он хочет покинуть текущий проект, а в ответ услышит, что на текущем проекте того все устраивает, то вероятность получить джоб оффер резко падает.
А вам не кажется, что при такой ситуации на рынке, когда миддлов / senior-ов просто разрывают на части с предложением 5-15-50 вакансий на человека компания должна обращать внимание на мотивацию? Разработчики ходят на такие скрининговые собеседования, потому что иначе вилку просто не узнать, ведь (сюрприз-сюрприз) HR-ы ее не говорят. И поэтому время 3-4-х человек тратится впустую и ради чего?
Но самый лучший способ углубить свои знания — это изучить материалы по подготовке к сертификации Oracle.
Совершенно некритично. Вон тут на DOU есть несколько безработных держателей этих сертификатов. Так что видимо дело в чем-то другом.

Что реально происходит и важно на собеседовании :
0) На Java developer-а крайне важен английский, просто необходим. Будет у вас высокий, вас будут звать куда угодно, даже с низкими знаниями, если средний — то норм, если плохой уровень — работы по найму (не фриланс) вы не найдете.
1) Реально спрашивают по коллекциям и потокам, на каждом собеседовании есть вопрос по HashMap-у, всегда есть вопросы по СУБД, подзапросы, индексы.
2) Оценивают адекватность кандидата, как он реагирует на вопросы, в т.ч. примитивные, готов ли переписать код. Готов ли признать свою ошибку. Чаще всего это происходит в мягкой форме.
3) Оценивают предыдущий опыт и глубину мышления, почему так, а не иначе, одобряют любые инициативы, даже провальные: подключил библиотеку, чтобы автоматизировать конвертацию объектов, в результате свалил билд из-за транзитивных депенденси — это гораздо лучше чем безыинициативно сидеть на попе и играть в теннис.
4) Тесты очень важны для проекта и для заказчиков, поэтому JUnit, Mockito, PowerMock, EasyMock все вместе или по отдельности — must have
5) Косвенно оценивают кофликтность по отзывам к предыдущей команде и работодателю, тут надо сгладить острые углы и вести себя как дипломат, подчеркивать конструктив и не давать негативу выныривать наружу.
6) Обязательно оценивают ЧСВ, оно должно быть в пределах 0,9-1,5, но over 9001 и не выбиваться за эти пределы.

Может быть напишу топик-опровержение, но по срокам точно не знаю.

Спасибо за развернутый комментарий и за дополнения! Ваш комментарий, вероятно, отражает ситуацию в компаниях лидерах рынка, но помимо них есть некоторое количество компаний, которые не готовы брать кандидатов, не имеющих знаний на уровне первого курса университета (перевернуть связный список, распечатать все элементы дерева).

Можно еще спрашивать про нахождение кратчайшего пути в графе — тоже очень часто возникающая задача.

а можно еще и по паттернам поспрашивать:
1. Реализуйте на бумажке такой-то паттерн.
или
2. Накидайте livelock на бумажке (отсюда и вопрос livelock, deadlock and starvation)
3. Реализуйте blocking queue или как бы вы реализовали producer-consumer.

есть некоторое количество компаний, которые не готовы брать кандидатов, не имеющих знаний на уровне первого курса университета (перевернуть связный список, распечатать все элементы дерева).
1) Если вы проверяете знания на уровне первого курса, то вы найдете людей которые обладают знаниями на уровне первого курса.
2) «Перевернуть связный список» и «распечатать все элементы дерева» — это принципиально разные задачи.
Про список — это задача на работу с указателями. Зачем это проверять у джава программиста?
Про распечатку дерева — это уже ближе к реальности, но ее еще надо правильно сформулировать. Ибо «распечатать все элементы дерева» проверяет в основном память, а не навыки.

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

Чтобы перевернуть список совершенно не обязательно знать, что такое указатель, если мы не говорим о С++.
А какой список вы будете использовать?
LinkedList из стандартной библиотеки, тогда это задачка на знание 2 вызовов из стд библиотеки, ну или черезчур простая для собеседовани.
А если предложите писать свою реализацию, то это таки на указатели.
Для этого можно использовать стек и здравый смысл.
Ну здравый смысл — это штука нужная, а стек зачем?

Я думаю, речь шла о структуре данных «связный список», а не о классе LinkedList. Стек можно использовать или нет.
В моем понимании указатель и ссылка — это две разные вещи. Поэтому что значит «задача на указатели» мне не понятно. В таком случае в Java почти любая задача — задача на «указатели».

Стек можно использовать или нет.
То есть вы поняли некорректность своего утверждения, но не способны это признать.
Поэтому что значит «задача на указатели» мне не понятно.
Еще раз: Что вы хотите проверить задачей про реверс связного списка?

Что значит «некорректность»? Я написал: «Для этого можно использовать стек», из чего следует, что можно и не использовать.

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

Это задача, чтобы проверить понимает ли человек как работает связный список или нет
Нет. Как работает связный список — это одно, а вот реализовать его — это другое.
Что значит «некорректность»? Я написал: «Для этого можно использовать стек», из чего следует, что можно и не использовать.
Так вот про понимание того как работает связный список. Упоминание стека — это как раз непонимание того как работает связный список: непонимание того что одно из преимуществ связного списка есть быстрая операция добавления в голову, в то же время добавление в хвост может быть и не оптимизирована (поэтому повторю вопрос «а стек зачем?»).
.
А теперь про разницу понимания и реализации: Понимание (или непонимание) написано 2-3 фразами (см выше), а вот реализация самой структуры займет сильно больше времени и при не покажет что человек понимает или нет, поскольку тут мы имеем написание код в стресовой ситуации, которой является собеседование.

Ну, что тут скажешь. Поздравляю, вы — экстрасенс. Диагностировали на расстоянии, что я не понимаю как работает связный список. Я слышал, экстрасенсы очень много сейчас зарабатывают: Junior экстрасенсы даже больше чем Senior Java Developer’ы. В случае, если IT у нас накроется медным тазом, у вас будет отличная альтернатива.
По поводу стека: речь шла о том, как перевернуть связный список (забудьте о классе LinkedList. есть только class Node {int value; Node next}). Стек можно использовать для того, чтобы менять порядок в котором идут какие-то элементы на противоположный, что отлично подходит для задачи: 1) добавить все элементы связного списка в стек в том порядке, в котором они шли изначально 2) извлекая из верхушки стека элементы один за другим до тех пор пока он не опустеет, можно менять ссылки и таким образом перевернуть список

есть только class Node {int value; Node next}). Стек можно использовать для того, чтобы менять порядок в котором идут какие-то элементы на противоположный, что отлично подходит для задачи: 1) добавить все элементы связного списка в стек в том порядке, в котором они шли изначально 2) извлекая из верхушки стека элементы один за другим до тех пор пока он не опустеет, можно менять ссылки и таким образом перевернуть список
Вы таки правы: Я экстрасенс! При том таки хороший, ибо угадал ваше решение :)
.
Сейчас внимательно. Моя задача сейчас вас не зачмырить, а рассказать что услышал интервьюер в вашем описании решения.
1) вы 2 раза пробежались по списку (1 раз по исходному, второй раз по стеку) и учитывая что у вас нет обертки, то есть нет ссылки на хвост, скорее всего, еще и по новому списку побегаете :)
2) вы потратили больше память (на дополнительные ссылки и тд)
3) вы нарушили инкапсуляцию. Это так же критично для __джава программиста__
4) ну и дженерики в джава есть уже давно и использовать int в примере — это признак или индуса, или джуна (который трейни). Этот пункт скорее всего уйдет на допвопрос, но не факт.
5) Появляется подозрение (точнее предвзятость), что вы не в курсе того какие отношения между стеками/очередями/связными списками, в смысле того что является более базовой структурой, а что более высокоуровневой. И этот пункт, скорее всего, уточнят не будут.
.
Вот объяснение некорректности вашего решения (и в общем семейства таких вопросов/ответов) на другом примере: dou.ua/...ew-tips/#585233

Почитав ваши посты, у меня складывается впечатление, что вы их пишете только ради того, чтобы разводить демагогию. С таким же успехом мне стоило бы придраться к слову «указатель» и дальше развивать тему в направлении: «Как вы можете быть Java программистом, если не понимаете что в Java указателей нету? А тем более синиором?».
Все пункты комментировать не хочу, потому что это, судя по всему, повлечет за собой дальнейшее цепляние к словам, что мне совсем не интересно. Могу лишь сказать, что когда меня собеседовал сотрудник Amazon, он дал мне задачу связанную с бинарным деревом, а когда я попросил его написать класс вершины дерева, он написал следующее:

Node {
int value;
Node right;
Node left;
}

Без геттеров, сеттеров и дженериков. Лично для меня очевидно, что в контексте таких задач использование геттеров, сеттеров и тем более дженериков совершенно не критично, потому что суть задачи, и это очевидно, не в том, чтобы проверить понимает ли кандидат что такое инкапсуляция и дженерики. Если же следовать вашим рассуждениям, то человек, который меня собеседовал — индус, либо Junior (который Trainee). Вы, наверное, поэтому и не работаете в крупной известной компании, потому что там собеседования проводят инудусы и Junior (Trainee), ну а вы же Senior и не индус, вроде бы. Наверное, из-за зависти не берут ну или не взяли бы.

Лично для меня очевидно, что в контексте таких задач использование геттеров, сеттеров
От только я говорил про инкапсуляцию, а не про сеттеры и геттеры :)
Я говорил про итератор по списку и наличие метода добавления в голову списка.
Если же следовать вашим рассуждениям, то человек, который меня собеседовал Junior
Нет, ибо он не предлагал решение, он __ставил задачу__ (вполне возможно что он ее ставил из предположений о вашем уровне, но это уже совсем экстросенсорика).
Момент № 2: задачи на дереьвя «это уже ближе к реальности, но ее еще надо правильно сформулировать». Поскольку она скорее всго проверит еще и представление о рекурсии и еще пару мелочей.

(Представим, что мы поменялись местами и ответ пишете вы)
Ясно, теперь выясняется, что вы не знаете, как связаны геттеры , сеттеры с инкапсуляцией. Java программист, который не знает, что в Java нету указателей да и еще не понимает принцип инкапсуляции. Это признак или индуса, или джуна (который трейни).

Классная дискуссия вышла?
Думаю, что нет. Такая писанина, в том числе, к сожалению, и мои ответы, не принесут ни нам, ни тем, кто их читает никакой полезной информации, связанной с топиком.
Извините, давайте на этом закончим.

Андрей, прекращайте и не позорьтесь. Указатель на вершину стека это совсем не тоже самое, что указатель на объект в памяти. Если вы этого не понимаете, вы даже не trainee. Если нет понимания что такое инкапсуляция, то лучше разобраться или просить пояснить, а не делать"гарну мiну при поганiй iгрi"

Скиньте, пожалуйста, фразу, из которой становится понятно, что речь идет не о указателях в памяти. И ту, по которой вы определили, что я не понимаю инкапсуляцию.

Ясно, теперь выясняется, что вы не знаете, как связаны геттеры , сеттеры с инкапсуляцией. Java программист, который не знает, что в Java нету указателей да и еще не понимает принцип инкапсуляции.

Инкапсуляция — сокрытие деталей, а public Integer getAge(), public void setAge(Integer age) ничего не скрывают, понадобится вам поменять на Long или BigDecimal и привет рефакторинг по всему проекту. Тру-инкапсуляция, например не показывать какой контейнер внутри объекте используется: List, Map, Set, просто Array или самодельный велосипед, класс имплементит Iterator, в этом случае и клиент не зависит от внутренней реализации.

Java программист, который не знает, что в Java нету указателей
А NullPointerException откуда берется и почему так называется? Pointer — указатель ведь.
Указатель на вершину стека, это что по-вашему?

1. Все же хочу увидеть фразу Богдана, по которой становится ясно, что речь не идет о указателях на объекты в памяти. Я указал на эту двузначность только лишь с той целью, чтобы показать, почему цепляться к словам — плохо. Потому мой пост, где содержались наброски класса связного списка, подвергся резкой критике, хотя там я не писал, что эти наброски — мое представление о том, как надо писать класс связного списка или, что это — хорошая реализация, я написал

есть только class Node {int value; Node next}

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

2. К инкапсуляции я придрался по той же причине. Но раз уж вы спросили:
www.coderanch.com/...n-encapsulation

Ясно, теперь выясняется, что вы не знаете, как связаны геттеры , сеттеры с инкапсуляцией.
Таки да, аксессоры довольно слабо связаны с инкапсуляцией. :)
Извините, давайте на этом закончим.
Извеняю, когда поймете что неправы (думаю через годик-второй после окончания универа), напишете в эту тему. А пока засчитаем вам слив.

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

Можете засчитывать у себя в голове кого угодно и куда угодно, если вам от этого лучше.

Из-за невнимательности, вы предположили, что набросок кода, который был в моем посте, отображает мое представление того, как должен быть написан связный список, хотя из текста ясно, что это не так.
Из-за своей фантазии вы предположили, что я предположил...
А теперь вопросы вам еще на подумать:
1) если такой код __заведомо__ не отображает стиль разработки, то нафика тратить на него время __на собеседовании__?
2) если вы понимали некорректность (тут и ранее это политкорректная замена слова «глупость») решения со стеком, то зачем было про него говорить?

1) Я заключил, что вы так предполагаете, потому что вы написали:


3) вы нарушили инкапсуляцию. Это так же критично для __джава программиста__
4) ну и дженерики в джава ...
5) Появляется подозрение ....

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

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

3) Решение, которое я привел — корректно. В моем понимании решение не корректно, если оно не работает. Это одно из нескольких решений, которое хуже решения «в лоб» по памяти. Аналогичное решению со стеком — решение рекурсией, которое тоже требует O(N) дополнительной памяти. Идеи решений рекурсией и стеком по моему личному мнению интереснее, чем решение задачи «в лоб».
Если кандидат решил задачу несколькими способами, это хорошо. Если кандидат решил задачу хотя бы одним способом, это уже значит, что он понимает, как работает связный список.

Извините, но не удержался. Эти ответы —
cs9971.vk.me/.../x_2627fa55.jpg

По поводу внимательности:
1)

В данном случае смысл задачи — проверить понимание у кандидата того, как работает связный список
Понимание (или непонимание) написано 2-3 фразами (см выше), а вот реализация самой структуры займет сильно больше времени и при не покажет что человек понимает или нет, поскольку тут мы имеем написание код в стресовой ситуации, которой является собеседование.
2)
Решение, которое я привел — корректно. В моем понимании решение не корректно, если оно не работает
некорректность (тут и ранее это политкорректная замена слова «глупость»)
.
Если кандидат решил задачу несколькими способами, это хорошо
Если они все не эффективны, то не имеет значения. Особенно если учесть что решение «в лоб» — это один цикл с одной строкой.
Если кандидат решил задачу хотя бы одним способом, это уже значит, что он понимает, как работает связный список.
А если не решил, что тогда? (подсказку см выше)

1) По поводу того, проверяет ли такая задача понимание кандидатом принципа работы связного списка: если вы считаете, что нет, это лично ваше мнение, в пользу которого есть как аргументы, так и контраргументы. Оно субъективное. Как и мое.

2) Что значит не эффективны? В моем понимании решение не эффективно, если оно не решает задачу. Но данная задача, как я уже писал выше, нужна для того, чтобы проверить понимает ли человек, как работает связный список или нет. Для того, чтобы ее решить, можно применить несколько разных подходов. Решение циклом требует меньше памяти, но не настолько, чтобы это было критичным, зато по сравнению с двумя другими оно более громоздкое. Другими словами, у каждого решения есть свои преимущества. Если человек, который собеседует кандидата, делает акцент на том, что нужно написать код, который требует меньше памяти, это уже другое дело.

3) Если не решил даже после нескольких подсказок, я бы заключил, что человек не понимает, как работает связный список

4) Написание относительно сложного кода на собеседовании — стрессовая ситуация. По вашему мнению, давая кандидату такую задачу, нельзя проверить понимает кандидат или нет. И все же многие компании, среди которых есть и очень известные, практикуют это. Я думаю, что там лучше понимают, какие техники применять для того, чтобы нанять хорошего кандидата.

Решение циклом требует меньше памяти, но не настолько, чтобы это было критичным, зато по сравнению с двумя другими оно более громоздкое.
А напишите сюда код для этих решений, бо в моем мире решение циклом — это цикл в котором одна строка.
И все же многие компании, среди которых есть и очень известные, практикуют это. Я думаю, что там лучше понимают, какие техники применять для того, чтобы нанять хорошего кандидата.
А еще когда-то спрашивали про люки и количество заправок, ну им же виднее. А сейчас не спрашивают, но им сно ва же виднее. А нам зачем думать, давайте на них смотреть ведь им виднее. :)
Кстати, а в каких конторах спрашивают реверс связного списка и на какие позиции. Я с такой задачей стлкивался 2 раза, и оба раза конторы и собеседование были так себе.

хуже только «написать пузырьковую сортировку»
нормальные задачи давали в Амазоне и Майкрософт.

задачка должна быть несложной (максимум на час времени), иметь быстрое но тупое решение в «лоб», и более производительное но с использованием дополнительных структур данных (хэш таблицы, бинарное дерево или сортированный массив и тд)
а чему можно научиться , перевернув связный список или изобретая худший из алгоритмов сортировки? да и нафиг это не нужно в продакшн коде

которые не готовы брать кандидатов, не имеющих знаний на уровне первого курса университета (перевернуть связный список, распечатать все элементы дерева).
Допустим кандидат заучил ответ на этот вопрос, а на проекте не справился и не прошел ИС. Вы не получаете свой HR-бонус, тех-спецы получают по шапке, а кандидат получает стресс и +1 шаг к волчьему билету, может негативный отзыв о вас на DOU, компания остается без сотрудника и теряет деньги, кому стало лучше от вашей непримиримой позиции и упрямства?

К тому же немаловажно чем кандидат-будущий сотрудник потом будет в реале заниматься на проекте? Фиксить баги на JSP-ах и верстать? Ну или в базе ковыряться или бэкэнд делать. Просто я слабо представляю себе деятельность когда Java (не С/С++) программист постоянно переворачивает связный список и распечатывает элементы дерева.

В 2008м у меня в паре контор спрашивали, работал ли я с хранимыми процедурами (MySQL). Тогда я просто отвечал «нет». Позже, когда уже попробовал с ними работать, я задавался вопросом «а зачем вообще спрашивали». Ответа так и не знаю.

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

Спрашивайте о том, что написано в резюме, или на худой конец о том, что будет важно для конкретного проекта (если есть такая возможность).
Если в резюме нет, например, PL/SQL, то и спрашивать о нём ни к чему.

спросите как увеличить быстродействие поиска в базе
все возможные способы
чем больше знает кандидат тем лучше

я вам скажу чем старше (в плане опыта) разработчик, тем меньше он сталкивается с такими задачами как «перевернуть список» , поэтому я считаю они бесполезны при наеме синьоров и миддлов.... и уж тем более тимлидов

Вот почему такие статьи не пишут те люди, которые реально проводят интервью — сеньйоры, лиды, архитекторы, а кто-то другой не-программист с их слов?! Смысл совершенно теряется и вымывается.

Вот была статья —
dou.ua/...ical-interview

Тут абсолютно все пункты — это слова сеньйоров, лидов, прхитекторов, СТО.
Некоторые прямо цитатами, некоторые перписаны от 3-его лица, но самодеятельности.

сейчас бешеный спрос на Java-программистов, который превышает предложение в разы, и поэтому компании должны быть заинтересованы в мотивации и найме к себе
Ну да, на сайтах 100500 вакансий на senior которые не закрываются месяцами и 20 человек на вакансию junior.
Не стоит засиживаться на одном проекте более двух лет. Время не стоит на месте: технологии развиваются, появляются новые подходы в разработке. А если вы работаете над одним и тем же проектом на протяжении нескольких лет, то ваши знания устаревают и теряют ценность. И, в конечном счете, ваша рыночная стоимость как специалиста падает. Чтобы сменить проект, совсем не обязательно покидать нынешнюю IT-компанию: можно перейти на другой проект и внутри нее.

просто замкнутый круг какой-то:
если работаешь везде понемногу, то рекрутеры называют тебя «колобком» и говорят «Вы не надежны, посмотрите на свое резюме — нигде долго не задерживались. Интересно почему?» :)

а тут сами советуют раз в 2 года менять работу :)

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

С другой стороны проект может за 2 года настолько кардинально измениться...

дык колобок тот, кто несколько раз в год, а не раз в два года
в среднем раз год нормально считается

меня учили, что нормально это когда смена работы происходит раз в 3-5 лет.
если человек меняет работу на втором году или сразу после то вероятно что его дважды не повысили.
практика больших компаний: они не говорят «Вы уволены», а просто не делают обещанного повышения :)

По-моему, сейчас такой большой спрос на программистов, что HR’ы особо не смотрят на то, что человек проработал в одной компании меньше двух-трёх лет.

Так то оно так, но все рано или поздно заканчивается :(

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

или учили сильно давно и учение уже out of date, или учитель не знает реалий в нашей стране, если работать 3-5 лет, то в маленькой компании будешь получать 500 долларов, а потом через 4 года уйдешь на +2000, если клянчить повышение, то до 1500 можно дойти, а в большой фирме будет 1500 ну и соответственно уход на +1000

работая по году получится как-то так 500-1200-1800-2600

p.s.: возможно это справедливо не для всех фирм, но я знаю десяток именно таких и у многих из них известные имена

Все зависит от конечной цели.

В Вашем примере смена фирм происходит из-за денежного фактора.

Лично для себя рассматриваю такой вариант:
1. Пришел сразу на людские +/- деньги как готовый специалист.
2. Проработал 3-5 лет.
3. Получил директорское кресло (хоть подразделения) и зарплата удвоилась +% в пределах компании.

Так что каждый выбирает сам :)

1. Пришел сразу на людские +/- деньги как готовый специалист.
ну тут все одинаково или не пришел бы :)
2. Проработал 3-5 лет.
ну а вот это как-то неоднозначно, времена меняются, компании тоже, если все хорошо, то хоть 20 лет работать, но работать за Х, когда тебе предлагают рядом 2Х это себя презирать надо, я вот буквально воспринимаю: если мне платят ниже рынка, то и считают что я хуже среднего, это унизительно
3. Получил директорское кресло (хоть подразделения) и зарплата удвоилась +% в пределах компании.
удвоилась?) что за бред? если начальник подразделения это тимлид, то вероятно что зп может оказаться ниже синьорской, а не в 2 раза больше +%, тем более быть начальниками не все хотят, вот меня, например, вообще не интересует менеджерская карьерная лестница, я люблю программировать, а не командовать
ну тут все одинаково или не пришел бы :)
Я готовый специалист, а не джуниор на 600 юсд.
ну а вот это как-то неоднозначно, времена меняются, компании тоже, если все хорошо, то хоть 20 лет работать, но работать за Х, когда тебе предлагают рядом 2Х это себя презирать надо, я вот буквально воспринимаю: если мне платят ниже рынка, то и считают что я хуже среднего, это унизительно

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

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

Я писал о себе, а не о Вас.
Лично мне нравится командовать, а не подчиняться :)

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

Заранее напишу, что ещё не читал.

Но я негодую!
Почему такие статьи выходят уже после того, как я нашёл работу? Во второй рабочий день.

зато ты можешь подтвердить или опровергнуть выше сказанное

Я джун без опыта работы.

Первые собеседования начинал со чтения «типичных вопросов», однако на каждом следующем у меня спрашивали что-нибудь новое. Старался не медлить, и разобраться с этим в тот же вечер.

SQL — да, частое явление.
Самое неприятное — это задания в стиле «напиши программу на листике».

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

Самый же лучший совет, который можно дать тому, кто хочет научиться успешно проходить собеседования, это самому стать интервьюером. А если есть возможность и желание, то также и преподавателем Java.
Боже, спаси студентов от таких преподавателей :)

Не обязательно учить студентов. Например, я начал помогать товарищу учить Java. Когда объясняешь что-либо, приходится углубиться в это несколько сильнее, нежели когда учишься сам.

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

но про колекції і багатопоточність 100% запитають)))

Підписатись на коментарі