Nebo
Насчёт собеседований. Главное, чтобы человек не подводил в работе, был ответственным. Это главное.

Остальному можно быстро научиться.

Ну не совсем соглашусь, видал много ответственных, которых на милю нельзя допускать к проекту. В основном встречаются три типа:
1) Волк-одиночка, типа вади, который сделает, сделает быстро и это даже будет работать, правда никто не будет понимать как, и в следующий раз придется все переписать нафиг. А он будет ходить такой напыщенный и думать вот д..лы, я тут 1000 строк кода написал за два часа а эти сидят тупят. тут же все понятно и никаких оберток
2) Любители паттернов и новых технологий - когда говоришь вот это надо сделать здесь и сейчас,и вот так - да, код легаси но у нас нет времени рефакторить, потом попытаемся выбить время. Пишешь через день - а он тебе - ну вот я уже спринг поднял, лямбды почти прикрутил, ща еще ломбок впилю и начну. И не скажешь что человек нифига не делал:)
3) Ну тут просто днари - вместо того чтобы отрефакторить ко, напишут за пару часов тонну жаваскрипта и создадут 12 дао и тп. Просто потому что мыслят узко

XDiaBLoКстати у устных собеседований есть недостаток. Например спрашивают тебя про различия ArrayList и LinkedList, и ты говоришь что-нибудь общее, типа там скорость выборки, скорость вставки. А собеседующий тебе "не всё так однозначно, бла-бла-бла". Ну то есть и начинает уже сам лекцию толкать про те нюансы, которые ему кажутся важнее чем перечисленные собеседуемым. Какова цель этого? Указать что собеседуемый не весь параграф из учебника выучил? Нет, ну это может пригодиться на следующем собеседовании. Но зачастую рассказывают уже знакомую тебе информацию, которую просто от растерянности или нерасторопности не вспомнил, или не успел рассказать.

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

lor2забыл ник,

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

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

just_vladimirА можно ссылку на фрагмент javadoc?

Ну реально ведь бред:
lor2если хэши равны то иквалзы равны


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

maytonЕсть интересные вопросы не по спекам. Например сколько места занимает инстанциированный Object.
В основном это в контексте Memory optimization или структур данных. На этом этапе можно очень
четко видеть человек опытный или студент. Опытный может рассуждать вслух. Новичек
может просто пискнуть что-то типа мы этого не проходили и нам не задавали... парам-пам-пам.

Хоть я и в теме, номеня бы такие вопросы смутили(особенно вначале собеса), если в конце как потрепаться - то да, не вопрос. И еще - смотря кого вы ищете, рок-стар или рабочую лошадку

lor2как тебе такой вопрос:
String a = "a"
String b = new String("a")
String c = b;
и далее: a==b? b==a? c==a?
ну или такой вариант
Integer a = 0; Integer b = 0; a==b? a.equals(b)?

т.е. да, тут в принципе понятно всё. но у меня вопрос такой - а ты дибил у себя в проекте строки сравниваешь ==?

Ну не самый плохой вопрос. Я бы ожидал такого ответа - все объекты в java надо сранивать через equals потому то и потому. Приведенный код адовый, но я понимаю что он может встречаться в легаси проектах и поэтому я бы отрефакторил так и так. Ну и пару слов про Integer cache.

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

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

Leonid Kudryavtsevзабыл никНу так в том и дело, что врядли от вас требуют ответ там будет напечатано тру или фолс, это такой вопрос-зацепка, из которого можно легко и непринужденно выйти на другие темы типа иммутабл, иквалс и тд.
"Непринужденно" и собеседование о приеме на работу - вещи не совместимые. Собеседование для приходящего скорее всего стресс.

Т.ч. "выйти на другие темы" может закончится и не начавшись. IMHO & AFAIK

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

Возможно у человека, занимающимся приемом на работу, фантазии мало свое придумать IMHO & AFAIK. Какие вопросы первыми в Инет увидел, те и взял.

Да я не спорю, просто говорю что встречались и похуже. Например - в java все объекты наследуются от Object, это так? Назовите 2(!) исключения из этого правила :)