Mock-собеседование старшего Go разработчика из Тинькофф | Самое полное интервью
ฝัง
- เผยแพร่เมื่อ 26 มิ.ย. 2024
- Курсы по программированию: clck.ru/37iG2b
Потренироваться проходить собеседования: it-interview.io
Присоединиться к моему сообществу: boosty.to/vladimir_balun
Консультации:
getmentor.dev/mentor/vladimir...
solvery.io/ru/mentor/vladimir...
Консультации от Дениса:
solvery.io/ru/mentor/de_maksimov
Таймкоды:
00:00 - Введение
00:20 - Горутины под капотом
01:37 - Расширение стэка горутины
02:36 - Разница потоков и горутин
05:00 - Context switching
06:08 - Планировщик в Go под капотом
06:58 - Системные вызовы с горутинами
08:21 - Work sharing и work stealing
09:16 - Кооперативная и вытесняющая многозадачнось
09:55 - Алгоритмы планирования
11:50 - Примитивы синхронизации
12:23 - Мьютексы под капотом
14:25 - Spinlock
15:07 - Deadlock, livelock, data race
16:23 - Каналы под капотом
18:29 - Семафоры
18:45 - Compare and swap (CAS)
19:25 - Контексты под капотом в Go
21:43 - Параллельное выполнение кода на одном ядре
22:45 - Когерентность кэшей
23:51 - Синхронизация map
25:36 - Архитектура web сервера
29:10 - Синхронизация связного списка
VK: vladimir_balun_program...
Telegram: t.me/vladimir_balun_programming
Instagram: / vladimir_balun_program...
TH-cam: / @vladimir_balun_progra...
YandexZen: zen.yandex.ru/id/623b6c964da9...
RuTube: rutube.ru/channel/25079714/
Golang собеседование. Golang уроки. Golang. Golang с нуля. Go программирование. Go программист. Go Junior собеседование. Go Middle собеседование. Go Senior собеседование. Ozon Go собеседование. Tinkoff Golang. Тинькофф Golang. Tinkoff Go. Тинькофф Go.
#программирование #айти #golang #mockinterview
Какие вопросы вы бы еще задали на собеседовании по теме Concurrency в Go?
Аксиомы каналов?
Как организовать Lock-Free и Wait-Free алгоритмы на Go и зачем они нужны
Lock-free semaphore. Cond var. Модель памяти и ее гарантии(но мне кажется это могло быть продолжением ABA problem)
а давайте такие темы - редис, кафка, паттерны pub-sub, сложные sql, nosql, паттерны проектирования в ооп, аспекты, инфрастуктура, логстеш, эластик? это бы я смотрел постоянно вообще. зачем надо горутины и мьютексы под капотом спрашивать?.. планировщик, мьютексы под капотом..это учится наизусть перед собеседованием и забывается потом как ненужное.
тем более ты как я вижу любишь и умеешь копать все вглубину - это оочень круто! давай эти темы также копнем, это же в работе гораздо полезнее
!
Владимир, очень жду видео про базы данных
Владимир, можешь дать ссылки на литературу, где покрыты темы из интервью? Хотелось бы почитать.
Я понял, это интервью на позицию разработчика драйверов на Golang (шучу), или в разработчики самого Golang. CAS, spinlocks, устройство стека, самих горутин, векторизация иструкций - нафиг оно нужно Golang разработчику? Постоянно ловлю себя на мысли, что я вроде все это знаю из предыдущего опыта, но оно лежит в glacier storage и в ежедневной рутине нафиг не впарилось.
Верьте мне, я поднялся с самого дна кернел спейса к свету распределенных транзакций в k8s кластерах.
Наверно потому что все вопросы которые уже можно было задать, были заданы. Надо же что то новое спрашивать))) А вообще круто что у вас вся эта информация сохраняется в голове. Я вот могу что то такое помнить только в контексте подготовки именно к собесу, через не продолжительное время все выветривается. С другой стороны какая вероятность именно мне это встретить на собесе?) и нужно ли это специально себе вкладывать в память
Отличные вопросы. Очень понравилось интервью!
про Context Switching потоков и потоки, горутины как мне кажется не сильно точно описали
TLB и вообще кеши не обязательно могут вымываться, если потоки одного процесса и на одном и том же ядре процессора.
еще непонятно про какие потоки в юзер-спейсе, в кернал-спейсе или какой-то гибридный вариант идет речь.
если про kernal space, то не указали одну из главных причин - syscall и все накладные расходы.
в user space switching потокв будет столько же стоить как и горутин.
в любом случае вопросы интересные и заставляют покопаться
отличная беседа, спасибо Владимир, почерпнул новое для себя как в плане техники, так и в плане того, что надо поизучать тему конкуретности поглубже, не на все твои вопросы ответил бы)
Владимир, здравствуйте! Такой вопрос - во многих компаниях сейчас устраивают подобные собеседования, возникает ощущение, что нанимают системного программиста, применяют ли ребята свои знания на работе, или же это не уходит дальше собеседования? Или вопросы, так скажем, требующие просто общей эрудиции?
Знания этих нюансов в 99% случаев никак вам не поможет в реальной работе.
Это только для собесов, чтобы как-то синьёров от остальных отделить.
Всё, что вам надо знать про concurrency в GO в реальной жизни - это когда её НЕ использовать,
т.е. когда нужно выставить GOMAXPROCS=1. Скорее всего вы с такой ситуацией не столкнетесь. В остальных же Go Runtime сделает всё за вас очень эффективно.
Оптимизация в GO - это в первую очередь работа с памятью. В этом видео эта тема совсем не раскрыта.
Вот это вообще в тему
Спасибо!
ку!
давно смотрю твои видео! можешь сделать2 часть "как правильно составить резюме"?
GPT ЧАТ в помощь
уже давно составил)) в топ банк залетел@@batpyiiikob7245
@@batpyiiikob7245 Это не работает.
За интервью спасибо, было интересно)
Для критиков - ну, собственно никто и не говорил, что это пример типового сеньорного Go-собеседования.
Это была проверка знаний довольно узкого профиля, которые нужны, если мы хотим выжать из Go максимум производительности (например, в каком-нибудь хайлоаде Авито или Озона).
И понятно, что во всех остальных случаях почти все это не нужно, и большая часть времени будет уходить на решение бизнесовых, а не таких высокотехнических задач.
Не за что!
За авито не скажу, а в озоне, если кто-то начнет оптимизировать продуктовый сервис на таком уровне, то его пошлют сначала оптимизировать логику и работу с памятью, т.к. проблема практически всегда там. Если этого не хватит - поскейлят поды. Устраивать в микросервисе жесть с оптимизацией, об которую потом сломают голову другие разработчики - никто не будет.
@@user-qx3km6wp1pтак и есть))
Ку, а всегда ли на собесах на высокие должности проходят так больше по операционным системам? Просто если чисто по Go, или Backend разработку спрашивать, то видимо изи и неинтересно да или как?)
меня недавно спрашивали по ОСке на стажера фронта))) Зависят от компании, если не в помойку, то может и спрашивают
Есть книги уровня Рихтера, но под го?
Небуферизированный канал чуть быстрее, но ведь если в момент записи в буферезированный канал, у него есть читатель, то передача данных выполняется ровно также, как и с буферезированным каналом
Если у P будет одна общая очередь, при записи в нее, они будут инвалидировать локальные кеши очереди на ядрах, и всем придется ожидать новой подгрузки пр обращении в нее, это была основная причина создания локальных очередей. Например у одного экземпляра sync.Pool под капотом на каждый P свой пул, по тем же причинам.
Привет. Я только начинаю изучать Golang и мне правда интересно, каким образом я могу изучить такие нюансы Go, достаточно изучать документацию и соответствующую литературу?
Нужно изучать не язык, а Computer Science с использованием этого языка программирования
@@vladimir_balun_programming, благодарю за ответ
@@vladimir_balun_programming Какие ресурсы посоветуете, и где сами изучали, если не секрет?
@@Roman-oc9df на канале есть видео про это :)
Посмотрите лекции Роман Липовский он все хорошо объясняет в течении курса создают свои корутины, мутексы, шедулеры (правда это там все на сях) и да там уже не о go, java, php там даются фундаментальные знания
мед для ушей....многопоточность.
А что значит в горутинах стэк динамический в отличие от потоков. В потоках он статический? Это про стек регистров или чё то такое?
В горутинах он растет, в потоках он фиксированный (абстрактно говоря)
@@vladimir_balun_programming А не подскажите какую нибудь статью, чтобы разобраться что есть поток в горутине
Конечно знание всех этих деталей работы потоков и горутин - здорово. Но какое это имеет отношение к 99% задач, которые решает пусть и синьор го? Если нужна супер оптимизация кода, то возможно выбран не тот инструмент?
Тут очевидно человек проникся частью низкоуровневых концепций и теперь эта инфа просачивается в любом его вопросе
Я проходил эту стадию. Был проект с широким использованием многопоточности и конечно конкуренции(Биллинг с большим потоком данных и очень узким окном расчета). Так вот новоприбывшие разработчики очень слабо разбирались в теме(по сравнению с дедами конечно). Проблема заключалась в том, что такому человеку не поручишь основные задачи проекта, только рутину. Приходилось натаскивать. Позже эти новички становились матерыми и очень уверенными в себе(иногда не оправдано), т.к. другие задачи выглядели просто рутиной.
На самом деле многопоточность очень проста когда ты её переварил и понял.
Задач бы посложнее на конкаренси в виде кода и решение накодить.
Судя по тому что сеньор не знал многих вопросов эти вопросы либо не нужны в реальной работе либо сеньор слабоват
Но все же кажется скорее что это не интервью, а просто толк о программировании
Если не понимать зачем эти вопросы задавать (ну часть из них) то это совершенно бесполезное интервью на котором нормальный сеньор будет выглядит бледно хотя в реальности он вполне компетентен
Самое гдавное в go, за быть что есть append!!!
garbage collection was not asked
Интересно, если сама идея и вопросы нравятся, а как собеседуемый отвечал не нравится- это лайк или дизлайк?
Это - написать, что конкретно не понравилось, чтобы была польза от комментария)
Дизлайк же пойдёт не собеседуемому
@@learngolang-od2qp согласен.
а давайте такие темы - редис, кафка, паттерны pub-sub, сложные sql, nosql, паттерны проектирования в ооп, аспекты, инфрастуктура, логстеш, эластик? это бы я смотрел постоянно вообще. зачем надо горутины и мьютексы под капотом спрашивать?.. планировщик, мьютексы под капотом..это учится наизусть перед собеседованием и забывается потом как ненужное.
Потому что это база. Что ты собрался «учить» в редисе и кафке?
Mutex в Go 3 стадийный, сначала атомиками проверяем можем ли захватить замок, этой же операцией и лочим, если можем. Потом идем и делаем банальный, но очень короткий спин лок, это позваляет в большенстве случаев не уйти на парковку. Затем опять атомиком пытаемся захватить замок. Если не вышло, паркуем рутину.
Смешно. Они все заучивают "как устроены горутины", а как дошло до реального программирования оба мычат какую-то херь. "Проще взять спинлок", ога.