Собеседование Senior Go-разработчика / Даниил Подольский, Владимир Балун - Антон Зиновьев

• Открытое собеседование для разработчиков уровня сеньор.  

• Состоит из двух частей: общая разговорная часть и лайф-кодинг.  

• Обсуждение вопросов, подготовка и поведение на собеседовании.  

• Ведущие: Данила Подольский и Владимир Балун.  

• На канале есть уроки для подготовки к собеседованию.  

• Видео записано в прямом эфире, зрители могут задавать вопросы.  

• Подписывайтесь на телеграм-канал для участия в будущих мероприятиях.  

• Ведущие: Данила Подольский и Владимир Балун.  

• Данила известен по статье "Коллеги, вы меня огорчаете".  

• Владимир работает в Яндексе и проводит собеседования.  

• Данила задает вопросы по ядерному опроснику.  

• Вопросы касаются специфики компании Ядро и разработки встроенного ПО.  

• Данила просит разрешения задавать вопросы с первых двух слов.  

• Данила просит рассказать о достижениях за последние три года.  

• Антон рассказывает о своем опыте и достижениях в разработке.  

• Данила задает вопросы о технологических преимуществах Go.  

• Антон объясняет технологические преимущества Go.  

• Обсуждаются особенности языка и его экосистемы.  

• Данила задает наводящие вопросы о многозадачности и эффективности Go.  

• Порождающая куча бойлерплейта сложна в обработке ошибок.  

• Невозможность ручного управления памятью в некоторых случаях.  

• Мемори арены пока экспериментальны и не используются в продакшене.  

• Компилятор Go имеет свои особенности, что усложняет написание библиотек для других языков.  

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

• Вопрос о том, почему это происходит, остается открытым.  

• Отсутствие типов tuples вызывает разочарование.  

• Проблемы с конвертацией интерфейсов и структур.  

• Необходимость вручную конвертировать типы при работе с интерфейсами.  

• Различие между императивными и декларативными языками.  

• Go можно считать как императивным, так и декларативным языком.  

• Примеры других декларативных языков.  

• Использование дженериков и интерфейсов.  

• Кодогенерация как способ обобщенного программирования.  

• Рефлексия как способ обобщенного программирования.  

• Понятие тип сумма и его реализация в Go.  

• Проблемы с использованием дженериков для создания тип сумма.  

• Возможность использования интерфейсов для реализации тип сумма.  

• Дефер как отложенный вызов функции.  

• Обработка ситуаций паник через дефер.  

• Возможность изменения ошибки на выходе через дефер.  

• Возможность выполнения любых операций с nil слайсами.  

• Ограничения на доступ к элементам nil слайсов по индексу.  

• Возможность изменения nil слайсов.  

• Слайсы имеют фиксированную длину, но могут быть инициализированы с разной длиной.  

• По умолчанию слайсы инициализируются с длиной 8 байт, что связано с выравниванием памяти в Golang.  

• Массивы в Go непосредственно лежат в памяти и не являются ссылками.  

• Слайс можно преобразовать в массив, если указать его размерность.  

• Массив должен быть объявлен с указанной размерностью.  

• Преобразование слайса в массив может быть полезно для работы с ключами в картах.  

• Хэш-карты в Go состоят из массивов, называемых бакетами.  

• Информация в бакетах хранится по модулю хэша ключа.  

• Поиск элемента в хэш-карте обычно занимает константное время, но возможны коллизии.  

• Каналы в Go служат для связи между goroutines.  

• Каналы бывают буферизованными и небуферизованными.  

• Буферизованные каналы позволяют записывать несколько значений, небуферизованные — только одно.  

• В небуферизованных каналах данные передаются напрямую из одной области памяти в другую.  

• В буферизованных каналах данные буферизуются, но не передаются по ссылке.  

• В небуферизованных каналах нет передачи ссылок, только копирование данных.  

• Обсуждение десяти трехбуквенных команд в Linux.  

• Трудности с запоминанием команд и использование автокомплита.  

• Примеры команд: vim, top, tar, zip, sed.  

• Знания о файловых системах Linux на уровне пользователя.  

• Различие между хардлинками и симлинками.  

• Хранение имен файлов в директориях.  

• Права доступа к файлам: чтение, запись, выполнение.  

• Команда kill и её влияние на процессы.  

• Перехватываемые и неперехватываемые сигналы.  

• Понятие коммита, ветки и тега в Git.  

• Различия между объектами и их использование.  

• Ветка как цепочка коммитов и теги для навигации.  

• Оценка знаний кандидата в Linux и программировании.  

• Возможность обучения в команде, пишущей сервисы.  

• Фидбек и отношение к сотрудникам, ходящим на собеседования в другие компании.  

• Ходить на собеседования важно для поддержания тонуса и оценки своей стоимости на рынке труда.  

• Это помогает оставаться в курсе тенденций и вопросов, которые задают на собеседованиях.  

• Для работодателя это может быть сигналом о необходимости улучшения условий работы для сотрудника.  

• Вопросы на собеседованиях могут быть не связаны напрямую с работой, но помогают оценить кругозор кандидата.  

• Для сеньоров важно умение решать сложные проблемы и делиться знаниями с коллегами.  

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

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

• В процессе решения задач важно собирать анамнез и анализировать проблемы с производительностью.  

• Использование локов и эксплейнов помогает выявить проблемные запросы и оптимизировать их.  

• Для оптимизации производительности базы данных важно понять тип нагрузки: чтение или запись.  

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

• Шардирование может быть дорогостоящим решением, поэтому важно тщательно оценить все варианты перед его применением.  

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

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

• Обсуждение различных таблиц и их разгрузка.  

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

• Переход к следующей задаче, связанной с кэшированием.  

• Описание базы данных с пользователями и IP-адресами.  

• Цель минимизировать время задержки между запросами.  

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

• Объявление интерфейса для кэша.  

• Обсуждение структуры кэша и использование слайсов указателей.  

• Важность обсуждения перед написанием кода.  

• Обсуждение паттерна декоратора.  

• Использование map для кэша, так как это рид-интенсивная структура.  

• Применение map с мьютексом для параллельных запросов.  

• Начало написания кода для кэша.  

• Использование sync/wait для инициализации мьютекса.  

• Обсуждение инициализации map и базы данных.  

• Обсуждение метода get для кэша.  

• Обработка ошибок и мимикрия под поведение базы данных.  

• Проблемы с синхронизацией и использование деферов.  

• Обсуждение использования деферов и блокировок.  

• Завершение обсуждения и переход к реализации метода get.  

• Обсуждение необходимости кэширования данных для синхронизации.  

• Рассмотрение методов, которые вызываются редко, и их влияние на кэширование.  

• Решение использовать итеративный подход для кэширования редко используемых данных.  

• Обсуждение доступа к базе данных и возможных проблем.  

• Необходимость сброса кэша при изменении данных.  

• Обсуждение инкапсуляции инвалидации кэша от пользователей.  

• Рассмотрение вариантов хранения данных в памяти.  

• Обсуждение увеличения объема данных при использовании TTL.  

• Решение хранить кэш-записи вместо данных.  

• Обсуждение необходимости инвалидации кэша при устаревании данных.  

• Рассмотрение различных методов инвалидации, включая использование TTL.  

• Решение инвалидировать всю карту при устаревании данных.  

• Обсуждение завершения работы с данными и инвалидации кэша.  

• Рассмотрение необходимости использования мьютекса для предотвращения конфликтов.  

• Решение использовать атомарные операции для корректного обновления указателей.  

• Использование двух мьютексов для синхронизации кажется неэффективным.  

• Важно обеспечить переносимость кода, особенно при портировании на разные платформы.  

• В случае с продуктовой компанией, где известна инфраструктура, можно использовать более сложные решения.  

• Обсуждение способов улучшения производительности кода.  

• Использование атомарных операций для минимизации блокировок.  

• Рассмотрение паттернов и их применение для улучшения производительности.  

• Обсуждение паттернов и их названий.  

• Применение паттернов для улучшения производительности кода.  

• Рассмотрение альтернативных решений, таких как использование условных индексов и шардинг.  

• Обсуждение лок фри решений и их реализации.  

• Рассмотрение сложностей и преимуществ лок фри подходов.  

• Примеры использования атомарных операций для достижения лок фри.  

• Обсуждение метрик для измерения эффективности кэша.  

• Важность хитрейта и занимаемой памяти для оценки производительности.  

• Примеры метрик для нового сервиса и их важность для мониторинга.  

• Процесс поиска и исправления проблем в сервисе.  

• Использование логов, метрик и трассировок для выявления причин проблем.  

• Дебаг и анализ кода для нахождения и устранения ошибок.  

• Обсуждение типичных проблем с базой данных.  

• Нехватка контекста и последовательного пути решения.  

• Необходимость анализа ресурсов и пропускной способности.  

• Нехватка требований и ключевых идей при написании кода.  

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

• Необходимость заранее выстроенного решения и доступа к метрикам.  

• Разработчики часто выполняют множество задач, включая администрирование.  

• Важность доступа к метрикам и данным для анализа проблем.  

• Обсуждение роли разработчика как боевой единицы.  

• Подготовка к собеседованию и важность знания метрик и данных.  

• Разработчики должны учитывать ограничения и условия работы.  

• Моделирование реальных ситуаций на собеседовании.  

• Интервью не показали, как кандидат будет решать рабочие задачи.  

• Владимир не узнал о кругозоре кандидата, так как задача была одна.  

• Антон не писал кэш в феврале, поэтому задача была сложной.  

• Теоретические задачи не показывают практической применимости.  

• Практические задачи помогают оценить, как кандидат решает проблемы.  

• Важно давать задачи с ограничениями и кейсами для проверки поведения кандидата.  

• Оценивается, как кандидат смотрит на инциденты и опыт работы с базами данных.  

• Важно смотреть на задачи под разными углами.  

• Трудности с сетью и контекстом мешали интервью.  

• Вопросы и задачи должны быть практичными и полезными.  

• Кандидат должен понимать, зачем он пишет код.  

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

• Важно учитывать ресурсы, такие как память и ядра.  

• Метрики помогают понять, не кончилась ли память и не ушли ли в своп.  

• Отдел эксплуатации следит за утилизацией ресурсов.  

• Обсуждение глобальных подходов к ресурсам.  

• Подкаст понравился зрителям, несмотря на технические проблемы.  

• Благодарность участникам и зрителям за участие.