Реальные задачи vs Учебные материалы Прошёл практически год, как я работаю на Go. Предлагаю сравнить, что из изученного используется в работе регулярно, что нужно лишь для прохождения собеседований, а каких знаний не хватает. Выровняем ваши ожидание/реальность На первом проекте в микрофинансах были те самые CRUDы и перекладывание JSONов, о которых все говорят. Я был в core команде, в которую ходят другие сервисы по GRPC, работал и с proto файлами и кодогенерацией. В следствие этого у нас не было ни фронтенда, ни REST API. Для работы с БД использовалась ORM bun, и использовалась Clean Architecture для написания кода по слоям. Пригодилось знание Docker и Postman для локального тестирования, но с деплоем на прод или какими-то инструментами Observability я не столкнулся, так как мы делали новую версию продукта, которую только готовили к первому релизу. На текущей работе в бигтехе у меня меньше написания кода, но больше ресерча, созвонов и обсуждений. Харды так качаются медленнее. Периодически есть задачи как на REST API, так и на GPPC ручки. Часто задачи связанные с внутренними инструментами компании, знание которых бесполезно на рынке, сюда относится различная настройка конфигов для мониторинга сервисов, правки ratelimiter, правки в админках и прочее. Сложность большинства задач в большом количестве микросервисов, которые используются для работы фичи, и в понимании общей картины в целом – что для чего используется и где какие-изменения нужно вносить. При этом деплой происходит в UI админки, либо одной командой через CLI, новые сервисы создаются другой командой через тот же CLI. Кажется, что навыки работы с инструментами инфрастуктуры атрофируются. С точки зрения бизнеса это логично, инженеры продуктовых команд должны тратить максимум времени на написание бизнес логики, но с точки зрения развития инженера это ограничивает набор инструментов, с которыми регулярно работаешь. В обоих проектах активно писались юнит-тесты с моками, кстати, LLM отлично помогают с ними. А что же на счёт самых сложных вопросы с собесов, которые постоянно спрашивают? Я ни разу не писал код для прода с горутинами, каналами, мютексами и прочим, связанным с многопоточкой. Лишь один раз использовал errgroup.WithContext для обращения к двум сервисам из одного метода. Работа с брокерами очередей сводится к вызову метода для отправки данных в очередь. Что же не пригодилось прямо совсем: Всё про сборщик мусора и планировщик. Детали работы мап, слайсов и хитрые кейсы с ними. Алгоритмические задачи. Разумеется, это лишь мой опыт и так не везде. В платформенной или системной разработке сложного кода явно больше. Так какие выводы? На работе платят за решение задач бизнеса, а не развитие наших навыков, так что не забываем учиться самостоятельно. Не засиживаемся на одном проекте чтобы качать насмотренность подходов и технологий. Принимаем, что для прохождения собеседований просто нужно знать много лишних вещей. Чтобы лучше ориентироваться в сервисах вашего проекта и решать рабочие задачи нужно решать больше рабочих задач, мало какой курс тут поможет.