❓ Можно ли присвоить int переменной типа int64 без преобразования

Нет. Это разные типы, даже если на текущей платформе они одного размера. Неявных числовых преобразований в Go нет, нужна явная конверсия int64(x).

🐸 Библиотека Go для собеса

❓ Как найти два числа с заданной суммой за O(n)

Наивное решение это два вложенных цикла и O(n²). Оптимальное использует map. Для каждого элемента вычисляем complement = target - s[i] и смотрим, есть ли он уже в map. Если есть, нашли пару. Если нет, кладём текущий элемент в map и идём дальше.

func twoSum(nums []int, target int) (int, int) {
    seen := make(map[int]int) // значение -> индекс
    for i, v := range nums {
        if j, ok := seen[target-v]; ok {
            return j, i
        }
        seen[v] = i
    }
    return -1, -1
}

Сначала ищем complement в map, только потом добавляем текущий элемент. Это защищает от ложного совпадения с самим собой при target = 2 * v.

🐸 Библиотека Go для собеса

❓ Что произойдёт при переполнении целого числа

При переполнении целого числа в Go значение не вызывает ошибку, а «переворачивается» внутри допустимого диапазона. Это поведение называется wrap-around: если значение превышает максимальное, оно продолжает отсчёт с минимального значения, и наоборот.

Поэтому переполнение нужно ловить проверками вручную. В константном выражении компилятор поймает его на этапе сборки, а в рантайме нет.

🐸 Библиотека Go для собеса

❓ Как сдвинуть срез на k позиций вправо

Есть несколько подходов. Самый элегантный через три разворота. Разворачиваем весь срез, потом первые k элементов, потом оставшиеся. Три операции, каждая O(n), итого O(n). Память O(1).

func rotate(s []int, k int) {
    n := len(s)
    k = k % n
    rev := func(a []int) {
        for i, j := 0, len(a)-1; i < j; i, j = i+1, j-1 {
            a[i], a[j] = a[j], a[i]
        }
    }
    rev(s)
    rev(s[:k])
    rev(s[k:])
}

k % n обязателен: если k >= n, сдвиг зацикливается. Без этого для k = n мы получим обратный срез вместо исходного.

🐸 Библиотека Go для собеса

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

time.Sleep — антипаттерн: вы не знаете нужную задержку заранее, и это не масштабируется.

Буферизованный канал здесь работает как предохранитель. Сервер пишет в канал, отдельная горутина читает из него и отправляет клиенту. Если буфер заполнен, то клиент не успевает читать, и это сигнал закрыть стрим с понятной ошибкой вместо того, чтобы копить данные в памяти бесконечно.

Рядом с буферизованным каналом обычно стоят ещё два инструмента. Контекст с дедлайном нужен чтобы не ждать вечно зависшего клиента. Тикер — для периодических keepalive-пингов, чтобы убедиться, что соединение живо и клиент на том конце вообще ещё читает.

🐸 Библиотека Go для собеса

❓ Чем отличается деление на ноль для целых чисел и для float

Для целых типов деление на ноль — это паника. Программа сразу падает с ошибкой division by zero, потому что результат такой операции в рамках целочисленной арифметики не определён.

Для float32 / float64 деление на ноль допустимо и подчиняется стандарту IEEE 754. Вместо ошибки получаются специальные значения: +Inf, -Inf, Nan.

🐸 Библиотека Go для собеса

❓ Что такое sliding window и когда его применять

Sliding window это приём для задач, где нужно найти подмассив или подстроку, удовлетворяющие условию. Вместо перебора всех пар (i, j) за O(n²) мы поддерживаем окно с двумя границами и двигаем их по условию.

Приём подходит, когда нужно найти минимальную или максимальную длину подмассива с суммой >= target, найти подстроку без повторяющихся символов, найти все анаграммы паттерна в строке. Окно бывает фиксированного размера или динамическим.

// минимальный подмассив с суммой >= target
func minSubarrayLen(target int, nums []int) int {
    left, sum, res := 0, 0, len(nums)+1
    for right := range nums {
        sum += nums[right]
        for sum >= target {
            if right-left+1 < res {
                res = right - left + 1
            }
            sum -= nums[left]
            left++
        }
    }
    if res == len(nums)+1 {
        return 0
    }
    return res
}

🐸 Библиотека Go для собеса

❓ Почему большой int64 может исказиться при разборе JSON

JSON по спецификации не имеет строгих типов int32/int64 — там есть только number, а в Go при разборе encoding/json число сначала парсится в float64, если не указан конкретный тип.

Есть несколько решений:

Использовать строки для больших чисел:

{"id": "9223372036854775807"}

Использовать json.Decoder.UseNumber():

dec := json.NewDecoder(r)
dec.UseNumber()

Кастомный Unmarshal

Читать как json.Number и вручную конвертировать в int64

🐸 Библиотека Go для собеса

❓ Как объединить два отсортированных среза в один

Классическая операция из mergesort. Заводим три указателя: i для a, j для b, k для результата. Сравниваем текущие элементы обоих срезов и берём меньший. После того как один из срезов закончился, дописываем остаток другого.

func mergeSorted(a, b []int) []int {
    res := make([]int, 0, len(a)+len(b))
    i, j := 0, 0
    for i < len(a) && j < len(b) {
        if a[i] <= b[j] {
            res = append(res, a[i])
            i++
        } else {
            res = append(res, b[j])
            j++
        }
    }
    res = append(res, a[i:]...)
    res = append(res, b[j:]...)
    return res
}

a[i:]... добавляет хвост одной операцией без лишнего цикла. Сложность O(n + m) по времени, O(n + m) по памяти на результат.

🐸 Библиотека Go для собеса

❓ Какого типа результат len и можно ли индексировать срез значением int64

len и cap возвращают int, индексы тоже имеют тип int. Индексировать срез значением int64 напрямую нельзя, нужна конверсия к int. Из-за этого длина среза ограничена размером int на платформе.

🐸 Библиотека Go для собеса

❓ У вас есть map[int]Record. Несколько горутин читают и пишут в него одновременно. Что произойдёт

Go рантайм с версии 1.6 содержит детектор конкурентных записей в map. При одновременной записи из нескольких горутин программа завершится с паникой concurrent map writes — намеренно, чтобы не допустить повреждения данных.
 
Но детектор срабатывает не всегда: он вероятностный. Поэтому полагаться на него как на защиту нельзя.
 
Правильные решения в зависимости от нагрузки: sync.RWMutex вокруг map, sync.Map для случаев с редкими записями и частыми чтениями, или шардирование — несколько map с отдельными мьютексами.

🐸 Библиотека Go для собеса

❓ Разработчик создаёт time.NewTicker внутри цикла и забывает вызвать ticker.Stop(). Что произойдёт

time.NewTicker регистрирует таймер в runtime heap таймеров. Раньше GC не собирал тикеры автоматически — они жили, пока не будет вызван Stop().

Начиная с Go 1.23 ситуация изменилась: garbage collector теперь может собирать неиспользуемые тикеры, если на них больше нет ссылок. То есть забытый Stop() больше не гарантирует утечку памяти.

⚠️ Важно

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

Это по-прежнему может проявляться как постепенный рост потребления памяти и деградация производительности под нагрузкой — просто теперь причина не всегда в самом факте отсутствия Stop(), а в удержании ссылок.

Как это поймать

go tool pprof с профилем goroutines покажет горутины, заблокированные на чтении из каналов тикеров. Heap-профиль может показать рост объектов, связанных с таймерами.

🐸 Библиотека Go для собеса

❓ Чем io.EOF отличается от io.ErrUnexpectedEOF? В каком случае Read должен возвращать EOF, а в каком — ErrUnexpectedEOF

io.EOF — сигнал о штатном конце данных. Read возвращает его когда источник исчерпан и больше нечего читать. Это не ошибка в смысле «что-то пошло не так» — это нормальное завершение потока.

По спецификации io.Reader, EOF может прийти либо вместе с последними байтами (n > 0, err == io.EOF), либо отдельным вызовом (n == 0, err == io.EOF). Оба варианта корректны — поэтому правильный код всегда сначала обрабатывает прочитанные байты, потом проверяет ошибку.

io.ErrUnexpectedEOF — сигнал о том, что поток закончился в неожиданном месте. Источник данных иссяк раньше, чем ожидалось по протоколу или по запросу.

Типичный пример — io.ReadFull. Функция просит ровно len(buf) байт. Если источник вернул EOF до того, как буфер заполнен, ReadFull транслирует это в ErrUnexpectedEOF.

🐸 Библиотека Go для собеса

❓ Вам нужно итерироваться по map[string]int и получать элементы всегда в одном и том же порядке. Какой подход использовать

Порядок итерации по map в Go намеренно рандомизирован с версии 1.0. Это сделано специально, чтобы разработчики не полагались на порядок как на гарантию.
 
Надёжный способ: keys := make([]string, 0, len(m)) → заполнить ключами → sort.Strings(keys) → итерироваться по слайсу, читая значения из map.
 
Отдельный вопрос со звёздочкой: если ключи — числа, а не строки, тип ключа влияет на аллокации при сортировке. []int с sort.Ints не аллоцирует лишнего, тогда как конвертация в []interface{} для универсальной сортировки создаёт нагрузку на GC при большом количестве элементов.

🐸 Библиотека Go для собеса

❓ Что возвращает append

append добавляет элементы в конец слайса и возвращает обновлённый слайс. Сам аргумент он менять не обязан, потому что при нехватке места выделяется новый базовый массив, и старая переменная продолжит указывать на старые данные. Поэтому пишут так.

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

🐸 Библиотека Go для собеса

❓ Что возвращает copy и сколько элементов он копирует

copy копирует элементы из исходного слайса в целевой и возвращает число скопированных элементов. Это число равно минимуму из len(dst) и len(src). Лишние элементы источника просто игнорируются, ошибки не будет.

src := []int{1, 2, 3, 4}
dst := make([]int, 2)
n := copy(dst, src)
fmt.Println(n, dst) // 2 [1 2]

🐸 Библиотека Go для собеса