Почему технические собеседования не нужны

Ремарка - речь пойдет о 98% собеседований в постсоветском пространстве на позицию Java Developer. 

Начну вот с чего: знание Collections Framework, его иерархии наследования, внутренней работы HashMap и количества примитивов в языке - никак, совсем никак, не может дать представления о работоспособности человека. 

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

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

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

1. Работа разработчика состоит из 40% кодинга и 60% рассуждений, размышлений и попыток понять и вместить задачу, выбрать оптимальный алгоритм ее решения. И я не говорю о созвонах, декомпозиции и обсуждении предстоящего спринта и т.д. и т.п. В таком случае кодинга остается процентов 20.

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

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

Теперь немного подробнее. Первый и второй пункт очень тесно взаимосвязаны друг с другом: часто приходится уточнять нюансы и задачи у тестировщиков, заказчика, аналитика… И я надеюсь никто не будет спорить, что пресловутые Soft Skills, умение задавать вопросы, понимать другого человека - очень сильно помогают осознать что именно ждут от вас и какой итог хотят видеть от проделанной работы. И в процессе осознания задачи и декомпозиции ее на подзадачи участвует много людей, как правило. А тот момент, когда вы останетесь с задачей один на один и приступаете к выбору инструментов ее решения наступает после длительного мыслительного процесса и процесса взаимосвязи между членами команды.

 - БАНАЛЬНО, это все и так зна…

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

Но в тот момент, когда мы остались с задачей наедине, код не начинает тут же появляться в нашей IDE. Конечно нет, даже тут приходится брать ручку или фломастер и рисовать диаграммы взаимодействия тех классов и методов, которые мы собираемся написать. В этот момент приходит осознание, как лучше реализовать бизнес логику, может быть правильнее потратить время на SQL запрос, или обработать данные в коде, стоит ли тут использовать наследование или композицию и т.д и т.п. И так, шаг за шагом, мы разматываем клубок и понимаем нюансы задачи и пазл собирается в картину. И даже тут старший товарищ, заметив ошибку, может невольно подвести вас к тому, что все рассуждения неверны, по типу ”””тут надо использовать HashTable, потому что она намного лучше и круче и вообще молодежнее, чем HashMap (Шелдон с табличкой --САРКАЗМ--)”””

Если мы сильно упростим и разделим наши вопросы на две категории, то это будут вопросы об ошибках и неточностях в бизнес-логике, которые, как правило, нужно обсуждать коллективно. И вопросы, которые стоит сначала погуглить, поискать решения, попробовать реализовать самому, а потом просить помощи (это я говорю сам себе, простите меня все, с кем я работал и не следовал этому важному правилу). Да, тут тоже уходит так много времени, совсем не на кодинг. Во всём этом ПРОЦЕССЕ знание языка и стандартной библиотеки, с которой он поставляется - далеко не на первом месте!

Конечно, я не имею в виду, что мы не должны этого знать. Но на 8-ми собеседованиях из 10-ти так и подмывает задать вопрос: «А вы-то сами имеете опыт работы с многопоточностью? Вы это спрашиваете, потому что на проекте приходится работать с этим?» Но ты молчишь и отвечаешь на вопросы о разнице между мониторами, мьютексами и радиоволнами...

Критикуешь - предлагай. Предлагаю: Давайте возьмем реальную бизнес-задачу и попросим человека рассказать, как бы он работал над ней. Послушаем какие вопросы он задает, как работает его мышление. На какие подзадачи он разобьет свое решение и почему? Если он на чем-то стопорнулся, спросим его, а чтобы он загуглил (да-да, почему на собеседованиях делают вид, что гугл взорвался, а stackoverflow теперь только на Иврите? Такого вопроса я вообще ни разу не слышал)? Если кандидат не знает ответа, как бы он его искал? Почему в одном случае стоит обратиться к коллеге, а в другом к строке поиска. Думаю многие понимают, что дает такое общение, оно показывает какими паттернами мыслит кандидат, где проявляет гибкость и какие задачи решает лучше всего. И конечно, когда речь зайдет о выборе инструмента, мы можем углубиться в знание этого инструмента и наконец задать вопрос, какие методы содержит класс Object и почему гораздо круче использовать три вложенных цикла и милкшейк, вместо Stream API.

Спасибо за ваше время, пожалуйста напишите почему я не прав и в чем разница между Spring и Spring Boot.