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

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang. Также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, что объединяет Go-разрабов каждого грейда.

А почитать о том, как сейчас стать Go-разрабом, можно в предыдущей статье.

Для начала важно разделять два понятия: навык прохождения собеседований и навык работы. Интервью длится 3-4 часа — этого невероятно мало, чтобы прочувствовать весь ваш кругозор в бою, поэтому индустрия использует стандартные задачи-заглушки. У большинства компаний такие задачи примерно про одно и то же, поэтому сейчас не редка ситуация, когда на собеседовании ваш реальный грейд на единицу или полторы выше реального — как раз потому, что такие заглушки отскакивают от зубов.

• Что это значит для кандидата: в такой ситуации можно быстрее вырасти в реальном навыке работы, потому что через навык собеседований вы получаете грейд. Эти задачи не даются просто так на позиции, которая соответствует навыку реальной работы. Так, в стрессовой ситуации вы максимально выравниваетесь за короткий срок. 
• Что это значит для компании: для работодателя это плохо, поскольку  определить грейд — еще сложнее. И есть шанс нанять кандидата, на которого потратят больше денег, чем он теоретически может принести.

Теперь разберем, что требуется от Go-разработчиков на каждом уровне.

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

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

Сейчас на рынке Go очень много джунов — он перегрет, и попасть в компанию без коммерческого опыта будет крайне сложно. Более того, от начинающих разработчиков ждут немало знаний и навыков. О них — ниже.

• Уметь абстрактно рассказать про очереди в планировщике.
• Знать про мапу под капотом: как устроено хеширование, коллизии и разрешение конфликтов.
• Уметь решать задачи по concurrency на относительно базовом уровне (воркер пул) и на слайсы
• Понимать принципы работы горутин и каналов.

• Знать виды баз данных и рассказать про максимальное количество юзкейсов из опыта с разными типами данных.
• Знать индексы и ACID и уметь их базово  писать.
• Знать SQL, уметь составлять схемы и идейно понимать, как работают самые известные базы —  PostgreSQL, ClickHouse.
• Понимать репликацию и шардирование

Да-да, теперь даже джуну нужно иметь абстрактное понимание сисдиза:

• Монолит vs. микросервисы: знать плюсы и минусы каждой архитектуры.
• Знать варианты коммуникаций между сервисами (брокеры сообщений, REST API, gRPC).

• Уметь решать медиум-задачки на LeetCode. Фокус при этом на задачах со слайсами, деревьями и графами.
• В Computer Science — знать про устройство Linux, планировщик, потоки/процессы, а еще про устройство сети — OSI, TCP/IP, протоколы и т.д.

Также в некоторых компаниях сейчас ко всему этому требуют еще и знание Kubernetes.

Вот здесь собрал дорожную карту, как влиться в IT на примере Go. Из полезных ссылок:

1. Один из лучших курсов по Go на Youtube
2. Крутой урок по системному дизайну
3. Все про каналы в Go

А здесь можно посмотреть, как джуну стать мидлом.

Схема примерно такая же, как и с джунами, правда, знать все нужно гораздо глубже.

• Знать планировщик на уровне того, какая структура данных используется в локальных очередях. 
• В слайсах — уметь решать задачи со срезом по capacity, плюс более уверенное решение кейсов по concurrency.

• MVCC, 
• Проблема разбухания индексов, 
• Селективность, 
• Шардирование на уровне реальных решений основной проблемы решардинга — Consistent Hash, 
• Реприликация и паттерн Raft.  

А еще важно уметь писать нормальные индексы и эффективные SQL запросы. Плюс ожидается, что у вас будет больше юзкейсов работы с разными типами баз данных.

Нужно знать про паттерны межсервисного взаимодействия: Saga, Transactional Outbox, Circuit Breaker. На мидла могут уже спокойно давать практические задачи на внедрение каких-то идейных дизайнерских штук, например, идемпотентности.

Здесь они играют меньшую роль. Главное — показать коммерческий опыт, рассказать о кейсах и блеснуть знаниями в Go, базах и проектировании.

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

Нужно знать библиотеку Reflection со всякими приколами, которые могут ускорить concurrency. Также разбираться в аренах памяти и планировщике.

В паттернах межсетевого взаимодействия история с обычным рассказом не пройдет — юзкейсы здесь must-have. Поэтому важно уметь проходить System Design-интервью — собирать функциональные и нефункциональные требования, считать нагрузку, проектировать на разных уровнях абстракции, углубляться и решать проблемы в своей же архитектуре. Это сложно, и без хотя бы косвенного соприкосновения с проектированием, будет непросто. Поэтому в качестве совета — стремитесь максимально участвовать на архитектурных сессиях и грумингах, будучи мидлом.

Будет круто знать, как под капотом реализован, например, PostgreSQL: как он поднимает что-то в буфер, как хранит данные на диске, что такое чекпоинты и бэкапы и как реализована MVCC.

В случае с ClickHouse лучше верхнеуровнево понимать LSM-дерево, а с ElasticSearch — инвертированные индексы.

Алгоритмы уже почти не играют роли в большинстве компаний, а Computer Science требуется примерно на том же уровне, что и на джуна. Единственное — в Linux могут чуть капнуть.

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

Мне часто на трансляциях говорят: «Зачем мне знать планировщик или уметь решать сложные задачи по concurrency? Когда мне это пригодится в работе?». Действительно, на эффективность в решении рабочих задач это влияет незначительно, но все же это особенность собеседований (подробнее можно посмотреть здесь):

• Собес ≠ работа. Принято считать, что знания, требуемые на собеседовании, пригодятся в работе — это не так. За несколько часов невозможно полностью оценить кандидата, поэтому интервью строятся на проверке общих знаний и концепций.
• Почему спрашивают про планировщик? Банально узнают софты. 
• Жесткая конкуренция. Все просто: знание — сила.

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

• Грейд Junior. Нужно уметь делать максимально базовые задачи. Например, добавить поле или прокинуть фича-флаг. Или же при курировании и ревью быть мотивированными. Этого достаточно. Да, как бы грустно это ни звучало, здесь по классике предполагается, что тебе нельзя доверить что-то серьезное без сторонней помощи.
• Грейд Middle. Относительно безболезненно брать на себя полноценные части продукта в зону ответственности, фича-лидить. Здесь предполагается, что ты можешь действовать относительно самостоятельно, приходя с вопросами лишь иногда. Тут уже желательно участвовать в каких-либо технических обсуждениях.
• Грейд Senior. Здесь нужно разрабатывать фичи любого уровня сложности под ключ. Тебе достаточно предоставить бизнес-требования, сходить с ними по командам с экспертизой. Затем спроектировать качественную архитектуру, которая развалится с минимальной вероятностью, самому реализовать и принести лиду  таску в Done. Здесь также важно менторить сотрудников, активнейшим образом участвовать на грумингах и любых других технических созвонах.

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