Правильно сказали, что 1-я и 3-я, 2-я и 4-я похожи. Не сделали только следующий шаг. Есть и 5-я, и 6-я ступень и т.д. Та самая пресловутая спираль развития.

Помню когда стал круто писать на C, то далее пошел на C++, потом Java аж бета-версии (менее 1.0), Java 2, J2EE, Java 5,… и понеслось. Где-то по дороге появился JavaScript, Groovy. Считать ли язык для Maven, Ansible, Ant языком? А bash, а bat файлы? И это не считая Fortran из института, Pascal оттуда же, Basic из школы, Delphi и VB. И совсем экзотику — Prolog. Считать, что это 4-ый уровень? В теории да. Вопрос лишь на каком уровне спирали. :-)

Ну, здравствуйте, коллега! Мой факультет, моя кафедра, специальность у меня правда видимо со старым значением: «Вычислительные машины, комплексы, системы и сети»

Конечно, разница, между нами лет этак 20 и многое изменилось. Я считаю, что в то время МИЭТ дал мне очень хорошую базу. Как инженерную, включая и железо, и ПО, так и научную с желанием проводить исследования и докапываться до истины. Все это пригодилось. С т.з. языков программирования Фортран, Паскаль и C. Про ассемблеры просто умолчу. Был еще Пролог. При этом как Вы понимаете, наша специальность скорее железячная, чем программная. Тогда объектно-ориентированные языки только появлялись. Сам учил C++, программируя на Turbo Vision, потом OWL, чуть позже на MFC. Работу после окончания нашел легко. Уже там учил SQL и как ни странно VB :-) В 1996 познакомился с Java, но не профессионально. Кажется это еще была 0.9. Профессионально на Java стал программировать с 2003 потихоньку изучая ее по мере выхода библиотек.

Это я все к чему? Я не уверен, что высшее образование должно давать узкоспециализированные знания. Все же у каждого свой путь в профессии. Мне кажется, что узкая специализация — это индусский подход. Это уровень не выше техникума. Именно широта и база позволяет мыслить и находить оригинальные решения вне рамок узкой специализации. Здесь скорее важно, чтобы образование сильно не отставало от жизни. Например, сейчас нет смысла учить Фортран, а ООП просто должно быть обязательным. И конечно, в идеале, преподаватель по программированию должен быть скорее программистом, чем академиком.

Какой факультет в МИЭТе Вы заканчивали и какую специальность?

Можно. И не нужно извиняться. Вы знаете я работал в разных отраслях и знания о внутренностях Java всегда помогали. Особенно там, где крайне важно быстродействие системы.Я не сказал, что «каждому программисту в моей команде» нужны такие знания. У меня хорошая команда и там есть программеры разного уровня. Я лишь сказал, что такого рода знания помогают писать программы лучше, качественнее и не делать детских ошибок. Это общий мой подход. Если ты используешь какую-то библиотеку, framework, то почитай документацию, а потом посмотри как он/она устроен(а). Я считаю, что это правильно и профессионально. Благо в Java практически все исходники открыты. Обычно этот код пишут и вылизывают досконально и чтение такого рода исходников отличный способ повысить свой профессионализм. У меня всегда в IDE подключены исходники jar-ников, а при отсутствии таковых — декомпилятор. Если возвращаться к исходной дискуссии, то меня крайне удивляет бравирование части хабровцев отсутствием знаний в элементарных вещах Computer Science, которое выдается как «крутой профессионализм». Для меня это верх идиотизма.

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

Есть, но только в промышленности они не используются. Пришлите мне реализацию HashMap, кардинально отличающуся от Сана-оракловой?

Может, если мы используем EnumMap, тыкаться каждый раз get'ом в цикле будет нормальной идеей?

Да ладно? ;-) Т.е. доступ по ref (итерация по keySet) + доступ по idx (массив) лучше чем просто доступ по ref (итерация по entrySet)?

наличие вкуса и умение читать документацию важнее заучивания наизусть кишок оракловой реализации

Эх! Почитали бы исходный код, тогда бы увидели, что HashMap и EnumMap на одном абстрактном классе построены. А если бы посмотрели как реализован ConcurrentHashMap поняли бы, что такую высококлассную реализацию мог сделать только человек, реально знающий «кишки» виртуальной машины в части синхронизации.

А можно я изучу исходный код JIT

Нужно. Это уже высший класс. И если мне на собеседовании вы расскажете, что JIT компилятор сделает так, что в случае EnumMap «тыкаться get-ом в цикле» быстрее, то это будет оценено по верхнему уровню.

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

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

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

Спишу Ваш вопрос на то, что Вы не Java разработчик.В противном случае — это очень грустно. Реализация HashMap в Java не меняется лет этак 15. Это по поводу «для конкретной JDK». Всякие улучшайзеры, например generics, я не беру в расчет. Конечно, замена на TreeMap в данной задаче итерирования не станет верным. Надо знать, что итерироваться необходимо по entrySet и что это быстрее вне зависимости от TreeMap или HashMap, чем итерироваться по keySet c дальнейшем запросом value через get(). А вот почему быстрее — вы сможете узнать, когда, например, хотя бы один раз заглянете в исходный код этих мапов, т.е. изучив структуру хранения.

Так некоторые не утруждают себя даже тем, чтобы заучить «строчки из википедии». :-) А подумать «на камеру» у всех будет шанс. У меня заковыристых задач в голове достаточно.

:-)))

Отличный анализ. Именно этого я и жду от разработчиков. Если коротко: «Знать, думать и делать»

Не льстите себе. :-)

Анекдот:
Стюардесса после тряски говорит: «Ну что вы так разволновались? Это обычная турбулентность. Спокойно. Успокаиваемся. Все? Нормально? Капитан? Первый пилот? Молодцы. Пойду успокою пассажиров.»

Так вот я никого по головке гладить не буду. Детский сад на прогулке закончился. Взрослая жизнь трудна и сурова.

У меня не бывает. Я их на работу не беру, но они приходят и нудят, что они все таки сеньёры, что не могут bubble sort написать. :-)

А вот говорят сложно… :-)

Вообще мой посыл в другом. Даже создатель бизнес приложений из кирпичиков должен понимать, что он делает. Если он делает кирпичиками получение сущности из базы данных, то должен знать, что это запрос в базу данных и вероятно по некоторым полям надо построить индекс. Что если ты делаешь ThreadPool из 10 потоков и видишь, что очередь растет, то надо подумать об увеличении кол-ва потоков. Если ты делаешь постоянные вставки в середину списка, то ArrayList не лучшее решение и т.д.

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

bubble sort? Не?

Если hello world запрограммировал, то уже программист. :-)

С каких это пор факториал или пузырек стал сложным алгоритмом? :-)

Базовые — сортировка, поиск, вычисление hash-а.
Базовые структуры — связанный список, хеш таблица, очередь, стек.

Далее по опыту и по резюме.

это к HR. А ко мне на техническое интервью апосля.

Это уже за деньги. :-) Ты просил

напишете пузырек тут в каментах — может и поверю ;)

Я написал. Теперь твой ход — верь. Договор дороже денег.