Как перестать огорчаться на коллег и полюбить собеседования

Публикации Коллеги вы меня огорчаете, Коллеги, вы и меня огорчаете. Тоже и Не нужно делать из фреймворков культ — они не настолько сложны, чтобы делить людей на React и Angular разработчиков в очередной раз привели к холиварам о собеседовании. По моему мнению участники этих батлов, а также собеседующие и собеседуемые упускают одну вещь о которой я хотел бы поговорить в этом посте.

Для начала ответим на вопрос как мы представляем себе джуниор разработчика? Если мы пойдем по классический стезе университетского образования, то это молодой специалист, недавно окончивший факультет компьютерных наук в N-ском университете. С одной стороны он не имеет много опыта, с другой обучаясь по адекватной программе он уже имеет и не так уж мало знаний: он разбирается в алгоритмах, их сложности и корректности, хорошо знаком с высшей математикой, знает устройство операционных систем, баз данных, компиляторов, разворачивает односвязный список не приходя в сознание и многое другое. Не сказать что у него много опыта, но тем не менее он тренировался решая задачи, делая лабораторные работы и даже сделал дипломный проект. Он конечно не построит идеальную архитектуру или сверхпроизводительный веб-сервер, но он уже вполне может решать боевые задачи, добиваясь конкретного результата. Если рассмотрим такой вот вполне классический образ успешного выпускника, то мы будем вынуждены признать, что есть люди (некоторые из которых даже читают хабр и даже пишут комментарии), которые нацепили сеньорские лычки, хотя с трудом дотягивают до такого джуниора. С другой стороны они успешно работают и даже получают за это зарплату. В чем же дело?

Что бы ответить на этот вопрос, отправимся в страну метафор и гипербол. Представим себе обычно такого мужичка Васю, преимущественно трезвый образ жизни которого делает его первым парнем на деревне. Наш Вася двадцать лет назад стал счастливым обладателем своих десяти соток и как рачительный хозяин построил там домик. Если кто забыл как строили частные дома двадцать лет назад, то я на помню: в земле вырывались неглубокая траншея под фундамент, ставилась опалубка, заливался бетон, сверху как конструктор собирался сруб из не струганного бруса (другого то и не было), отстаивалось, из досок сколачивались полы и конструкция крыши, клался шифер и самодельные окна из стекла, потыренного с пилорамы, плюс утепление паклей и наведение марафета штукатуркой и побелкой. Ничего из это не требовало высоких технологий и достаточно было иметь только прямые руки. Потом наш Вася построил ещё дом богатому соседу, ещё одному, да так и начал строить домики. Но вот в один прекрасный момент все желающие в его деревне одомашнились и Васе пришлось так сказать выходить из зоны комфорта (то есть ехать в город). Городской кум послушав, про огромный опыт Васи в строительстве, радостно говорит: "Иди в "Default-city Incorparation, там уже полгода не могут найти человека на позицию Senior Building Developer". Далее дадим слово самому Васе и пусть он поведает нам о прошедшем собеседовании:

- Ну пришел я к ним, сидят два очкарика, хоть и бородатые, но додики додиками, с виду никогда стамески в руках не держали. Ну они меня и спрашивают, по каким-таким методикам проектирования вы работаете, знакомы ли вы с BIM. Ну я подвох сразу чую, говорю какой VIM, он же только бибикает и все портит, а методика у нас одна: сборка трезвым. Они моей твердости в этом вопросе подивились, видно дисциплина у них в конторе хромате, и спрашивают, а каким CAD вы пользуетесь, ну я говорю, Я по ММК приехал, а в чём дело. Ну как-то у нас разговор затих, мы и разошлись.

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

Собственно все тоже самое мы можем увидеть и вайти: разработчики это уже давно не убелённые постдоки, оптимизирующие алгоритм на уровне ассемблера и рассуждающие о воплощении платоновских эйдосов в пентамино тетриса. Для какой-то работы нужны рабочие, для какой-то инженеры. Именно этот факт я призываю осознать составителей вакансий. Какой сеньор вам нужен: Python разработчик шестого разряда или C++ инженер на должность ведущего специалиста. Поставив так вопрос вы сразу определяете какой бэкграунд вам нужен от кандидата.

Здесь конечно мешает общественная предубежденность против рабочих профессий (все помнят, что если они будут плохо учится, то пойдут в цех работать, а не в теплом офисе сидеть?). Но не боги горшки обжигают, дело есть дело.

Также мы сможем ответить на вопрос об отношениях разработчиков с фреймворками. Вот представьте вы наняли сварщика, привозите его на объект и даете сварочный аппарат, а он так задумчиво вертит электроды в руках и спрашивает: "А куда здесь кислород подается?". От рабочего не требуется понимание принципов проектирования фреймворка (и понимание что они внутри все на одно лицо), у него задача простая, взял краскопульт и пошел вьюхи с контроллами пилить.

Конечно не всегда есть только контрастные оттенки, есть и посредственные инженеры, и смышленые изобретали-самоучки. Например целевой язык программирования задает свой уровень: с++ объективно можно назвать самым сложным языком в промышленном программировании и поэтому даже от джуниора требуется разбираться во многих тонкостях языка чтобы программа хотя бы с компилировалась, не сегфолтилась и не проливала память. В тоже время бессмысленно искать среди Python или Go разработчиков архитектора для мега проекта на 3KK строк.

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

Автор: MechanicZelenyy

Источник