Виталий Лихачев, Олег Козырев : Публичное собеседование Senior Golang Developer

Поделиться
HTML-код
  • Опубликовано: 4 фев 2025
  • Публичное собеседование на Senior Golang разработчика. Обсудим реально встречающиеся задачи у golang разработчиков в больших микросервисных проектах, немного погрузимся в system design и как это выражается в коде.
    Никакой балансировки скобок и вопросов про работу шедулера горутин (ну почти).
    Собеседование будет проводить Виталий Лихачев - Senior software engineer в avito.tech. Автор и преподаватель курса slurm.io/go.
    Ментор курсов slurm.io/devop... и slurm.io/cours...
    Проходить собеседование будет Олег Козырев - работает старшим инженером в платформенной команде Авито, ведет свой блог на ютубе и в телеграм, а также преподаю на своём курсе по разработке микросервисов на go. Ссылки на все ресурсы Олега taplink.cc/ole...
    Канал с анонсами t.me/megdu_skobok
    Boosty boosty.to/megd...
    Ламповый чат t.me/backend_m...

Комментарии • 15

  • @rerurkful
    @rerurkful 4 месяца назад

    Осень полезно смотреть такой контент . Иногда можно на перед знать как решить задачу. Спасибо!

  • @Igor-ale
    @Igor-ale 3 месяца назад

    Косяк с блокнотом, но неплохо бы проговорить следующие моменты:
    1) закрытие каналов, и как в итоге не записать в закрытый канал
    2) удаление из второй мапы когда ответ сохранили в первую
    3) синхронизация мап, между операциям в разных мапах могут встроится новые запросы

  • @noone7796
    @noone7796 9 месяцев назад +6

    По факту Вроде они договорились делать broadcast ответа чтобы не делать лишние одинаковык запросы, но написали простой кеш без инвалидации,
    а потом только начали делать broadcast, и его не успели.
    имхо в реальном собесе это no hire.

  • @АлександрЛобов-ю6ж
    @АлександрЛобов-ю6ж 9 месяцев назад +2

    Вот бы всегда собесы проводились так, как будто есть ещё зрители, для которых неотвеченный вопрос раскрывается. А то интервьюверы любят просто пойти дальше, типа не знаешь ну и не знай дальше.

  • @Smolandgor
    @Smolandgor 2 месяца назад +1

    Как упражнение для мозга наверное ок, но в нормальных системах обычно не делают кэш мапами. Для этого есть редис. Плюс юзают месадж брокеры. Вся эта конструкция не будет работать в случае когда много инстансов микросервиса.

    • @constantinegeist1854
      @constantinegeist1854 17 дней назад

      Кэшировать в памяти Go плохая идея не только из-за stateless-сервисов, но потому что сборщик мусора будет всё это барахло сканировать каждый раз, и на больших объёмах будет трещать по швам. Пример: Дискорду из-за проблем GC пришлось переписать кэш-сервис с Go на Rust

  • @Евгений-н6р8х
    @Евгений-н6р8х 8 месяцев назад +1

    Почему бы не рассмотреть вариант с возвратом результата в виде некоторого промиса с каналом Done()? Внутри кеша, если надо, в отдельной горутинке идем во внешний сервис, а горутины хендлеров получают промис и сами решают подождам им готовности результата или сразу вернуть результат клиенту.
    зы
    Рекспект Виталию, кейс классный.

  • @genya2463
    @genya2463 9 месяцев назад +4

    Не палите в следующий раз урл кодшера и код не будет исчезать

    • @pavel4279
      @pavel4279 8 месяцев назад +1

      А может зрителям надо быть добропорядочными, а не клоунами?

    • @genya2463
      @genya2463 8 месяцев назад +4

      На это ты не можешь повлиять

  • @slavanikulin8069
    @slavanikulin8069 6 месяцев назад

    вместо броадкастера и мапы с каналами, который Виталий предложил, можно же было использовать один канал и закрытие канала в качестве сигнала. Потом из кэш-мапы забирать данные

    • @СергейМельниченко-у8п
      @СергейМельниченко-у8п 17 дней назад

      С одним каналом да. Ещё понадобилась бы мапа, в которой мы писали бы айдишники, по которым уже выполняется запрос

  • @МаксимТкаченко-б2л
    @МаксимТкаченко-б2л 8 месяцев назад +2

    Отличная задача, кмк, даже крепкий мидл ее вполне может запилить

  • @antoniusupov
    @antoniusupov 2 месяца назад

    Return то забыл на 20 строчке