Открытое собеседование на Middle Go разработчика

16 июля 2024 г. · 29 мин. чтения

Сегодня мы разберём реальное собеседование по Go, в котором кандидат Сергей — человек с не-IT бэкграундом и годом опыта в языке — демонстрирует уверенное владение конкурентностью, мапами, каналами и планировщиком, а также открыто делится своим нестандартным путём в разработку. Мы увидим, как интервьюер Дани проверяет глубину понимания языка через каверзные задачи на конкурентный доступ к map, эвакуацию бакетов, sync.Map и архитектурные подходы к шардированию — и как кандидат, пусть и не всегда детально, мыслит в правильном направлении, опираясь на практику и искренний интерес к Go.

Вопрос 1. Что выведется при передаче слайса в функцию и изменении его длины внутри функции?

Таймкод: 00:08:19

Ответ собеседника: неполный. Кандидат предположил, что выведется "Привет Привет", потому что capacity не превышена. Верно отметил, что слайс — это структура с указателем на массив, len и cap. Однако не смог самостоятельно объяснить, почему третий элемент ("Пока") не выводится. После подсказки понял: в функции test инкрементируется скопированный len, а оригинальный len в main остаётся равным 2, поэтому выводится только два элемента.

Правильный ответ:

Рассмотрим задачу подробно. Допустим, код выглядит примерно так:

package main

import "fmt"

func test(s []string) {
    s = append(s, "Пока")
}

func main() {
    s := make([]string, 2, 3)
    s[0] = "Привет"
    s[1] = "Привет"
    test(s)
    fmt.Println(s)
}

Что происходит в памяти

Слайс в Go — это структура (slice header), содержащая три поля:

указатель на базовый массив (pointer)
длина — количество элементов, доступных для чтения (len)
ёмкость — общий размер базового массива (cap)

Slice header:
┌──────────┬─────┬─────┐
│ pointer  │ len │ cap │
└──────────┴─────┴─────┘

Когда слайс передаётся в функцию, передаётся копия этой структуры (value semantics). Копируются указатель, len и cap, но указатель ссылается на тот же базовый массив.

Что происходит внутри test

Внутри test вызывается append(s, "Пока"). Поскольку len == 2 и cap == 3, ёмкости хватает — перевыделение памяти не происходит. append записывает "Пока" в третью ячейку базового массива и возвращает новый slice header, в котором len == 3.

Однако этот новый slice header присваивается локальной переменной s внутри функции. Оригинальный slice header в main остаётся неизменным — его len по-прежнему равен 2.

Почему в базовый массив данные записались, но не выводятся

Данные в базовый массив действительно были записаны. Но когда main вызывает fmt.Println(s), он выводит элементы от 0 до len - 1, то есть только 2 элемента. Третий элемент физически существует в массиве, но "невидим" для слайса в main.

Как получить доступ к третьему элементу

Если внутри test вернуть новый слайс и присвоить его в main, всё заработает:

func test(s []string) []string {
    s = append(s, "Пока")
    return s
}

func main() {
    s := make([]string, 2, 3)
    s[0] = "Привет"
    s[1] = "Привет"
    s = test(s)
    fmt.Println(s) // [Привет Привет Пока]
}

Ключевые правила для запоминания

Слайс передаётся в функцию по значению (копия header).
Изменение элементов слайса внутри функции видно снаружи (общий базовый массив).
Изменение len через append внутри функции не видно снаружи, если не вернуть новый слайс.
Если append вызывает перевыделение (cap исчерпан), то даже элементы базового массива будут разными — функция работает с совершенно новым массивом.

Практический вывод

Это один из самых частных источников багов в Go. Всегда возвращайте слайс из функции, если внутри него происходит append.

Вопрос 2. Как вывести все элементы базового массива слайса, не меняя функцию и не используя указатели?

Таймкод: 00:13:29

Ответ собеседника: неполный. Кандидат предложил создать срез от слайса. Первая попытка — s[0:] — не сработала, потому что правая граница по умолчанию равна len (2), а не cap (3). Верное решение — s[0:3] или s[:cap(s)], чтобы явно указать, что нужно прочитать все 3 элемента из базового массива.

Правильный ответ:

Дано: функция test добавляет элемент "Пока" в базовый массив через append, но изменение len остаётся локальным. В main слайс по-прежнему имеет len == 2. Задача — вывести все три элемента, не меняя функцию и не передавая указатель на слайс.

Проблема в деталях

После вызова test(s) состояние памяти выглядит так:

Базовый массив (cap=3):
┌──────────┬──────────┬──────┐
│ Привет   │ Привет   │ Пока │
└──────────┴──────────┴──────┘
                        ↑
                        записано test'ом

Slice header в main:
┌──────────┬─────┬─────┐
│ pointer  │  2  │  3  │   ← len всё ещё 2
└──────────┴─────┴─────┘

Данные "Пока" физически есть в массиве, но len == 2 не даёт к ним доступ через обычный fmt.Println(s).

Срез с явным указанием границ

Оператор среза s[low:high] создаёт новый slice header с тем же указателем на базовый массив, но с другим len. Правая граница high может быть указана вплоть до cap(s), а не только до len(s).

s := make([]string, 2, 3)
s[0] = "Привет"
s[1] = "Привет"
test(s)

// Неправильно: s[0:] → len по умолчанию = 2, получим срез длиной 2
// Правильно: явно указываем правую границу
fmt.Println(s[:3])         // [Привет Привет Пока]
fmt.Println(s[0:3])        // [Привет Привет Пока]
fmt.Println(s[:cap(s)])    // [Привет Привет Пока] — наиболее идиоматичный вариант

Почему s[0:] не работает

Когда в выражении среза s[low:high] опущена правая граница, она по умолчанию равна len(s), а не cap(s). Это важное отличие:

s := make([]string, 2, 3)
fmt.Println(len(s))  // 2
fmt.Println(cap(s))  // 3

s1 := s[0:]   // len = 2 (по умолчанию = len(s))
s2 := s[:3]   // len = 3 (явно указано до cap)

Механика расширения среза

Go позволяет расширять срез вправо вплоть до ёмкости базового массива. Это возможно, потому что базовый массив уже выделен и имеет достаточный размер. Операция s[:cap(s)] просто создаёт новый header с увеличенным len, не копируя данные.

До расширения:          После s[:cap(s)]:
┌─────┬─────┐          ┌─────┬─────┐
│  2  │  3  │          │  3  │  3  │
└─────┴─────┘          └─────┴─────┘
  len  cap              len  cap

Ограничения метода

Этот приём работает только в том случае, если:

append внутри функции не вызвал перевыделение памяти (cap не был исчерпан).
Вы знаете или можете определить, сколько элементов было добавлено.

Если append вызвал перевыделение (ёмкость была исчерпана), базовый массив изменился, и срез s[:cap(s)] в main будет ссылаться на старый массив, где нового элемента нет.

Идиоматичная запись

Наиболее читаемый и безопасный вариант:

fmt.Println(s[:cap(s)])

Это явно показывает намерение: "вывести все элементы, на которые хватает ёмкости базового массива".

Ключевой вывод

Срез s[:cap(s)] — это легальный и безопасный способ получить доступ к элементам базового массива за пределами текущего len. Однако в промышленном коде такой подход считается хрупким — правильнее возвращать новый слайс из функции или использовать указатель на слайс. Этот приём полезен для понимания внутреннего устройства слайсов и для отладки, но не как основной паттерн проектирования.

Вопрос 3. Как обработать миллион URL с HTTP-запросами с использованием worker pool?

Таймкод: 00:14:59

Ответ собеседника: правильный. Кандидат верно определил проблему: при миллионе запросов нельзя запускать миллион горутин — упрёмся в ограничение на файловые дескрипторы. Предложил использовать буферизированный канал как семафор для ограничения количества одновременно работающих горутин (1000 как разумное значение). Обсудили worker pool как альтернативу, планировщик Go (GMP), Network Poller, локальные и глобальные очереди горутин, work stealing. Кандидат продемонстрировал понимание работы буферизированных каналов. В итоге с подсказками реализовал worker pool: канал с задачами (URL), 1000 воркеров которые читают из канала в цикле for-range, делают запрос, записывают HTTP-код в sync.Map, используют sync.WaitGroup для ожидания завершения.

Правильный ответ:

Архитектура решения

Worker pool — это паттерн, при котором фиксированное количество горутин (воркеров) обрабатывают задачи из общей очереди. Это решает проблему ограниченных ресурсов системы (файловые дескрипторы, память, сетевые соединения) при обработке большого объёма задач.

┌─────────────────────────────────────────────────────┐
│                    Producer (main)                   │
│  Отправляет URL в канал задач                        │
└──────────────────────┬──────────────────────────────┘
                       │ канал задач (буферизированный)
                       ▼
┌─────────────────────────────────────────────────────┐
│                  Worker Pool                         │
│  ┌──────────┐  ┌──────────┐       ┌──────────┐     │
│  │ Worker 1 │  │ Worker 2 │  ...  │ Worker N │     │
│  │ recv url │  │ recv url │       │ recv url │     │
│  │ http.Get │  │ http.Get │       │ http.Get │     │
│  │ store    │  │ store    │       │ store    │     │
│  └──────────┘  └──────────┘       └──────────┘     │
└──────────────────────┬──────────────────────────────┘
                       │ канал результатов / sync.Map
                       ▼
┌─────────────────────────────────────────────────────┐
│           Агрегация результатов                      │
│  map[int]int — счётчик по HTTP-кодам               │
└─────────────────────────────────────────────────────┘

Полная реализация

package main

import (
    "fmt"
    "net/http"
    "sync"
    "time"
)

const (
    numWorkers = 1000
    bufferSize = 10000
)

func worker(id int, urls <-chan string, results chan<- int, wg *sync.WaitGroup) {
    defer wg.Done()

    // Переиспользуем HTTP-клиент для каждого воркера
    // Это критически важно для производительности
    client := &http.Client{
        Timeout: 10 * time.Second,
        Transport: &http.Transport{
            MaxIdleConns:        100,
            MaxIdleConnsPerHost: 100,
            IdleConnTimeout:     90 * time.Second,
        },
    }

    for url := range urls {
        resp, err := client.Get(url)
        if err != nil {
            // Ошибка сети или таймаут — записываем как 0
            results <- 0
            continue
        }
        results <- resp.StatusCode
        resp.Body.Close() // Важно: закрывать body для переиспользования соединения
    }
}

func main() {
    urls := make([]string, 1_000_000)
    for i := range urls {
        urls[i] = fmt.Sprintf("https://example.com/page/%d", i)
    }

    urlChan := make(chan string, bufferSize)
    resultChan := make(chan int, bufferSize)

    var wg sync.WaitGroup

    // Запускаем воркеров
    for i := 0; i < numWorkers; i++ {
        wg.Add(1)
        go worker(i, urlChan, resultChan, &wg)
    }

    // Запускаем горутину для закрытия resultChan после завершения всех воркеров
    go func() {
        wg.Wait()
        close(resultChan)
    }()

    // Отправляем URL в канал (producer)
    go func() {
        for _, url := range urls {
            urlChan <- url
        }
        close(urlChan)
    }()

    // Агрегируем результаты
    statusCounts := make(map[int]int)
    for code := range resultChan {
        statusCounts[code]++
    }

    // Выводим результаты
    for code, count := range statusCounts {
        fmt.Printf("HTTP %d: %d\n", code, count)
    }
}

Почему именно 1000 воркеров

Количество воркеров определяется ограничением на файловые дескрипторы. Каждый HTTP-запрос открывает соединение (файловый дескриптор). По умолчанию Linux ограничивает процесс 1024 дескрипторами, но это можно увеличить:

ulimit -n 65536

При миллионе запросов и таймауте 10 секунд каждый воркер может обрабатывать примерно 1000 запросов в секунду (с учётом сетевой задержки). 1000 воркеров дают пропускную способность порядка миллиона запросов в секунду при достаточной пропускной способности сети.

Альтернатива: sync.Map вместо канала результатов

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

func worker(id int, urls <-chan string, counts *sync.Map, wg *sync.WaitGroup) {
    defer wg.Done()
    client := &http.Client{Timeout: 10 * time.Second}

    localCounts := make(map[int]int) // Локальный буфер для батчинга

    for url := range urls {
        resp, err := client.Get(url)
        code := 0
        if err == nil {
            code = resp.StatusCode
            resp.Body.Close()
        }
        localCounts[code]++

        // Периодически сливаем локальные данные в общую Map
        if len(localCounts) > 100 {
            for c, n := range localCounts {
                for {
                    actual, _ := counts.LoadOrStore(c, 0)
                    if counts.CompareAndSwap(c, actual, actual.(int)+n) {
                        break
                    }
                }
            }
            localCounts = make(map[int]int)
        }
    }
}

Критически важные детали

Переиспользование HTTP-клиента: создание нового http.Client для каждого запроса приводит к утечке соединений и исчерпанию дескрипторов. Каждый воркер должен иметь свой клиент с настроенным Transport.
Закрытие resp.Body: без resp.Body.Close() соединение не возвращается в пул и дескриптор утекает.
Буфер канала: буферизированный канал позволяет продюсеру не блокироваться на каждой отправке, пока воркеры обрабатывают предыдущие задачи.
Graceful shutdown: закрытие urlChan сигнализирует воркерам о завершении. wg.Wait() гарантирует, что все результаты записаны перед закрытием resultChan.

Сравнение подходов

Подход	Плюсы	Минусы
Буферизированный канал как семафор	Простота реализации	Нет переиспользования воркеров
Worker pool с каналом задач	Контроль ресурсов, переиспользование	Сложнее в реализации
sync.Map для результатов	Нет бутылочного горлышка на агрегации	Compare-and-swap может спиннить
errgroup	Удобная обработка ошибок	Меньше контроля над воркерами

Производительность

При правильной настройке (1000 воркеров, переиспользуемый HTTP-клиент, буфер канала 10000) обработка миллиона URL занимает порядка 10-30 минут в зависимости от сетевой задержки и ответа серверов. Основное время уходит на ожидание сетевых ответов, а не на вычисления.

Вопрос 4. Что произойдёт при конкурентной записи в map из нескольких горутин?

Таймкод: 00:48:42

Ответ собеседника: неполный. Кандидат сначала предположил, что результат зависит от планировщика. Когда интервьюер сказал, что результат детерминирован, кандидат изменил ответ на data race. Однако правильный ответ — паника "concurrent map writes" (начиная с Go 1.6 runtime детектирует конкурентную запись в мапу и вызывает панику). Кандидат знал, что мапа не потокобезопасна, но не знал про встроенный детектор паники. Также обсудили, что в Go 1.22 исправили поведение замыканий в циклах.

Правильный ответ:

Детерминированное поведение: паника

Начиная с Go 1.6, runtime Go встроил детектор конкурентного доступа к map. При обнаружении одновременной записи в map из нескольких горутин runtime вызывает панику с сообщением:

fatal error: concurrent map writes

Это не data race в классическом понимании (который приводит к неопределённому поведению), а детерминированная паника — программа гарантированно упадёт.

Почему это происходит

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

// Упрощённая логика внутри runtime.mapassign()
if h.flags&hashWriting != 0 {
    throw("concurrent map writes")
}
h.flags |= hashWriting
// ... запись в бакет ...
h.flags &^= hashWriting

Код, демонстрирующий проблему

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    m := make(map[int]int)
    var wg sync.WaitGroup

    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            m[i] = i // Паника: concurrent map writes
        }(i)
    }

    wg.Wait()
    time.Sleep(5 * time.Second)
    fmt.Println(m)
}

Вывод:

fatal error: concurrent map writes

goroutine 7 [running]:
main.main.func1(0xc0000b4008, 0x5, 0xc0000b4010)
...

Важное уточнение: запись и чтение

Паника возникает при конкурентной записи. Конкурентное чтение и запись также детектируется:

fatal error: concurrent map read and map write

Однако конкурентное чтение из нескольких горутин безопасно — паники не будет.

Как правильно решить задачу

Вариант 1: sync.Mutex

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    m := make(map[int]int)
    var mu sync.Mutex
    var wg sync.WaitGroup

    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            mu.Lock()
            m[i] = i
            mu.Unlock()
        }(i)
    }

    wg.Wait()
    time.Sleep(5 * time.Second)

    mu.Lock()
    fmt.Println(m)
    mu.Unlock()
}

Вариант 2: sync.RWMutex (если много чтений)

var mu sync.RWMutex

// В горутине-писателе:
mu.Lock()
m[i] = i
mu.Unlock()

// В горутине-читателе:
mu.RLock()
val := m[i]
mu.RUnlock()

Вариант 3: sync.Map

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var m sync.Map
    var wg sync.WaitGroup

    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            m.Store(i, i) // Потокобезопасно
        }(i)
    }

    wg.Wait()
    time.Sleep(5 * time.Second)

    m.Range(func(key, value interface{}) bool {
        fmt.Printf("%v: %v\n", key, value)
        return true
    })
}

Когда использовать sync.Map

sync.Map оптимизирован для двух сценариев:

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

Для общего случая с частой записью sync.Mutex + обычная map работает быстрее.

Race detector

Даже если runtime не поймал конкурентную запись (например, в старых версиях Go), race detector обнаружит проблему:

go run -race main.go

Вывод:

WARNING: DATA RACE
Write at 0x00c0000... by goroutine 7:
  runtime.mapassign_fast64()
Previous write at 0x00c0000... by goroutine 8:
  runtime.mapassign_fast64()

Исправление замыканий в Go 1.22

В Go 1.22 исправили поведение переменных цикла в замыканиях. До Go 1.22 требовалось явно передавать i как параметр функции:

// До Go 1.22 — обязательно передавать i как аргумент
go func(i int) {
    m[i] = i
}(i)

// В Go 1.22+ — можно использовать i напрямую
go func() {
    m[i] = i // Теперь i уникально для каждой итерации
}()

Ключевые выводы

Конкурентная запись в map вызывает детерминированную панику (Go 1.6+).
Конкурентное чтение без записи — безопасно.
Для потокобезопасной записи используйте sync.Mutex, sync.RWMutex или sync.Map.
Всегда запускайте тесты с флагом -race для обнаружения гонок данных.

Вопрос 5. Что выведет программа с каналом структур, где горутина пишет, а main сразу читает?

Таймкод: 00:55:33

Ответ собеседника: правильный. Кандидат верно определил, что программа зависнет (deadlock), потому что горутина пытается записать в небуферизированный канал, но чтение происходит в main после запуска горутины, и никто не успевает прочитать. Если поменять местами — сначала запустить горутину-читателя, а потом писать — всё заработает.

Правильный ответ:

Анализ задачи

Рассмотрим типичный код, описанный в вопросе:

package main

import "fmt"

type Data struct {
    Value int
}

func main() {
    ch := make(chan Data)

    go func() {
        ch <- Data{Value: 42} // Запись в небуферизированный канал
    }()

    // main продолжает выполнение и сразу читает
    data := <-ch
    fmt.Println(data.Value)
}

Ответ: программа выведет 42 и завершится нормально.

Кандидат ошибся в анализе. Давайте разберём почему.

Механика небуферизированного канала

Небуферизированный канал работает по принципу синхронной передачи данных (rendezvous). Запись блокируется, пока кто-то не прочитает, и чтение блокируется, пока кто-то не запишет.

Горутина:              Main:
ch <- Data{42}         data := <-ch
    │                      │
    │  блокировка          │  блокировка
    │  (ждёт читателя)     │  (ждёт писателя)
    │                      │
    ▼                      ▼
    └──── rendezvous ──────┘
          данные переданы

Порядок выполнения в данной программе

Main создаёт канал ch.
Main запускает горутину (но горутина может ещё не начать выполняться).
Main доходит до data := <-ch и блокируется, ожидая данные.
Планировщик Go переключается на горутину.
Горутина выполняет ch <- Data{Value: 42} — данные переданы напрямую main.
Main получает данные, выводит 42.

Когда действительно будет deadlock

Deadlock возникнет, если и запись, и чтение находятся в одной и той же горутине (обычно в main):

func main() {
    ch := make(chan Data)

    ch <- Data{Value: 42}  // Блокировка — никто не читает
    data := <-ch           // Сюда никогда не дойдём
    fmt.Println(data.Value)
}

Вывод:

fatal error: all goroutines are asleep - deadlock!

Когда deadlock при двух горутинах

Deadlock возникнет, если обе горутины пытаются записать, а читателя нет:

func main() {
    ch := make(chan Data)

    go func() { ch <- Data{Value: 1} }()
    go func() { ch <- Data{Value: 2} }()

    // Читаем только одно значение — вторая горутина зависнет
    data := <-ch
    fmt.Println(data.Value)

    time.Sleep(time.Second) // Даём время, чтобы runtime обнаружил deadlock
}

Или если обе горутины читают, а писателя нет:

func main() {
    ch := make(chan Data)

    go func() { <-ch }()
    go func() { <-ch }()

    time.Sleep(time.Second) // Deadlock — никто не пишет
}

Визуализация состояний

Сценарий 1 (из вопроса):          Сценарий 2 (deadlock):
                                  
Main:                              Main:
  ch := make(chan Data)              ch := make(chan Data)
  go func() { ch <- x }()           ch <- x  ← блокировка
  data := <-ch ← получает           data := <-ch  ← недостижимо
  ✓ Работает                        ✗ Deadlock

Ключевое правило

Deadlock возникает, когда все горутины заблокированы и ни одна не может продолжить выполнение. Если хотя бы одна горутина может сделать шаг — deadlock нет. В данном вопросе main блокируется на чтении, но горутина может записать — значит, deadlock не возникает.

Практический вывод

Небуферизированный канал = синхронная передача.
Запись и чтение из разных горутин с небуферизированным каналом — стандартный паттерн синхронизации.
Deadlock возникает только когда все горутины заблокированы одновременно.

Вопрос 6. Как устроена мапа в Go под капотом: структура, бакеты, хеширование, эвакуация данных при росте?

Таймкод: 00:56:19

Ответ собеседника: неполный. Кандидат знает, что мапа — это структура с бакетами (8 элементов в каждом), в которых хранятся хеш и значение. Бакеты увеличиваются по мере росты мапы, при этом происходит постепенная эвакуация данных в новую мапу. Знает, что 8 элементов связано с выравниванием памяти (cache line). Знает про использование логарифма для определения номера бакета. Однако не смог детально рассказать весь путь от записи до попадания в бакет (low bits / high bits). Прямо сказал, что не вспомнит детали сходу.

Правильный ответ:

Общая архитектура

Map в Go — это хеш-таблица с открытой адресацией и методом цепочек на основе бакетов. Исходный код находится в runtime/map.go.

Струкatura hmap

Всё начинается с структуры hmap — заголовка map:

// runtime/map.go
type hmap struct {
    count     int        // Количество элементов (len(m))
    flags     uint8      // Флаги состояния (hashWriting, iterating и т.д.)
    B         uint8      // log2 количества бакетов (2^B бакетов)
    noverflow uint16     // Примерное количество overflow-бакетов
    hash0     uint32     // Сид для хеш-функции (рандомизирует хеши)

    buckets    unsafe.Pointer // Указатель на массив бакетов (2^B штук)
    oldbuckets unsafe.Pointer // Указатель на старый массив при эвакуации
    nevacuate  uintptr        // Прогресс эвакуации (номер следующего бакета)
}

Поле B — это ключ к пониманию размера. Если B = 3, то бакетов 2^3 = 8. При росте B увеличивается на 1, и количество бакетов удваивается.

Структура бакета (bmap)

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

Бакет (bmap) — 64 байта:
┌──────────────────────────────────────────────────────────┐
│ tophash[8]  │  keys[8]    │  values[8]  │ overflow ptr  │
│ 1 байт × 8  │ K байт × 8  │ V 字节 × 8  │  8 байт       │
│ (верхние     │ (ключи)     │ (значения)  │ (указатель    │
│  биты хеша)  │             │             │  на overflow) │
└──────────────────────────────────────────────────────────┘

Подробнее о каждом поле бакета:

tophash[8] — массив из 8 байт. Хранит старшие 8 бит хеша ключа. Это позволяет быстро отбросить неподходящие элементы, не сравнивая ключи целиком.
keys[8] — массив ключей. Ключи хранятся компактно, отдельно от значений.
values[8] — массив значений. Отдельное хранение ключей и значений улучшает локальность кэша при поиске.
overflow — указатель на следующий бакет в цепочке (если текущий переполнен).

Путь записи: от ключа до бакета

Рассмотрим полный путь операции m[key] = value:

Шаг 1: Вычисление хеша

// Упрощённо
hash := t.hasher(key, uintptr(h.hash0))

Хеш-функция зависит от типа ключа. Для строк используется memhash, для целых чисел — int64hash и т.д. Сид hash0 рандомизирует хеши для защиты от атак на коллизии (Hash DoS).

Шаг 2: Определение номера бакета

// Маска = количество бакетов - 1 = 2^B - 1
bucket := hash & bucketMask(h.B)
// bucketMask(3) = 0b111 = 7
// bucketMask(4) = 0b1111 = 15

Младшие B бит хеша определяют номер бакета. Это работает как операция hash % numBuckets, но значительно быстрее.

Пример:

B = 3 (8 бакетов)
hash = 0b10110101101101011011010110110101
mask = 0b00000000000000000000000000000111
bucket = hash & mask = 0b101 = 5 → бакет №5

Шаг 3: Поиск внутри бакета

Внутри бакета проверяются все 8 слотов:

// Упрощённый поиск
top := tophash(hash) // Старшие 8 бит хеша

for i := 0; i < 8; i++ {
    if b.tophash[i] != top {
        continue // Быстрый отсев — хеши не совпали
    }
    if b.keys[i] == key {
        // Ключ найден — обновляем значение
        b.values[i] = value
        return
    }
}

Порядок проверки: сначала tophash (1 байт сравнения), потом ключ (полное сравнение). Это минимизирует количество дорогих сравнений.

Шаг 4: Обработка коллизий и overflow

Если все 8 слотов заняты и ключ не найден, следующий элемент записывается в overflow-бакет:

Бакет 5 (основной)          Overflow-бакет
┌─────────────────┐        ┌─────────────────┐
│ tophash: [1,2,3,│        │ tophash: [9,10, │
│          4,5,6,7,│   →   │          0,0,0, │
│          8,0]    │        │          0,0,0] │
│ keys:    [k1..k8]│       │ keys:    [k9,k10│
│ values:  [v1..v8]│       │ values:  [v9,v10│
│ overflow: ────────┼──────→│ overflow: nil   │
└─────────────────┘        └─────────────────┘

Overflow-бакеты выделяются из пула hmap.extra.nextOverflow для минимизации аллокаций.

Визуализация поиска при чтении

Поиск ключа "apple" в map:

1. hash("apple") = 0xA3F7B2C1
2. bucket = 0xA3F7B2C1 & 0b111 = 1 → бакет №1

3. В бакете №1:
   tophash[0] = 0xA3 ✓ совпало → сравниваем ключ
   keys[0] = "banana" ✗ не совпал
   
   tophash[1] = 0xA3 ✓ совпало → сравниваем ключ
   keys[1] = "apple" ✓ совпали!
   
4. Возвращаем values[1]

Рост map: когда и как

Map растёт, когда load factor превышает порог:

// Условие роста (упрощённо)
if h.count > bucketCnt * 6.5 {
    // Нужен рост (B += 1, количество бакетов удваивается)
    hashGrow(t, h)
}

bucketCnt = 8, порог = 8 × 6.5 = 52 элемента на 8 бакетов. В среднем бакет заполнен на 6.5/8 ≈ 81%.

Также рост может быть вызван слишком большим количеством overflow-бакетов:

if noverflow >= bucketCnt {
    // Слишком много коллизий — нужен рост
}

Эвакуация данных (grow)

Рост map — это не одномоментная операция. Go использует постепенную эвакуацию (incremental evacuation):

Фаза 1: Выделение новой памяти

func hashGrow(t *maptype, h *hmap) {
    newB := h.B + 1 // Удваиваем количество бакетов
    newbuckets := makeBucketArray(t, newB, nil)

    // Сохраняем старые бакеты
    h.oldbuckets = h.buckets
    h.buckets = newbuckets
    h.nevacuate = 0 // Начинаем эвакуацию с бакета 0
}

Фаза 2: Постепенная эвакуация

Эвакуация происходит при каждой последующей записи и чтении:

func growWork(t *maptype, h *hmap, bucket uintptr) {
    // Эвакуируем один старый бакет
    evacuate(t, h, bucket)

    // Если ещё не всё эвакуировано — эвакуируем ещё один
    if h.oldbuckets != nil {
        evacuate(t, h, h.nevacuate)
    }
}

Логика эвакуации одного бакета

При удвоении количества бакетов элементы из старого бакета распределяются в два новых бакета:

Старый бакет №3 (B=3):          Новые бакеты (B=4):
┌────────────────────┐          ┌──────────┐  ┌──────────┐
│ hash: 0b...0011    │          │ Бакет #3 │  │ Бакет #11│
│ hash: 0b...1011    │    →     │ (0011)   │  │ (1011)   │
│ hash: 0b...0111    │          │          │  │          │
└────────────────────┘          └──────────┘  └──────────┘

Элемент попадает в бакет №3 или №11 в зависимости от бита на позиции B:

Старый номер бакета: 3 = 0b0011
Новый B = 4, маска = 0b1111

hash = 0b...0011 → бит[3] = 0 → бакет 3
hash = 0b...1011 → бит[3] = 1 → бакет 11 (3 + 2^3)
hash = 0b...0111 → бит[3] = 0 → бакет 7

Визуализация процесса эвакуации

Время T0: Рост начат
┌─────────────────────────────────────────────┐
│ oldbuckets: [B0][B1][B2][B3][B4][B5][B6][B7]│
│ newbuckets: [B0][B1][B2][B3][B4][B5][B6][B7]│
│              [B8][B9][B10][B11][B12][B13][B14][B15]│
│ nevacuate: 0                                 │
└─────────────────────────────────────────────┘

Время T1: После нескольких операций
┌─────────────────────────────────────────────┐
│ oldbuckets: [  ][  ][B2][B3][B4][B5][B6][B7]│  ← B0, B1 эвакуированы
│ newbuckets: [  ][  ][  ][  ][  ][  ][  ][  │
│              ][  ][  ][  ][  ][  ][  ][  ]  │
│ nevacuate: 2                                 │
└─────────────────────────────────────────────┘

Время T2: Эвакуация завершена
┌─────────────────────────────────────────────┐
│ oldbuckets: nil                              │  ← освобождена память
│ newbuckets: [  ][  ][  ][  ][  ][  ][  ][  │
│              ][  ][  ][  ][  ][  ][  ][  ]  │
│ nevacuate: все эвакуированы                  │
└─────────────────────────────────────────────┘

Зачем постепенная эвакуация

Без постепенной эвакуации вставка 10 000 000 элементов вызвала бы паузу на перемещение всех элементов за раз. С постепенной эвакуацией стоимость распределяется по всем последующим операциям, и максимальная задержка на одну операцию остаётся малой.

Tophash и специальные значения

tophash использует несколько специальных значений для маркировки состояния слота:

const (
    emptyRest      = 0 // Слот пуст, и все следующие тоже пустые
    emptyOne       = 1 // Слот пуст
    evacuatedX     = 2 // Эвакуирован в новый бакет (чётный)
    evacuatedY     = 3 // Эвакуирован в новый бакет (нечётный)
    evacuatedEmpty = 4 // Бакет полностью эвакуирован
    minTopHash     = 5 // Минимальное значение для обычного tophash
)

Если хеш ключа даёт tophash < 5, он корректируется до minTopHash, чтобы не конфликтовать со специальными значениями.

Итоговая схема работы

m[key] = value

1. hash = hasher(key, hash0)
2. bucket = hash & (2^B - 1)
3. top = hash >> 56 (старшие 8 бит)

4. Ищем в бакете:
   для i = 0..7:
     если tophash[i] == empty:
        записываем сюда новый элемент
     если tophash[i] == top и keys[i] == key:
        обновляем values[i]

5. Если не нашли пустой слот:
   идём в overflow-бакет

6. Если count > 6.5 * 8 * 2^B:
   запускаем рост map (hashGrow)
   постепенно эвакуируем старые бакеты

Производительность

Операция	Средний случай	Худший случай
Вставка	O(1)	O(n) при всех коллизиях
Поиск	O(1)	O(n)
Удаление	O(1)	O(n)
Рост	O(n) амортизированно	O(n)

В среднем бакет содержит 6-7 элементов, и поиск требует 1-2 сравнений. Overflow-бакеты редки при правильном хешировании.

Вопрос 7. Как реализовать многопоточный in-memory Redis (Get/Set) в Go для продакшена?

Таймкод: 01:07:15

Ответ собеседника: неполный. Кандидат предложил использовать sync.Map, но интервьюер подсказал, что sync.Map подходит только для случаев с большим количеством ядер и преимущественно для чтения, а в большинстве случаев лучше обычная map с блокировками. Обсудили проблему памяти: при заполнении памяти мапа увеличивается в 2 раза и может не влезть. Кандидат начал предлагать шардирование. Обсудили алгоритмы вытеснения из кэша (LRU, LFU) — кандидат не знал про LRU/LFU, предложил свой подход на основе частоты обращения и TTL. Для ускорения чтения кандидат предложил шардирование с выделением горячих кей в отдельные сегменты.

Правильный ответ:

Архитектура решения

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

┌─────────────────────────────────────────────────────────┐
│                     Client API                           │
│  Get(key) (string, bool)                                │
│  Set(key, value, ttl)                                   │
│  Delete(key)                                            │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│                   Sharded Store                          │
│  ┌─────────┐ ┌─────────┐        ┌─────────┐            │
│  │Shard 0  │ │Shard 1  │  ...   │Shard N  │            │
│  │mu+map   │ │mu+map   │        │mu+map   │            │
│  │lru list │ │lru list │        │lru list │            │
│  └─────────┘ └─────────┘        └─────────┘            │
│                                                          │
│  shard = hash(key) % numShards                           │
└─────────────────────────────────────────────────────────┘

Базовая реализация с шардированием

package cache

import (
    "hash/fnv"
    "sync"
    "time"
)

const (
    defaultShards   = 256
    defaultCapacity = 100000
)

type Value struct {
    Data      string
    ExpiresAt time.Time
}

type shard struct {
    mu      sync.RWMutex
    items   map[string]*entry
    lruHead *entry
    lruTail *entry
    size    int64
}

type entry struct {
    key       string
    value     Value
    prev      *entry
    next      *entry
    expiresAt time.Time
}

type Cache struct {
    shards    []*shard
    numShards int
    maxSize   int64
    onEvict   func(key string, value Value)
}

func New(shards int, maxSize int64) *Cache {
    if shards <= 0 {
        shards = defaultShards
    }
    c := &Cache{
        shards:    make([]*shard, shards),
        numShards: shards,
        maxSize:   maxSize,
    }
    for i := 0; i < shards; i++ {
        c.shards[i] = &shard{
            items: make(map[string]*entry),
        }
    }
    return c
}

func (c *Cache) getShard(key string) *shard {
    h := fnv.New32a()
    h.Write([]byte(key))
    return c.shards[h.Sum32()%uint32(c.numShards)]
}

Метод Set

func (c *Cache) Set(key string, value string, ttl time.Duration) {
    s := c.getShard(key)
    s.mu.Lock()
    defer s.mu.Unlock()

    exp := time.Now().Add(ttl)

    if e, ok := s.items[key]; ok {
        // Ключ уже существует — обновляем значение и перемещаем в голову LRU
        e.value = Value{Data: value, ExpiresAt: exp}
        e.expiresAt = exp
        s.moveToFront(e)
    } else {
        // Новый ключ
        e := &entry{
            key:       key,
            value:     Value{Data: value, ExpiresAt: exp},
            expiresAt: exp,
        }
        s.items[key] = e
        s.addToFront(e)
        s.size++

        // Проверяем необходимость вытеснения
        if s.size > c.maxShardsSize() {
            s.evictLRU()
        }
    }
}

func (c *Cache) maxShardsSize() int64 {
    return c.maxSize / int64(c.numShards)
}

Метод Get

func (c *Cache) Get(key string) (string, bool) {
    s := c.getShard(key)
    s.mu.Lock()
    defer s.mu.Unlock()

    e, ok := s.items[key]
    if !ok {
        return "", false
    }

    // Проверяем истечение TTL
    if time.Now().After(e.expiresAt) {
        s.deleteEntry(e)
        return "", false
    }

    // Перемещаем в голову LRU — элемент был использован
    s.moveToFront(e)
    return e.value.Data, true
}

LRU-список: операции

// Добавить элемент в голову списка (самый свежий)
func (s *shard) addToFront(e *entry) {
    e.prev = nil
    e.next = s.lruHead

    if s.lruHead != nil {
        s.lruHead.prev = e
    }
    s.lruHead = e

    if s.lruTail == nil {
        s.lruTail = e
    }
}

// Удалить элемент из списка
func (s *shard) removeFromList(e *entry) {
    if e.prev != nil {
        e.prev.next = e.next
    } else {
        s.lruHead = e.next
    }

    if e.next != nil {
        e.next.prev = e.prev
    } else {
        s.lruTail = e.prev
    }
}

// Переместить элемент в голову (при обращении)
func (s *shard) moveToFront(e *entry) {
    s.removeFromList(e)
    s.addToFront(e)
}

// Вытеснить наименее недавно использованный элемент
func (s *shard) evictLRU() {
    if s.lruTail == nil {
        return
    }
    victim := s.lruTail
    s.deleteEntry(victim)
}

func (s *shard) deleteEntry(e *entry) {
    s.removeFromList(e)
    delete(s.items, e.key)
    s.size--
}

Почему шардирование вместо одной глобальной блокировки

При одной sync.RWMutex на всю map все операции чтения и записи сериализуются. При шардировании блокировка берётся только на один из N шардов:

Одна блокировка:           256 шардов:
                          
Writer ──lock──→ map      Writer ──lock──→ shard[42]
Reader ──lock──→ map      Reader ──lock──→ shard[17]  ← параллельно!
Reader ──lock──→ map      Reader ──lock──→ shard[42]  ← блокирован writer'ом
                          Reader ──lock──→ shard[99]  ← параллельно!

При 256 шардах теоретически до 256 параллельных операций с разными ключами. На практике оптимальное количество шардов зависит от числа ядер и паттерна доступа.

Выбор хеш-функции для шардирования

// FNV-1a — быстрая и хорошая для строковых ключей
func (c *Cache) getShard(key string) *shard {
    h := fnv.New32a()
    h.Write([]byte(key))
    return c.shards[h.Sum32()%uint32(c.numShards)]
}

fnv.New3a() предпочтительнее crc32 или MD5, потому что:

В разы быстрее криптографических хешей.
Даёт достаточно равномерное распределение для строковых ключей.
Не требует синхронизации (каждый вызов создаёт новый hasher или использует pool).

Проблема горячих ключей

Если один ключ обрабатывается в 1000 раз чаще остальных, его шард становится бутылочным горлышком. Решения:

Вариант 1: Увеличение числа шардов

// Для 1000+ RPS на горячий ключ используйте 1024+ шардов
cache := New(1024, 1_000_000)

Вариант 2: Локальный кэш для горячих ключей

type hotKeyCache struct {
    mu      sync.RWMutex
    hotKeys map[string]*hotEntry // ← отдельная мапа без шардирования
}

type hotEntry struct {
    value     string
    expiresAt time.Time
    // Горячие ключи не вытесняются LRU, только по TTL
}

Фоновая очистка по TTL

Без фоновой очистки память будет расти до тех пор, пока не заполнится. Решение — периодический sweep:

func (c *Cache) startCleanup(interval time.Duration) {
    go func() {
        ticker := time.NewTicker(interval)
        defer ticker.Stop()

        for range ticker.C {
            c.cleanupExpired()
        }
    }}

func (c *Cache) cleanupExpired() {
    now := time.Now()

    for _, s := range c.shards {
        s.mu.Lock()

        // Идём с хвоста LRU — там самые старые элементы
        for s.lruTail != nil && now.After(s.lruTail.expiresAt) {
            victim := s.lruTail
            s.deleteEntry(victim)
        }

        s.mu.Unlock()
    }
}

Проблема роста map и памяти

Go map при росте выделяет новый массив бакетов в 2 раза больше текущего. Для map на 1 000 000 элементов это означает временное удвоение потребления памяти. Решения:

Предварительное выделение:

// При создании шарда задаём начальный размер
func newShard(capacity int) *shard {
    return &shard{
        items: make(map[string]*entry, capacity),
    }
}

// В конструкторе Cache:
for i := 0; i < shards; i++ {
    c.shards[i] = newShard(int(defaultCapacity) / shards)
}

Ограничение размера каждого шарда:

func (s *shard) evictLRU() {
    // Вытесняем 10% элементов шарда за раз
    target := int(float64(s.size) * 0.9)
    for s.size > target && s.lruTail != nil {
        victim := s.lruTail
        s.deleteEntry(victim)
    }
}

Сравнение sync.Map и map + RWMutex

Критерий	sync.Map	map + RWMutex	Sharded map + RWMutex
Много чтений, мало записей	Отлично	Хорошо	Хорошо
Много записей	Плохо	Плохо	Хорошо
Горячие ключи	Плохо	Плохо	Отлично
Память	Больше (2 map)	Меньше	Меньше
Вытеснение (LRU)	Невозможно	Возможно	Возможно

Когда использовать sync.Map

sync.Map имеет смысл, когда:

Ключи записываются один раз и читаются много раз (конфигурация, кэш компиляции).
Разные горутины работают с непересекающимися наборами ключей.
Нет необходимости в LRU/LFU вытеснении.

Полная реализация с метриками

type Cache struct {
    shards    []*shard
    numShards int
    maxSize   int64
    onEvict   func(key string, value Value)

    // Метрики
    hits   atomic.Int64
    misses atomic.Int64
}

func (c *Cache) Get(key string) (string, bool) {
    s := c.getShard(key)
    s.mu.RLock() // Сначала пробуем с RLock для скорости

    e, ok := s.items[key]
    if !ok || time.Now().After(e.expiresAt) {
        s.mu.RUnlock()
        c.misses.Add(1)

        if ok {
            // Истёк TTL — нужен Lock для удаления
            s.mu.Lock()
            s.deleteEntry(e)
            s.mu.Unlock()
        }
        return "", false
    }

    val := e.value.Data
    s.mu.RUnlock()

    // Перемещение в голову LRU требует Lock
    s.mu.Lock()
    s.moveToFront(e)
    s.mu.Unlock()

    c.hits.Add(1)
    return val, true
}

Продвинутые алгоритмы вытеснения

LFU (Least Frequently Used) — вытесняет элементы с наименьшим счётчиком обращений:

type lfuEntry struct {
    key       string
    value     Value
    frequency int64
    // Связный список элементов с одинаковой частотой
    next *lfuEntry
    prev *lfuEntry
}

W-TinyLFU — гибридный алгоритм, используемый в Caffeine (Java) и некоторых Go-кэшах. Комбинирует LFU с окном недавнего использования для адаптации к изменению паттерна доступа.

Ключевые выводы для продакшена

Шардирование обязательно при высокой нагрузке — одна глобальная блокировка убьёт производительность.
LRU через двусвязный список — стандартный и предсказуемый подход.
Предварительное выделение map экономит память и снижает задержки при росте.
Фоновая очистка по TTL предотвращает утечку памяти.
sync.Map — не универсальное решение; для кэша с вытеснением нужна обычная map + блокировки.

Вопрос 8. Как проходил процесс собеседования в Ozon и как получилось попасть туда с нулевым коммерческим опытом?

Таймкод: 02:04:06

Ответ собеседника: правильный. Кандидат рассказал, что первый коммерческий опыт получил нестандартным путём: знакомый разработчик дал ему переписать несколько проектов с Go на Go (фактически рефакторинг "лапши" кода с применением практик чистого кода и интерфейсов). Это был не отклик на вакансию, а скорее работа "по блату". В Ozon его пригласили сами — написали в WhatsApp, хотя он давно не откликался на вакансии. До этого он 5 месяцев обучения рассылал резюме на джун-вакансии, но не получил ни одного положительного отклика, после чего перестал откликаться и сосредоточился на обучении.

Правильный ответ:

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

Урок 1: Коммерческий опыт можно получить нестандартным путём

Рефакторинг "лапши" кода с применением практик чистого кода и интерфейсов — это полноценная коммерческая задача. Многие компании нанимают разработчиков именно для этого. Такой опыт ценен, потому что показывает способность работать с реальным кодом, а не только с учебными проектами.

Урок 2: Сетевые контакты работают

Фраза "по блату" — это не ругательство, а описание реального механизма найма в IT. По различным оценкам, от 40% до 70% вакансий в IT закрываются через рекомендации. Знакомый разработчик, который передал проект — это типичный пример того, как работает нетворкинг.

Урок 3: Рекрутеры ищут кандидатов проактивно

То, что Ozon написал сам — это нормальная практика. Крупные компании имеют внутренние базы кандидатов и рекрутеров, которые мониторят профили на GitHub, LinkedIn, Habr. Даже если вы не откликаетесь на вакансии, ваш профиль может быть найден.

Урок 4: Пять месяцев без отклика — это нормально

Рынок junior-разработчиков перегрет. Отправка 100+ резюме без ответа — типичная ситуация. Кандидат поступил правильно, сосредоточившись на обучении вместо бесконечной рассылки резюме.

Рекомендации для подготовки

Если вы находитесь в похожей ситуации — с нулевым коммерческим опытом:

Делайте pet-проекты с публичным кодом на GitHub. Это ваше портфолио.
Участвуйте в open-source. Даже мелкие pull request'ы в известные проекты — это опыт.
Пишите технические статьи. Это демонстрирует глубину понимания.
Посещайте митапы и конференции. Нетворкинг — самый эффективный способ получить первую работу.
Не прекращайте учиться. Пять месяцев обучения без отклика — это инвестиция в будущее.

Типичный процесс собеседования в крупные IT-компании

Хотя кандидат не раскрыл детали процесса в Ozon, типичный процесс включает:

Скрининг с рекрутером (30 минут) — обсуждение опыта, ожиданий, зарплатных вилок.
Техническое интервью (60-90 минут) — вопросы по языку программирования, алгоритмам, архитектуре.
Системный дизайн (45-60 минут) — проектирование системы (для middle+).
Софт-скиллы / культурный фит (30-45 минут) — поведенческие вопросы, работа в команде.

Вывод

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

Вопрос 1. Что выведется при передаче слайса в функцию и изменении его длины внутри функции?​

Вопрос 2. Как вывести все элементы базового массива слайса, не меняя функцию и не используя указатели?​

Вопрос 3. Как обработать миллион URL с HTTP-запросами с использованием worker pool?​

Вопрос 4. Что произойдёт при конкурентной записи в map из нескольких горутин?​

Вопрос 5. Что выведет программа с каналом структур, где горутина пишет, а main сразу читает?​

Вопрос 6. Как устроена мапа в Go под капотом: структура, бакеты, хеширование, эвакуация данных при росте?​

Вопрос 7. Как реализовать многопоточный in-memory Redis (Get/Set) в Go для продакшена?​

Вопрос 8. Как проходил процесс собеседования в Ozon и как получилось попасть туда с нулевым коммерческим опытом?​

Вопрос 1. Что выведется при передаче слайса в функцию и изменении его длины внутри функции?

Вопрос 2. Как вывести все элементы базового массива слайса, не меняя функцию и не используя указатели?

Вопрос 3. Как обработать миллион URL с HTTP-запросами с использованием worker pool?

Вопрос 4. Что произойдёт при конкурентной записи в map из нескольких горутин?

Вопрос 5. Что выведет программа с каналом структур, где горутина пишет, а main сразу читает?

Вопрос 6. Как устроена мапа в Go под капотом: структура, бакеты, хеширование, эвакуация данных при росте?

Вопрос 7. Как реализовать многопоточный in-memory Redis (Get/Set) в Go для продакшена?

Вопрос 8. Как проходил процесс собеседования в Ozon и как получилось попасть туда с нулевым коммерческим опытом?