Разбор задач с собеседований по Go

26 марта 2024 г. · 34 мин. чтения

Сегодня мы разберём разбор двух алгоритмических задач на Go: первая — задача на аккуратное написание кода (сжатие последовательных чисел в отрезки), вторая — задача на многопоточность (реализация собственной версии errgroup с обработкой паник и сбором ошибок). Ведущий Саша, разработчик из Яндекс с опытом в бигтехе, подробно разбирает решения, обсуждает корнер-кейсы, типичные ошибки кандидатов и критерии оценки на собеседованиях.

Вопрос 1. Расскажите о менторской программе «Навыки» и как она работает.

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

Ответ собеседника: Правильный. Программа «Навыки» — это менторская программа, в которой более 300 менторов и более 700 проведённых занятий. Менторы помогли трудоустроить участников в компании Amazon, VK, Ozon, Сбер и другие. Процесс начинается с смок-интервью, после которого составляется план занятий и фидбек от ментора. Исходя из пробелов в знаниях, ментор и менти вместе проходят занятия. Ментор поддерживает в чате между занятиями, а также помогает с трудоустройством. Стоимость мок-интервью — 3900 рублей, на вебинаре действует скидка — 2900 рублей.

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

Программа «Навыки» — это структурированная менторская программа, направленная на подготовку разработчиков к прохождению технических интервью и успешному трудоустройству в ведущие IT-компании.

Масштаб программы

На момент проведения интервью в программе задействовано более 300 менторов и проведено свыше 700 занятий. Выпускники программы были трудоустроены в такие компании, как Amazon, VK, Ozon, Сбер и другие.

Как устроен процесс

Смок-интервью (mock interview) — это входная точка в программу. Ментор проводит пробное интервью, максимально приближённое к реальному, чтобы оценить текущий уровень кандидата.
Составление плана занятий — по результатам смок-интервью ментор даёт развёрнутый фидбек и совместно с менти формирует индивидуальный план подготовки, ориентированный на выявленные пробелы в знаниях.
Проведение занятий — ментор и менти проходят серию занятий, в ходе которых разбираются темы, необходимые для успешного прохождения интервью (алгоритмы, структуры данных, системный дизайн, язык программирования и т.д.).
Поддержка в чате — между занятиями ментор остаётся на связи, отвечает на вопросы и помогает с возникающими затруднениями.
Помощь с трудоустройством — ментор также оказывает содействие в подготовке резюме, прохождении интервью и трудоустройстве в целевые компании.

Стоимость

Стоимость смок-интервью составляет 3900 рублей, при покупке на вебинаре действует скидка — стоимость снижается до 2900 рублей.

Вопрос 2. Расскажите о себе и своём опыте работы.

Таймкод: 00:03:45

Ответ собеседника: Правильный. Имя — Саша, работает в бигтехе, ранее работал в Озоне, сейчас работает в Яндексе. Занимается разными проектами: беспилотники, поиск, статический анализ языков программирования. Имеет большой опыт работы на Go, много нанимал Go-разработчиков в бигтех, поэтому пришёл делиться опытом о популярных задачах и проблемах на собеседованиях.

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

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

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

Кратко представиться — назвать имя и текущую роль. Не нужно пересказывать всё резюме дословно — интервьюер его уже видел.
Обозначить ключевые места работы — упомянуть наиболее релевантные компании и проекты. В данном случае кандидат корректно указал Озон и Яндекс, что сразу формирует представление о его уровне.
Описать область экспертизы — беспилотники, поиск, статический анализ языков программирования. Это показывает широту опыта и глубину технических знаний.
Связать опыт с контекстом интервью — кандидат упомянул, что много нанимал Go-разработчиков, что объясняет его мотивацию и компетентность в проведении собеседований.

Чего стоит избегать

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

Оптимальная длительность ответа — 1–2 минуты. Ответ должен быть лаконичным, структурированным и релевантным вакансии, на которую проходит собеседование.

Вопрос 3. Будет ли запись стрима?

Таймкод: 00:05:31

Ответ собеседника: Правильный. Да, запись будет доступна через неделю на сайте.

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

Да, запись стрима будет доступна примерно через неделю на сайте программы «Навыки». Это стандартная практика для вебинаров и стримов — запись публикуется после обработки, чтобы участники, которые не смогли присутствовать в реальном времени, могли ознакомиться с материалом в удобное время.

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

Вопрос 4. Как вы оцениваете уровень кандидата и какие критерии используете для определения грейда (начальный, средний, продвинутый)?

Таймкод: 00:07:32

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

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

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

1. Процесс решения задачи (Problem-Solving)

Это, пожалуй, самый важный критерий. Интервьюер наблюдает за тем, как кандидат подходит к задаче:

Задаёт уточняющие вопросы перед тем, как начать решать.
Рассматривает граничные случаи (edge cases).
Способен ли кандидат самостоятельно прийти к оптимальному решению или ему нужны подсказки.
Как кандидат реагирует на затруднения — замыкается в себе или продолжает рассуждать вслух.

2. Качество кода

Читаемость и структурированность кода.
Использование осмысленных имён переменных и функций.
Следование идиомам языка (в случае Go — идиоматический Go).
Обработка ошибок.

3. Глубина знаний языка и технологий

Понимание внутреннего устройства языка (горутины, планировщик, сборщик мусора в случае Go).
Знание стандартной библиотеки.
Понимание конкурентности и параллелизма.

4. Коммуникация

Способность объяснить своё решение.
Готовность обсуждать альтернативные подходы.
Умение принимать фидбек и корректировать решение.

Как это соотносится с грейдами

Junior (начальный): Нуждается в подсказках, решает задачу с помощью интервьюера. Код может быть не оптимальным, но рабочим. Базовое понимание языка.
Middle (средний): Самостоятельно решает задачу, возможно, не с первого раза. Пишет чистый код, понимает основные концурентные примитивы. Может обосновать свой выбор.
Senior (продвинутый): Быстро находит оптимальное решение, учитывает граничные случаи без напоминаний. Пишет идиоматический код, предлагает альтернативные подходы. Глубоко понимает внутреннее устройство языка и может объяснить trade-offs различных решений.

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

Вопрос 5. Стоит ли идти в менторскую программу, если вы новичок в Go и только начинаете его изучать?

Таймкод: 00:09:04

Ответ собеседника: Неполный. Вопрос был отложен для обсуждения с Димой позже, прямого ответа в данном фрагменте не прозвучало.

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

Это хороший вопрос, и ответ на него зависит от ваших целей и текущего уровня подготовки.

Когда программа будет полезна новичку

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

Когда стоит повременить

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

Рекомендация

Прежде чем записываться на программу, рекомендуется:

Пройти базовый курс по Go (например, «A Tour of Go» с официального сайта).
Написать несколько небольших проектов самостоятельно.
Попробовать решить несколько задач на LeetCode или Codewars на Go.
После этого смок-интервью даст более точную картину ваших пробелов, и ментор сможет составить действительно полезный план подготовки.

Таким образом, программа будет наиболее эффективна для тех, кто уже имеет базовый уровень владения Go и хочет целенаправленно подготовиться к техническим интервью.

Вопрос 6. Можно ли купить курс для подготовки к алгоритмическим задачам и к систем дизайну, или нужно строго следовать заранее составленному скрипту?

Таймкод: 00:09:11

Ответ собеседника: Неполный. Вопрос был отложен для обсуждения с Димой позже. Было упомянуто, что на «Навыках» есть и систем дизайн, и алгоритмические задачи, и можно отходить от скрипта, если вы сами понимаете, что вам нужно, и хотите валидацию знаний.

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

Программа «Навыки» предлагает гибкий подход к подготовке, и строгого следования заранее составленному скрипту не требуется.

Что доступно в программе

В рамках программы можно подготовиться к различным типам интервью:

Алгоритмические задачи — разбор структур данных, алгоритмов, паттернов решения задач, характерных для технических интервью в крупные компании.
Системный дизайн (System Design) — проектирование распределённых систем, выбор архитектурных решений, обоснование trade-offs.
Специфические темы по Go — конкурентность, внутреннее устройство языка, стандартная библиотека.

Гибкость программы

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

Рекомендация

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

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

Вопрос 7. Задача LeetCode 228 — Summary Ranges: дан отсортированный массив уникальных целых чисел, нужно вернуть список строк, представляющих непрерывные диапазоны чисел. Как решить эту задачу и на что обратить внимание?

Таймкод: 00:11:05

Ответ собеседника: Правильный. Задача на аккуратное написание кода, без сложных алгоритмов. Алгоритм линейный: проверка пустого массива, инициализация переменных start и prev первым элементом, итерация со второго элемента. Если текущий элемент отличается от prev больше чем на 1 — заканчивается отрезок: добавляем в ответ диапазон от start до prev (если start == prev — просто одно число, иначе строка со стрелкой). После цикла обязательно добавить последний отрезок. Инвариант: start — начало текущего отрезка, prev — посещённое значение. Не рекомендуется сравнивать элемент со следующим (i+1), так как на последнем элементе выйдем за границу массива. Важно заранее продумывать тест-кейсы: пустой массив, один элемент, один отрезок, все отрезки из одной точки, разрывы посередине. Это тоже часть проверки кандидата.

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

Задача LeetCode 228 «Summary Ranges» — это классическая задача на аккуратность написания кода. Она не требует знания сложных алгоритмов, но проверяет умение кандидата писать корректный, чистый код и думать о граничных случаях.

Условие задачи

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

Диапазон [a, b] представляется как "a->b", если a != b, и как "a", если a == b.

Алгоритм решения

Проверить, что массив не пустой.
Инициализировать переменные start и prev первым элементом массива.
Итерироваться со второго элемента. Для каждого элемента:
- Если текущий элемент отличается от prev больше чем на 1, значит текущий непрерывный отрезок закончился — добавляем диапазон от start до prev в результат.
- Обновляем start текущим элементом.
- Обновляем prev текущим элементом.
После завершения цикла обязательно добавить последний отрезок (от start до prev).

Инвариант цикла: start — начало текущего непрерывного отрезка, prev — последний посещённый элемент.

Решение на Go

func summaryRanges(nums []int) []string {
    if len(nums) == 0 {
        return nil
    }

    var result []string
    start := nums[0]

    for i := 1; i < len(nums); i++ {
        if nums[i] != nums[i-1]+1 {
            result = append(result, formatRange(start, nums[i-1]))
            start = nums[i]
        }
    }

    // Добавляем последний отрезок
    result = append(result, formatRange(start, nums[len(nums)-1]))

    return result
}

func formatRange(start, end int) string {
    if start == end {
        return strconv.Itoa(start)
    }
    return strconv.Itoa(start) + "->" + strconv.Itoa(end)
}

На что обратить внимание

Сравнение с предыдущим элементом, а не со следующим. Многие кандидаты пытаются сравнивать nums[i] с nums[i+1], что приводит к необходимости отдельно обрабатывать последний элемент или риску выхода за границу массива. Сравнение с nums[i-1] — более элегантный и безопасный подход.

Обработка последнего отрезка. После завершения цикла последний непрерывный отрезок ещё не добавлен в результат. Это частая ошибка — забыть добавить его.

Граничные случаи (edge cases):

Пустой массив — вернуть пустой список.
Массив из одного элемента — вернуть один элемент без стрелки.
Весь массив — один непрерывный диапазон.
Все элементы изолированы (каждый отрезок из одной точки).
Разрывы в середине массива.

Сложность: O(n) по времени и O(1) дополнительной памяти (не считая выходного массива).

Почему эта задача важна на интервью

Задача проверяет не знание сложных алгоритмов, а базовую аккуратность: умение продумывать граничные случаи, писать чистый код, следить за инвариантами и не допускать off-by-one ошибки. Это именно то, что отличает сильного кандидата от слабого на уровне написания кода.

Вопрос 8. Нужно ли в решении задачи проверять входные данные на валидность или можно принять их как гарантированные?

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

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

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

Это отличный вопрос, который часто возникает на собеседованиях. Ответ действительно зависит от контекста, но есть несколько общих принципов.

Когда валидация не нужна

Если в условии задачи явно указаны гарантии — например, «дан отсортированный массив уникальных целых чисел», «длина массива ≥ 1», «строка содержит только строчные латинские буквы» — то дополнительные проверки избыточны. В этом случае кандидат должен явно использовать эти гарантии в своём решении (например, не сортировать массив, а использовать тот факт, что он уже отсортирован).

Когда валидация ожидается

Если условие задачи не даёт явных гарантий, хороший тон — задать интервьюеру уточняющий вопрос: «Могу ли я предположить, что входные данные валидны?» или «Нужно ли обрабатывать случай, когда массив пустой?». Это демонстрирует зрелость кандидата и его привычку думать о граничных случаях.

Общий подход на интервью

Прочитать условие внимательно — проверить, какие гарантии даны.
Задать уточняющие вопросы — если что-то неясно, спросить интервьюера.
Упомянуть о валидации — даже если решать её не нужно, хорошо сказать: «В реальном коде я бы добавил проверку на пустой массив, но по условию задачи длина ≥ 1, поэтому пропущу эту проверку». Это показывает, что кандидат думает о робастности кода.

В реальной разработке

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

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

Вопрос 9. Как бы вы оценили решение задачи Summary Ranges и на что обращаете внимание при проверке?

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

Ответ собеседника: Правильный. Оценивается процесс решения, а не заученное решение. Кандидат должен сам придумать алгоритм, глядя на примеры, понять закономерность и реализовать корректно. Важно: понимает ли кандидат что нужно правильно проинициализировать начальное состояние и поддерживать инварианты, или пишет код от балды. Также важно обрабатывать плохие случаи — пустой вход, проверки валидности индексов при обращении к элементам массива (чтобы не выйти за границы). Рекомендуется сразу писать проверку на пустые входные данные и везде, где есть индексирование с i+1, писать проверки валидности индекса.

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

При оценке решения задачи Summary Ranges интервьюер обращает внимание на несколько ключевых аспектов, которые в совокупности формируют представление о уровне кандидата.

1. Процесс решения, а не результат

Главное — это не то, заучил ли кандидат решение, а то, как он пришёл к нему. Сильный кандидат:

Анализирует примеры из условия задачи.
Выявляет закономерность (непрерывные последовательности чисел).
Формулирует алгоритм словами перед тем, как писать код.
Обсуждает подход с интервьюером.

2. Инициализация и инварианты

Это критически важный момент. Кандидат должен понимать:

Как правильно проинициализировать начальное состояние (start и prev).
Какой инвариант поддерживается в цикле.
Что происходит при завершении цикла (не забыть добавить последний отрезок).

Если кандидат сразу начинает писать код, не подумав об инициализации и инвариантах, это сигнал о том, что он пишет «от балды», а не осознанно.

3. Обработка граничных случаев

Пустой массив — кандидат должен проверить это в начале.
Массив из одного элемента.
Выход за границы массива — особенно если кандидат использует сравнение с nums[i+1].

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

if len(nums) == 0 {
    return nil
}

4. Корректность индексации

Если кандидат выбирает подход с сравнением nums[i] и nums[i+1], он должен осознавать риск выхода за границу массива и корректно обработать последний элемент. Подход с сравнением nums[i] и nums[i-1] предпочтительнее, так как он безопаснее и элегантнее.

5. Чистота кода

Осмысленные имена переменных (start, prev, а не a, b, x).
Вынос форматирования диапазона в отдельную функцию.
Отсутствие избыточных проверок и дублирования кода.

6. Тестирование

Сильный кандидат после написания кода прогоняет его на нескольких тест-кейсах:

Пустой массив.
Один элемент: [5] → ["5"].
Один диапазон: [1, 2, 3] → ["1->3"].
Все изолированы: [1, 3, 5] → ["1", "3", "5"].
Смешанный случай: [0, 1, 2, 4, 5, 7] → ["0->2", "4->5", "7"].

Если кандидат самостоятельно предлагает протестировать код на различных входных данных — это большой плюс и показатель зрелого подхода к разработке.

Вопрос 10. Реализуйте упрощённую версию sync.ErrGroup на Go — структуру SynGroup с методами Go (запуск функции в горутине) и Wait (ожидание завершения всех горутин и возврат агрегированной ошибки). Функции могут возвращать ошибку или паниковать. Как это сделать, какие подводные камни есть и какие есть альтернативные подходы?

Таймкод: 00:47:02

Ответ собеседника: Правильный. Задача проверяет владение многопоточными инструментами Go и синхронизацией между горутинами. Решение с каналом: структура SynGroup содержит errChan (канал ошибок) и WaitGroup. Метод Go запускает функцию в горутине через анонимную функцию с defer/recover для перехвата паник. Ошибки и паник отправляются в канал. Метод Wait запускает отдельную горутину, которая ждёт WaitGroup и закрывает канал. Параллельно ошибки читаются из канала через for range и собираются в кастомный тип ошибки (слайс ошибок с методом Error()). Ключевой подводный камень: нельзя сначала ждать WaitGroup, а потом читать канал — это deadlock, так как горутины заблокируются при записи в небуферизованный канал, а Wait ждёт их завершения. Альтернативный подход без каналов: использовать sync.Mutex и слайс ошибок — горутины записывают ошибки напрямую в слайс под локом, а Wait просто возвращает собранные ошибки после завершения всех горутин. Этот подход проще и читабельнее, не требует закрытия каналов и не имеет проблем с deadlock. Каналы в Go предназначены для передачи сигналов между горутинами в реальном времени, а не для простого сбора результатов.

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

Это классическая задача на собеседованиях для Go-разработчиков, которая проверяет глубокое понимание конкурентности, примитивов синхронизации и обработки паник.

Условие задачи

Реализовать структуру SynGroup с методами:

Go(f func() error) — запускает функцию f в отдельной горутине.
Wait() error — ожидает завершения всех запущенных горутин и возвращает агрегированную ошибку (если были ошибки или паники).

Подход 1: Решение с каналами

package main

import (
    "fmt"
    "strings"
    "sync"
)

type SynGroup struct {
    wg      sync.WaitGroup
    errChan chan error
}

func NewSynGroup() *SynGroup {
    return &SynGroup{
        errChan: make(chan error, 0), // небуферизованный канал
    }
}

func (g *SynGroup) Go(f func() error) {
    g.wg.Add(1)
    go func() {
        defer g.wg.Done()
        defer func() {
            if r := recover(); r != nil {
                g.errChan <- fmt.Errorf("panic: %v", r)
            }
        }()
        if err := f(); err != nil {
            g.errChan <- err
        }
    }()
}

func (g *SynGroup) Wait() error {
    // Запускаем горутину, которая закроет канал после завершения всех горутин
    go func() {
        g.wg.Wait()
        close(g.errChan)
    }()

    // Параллельно читаем ошибки из канала
    var errs []error
    for err := range g.errChan {
        errs = append(errs, err)
    }

    if len(errs) > 0 {
        return &multiError{errs: errs}
    }
    return nil
}

type multiError struct {
    errs []error
}

func (m *multiError) Error() string {
    var sb strings.Builder
    for i, err := range m.errs {
        if i > 0 {
            sb.WriteString("; ")
        }
        sb.WriteString(err.Error())
    }
    return sb.String()
}

Критический подводный канал с каналами

Нельзя в методе Wait сначала вызвать g.wg.Wait(), а потом читать из канала:

// НЕПРАВИЛЬНО — приведёт к deadlock!
func (g *SynGroup) Wait() error {
    g.wg.Wait()        // Ждём завершения всех горутин
    // Но горутины заблокировались при записи в небуферизованный канал,
    // потому что никто не читает из него → deadlock!
    var errs []error
    for err := range g.errChan {
        errs = append(errs, err)
    }
    // ...
}

Это происходит потому, что небуферизованный канал блокирует отправителя, пока нет получателя. Горутины не могут завершиться (и вызвать wg.Done()), пока не запишут ошибку в канал, а wg.Wait() не может завершиться, пока горутины не вызовут wg.Done().

Решение: Запускать wg.Wait() и close(errChan) в отдельной горутине, а в основном потоке параллельно читать из канала через for range.

Подход 2: Решение с sync.Mutex (предпочтительный)

package main

import (
    "fmt"
    "strings"
    "sync"
)

type SynGroup struct {
    wg    sync.WaitGroup
    mu    sync.Mutex
    errs  []error
}

func (g *SynGroup) Go(f func() error) {
    g.wg.Add(1)
    go func() {
        defer g.wg.Done()
        defer func() {
            if r := recover(); r != nil {
                g.mu.Lock()
                g.errs = append(g.errs, fmt.Errorf("panic: %v", r))
                g.mu.Unlock()
            }
        }()
        if err := f(); err != nil {
            g.mu.Lock()
            g.errs = append(g.errs, err)
            g.mu.Unlock()
        }
    }()
}

func (g *SynGroup) Wait() error {
    g.wg.Wait()

    if len(g.errs) > 0 {
        return &multiError{errs: g.errs}
    }
    return nil
}

type multiError struct {
    errs []error
}

func (m *multiError) Error() string {
    var sb strings.Builder
    for i, err := range m.errs {
        if i > 0 {
            sb.WriteString("; ")
        }
        sb.WriteString(err.Error())
    }
    return sb.String()
}

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

Аспект	Каналы	Mutex
Сложность	Выше (нужна отдельная горутина для закрытия канала)	Ниже
Риск deadlock	Есть	Отсутствует
Читаемость	Ниже	Выше
Применимость	Когда нужна потоковая обработка ошибок в реальном времени	Для простого сбора результатов

Ключевые моменты

Перехват паник — обязательно использовать defer recover() в каждой горутине, чтобы паника в одной горутине не убила всю программу.
Потокобезопасность — при использовании канала он сам по себе обеспечивает синхронизацию записи. При использовании слайса ошибок необходим sync.Mutex.
Агрегация ошибок — нужно реализовать кастомный тип ошибки, реализующий интерфейс error, который объединяет несколько ошибок в одну строку.
Каналы vs Mutex — каналы в Go предназначены для передачи сигналов и данных между горутинами. Для простого сбора результатов sync.Mutex — более подходящий и простой инструмент. Использование каналов для этой задачи — это усложнение без необходимости.

Вопрос 11. Можно ли будет посмотреть третью задачу (SQL), которую не успели разобрать на стриме?

Таймкод: 01:18:03

Ответ собеседника: Правильный. Третья задача будет разослана вместе с записью стрима.

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

Да, третья задача (по SQL) будет разослана участникам вместе с записью стрима. Запись обычно доступна через неделю после проведения стрима на сайте программы «Навыки». Рекомендуется подписаться на уведомления, чтобы не пропустить момент публикации и получить доступ ко всем материалам, включая разбор SQL-задачи.

Вопрос 12. Можно ли выбрать конкретного ментора в программе «Навыки» или его назначают случайно? Работаете ли вы с кандидатами из-за пределов РФ?

Таймкод: 01:25:26

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

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

Программа «Навыки» предоставляет гибкий подход к выбору ментора и работает с кандидатами по всему миру.

Выбор ментора

Ментор не назначается случайно. Процесс подбора выглядит следующим образом:

Заполнение формы — при регистрации кандидат указывает свой текущий грейд (junior, middle, senior), а также темы, на которые хочет сделать акцент в обучении (алгоритмы, системный дизайн, Go, SQL и т.д.).
Подбор ментора — на основе указанных параметров система подбирает подходящего ментора, который имеет опыт в нужных областях и может эффективно закрыть пробелы кандидата.
Согласование — кандидату предлагается конкретный ментор. Если по какой-либо причине он не подходит, можно запросить другого. Без согласия кандидата ментор не назначается.

Работа с международными кандидатами

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

Вопрос 13. Работаете ли вы с кандидатами из-за пределов РФ, например из Казахстана?

Таймкод: 01:26:02

Ответ собеседника: Правильный. Да, работаем. Можно оплатить как российскими, так и иностранными картами. В форме оплаты есть специальная кнопка «оплатить иностранной картой». Чек придёт официально. Доступно из любой страны, включая Сербию и другие.

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

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

Вопрос 14. Когда беспилотное такси станет массовым явлением?

Таймкод: 01:26:58

Ответ собеседника: Правильный. Не скоро. Человечество пока не дошло до уровня полной автономности беспилотников. Массовость будет, но это вопрос времени. Хорошо уже то, что беспилотность вообще появляется и будет развиваться, так как это очень хорошая технология.

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

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

Текущее состояние технологии

Беспилотные автомобили уже существуют и тестируются в нескольких городах мира. Компании вроде Waymo (Alphabet), Cruise (GM), а также Яндекс в России активно развивают эту технологию. Однако до массового внедрения ещё далеко.

Основные барьеры

Технологические — достижение полной автономности (Level 5 по классификации SAE) требует решения множества сложных задач: распознавание объектов в сложных погодных условиях, принятие решений в нестандартных ситуациях, взаимодействие с пешеходами и другими участниками движения.
Регуляторные — в большинстве стран законодательство ещё не готово к массовому использованию беспилотных автомобилей. Вопросы ответственности в случае аварии, страхования, сертификации — всё это требует проработки.
Инфраструктурные — дорожная инфраструктура в большинстве городов не адаптирована для беспилотных транспортных средств.
Социальные — доверие людей к беспилотным технологиям в транспорте пока невысоко.

Прогноз

Массовое внедрение беспилотного такси — это вопрос не ближайших лет. Скорее всего, это произойдёт поэтапно: сначала в ограниченных зонах и определённых городах, затем постепенное расширение. Оптимистичные оценки называют горизонт 10–15 лет для массового внедрения в развитых странах, но реальные сроки могут быть и больше. Тем не менее сам факт того, что технология активно развивается и уже используется в пилотных проектах, является очень положительным сигналом для отрасли.

Вопрос 15. Чем отличается RWMutex от Mutex, а также когда следует использовать sync.Map вместо обычной map с мьютексом?

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

Ответ собеседника: Правильный. RWMutex и Mutex — это разные вещи. Есть концепция shared (разделяемых) и exclusive (эксклюзивных) локов в программировании. RWMutex позволяет разделять доступ: несколько горутин могут одновременно читать (RLock), но запись эксклюзивна (Lock). Используйте RWMutex, когда нужно шарить доступ к объекту на несколько горутин, но преимущественно на чтение. Что касается sync.Map — она быстрее работает на больших масштабах и должна быть производительнее, чем map с мьютексом, но на практике мало кто её использует, так как обычно нет места, где она реально даст выигрыш. Это специфичный инструмент для конкретных сценариев.

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

Это классический вопрос на понимание примитивов синхронизации в Go. Оба инструмента решают задачу потокобезопасного доступа к данным, но делают это по-разному.

sync.Mutex vs sync.RWMutex

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

var mu sync.Mutex
var data map[string]int

func Read(key string) int {
    mu.Lock()
    defer mu.Unlock()
    return data[key]
}

func Write(key string, value int) {
    mu.Lock()
    defer mu.Unlock()
    data[key] = value
}

sync.RWMutex реализует концепцию shared/exclusive lock:

RLock() / RUnlock() — разделяемый лок на чтение. Одновременно может быть множество читателей.
Lock() / Unlock() — эксклюзивный лок на запись. Только одна горутина может писать, и при этом никто не может читать.

var mu sync.RWMutex
var data map[string]int

func Read(key string) int {
    mu.RLock()
    defer mu.RUnlock()
    return data[key]
}

func Write(key string, value int) {
    mu.Lock()
    defer mu.Unlock()
    data[key] = value
}

Когда использовать RWMutex

RWMutex выгоден, когда:

Преобладают операции чтения над операциями записи (read-heavy workload).
Операции чтения выполняются достаточно долго, чтобы оправдать накладные расходы RWMutex.
Множество горутин читают одни и те же данные параллельно.

RWMutex не выгоден, когда:

Операции записи происходят часто — в этомслучае RWMutex фактически деградирует до Mutex, но с бо́льшими накладными расходами.
Операции чтения очень быстрые (например, чтение одного int) — накладные расходы RWMutex могут превысить выгоду.

sync.Map vs map + Mutex

sync.Map — это встроенная в стандартную библиотеку Go потокобезопасная карта, оптимизированная для двух конкретных сценариев:

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

var m sync.Map

// Запись
m.Store("key", 42)

// Чтение
if val, ok := m.Load("key"); ok {
    fmt.Println(val.(int))
}

// Удаление
m.Delete("key")

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

Когда у вас read-heavy нагрузка и ключи относительно стабильны.
Когда горутины работают с разными ключами и нет конкуренции за одни и те же ключи.

Когда использовать map + Mutex

Когда вам нужны сложные атомарные операции (прочитать-изменить-записать).
Когда нужно итерировать по карте.
Когда горутины конкурируют за одни и те же ключи.
В большинстве типичных сценариев — map с Mutex проще, понятнее и достаточно быстр.

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

На практике sync.Map — это специализированный инструмент, который редко даёт выигрыш в типичных приложениях. Большинство Go-разработчиков предпочитают использовать обычную map с sync.Mutex или sync.RWMutex, так как это более предсказуемо и проще в отладке. Используйте sync.Map только тогда, когда профилирование явно показывает, что конкуренция за доступ к карте является узким местом производительности.

Вопрос 16. Стоит ли использовать ресивер по ссылке (pointer receiver) для методов структуры?

Таймкод: 01:30:18

Ответ собеседника: Правильный. Лучше всего использовать ресивер по ссылке (pointer receiver). Это личное мнение спикера, который признаётся, что в данном стриме выпендрился и не стал так делать, но вообще рекомендует всегда использовать pointer receiver. Правильного ответа не существует — это вопрос предпочтений и контекста.

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

Выбор между value receiver и pointer receiver — это один из часто обсуждаемых вопросов в Go. Единого правильного ответа нет, но есть чёткие рекомендации.

Value Receiver vs Pointer Receiver

Value receiver — метод получает копию структуры:

type MyStruct struct {
    Value int
}

func (s MyStruct) GetValue() int {
    return s.Value
}

Pointer receiver — метод получает указатель на структуру:

func (s *MyStruct) SetValue(v int) {
    s.Value = v
}

Когда использовать pointer receiver

Когда метод должен изменять состояние структуры. Value receiver работает с копией, поэтому изменения не будут видны вызывающей стороне.
Когда структура большая. Копирование больших структур при каждом вызове метода может быть дорогостоящим с точки зрения производительности.
Для единообразия. Если хотя бы один метод структуры использует pointer receiver, рекомендуется, чтобы все методы использовали pointer receiver. Это делает API предсказуемым и позволяет избежать путаницы.

Когда можно использовать value receiver

Когда структура маленькая и неизменяема. Например, если структура содержит только одно поле примитивного типа и метод только читает данные.
Для типов, которые по своей природе являются значениями. Например, time.Time использует value receiver, потому что время — это значение, а не изменяемое состояние.
Когда вы хотите гарантировать, что метод не изменит состояние. Value receiver обеспечивает это автоматически.

Практическая рекомендация

Многие опытные Go-разработчики (включая спикера стрима) рекомендуют по умолчанию использовать pointer receiver, если нет веских причин использовать value receiver. Это связано с тем, что:

Pointer receiver более гибкий — метод может как читать, так и изменять состояние.
Это избавляет от необходимости переделывать API позже, если потребуется добавить изменяющий метод.
Для небольших структур разница в производительности между value и pointer receiver пренебрежимо мала.

Важно помнить

Независимо от выбора, все методы одной структуры должны использовать один тип ресивера — либо все value, либо все pointer. Смешение приводит к непредсказуемому поведению и нарушает интерфейсную совместимость.

Вопрос 17. Что оценивается выше — оптимизация по скорости или по памяти? Например, если решение использует слайс слайсов и получает квадратичную сложность по памяти, но оптимально по скорости.

Таймкод: 01:31:14

Ответ собеседования: Правильный. Обычно все смотрят на скорость — на количество операций, которые нужно сделать, и хотят это оптимизировать в первую очередь. Считается, что память дешевле, чем CPU-время исполнения, поэтому принято оптимизировать скорость исполнения. Однако в каждой задаче нужно смотреть отдельно — иногда квадрат по памяти может быть M×N, где M — количество слайсов, а N — размер каждого слайса, и это не обязательно чисто квадратичная сложность.

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

Это фундаментальный вопрос о trade-offs в разработке, и ответ на него зависит от контекста.

Общий приоритет

В большинстве случаев на собеседованиях и в реальной разработке приоритет отдаётся оптимизации по времени (скорости выполнения). Это связано с несколькими факторами:

Память дешевле CPU. Серверная память относительно недорога, а время выполнения напрямую влияет на пользовательский опыт и стоимость инфраструктуры.
Сложность по времени чаще является узким местом. Алгоритмы с высокой временной сложностью (O(n²), O(2^n)) быстрее становятся неприемлемыми при росте входных данных.
На собеседованиях временная сложность — основной критерий оценки. Интервьюеры в первую очередь спрашивают: «Какова временная сложность вашего решения?»

Когда память важнее

Однако есть сценарии, где оптимизация по памяти критична:

Встраиваемые системы (embedded) — ограниченные ресурсы памяти.
Мобильные приложения — ограничения по памяти на устройстве.
Обработка очень больших объёмов данных — когда данные не помещаются в память.
Системы реального времени — где выделение памяти может вызывать непредсказуемые задержки (GC pauses).

Как рассуждать на интервью

Начните с оптимального по времени решения. Это демонстрирует, что вы понимаете алгоритмическую сложность.
Обсудите пространственную сложность. Скажите: «Это решение имеет временную сложность O(n) и пространственную сложность O(n). Мы можем уменьшить пространственную сложность до O(1), если...»
Обсудите trade-offs. Покажите, что вы понимаете компромиссы: «Мы можем сэкономить память, но это увеличит время выполнения, потому что...»
Уточните у интервьюера. Спросите: «Есть ли ограничения по памяти, которые я должен учитывать?» Это показывает зрелый подход.

Пример рассуждения

Если решение использует слайс слайсов и имеет квадратичную пространственную сложность:

Если M — количество слайсов, а N — средний размер каждого слайса, то общая пространственная сложность — O(M×N).
В худшем случае, если M ≈ N, это O(N²).
Нужно оценить, является ли это проблемой для конкретных ограничений задачи. Если N ≤ 10⁴, то N² = 10⁸ элементов — это может быть приемлемо. Если N ≤ 10⁶, то N² = 10¹² — это уже проблема.

Вывод

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

Вопрос 18. Есть ли кейсы успешного перехода в IT на Go в 40+ лет, например с PHP или 1С?

Таймкод: 01:34:40

Ответ собеседника: Правильный. Такие кейсы есть. Всё зависит от бэкграунда. Если человек 40 лет программирует на PHP и переходит на Go — высокая вероятность, что это получится. Были менти, которые программировали на 1С и переходили на Go, устраивались в бигтех. Если совсем нет IT-опыта, то это будет серьёзный вызов, который займёт много времени. В любом случае рекомендуется прийти на мок-интервью, чтобы ментор оценил конкретный кейс и дал рекомендации.

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

Да, успешные кейсы перехода на Go в возрасте 40+ существуют, и они вполне реалистичны при правильном подходе.

Переход из смежных технологий

Если человек имеет многолетний опыт программирования на других языках (PHP, 1С, Java, Python и т.д.), переход на Go значительно проще:

Базовые концепции программирования уже знакомы — переменные, функции, структуры данных, алгоритмы, принципы ООП.
Опыт проектирования и отладки — умение разбираться в чужом коде, писать тесты, работать с системами контроля версий.
Понимание жизненного цикла разработки — code review, CI/CD, деплой, мониторинг.

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

Переход из 1С

Разработчики 1С имеют преимущество — они уже понимают бизнес-логику, работу с данными, проектирование систем. Go часто используется для построения микросервисов и бэкенд-систем, которые интегрируются с учётными системами, так что понимание доменной области может быть ценным активом.

Переход без IT-опыта

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

Рекомендации

Пройти мок-интервью — ментор оценит текущий уровень и даст персонализированные рекомендации.
Не сравнивать себя с 20-летними разработчиками — зрелые кандидаты часто имеют преимущество в мягких навыках, понимании бизнеса и ответственности.
Фокусироваться на практических проектах — написать несколько pet-проектов на Go, чтобы набрать портфолио.
Использовать свой опыт — понимание бизнес-процессов, навыки коммуникации и умение работать в команде — это ценные качества, которые не зависят от возраста.

Возраст в IT — это не барьер, а часто преимущество, особенно если кандидат демонстрирует способность к обучению и мотивацию.

Вопрос 19. Как работает захват переменных в цикле for в Go 1.22? Почему теперь в каждой итерации создаётся новая переменная?

Таймкод: 01:36:50

Ответ собеседника: Правильный. В Go 1.22 изменилось поведение циклов — теперь в каждой итерации создаётся новая переменная, а не переиспользуется одна и та же. Никакой магии нет: компилятор генерирует явную инструкцию для объявления новой переменной каждый раз. Это исправило известную проблему, когда замыкания внутри цикла захватывали одну и ту же переменную и все видели последнее значение.

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

Это одно из самых значимых изменений в Go 1.22, которое исправило давно известную проблему, источавшую множество багов.

Проблема до Go 1.22

До версии 1.22 переменная цикла for была одной и той же на всех итерациях. Это приводило к неожиданному поведению при использовании замыканий:

// Go 1.21 и ранее
var funcs []func()
for i := 0; i < 3; i++ {
    funcs = append(funcs, func() {
        fmt.Println(i)
    })
}
for _, f := range funcs {
    f() // Выведет: 3, 3, 3
}

Все замыкания захватывали одну и ту же переменную i, и к моменту их вызова i уже равнялось 3 (значение, при котором цикл завершился).

Решение до Go 1.22

Разработчики использовали обходной путь — создавали локальную копию переменной:

for i := 0; i < 3; i++ {
    i := i // Создаём новую переменную в области видимости итерации
    funcs = append(funcs, func() {
        fmt.Println(i)
    })
}

Что изменилось в Go 1.22

Начиная с Go 1.22, компилятор автоматически создаёт новую переменную на каждой итерации цикла. Это часть более широкого изменения, описанного в proposal #56010.

// Go 1.22+
var funcs []func()
for i := 0; i < 3; i++ {
    funcs = append(funcs, func() {
        fmt.Println(i)
    })
}
for _, f := range funcs {
    f() // Выведет: 0, 1, 2
}

Как это работает

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

Важные замечания

Это изменение применяется только к циклам for и for range.
Переменные цикла больше не переиспользуются между итерациями.
Это изменение может повлиять на производительность в горячих циклах, так как теперь на каждой итерации создаётся новый объект в памяти (хотя компилятор может оптимизировать это в простых случаях).
Для включения нового поведения необходимо указать go 1.22 или выше в go.mod.

Практическое значение

Это изменение устраняет один из самых распространённых источников багов в Go и делает поведение циклов более интуитивным для разработчиков, пришедших из других языков.

Вопрос 20. Если у меня проекты связаны с парсингом данных, чем мне это поможет и для какой профессии?

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

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

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

Опыт работы с парсингом данных — это ценный навык, который может быть применён в нескольких направлениях.

Какие навыки развивает парсинг

Работа с парсингом предполагает знание и применение множества технических навыков:

Работа с HTTP-запросами — отправка запросов, обработка ответов, работа с заголовками, куками, сессиями.
Парсинг структурированных данных — HTML, XML, JSON, CSV.
Работа с регулярными выражениями.
Обработка ошибок и ретраи — сетевые запросы могут падать, нужно уметь обрабатывать это.
Конкурентность — параллельный парсинг множества страниц для ускорения работы.
Работа с базами данных — сохранение и обработка спарсенных данных.
Обход защиты — User-Agent, rate limiting, CAPTCHA (в легальных рамках).

Для каких профессий это полезно

Backend-разработчик (Go) — парсинг часто является частью бэкенд-системы: интеграция с внешними API, сбор данных, ETL-процессы. Go отлично подходит для этих задач благодаря встроенной поддержке конкурентности.
Data Engineer — построение пайплайнов сбора и обработки данных. Парсинг — это первый шаг в большинстве ETL-процессов.
DevOps/SRE — написание скриптов для сбора метрик, мониторинга, автоматизации.
QA Automation — написание тестов, которые проверяют веб-интерфейсы и API.

Как использовать этот опыт при переходе на Go

Если вы уже занимаетесь парсингом на другом языке (Python, PHP и т.д.), переход на Go будет естественным:

Go имеет отличные библиотеки для парсинга: net/http, html/template, encoding/json, golang.org/x/net/html.
Встроенная конкурентность (горутины и каналы) делает Go идеальным для параллельного парсинга.
Статическая типизация и компиляция обеспечивают лучшую производительность по сравнению с интерпретируемыми языками.

Рекомендация

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

Вопрос 1. Расскажите о менторской программе «Навыки» и как она работает.​

Вопрос 2. Расскажите о себе и своём опыте работы.​

Вопрос 3. Будет ли запись стрима?​

Вопрос 4. Как вы оцениваете уровень кандидата и какие критерии используете для определения грейда (начальный, средний, продвинутый)?​

Вопрос 5. Стоит ли идти в менторскую программу, если вы новичок в Go и только начинаете его изучать?​

Вопрос 6. Можно ли купить курс для подготовки к алгоритмическим задачам и к систем дизайну, или нужно строго следовать заранее составленному скрипту?​

Вопрос 8. Нужно ли в решении задачи проверять входные данные на валидность или можно принять их как гарантированные?​

Вопрос 9. Как бы вы оценили решение задачи Summary Ranges и на что обращаете внимание при проверке?​

Вопрос 11. Можно ли будет посмотреть третью задачу (SQL), которую не успели разобрать на стриме?​

Вопрос 12. Можно ли выбрать конкретного ментора в программе «Навыки» или его назначают случайно? Работаете ли вы с кандидатами из-за пределов РФ?​

Вопрос 13. Работаете ли вы с кандидатами из-за пределов РФ, например из Казахстана?​

Вопрос 14. Когда беспилотное такси станет массовым явлением?​

Вопрос 15. Чем отличается RWMutex от Mutex, а также когда следует использовать sync.Map вместо обычной map с мьютексом?​

Вопрос 16. Стоит ли использовать ресивер по ссылке (pointer receiver) для методов структуры?​

Вопрос 18. Есть ли кейсы успешного перехода в IT на Go в 40+ лет, например с PHP или 1С?​

Вопрос 19. Как работает захват переменных в цикле for в Go 1.22? Почему теперь в каждой итерации создаётся новая переменная?​

Вопрос 20. Если у меня проекты связаны с парсингом данных, чем мне это поможет и для какой профессии?​

Вопрос 1. Расскажите о менторской программе «Навыки» и как она работает.

Вопрос 2. Расскажите о себе и своём опыте работы.

Вопрос 3. Будет ли запись стрима?

Вопрос 4. Как вы оцениваете уровень кандидата и какие критерии используете для определения грейда (начальный, средний, продвинутый)?

Вопрос 5. Стоит ли идти в менторскую программу, если вы новичок в Go и только начинаете его изучать?

Вопрос 6. Можно ли купить курс для подготовки к алгоритмическим задачам и к систем дизайну, или нужно строго следовать заранее составленному скрипту?

Вопрос 8. Нужно ли в решении задачи проверять входные данные на валидность или можно принять их как гарантированные?

Вопрос 9. Как бы вы оценили решение задачи Summary Ranges и на что обращаете внимание при проверке?

Вопрос 11. Можно ли будет посмотреть третью задачу (SQL), которую не успели разобрать на стриме?

Вопрос 12. Можно ли выбрать конкретного ментора в программе «Навыки» или его назначают случайно? Работаете ли вы с кандидатами из-за пределов РФ?

Вопрос 13. Работаете ли вы с кандидатами из-за пределов РФ, например из Казахстана?

Вопрос 14. Когда беспилотное такси станет массовым явлением?

Вопрос 15. Чем отличается RWMutex от Mutex, а также когда следует использовать sync.Map вместо обычной map с мьютексом?

Вопрос 16. Стоит ли использовать ресивер по ссылке (pointer receiver) для методов структуры?

Вопрос 18. Есть ли кейсы успешного перехода в IT на Go в 40+ лет, например с PHP или 1С?

Вопрос 19. Как работает захват переменных в цикле for в Go 1.22? Почему теперь в каждой итерации создаётся новая переменная?

Вопрос 20. Если у меня проекты связаны с парсингом данных, чем мне это поможет и для какой профессии?