Столкнулся с тем, что golang разрабов нанимают уровнем senior, по большей части. Мидлы резко упали в интересе.
Всегда считал себя уверенным middle, и не стремился быть выше, потому что имел опыт руководства командой, и хотя он не является совсем уж провальным, мне не понравилось. Делится идеями, критиковать чужие, обсуждать, пробовать, чтобы найти лучший вариант - это мне нравится, но это точно не руководство командой.
Предвидя подъем интереса к golang, лет пять тому назад, я его выучил, как мне казалось, до middle уровня. Синтаксис, конкурентность и некоторые шаблоны проектирования, web, api, grpc, взаимодействие с БД и сервисами, типа редиски или кролика.
Чтобы зайти сеньором, они не всегда руководят, есть идея - качнуть kuber. И так, пользование кубер, шаблоны облачных решений, у кубера, вроде как, есть api для golang, что еще нужно, чтобы хантер сразу отложил твое резюме в стопку "перспективных"? Кроме опыта, реального на этом языке набирается года на 3, примерно, да и то - все довольно просто и прозрачно, общение с базой и немного кэша, в половине случаев.
Вот человек кодил 30 лет на эрланге/эликсире, писал высоконагруженные телекоммуникационные системы, включая планирование архитектуры и баз данных для лидирующих мировых телеком компаний, а потом решил уйти во фронтенд, про который он ничего не знает. Он джун или сеньор?
Можем зайти вообще с другой стороны. Человек может быть миддлом по хард скиллам какой-то произвольно взятой матрицы скиллов, однако при этом быть сеньором в компании, ибо он очень много знает про проект, работает на нем много лет, знает нюансы, однако не пишет "супер сеньорский" код.
Поэтому, имхо, тяжело сказать, что нужно знать на определенную роль. Однако, я бы добавил, что сеньорность, в целом, сопровождается самостоятельностью и вниманием к деталям.
Mikhail Osher, вопрос был про вполне конкретный род деятельности, разработка на golang.
попробую переформулировать.
если бы вы принимали на работу golang разработчика, на позицию middle разработчика, наличие каких компетенций или опыта вас интересовало бы в первую очередь?
аналогично для senior, наличие каких компетенций вас интересовало бы в первую очередь?
Не знаю почему, последнее место работы было perl+golang, до этого python, который является моим основным языком, и хабр и хантер подымают вакансии с golang в выдаче. В принципе я не против, если смогу кого нибудь убедить в своей профпригодности, и технологии интересные, и желание ими заниматься присутствует. Только хантеры не горят желанием со мной по этому поводу разговаривать, от слова совсем. Говорят что возраст имеет значение. Может не врут?
аналогично для senior, наличие каких компетенций вас интересовало бы в первую очередь?
Тех же, что и у мидла. Только я бы не проверял знания по списку, а попросил рассказать о прошлом опыте, в интересных местах задавал бы наводящие вопросы, подкинул ситуаций из своего опыта и спросил бы кандидата, что он о них думает, как бы действовал в подобных ситуациях.
Zanak, на мой взгляд, миддл и сеньор по хард скиллам не так сильно отличаются. Уверенное знание языка/конструкций/подходов - как минимум для обоих.
Я бы не спрашивал "а как написать какую-то штуку минимальным количеством символов" и точно не спрашиваю ничего, что в faang просят, типа переворачивания деревьев или скользящие окна, однако затронул бы основные типовые задачи, и какие нюансы с ними могут быть в реальном мире. Поспрашивал бы опыт с разными инструментами, позадавал бы вопросов на тему библиотек.
Миддлов лет 5 не собесил. Сеньору буду более открытые вопросы задавать, чтобы они со своего опыта порассказывали вещи - буду слушать, как говорят и что говорят. Буду обращать внимание, как они поняли вопрос, и что они посчитали нужным ответить, а что нет.
По поводу возраста - не подскажу, но вообще в жизни людей лет так до 25-27 считаю маленькими и еще растущими.
Сеньористость опеределяется не столько знаниями. Это вот с джуна на миддла знания роляют.
А сеньористость это опыт, ответственность (не как скилл, а как обязанность - если что то пойдет не так - ты виноват), инициативность и прочие крутые эйчарные слова
Если что - то пойдет не так по твоей вине - ты виноват, чем бы это не вылилось в практическом плане. Ты знаешь, что налажал, коллеги тоже в курсе, Начальство в курсе, что есть проблемы, и самый неприятный момент - кому достанется его гнев и каков будет потенциал последствий.
Твое разгильдяйство, некомпетентность, лень, глупость и прочие личностные недостатки должны иметь самые серьезные последствия, и, наверное, имеют, не часто встречал, чтобы составить какое - то системное мнение.
Случай, когда выбранное техническое решение не сработало - здесь сложнее.
В небольших проектах ошибиться сложнее. Один сайт, его бакенд с api, и просто бакенд, если имеет смысл. Здесь все просто, и если что - то не взлетело, то человек, скорее всего, профессионально не пригоден. Гнать таких, если анализ подтвердит ситуацию.
В средних и крупных системах - выбор решения не всегда единоличное мнение. И кому достанутся последствия - это вопрос открытый. Точнее, диапазон последствий может быть разный, от разумных, до бесполезных или даже деструктивных.
Zanak, когда лажает джун, он говорит, что ему не объяснили, не научили, не показали. Когда лажает мидл, он говорит, что постановка была плохая, что сроки были нереальные, что инструменты были неподходящие и т.п. Сеньору перекладывать ответственность грешно, ты опытный, ты должен был сам всё знать, сам уточнить постановку, ещё и подсказать граничные случаи, сам договориться с менеджером о сроках и возможных компромисах и т.п.
Сергей Горностаев, ответ мимо вопроса, впрочем, возможно, я сам чего - то не так понимаю, судя по ответам других коллег.
имел ввиду весьма простую мысль, как - то так:
1. джун - знания языка и его окружения, установка библиотек, написание кода и запуск, отладка, поход в какую либо БД за данными, юнит-тесты.
2. мидл - джун + лучшие практики + теоря реляционных БД, noSQL БД, эффективная реализация типовых проектов, интеграционные тесты, устранение проблем с развернутым проектом, интеграции с внутренними сервисами.
3. сеньор - мидл + архитектурные паттерны, типа сайткар, амбасадор, ... , умение их идентифицировать, и понимание, для чего они здесь, умение их реализовать в проекте, интеграция между внутренними и внешними сервисами, тестирование проекта в целом, наблюдение за состоянием, решение проблем и предложения по улучшению.
4. лидер - сеньор, который говорит "дальше будем делать так ..."
Zanak, не, у нормального джуна должна быть вся теоретическая база. На первую работу человек должен выходить к работе готовый, а не требующий обучения. Другое дело, что на текущем рынке труда в ИТ брать готовы всех, кто голову на звук уверенно поворачивает, отсюда и устойчивое заблуждение, что между грейдами должна быть разница в теоретической подготовке.
сначала ты приобретаешь знания, их применение дает тебе опыт, который определяет образ твоих мыслей и практических подходов. это как - то так работает, кмк :)
Средний
