Набирая It-специалистов для решения разного рода задач, компании или департаменты стараются брать от middle и выше, казалось бы, это удобно. Вот придёт такой человек в компанию, рассказали о структуре - он вник в структуру, разъяснили как коммуницировать - коммуницирует, описали задачу - сразу приступит к работе над своим блоком и решает. В том числе и все имеющиеся подзадачи - закрывает, и кампания (департамент / компания) идет семимильными шагами к релизу продукта. А потом?! Но где их набраться, таких специалистов, которые сразу станут не только "пломбировочным материалом в дырах проекта", но и в дальнейшем станут заниматься развитием проекта!? На такие задачи есть HR-мудрецы!, - скажете Вы. Да. Они могут найти решение, но им заявку кто подаёт?! Тот кому нужны ответы на вопросы: Сможешь? - Смогу. Как..? - Вот так. Ок, берём. В последствии получаем результаты нечитаемости кода, решает только узкий круг задач, не вникает в проект целиком и подобное... Кейсовое мышление, привело к узко мыслящим специалистам. Разносторонние интересы = ширина взглядов. Программисты народ логичный и когда возникает задача - её начинают решать привычным способом, а именно - путем наименьшего сопротивления. То есть, взять в команду сильного специалиста: со знанием необходимых библиотек и умением применять их в проектах. а точнее сказать, применяемых в данном проекте, который одобряет своими знаниями ведущий команды (TeamLead). начинается приращивание со своими знаниями собеседуемого, который имеет своё мнение, но плюшки от компании ему нравятся, и он надеясь что изменится, иногда подавляет "истинного себя", рассказывает о "новом себе" которым даже не хотел быть, а то что хочет услышать собеседник. Далее примерно так: одобрение персонажа, которого как правило долго ищут (что влияет на сроки реализации задачи); ещё бывает что спец - дороже чем планировали (и это я сейчас не бОльшей сумме за его умения, а о том что спец "дешевле" чем предлагают; хотя и другие варианты есть, но я не про это.` Берём junior специалиста. И именно специалиста - Да он спец, просто без опыта. Страх, что он будет тянуть кампанию вниз или замедлять её работу - оставьте блогерам, это их "хлеб". Важно! - берём такого, который уверен, что выбрал для себя правильный путь развития, сферу деятельности, тут как раз HR-магия выявить такого поможет, они это хорошо умеют делать (если они не случайные люди в этой важной профессии). Когда этот профессионал Junior (ProfiJun) к ИТ плюсом имеет опыт не смежной работы, а увлечения из совсем другой сферы, то это клад. Такой знает, чего хочет, какую науку двигать и понять её хочет, он знает теорию и не обременён опытом стереотипов. Он не специалист, который ничего больше не знает - кроме как кодить и мыслить математикой (кстати, это очень неплохо), а но как и Ломоносов, и Кулибин, и Королев, и Калашников и многие другие, у него нет предобученного отношения к решению задач, у него ещё нет своей стилистики. Но у него уже горит пламя идеей внести весомый вклад в дело, надо себя показать. Вот он и нужен. А если для начала его энергию пустить в другое русло, Он больше напоминает чистый проверочный код JuniORtestCode. И вот уже не так печально выглядит начинающий, ведь начинающий - это человек, который придёт к вам в команду с новым взглядом, ведь он может дать новый вариант решения. Очень важно, чтобы ему верно объяснили задачу, саму идею проекта и дали возможность нарисовать её в голове. Наверняка, знаете историю с изобретением матового света, когда специалисты знали, что это невозможно, а новичок просто взял и сделал… Не рассказать ему, как вы (команда) пришли к тому что есть, а рассказать идею, которую реализуете. Не загромождать его голову всеми этапами в хронологическом порядке с самого начала проекта, когда высказывали различные мнения и "лучшие" мнения, остались в голове у каждого в группе. Особенно полезна роль Junior-а будет в группе, если он приходит не в самом начале проекта, а в середине проекта и для того, чтобы ему начать работать над проектом, ему нужно изучить имеющийся материал. А именно всё, что написано ранее: инструкции, документацию процессов, к этому нужно установить на свой новый П.К. какие-то программы, нужно запустить какие-то тесты и человек как конечный пользователь, но только имея опыт программирование, в отличии от конечного пользователя, начинает разбираться в программе как более продвинутый, глубоко понимающий пользователь и, видя какие-то нестыковки, начинается. Сообщать об этом своему наставнику / куратору. И вот тут его «свежий взгляд» и отсутствие «установок от команды» принесут огромную пользу. Вот здесь, на мой взгляд, лучше письменно декларировать поток мыслей, это позволит и опытному специалисту прочитав, осмыслить, взглянуть со своей точки зрения на то, что увидел junior, как специалист другого уровня. Вы ведь тоже когда-то были начинающими. Junior разработчик – эдакий специалист-критик, но не тот, который говорит: "Всё плохо, надо по-другому", а на вопрос "Как?" - отвечает: "Вы спецы вам и думать", опуская уровень духа кампании. А вот именно тот критик, который предлагает иные варианты, своего видения, решения имеющихся задач, своим взглядом созидателя, инженера, творца. Можно поругать... Можно покритиковать... Можно воспользоваться! Вам решать. Этот пост с надеждой на качественный рост. Всех компаний и профессионалов. Успехов всем нам!  Data Scientist (Deep Learning)