Ко мне в последнее время было много вопросов от Джава Джуниоров, запишу по памяти что отвечал:

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

У меня нет, а если бы и были то не дал. Это не честно, это всё равно что на экзамен прийти зная что за билеты.
Каждая компания старается задавать свои вопросы чтобы лучше узнать уровень соискателя. Они их придумывают, они не хотят чтобы эти вопросы другие знали, это их авторские права в конце концов.
Эта информация практически с грифом для служебного пользователя и не распространяется. Точно также как не распространяется информация о том какие грейды разработчиков (уровни Мидл, Синьёр) потому что в каждой компании разный уровень и по этой информации можно определить насколько в целом уровень профессионализма в ней.

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

Есть часть вопросов которые практически стандартные, и их легко найти в интернете.
Например: «Чем отличается абстрактный класс от интерфейса?»
И даже если вы ответите на этот вопрос, то его можно немного перефразировать или усложнить.
Например на вопрос «Чем List отличается от Set?» можно задать следующий вопрос «А почему Set не наследуется от List если он по сути похож, разве что не позволяет сохранять дубликаты?».
Ответ уже на этот вопрос потребует от вас именно полного понимания темы.

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

Большинство вопросов идут из сертификации OCJP их легко найти и есть книги для подготовки по теме.

Так что вопросы с реальных собеседований не выпрашивайте, это преступление и они всё равно вам особо не помогут.

А пример проектика?

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

Как правило, если это вакансия для веб разработчика, вас попросят написать простое CRUD приложение, например TODO лист с использованием БД.

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

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

Тут ещё такой момент: бывает что на тестовом задании ты где-то застрял. Например у тебя исключение какое-то и ты не можешь двигаться дальше. Т.е. ты в приницпе понимаешь как это сделать но вот конкретно в этом случае застрял. В таком случае абсолютно нормально спросить помощи у знакомого программиста\ментора.
Ещё это вполне нормально когда ты уже готовое тестовое задание покажешь ментору чтобы он проверил перед отправкой заказчику. Ты его уже написал, так что если кто-то тебе найдёт ошибку или подскажет как лучше и объяснит то от этого ты только умнее станешь а твой необходимый уровень знаний ты итак покажешь.
Это примерно как с курсовым проектом в университете — тебе может и помогли, но рассказывать всё равно придётся тебе самому. Но с курсачём тебе его главное сдать, а тут от твоих знаний будет зависеть реально чья то жизнь и бизнес.

Что учить?

Только то что востребовано на рынке и за что больше платят. Например, может Ruby on Rails или какой нибудь Python и кажутся вам самыми модными, но вакансий намного меньше чем на Java или PHP. А из Java и PHP больше платят за Java. Следовательно её и нужно учить (по крайней мере сегодня).

Походите по сайтам работы, посмотрите вакансии, почитайте в Википедии что за технологии там описаны. Зайдите на сайт indeed.com и посмотрите какие там тренды.

Что сегодня на рынке востребовано я точно не скажу. Что будет востребовано в будущем вообще никто точно сказать не может. Может новую версию PHP доведут до ума, а может все вообще перейдут на MPS.
Всё меняется, елси раньше Хибернет был «маст хэв» то сегодня уже, насколько я могу судить, работодатели уже интересуются знанием NoSQL баз данных, в частности MongoDB. А Hibernate им уже может быть не принципиально.

На сегодняшний день в принципе ещё актуальная моя старая статья. Её может и стоит переписать или дополнить, но в целом там описывается подход по которому вы сможете немного сориентироваться на рынке, а он не меняется.

1) Какими веб технологиями должен обладать хороший программист на Java? Sping, JDBC, Hibernate? Что еще? Есть ли смысл читать книги по этим технологиям или хватает спецификации / туториалов?

Точно нужно вникнуть в базовые технологии. Если с БД то в Java вы не опуститесь ниже JDBC, если делайте веб то ниже уровня JSP и Servlets вы не уйдёте. Поэтому с ними нужно точно разобраться. Поэтому может быть лучше вместо знаний Hibernate и Spring вникнуть в базовые JDBC и Servlets.
Скорее всего вас будут их спрашивать. Но тем не менее Хайбернейт и Спринг нужно тоже как минимум потрогать чтобы знать что это и куда его пихать.
Есть ли смысл читать книги — да. В книгах обычно пишут почему спроектированно именно так, т.е. передают некую инженерную мудрость которая намного ценнее чем даже знание самой технологии. Вы можете прочесть книгу по Спрингу и применить знания если вы нашли работу в ASP.NET где те же самые контроллеры.
Поэтому одна из самых важных книг по Джаве так и называется — Философия Java.

Туториалы нужны для того чтобы быстро и пошагово развернуть у себя проект с их использованием и чтобы вы могли сами прощупать как это делается. Это тоже важно — это мышечная память, без этого знания не зафиксируются в голове.
Вот недавно был выпуск подкаста Разбор полётов где как раз гуру давали рекомендации. И смысл такой: знаний Спринга у тебя может и не быть, это нормально для джуна, даже было бы удивительно если бы они были.
Но фундаментальные знания которые написаны в книгах у тебя должны быть, потому что интервьюверы хотят прежде всего понять насколько ты вообще обучаемый.
Если ты не смог прочесть и понять книжку, то как же ты будешь разбираться с кодом на работе?
Некий мифический параметр «Обучаемость» это то что они хотят вычислить прежде всего. Но это практически только интуитивно можно определить.
Есть и другие параметры, например знание конкретной технологии. Например работа на которую тебя рассматривают требуют чтобы ты занимался больше фронтендом и нужно там разобраться с CSS3 и HTML5. Может даже быть что в той команде никто их не знает толком и ты как джун там будешь их же обучать.
Я знаю такой реальный случай, там даже было неловко тимлиду который собеседовал джуна потому что он не знал что спрашивать по CSS3 (как там анимации делать, например), потому что он сам не знал, но на проект такой человек был нужен.
Ты может даже не очень обучаем и тебе сложнее въезжать в тему, но зато ты очень прилежный и исполнительный. И тебя могут взять вместо другого более «обучаемого» и опытного джуна. Или ты может просто прикольный весельчак и тебя возьмут разбавить команду нердов. Знаю случай когда девочку взяли в команду из девяти пацанов чтобы они хоть бриться начали 🙂

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

2) Посоветуйте литературу по архитектуре / паттернам. По паттернам читал книгу headfirst, но она, видимо, не очень глубоко описывает все. Есть ли альтернатива банде четырех не с кодом на С++?

Тут сразу нужно разделить два понятия: ты либо имеешь опыт программирования на других языках, например ПХП, а теперь учишь Джаву либо ты вообще студент и толкового опыта программирования у тебя нет.
В первом случае, тебе лучше взять книгу по языку программирования который ты лучше знаешь, просто ищешь по запросу, например «Шаблоны проектирования в PHP». И вникаешь на одном языке.
Паттерны практически не зависимы от языка программирования, поэтому главное понять их суть, а там уже на Джаве напишешь и сам. Но опять таки, половина шаблонов проектирования нафиг не не нужны в функциональных языках программирования где всё делается простой кложурой

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

Опять таки, для базовых ООП языков C++, Java, C# и даже PHP реализации шаблонов будут одинаковы. Но в отличии от PHP в Java все вообще представлено объектами и в ней без шаблонов не выжить.

Изначально само понятие «паттерны проектирования» и их классификацию ввели GoF в своей книге. Соответственно те шаблоны которые они в ней описали называют «паттерны по Гофу».
Просто потом всем так понравилось понятие паттернов что каждый поупражнялся в интеллекте и напридумали ещё потом тысячу других паттернов и даже антипаттернов.
Но больше ничем примечательным их книга не отличается — ни доступностью материала, ни даже полнотой. Именно поэтому есть более поздние книги где лучше разжёвано с большим числом примеров и с конкретными особенностями платформы.
Иногда может хватить статьи на Хабре, благо их валом.
Лично мне ещё было проще: мне мой ментор сказал «ну вот помнишь как Xml парсер ты создаёшь? Ну вот, это абстрактная фабрика» или «ну вот тебе нужно получить неизменяемый List, для этого есть метод Collections.unmodifableList(myList) который вернёт тебе декоратор myList с скопироваными элементами который на самом деле будет подклассом UnmodifableArrayList с заглушками на методы add() и remove(). Но это от тебя скрыто за методом unmodifableList() и тебя вообщем и не интересует какой там класс реально будет.».
И всё стало сразу мне понятно: «Тю, так я эти шаблоны постоянно использовал! Просто не знал что у них есть названия».
Вот в том и смысл: шаблоны, точно также как и рефакторинги — это классификация для программистов чтобы им было проще общаться между собой: «Слушай, а давай здесь выделим интерфейс и сделаем фабрику?».
Поэтому вся ценность паттернов — это то знают ли их. А все остальные шаблоны можно смело выкидывать потому что пользы от них нет. Это обычные структурные конструкции которых может быть безграничное количество и смысла им давать свои имена нет.
Поэтому когда говорим паттерн — подразумеваем паттерны ГоФ, и то только ту часть что используем.

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

Поэтому отнеситесь к книге Head First как к комиксу «как сделать коронарное шунтирование сердца».

А вот что намного важнее понять, это когда именно нужно применять и какой именно шаблон. К этому можно только прийти постепенно изменяя код с помощью рефакторинга.
И соответственно самые лучшие книжки про шаблоны проектирования — это книжки не про паттерны, а про рефакторинг.
Я уже повторял неоднократно и не постесняюсь ещё раз повторить, что лучшая книга для того чтобы разобраться как лучше проектировать архитектуру, писать код, писать тесты, и сопровождать его, это бестселлер Матрина Фаулера «Рефакторинг — улучшение существующего кода».

Более полезной, монументальной, теоретической и практической одновременно книги я ещё не видел. Она сразу выводит на новый уровень профессионального мышления.
Даже нет смысла искать работу пока вы её не прочли и не осознали.

Для чуть опытных программистов есть более продвинутая книга Джошуа Кириевски которая так и называется Refactoring to Patterns. Я её сам правда как-то так и не прочёл, но все знакомые кто читал были в восторге.

А вообще я не понимаю почему джуны так сильно зацикливаются на паттернах. И зачем их спрашивают на интервью. Когда я искал себе работу и меня спрашивали по шаблонам то вопрос звучал примерно так «расскажи хоть какой нибудь шаблон». И я просто заучил их и по очереди называл их названия всех 23х шаблонов. И каждый раз интервьюеры офигевали «ого, это их столько? А можешь хоть один объяснить». И я рассказывал про один из трёх которые я реально понял. Интервьюер как правило знал столько же.

Я так понимаю что это связано с тем что вокруг шаблонов некий ореол «проектирования» которое якобы их делает чем то таким научным и теоретическим. Как будто их знание делает тебя умнее тех быдлокодеров унтерменшей.

Поэтому у нас есть такие наумняченные программисты которые могут отличить Прокси от Декоратора, а при этом не знают комбинацию клавиш в IDE для форматирования когда.

Так что вы поймите хоть парочку шаблонов, желательно из разных групп, например структурный — Декоратор, creational — Singleton и behavioral — Observer. Это реально, остальные просто знайте что есть. Для джуна это нормально.

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

У меня тоже впечатление, но это впечатление. Тут довольно сложная и большая тема возникает о самом формате обучения, у меня по этому поводу очень много мыслей но не все ещё сформулировал для себя. Если в двух словах то примерно такие мысли:
* Курсера — это всё таки курсы солидных унверситетов, это уже вызывает доверие. Это годами отработанные обучающие материалы, и они там не зря. Зарплаты преподавателей огромны, и это люди как правило имеющие отношение к реальной индустрии.
* Качество курсов от чуть ниже нормального до хорошего. Отлично сделать практически невозможно, всегда будет какая-то вода, всегда будут недостаточно хорошие примеры. Всегда может быть по теме более интересная книга или туториал на ютубе, всегда можно найти чувака который лучше расскажет, но на курсе всегда будет некая усреднённая доведённая до занудства «академичная» информация.
* Что ещё важно там есть вопросы для самопроверки и определённая сертификация. Это очень важно, а просто книга такого не даст.

Всё. Больше никаких особо преимуществ нет и быть не может. На курсере невозможно получить практическую пользу и интерес большую чем от реального проекта или видео на ютубе.
Это всё равно что сравнивать статью в Википедии и статью на Хабре.
Но если взять статью на хабре и дописать к ней то что в ней опустили, и убрать то что может меняться со временем, попытаться вывести из материала какие-то общие законы и убрать субъективный и упрощённый научно-популярный стиль, то получится та же статья с Википедии.
Например, вот одна из самых первых статьей про Юнит тестирование за 2008й год к тому моменту это уже докатилось до нас и было отхоливорено со всех сторон и эта статья была подведением черты.
А вот какая статья в Википедии на сегодня.
А вот все курсы на Курсере где тебя обучат рефакторингу.

Например я бы мог в сто раз лучше базы данных чем на курсере, но я бы два года составлял курс прорабатывая материал, отбирая что важно что не важно, прийдя к выводу что всё важно, тестируя эффективность на студентах и он бы у меня разросся в пять раз больше и я бы стал его сокращать а на выходе получилось бы почти тоже самое что сейчас на курсе Introduction to Databases.

Нужно чётко осознать важный закон: кто не знает, но умеет — делает, кто знает, но не умеет — учит, кто не знает и не умеет — руководит.

Почти все учёные и преподаватели в вузах себя считают теоретиками и почти вся их суть в этом видео

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

Но где же найти тех кто реально шарит, и рассказать может хорошо и правильно, и самый свежий опыт?
Собственно мы программисты постоянно и много обучаемся, поэтому уже всё сформировали для себя:
* Блоги, правки в документации, меил листы, форумы, StackOverflow, скринкасты, туториалы, и напрямую чтение спецификаций. Написать более менее толковую развёрнутую статью занимает ну просто дофигища времени, сколько точно не знаю, зависит, но четыре часа минимум. А теперь представь что ты синьйор с загруженным графиком, у тебя семья, как ты выдыхаешься и при этом найти время и силы написать статью. А потом ещё переругаться с тролями в каментах.
* Конференции с докладами по часу-два с презентацией или мастер классом с живым кодированием. На подготовку одного часового доклада может уйти почти столько же времени как на статью, но, статью нужно писать и это напрягает, а презентацию к докладу накидывать как-то намного приятнее и там рассказывать можно голосом по ходу подстраиваясь под публику.
* Книги, программисты читают много их.

Итак, наиболее эффективными и ценными являются именно конференции с докладами. Там можно получить самый свежий опыт, и даже зачастую от самих создателей технологии.
Там же разворачиваются самые интересные дискуссии.
Но проблема в том, что как правило новичкам это совсем не подходит, это наиболее ценно для мидлов.
Рассказывать какие-то основы для джунов им не интересно. Это всё равно что если Шекспира попросить стать учителем английского. Да он сам создавал этот английский.

Так что пока вы джуны и вы учитесь, вам просто придётся всё время искать самим хорошую информацию по кускам и смирится что та полная что есть «академическая» скучная и с множеством воды. И постоянно искать себе менторов и спрашивать у них что нужно именно на практике. На примере шаблонов я это показал. Ваша задача — как можно быстрее устроится на работу, а там уже будет точно видно что нужно а что нет.

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

Я сам почти не проходил никаких курсов на Курсере (где же взять 8 недель на это?), но из того что видел считаю самым полезным и вменяемым курс основам вычтехники The Hardware/Software Interface. Тут вам расскажут как работает булева алгебра, как устроен компьютер, как считаются и складываются числа внутри, что такое указатели, освоите основы Си и перейдёте к высокоуровневым языкам. При этом это полноценный курс с множеством классных заданий.
Это очень и очень правильный курс который закрывает огромный пробел знаний и почти полностью имеет практическую пользу. Всё остальное что на курсере по компьютерам, имхо можно выкинуть нафиг. Разве что по алгоритмам может адекватный курс, но не смотрел.

4) Хочу начать делать какой-то пет проект, но не очень представляю с чего приступить.

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

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

Могу дополнить только что у вас должна быть личная мотивация и интерес сделать проект. А такое может быть только если вы делаете программу для себя.
Например мой знакомый когда учил английский сделал себе программу под 1С с тестом слов. Потом когда он учил Джаву он себе написал фотовьювер как ему нравился.
Напиши любую программу например свой броузер. Джаст фор фан, пофигу что такое уже есть. А вдруг в твоей программе будет (или не будет) такой функционал который кому-то нужен. Твоя программа может найти своего пользователя и вырасти в полноценный продукт, как это было например с операционной системой Linux которую написал школьник а теперь используется многомиллиардными корпорациями.

Тут я могу ещё посоветовать не зацикливаться на технологиях. Просто некоторые начинают: о блин, мне тут нужно всё делать со Спрингом и Хибернейтом потому что их требуют при устройстве на работу. Забей. Сделай просто для себя программу на чём сможешь. Опять таки, парень который написал себе фотовьювер потом прошёл туториал по спрингу и нашёл себе работу.

Очень часто ещё часто советуют поконтрибьютить в опенсорс. Из моего опыта — идея никакая.
В опен сорс проектах человек который его ведёт всё таки должен разбираться в коде который ему присылают, и все хотят как правило чтобы контрибьютили уже опытные разработчики.
Так что например законтрибьютить в Друпал тебе никто не даст, потому что ты скорее всего напишешь никому не нужную плохо написанную фигню.
Примитивной работы, где много чего-то которое нужно однотипно переписать, на опен сорсе практически мало, потому что хорошие программисты потому и хорошие что пытаются писать код без дублирования.
Можно чисто теоретически найти проект где ребята вашего уровня пишут, но тогда чему вы там научитесь? Хотя если интересы совпадают — делайте.

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

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

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

Что реально ещё работает: у Гугла есть программа Summer of Code и в её рамках можно поконрибьютить в опенсорс проекте под присмотром менторов. Опенсорс проекты готовят задачи для студентов и вместе их фигачат.
Вот например есть интересная программа для чата и онлайн звонков Jitsi и её страница с идеями для GSoC.
Задачи довольно интересные и в меру сложные.

5) Посоветуйте проекты с открытым кодом на Java, чтобы посмотреть как строиться архитектура и тд.

Опять таки, берите проект с плагинами и пишите свой плагин. А так, я не знаю что посоветовать, но есть например книга The Architecture of Open Source Applications и в ней же есть и описание тай же Jisti.
Вот посмотри исходники проектов из этой книги.

6) Как вы совмещаете изучение теории и практики? Предпочитаете читать только то, что в данный момент необходимо или же изучаете наперед?

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

P.S. Статью написал под эту песню

---

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