Самое полное интервью Golang Middle
Вставка
- Опубліковано 15 чер 2024
- Самое объемное открытое собеседование на Middle Go разработчика: реальные вопросы, кейсы, задачи без урезания по времени. Расскажем почему спрашивали именно эти вопросы и как лучше всего подготовиться к собеседованию.
Проведет интервью Александр Сахаров
- Работает в Озоне, платформа Observability, команда логирования
- Опыт разработки 5 лет, за Go последние 3 года
- Интервьюирует ребят на Junior, Middle, Senior
Чтобы получать уведомления о предстоящих открытых интервью или записаться на менторскую сессию, напишите нашему боту: t.me/skills_mentee_bot?start=...
0:00-01:34 Разница между C# и Go, что понравилось и не понравилось?
01:34-03:40 Какая задача на го последние полгода понравилась/порадовала?
03:40-05:06 Модели, структуры в Go и в C# сравнения
05:06-06:28 Рассуждения про дженерики
06:28-08:07 Интерфейсы в го, реализация
08:07-09:59 Кейс с интерфейсами
09:59-11:04 Что такое пустой интерфейс?
11:04-12:17 Типы. Что такое слайсы?
12:17-13:41 Кейс со слайсами, капасити
13:41-15:28 Когда мы передали слайс, что можем с ним дальше делать?
15:28-17:08 Насколько слайс безопасен?
17:08-18:37 Маппа, Хэш-таблица (отличия)
18:37-19:36 Какая в среднем сложность поиска по слайсы и по Маппе?
19:36-21:40 Насколько Маппа безопасна?
21:40-23:20 Объявления переменных, в чем разница?
23:20-25:30 Объявление слайсов
25:30-27:21 Мьютексы, какие используешь? Кейсы.
27:21-28:29 Каналы. Как он работает в го?
28:29-29:15 Насколько каналы безопасны?
29:15-31:00 Кейсы с закрытием канала
31:00-37:10 Select.default.Кейсы.
37:10-39:43 Буферизированные и не буферизированные каналы это
39:43-01:05:40 Анализ кода, задачи
01:05:49-01:10:58 Что такое горутины? Кейсы.
01:10:58-01:12:22 Scheduler, как работает планировщик?
01:12:22-01:16:40 Garbage collector C# и в Go
01:16:40-01:32:36 Кастомные ошибки. Задачи
01:32:36-01:36:09 Контекст, дочерние контексты
01:36:09-01:43:53 Тестирования. Как тестируешь? Какие тесты знаешь?
01:43:53-01:45:14 Профилировщики
01:45:14-01:50:15 Процессы в Linux. Как закончить процессы?
01:50:15-01:56:59 Какие бывают протоколы? Их применение.
01:56:59-02:00:50 Виды баз данных и в чём их различия?
02:00:50-02:04:20 Индексы. Что такое индекс? Как чистить? Кейсы
02:04:20-02:10:15 Что такое Транзакции, что означает сериализуемость?
02:10:15-02:14:15 Race conditions. Data Race
02:14:15-02:17:36 Message broker
02:17:36-02:50:15 System Design
02:50:15-02:56:13 Вопросы из чата.
02:56:13-03:03:20 Фидбэк собеседования с Сергеем
03:03:20-03:08:31 Менторская программа - Розваги
Респект кандидату (независимо от ответов) - 3 часа отвечать на вопросы это конечно хардкор...
Лайк) Очень крутое интервью, спасибо
Для общего понимания было бы хорошо пригласить стороннего сеньора с одной из известных компаний (незнакомого) и чтобы он прособеседовал собеседующего, и по го и по system design.
Перед этим нужно прочитать хотя документацию по БД, полное отсутствие проф терминологии
для озона в этом нет необходимости )
Спасибо за видео. Коммент в поддержку!
а для оживления worker controller нужен еще worker supercontroller , но если под не живой, то и это не поможет;-))) при выборке из БД в отдельном столбце ставим время последней выборки, если оно больше определенного предела, то отдаем еще раз, если запись необработана. все придумано до нас, аналогично работают многие очереди сообщений
спасибо за такой проект
Было бы здорово, если бы на примеры, которые продемонстрировали, предоставили ссылочки. Что бы не приходилось красноглазить.
Супер контент, лучший
02:10:15-02:14:15 Raise conditions. Data raise - опечатка в тайминге. )
Пофиксили, спасибо, что обратили внимание
Лайк за "Elegant objects" на полке)
3 часа ? это законно?
За System Design, инетрвьюемый, конечно, однозначно завалил, и интервьюер тоже. Это их решение с локом рядов в БД и релизом по таймаутам самое наивное и ненадежное. А если воркер просто дольше чем таймаут обрабатывает сообщение? Будет дубликат. Проблема конечно не простая, но есть пара более надежных решений.
Первое это шардинг где каждый инстанс кластера отвечает только за свои сообщения (грубо говоря если 3 инстанса, то первый обрабатывает сообщения только начинающиеся с букв А до Й, тут я утрирую конечно, надо хэш использовать а не напрямую, и т.д.). У такого решения тоже куча минусов конечно, например пока сервер не перезапустится сообщения не будут обрабатываться, ну и с автоскейлингом траблы там, так как нужно чтоб количество серверов было фиксированным. Но по крайней мере можно гарантировать обработку только один раз.
Второе покруче это использовать Rabbit MQ - сообщения кладутся не в постгрес а в локальный Rabbit MQ. Если воркер отвалится без акка сообщения, то оно сразу подберется другим ворекром. Для более сложных сценариев можно использовать etcd или zookeeper. Недостаток этого решения что нужно иметь Rabbit MQ / etc / zookeepr.
Ну а вообще, exactly once это интервьюер загнул конечно. Я бы ему сразу сказал что он размечтался и добиться exactly once это практически нереально, поэтому надо выбирать в зависимости он нужд либо at least once (когда важно чтоб юзер точно получил), или at most once (какая-нибудь рекламная рассылка где непринципиально если одно сообщение потеряется), потому что всегда может быть ситуация когда сообщение пользователю ушло, но воркер отвалился до того как пометил его обработанным.
Интересно описал! Если не сложно, можешь написать в каких проектах приходилось самому столкнуться с этими моментами?
@@maksimsergeevich5939 Любой проект где есть асинхронная задача (в противовес обычному запрос - ответ), которая должна выполнятся исключительно в единственном экземпляре и надежно (то есть переживать рестарт или остановку серверов, и тут даже не вопрос в том что сервер может сломаться, здесь может быть простой деплоймент или даунскейлинг, такие вещи могу происходить несколько раз в день). Их решение в принципе работает, но это какой-то ненадежный велосипед, с кучей корнер кейсов которые они не учли, ну например а если работу нужно подбирать сразу после того как выполнявший ее сервер отвалился? В их решении работа не будет подобрана пока следующий цикл полинга не пройдет.
@@tyapka запись в БД должна быть идемпотентной, тк не погут никакие твои мульты-пульты на сервисах
Тоже бы сделал по другому, я бы предложил сделать writer (то что на видео нарисовано как Notifier) принимающим запросы синхронно, аля gateway. В таком случае там можно и валидацию сообщения сделать, и ограничить их поток (rate limitter и тому подобное), и прочее, и там уже положить в kafka / rabbit, на которую подписаны worker'ы. И не нужно этих select for update skip locked, механизм очередей эту задачу решает.
Респект за развёрнутый коммент. Многим поможет
Собес 3 часа подряд, это ужасно...
Норм, время быстро пролетает
У меня как-то был собес на 2,5 часа. Не в IT, но какая разница. Ничего, если ты с интервьюером на одной волне, все проходит легко и просто. Трудно, когда интервьюер хочет показать свою значимость и превосходство, вплоть до того, что чуть ли не унизить тебя. С таким тоже встречался и такое собеседование - это каторга даже на 40 минут. Когда был молод еще терпел, когда повзрослел, просто вставал и уходил. А с приятным человеком можно и 5 часов поговорить, не напрягает.
У меня было 2 собеса в одну и ту же команду на стажёра разработчика. Первый собес длился 2:20 минут, второй начинался со слов "не всё у тебя спросил" и продлился ещё 2:40) Скажу что прям 3 часа подряд это правда очень тяжело
Законспектировал почти всё словов в слово. Большое спасибо за это видео!
Только не знаю как человек может выдержать 3 часа собеса. Это вынос мозга. Наверное вы так ещё проверяете психологическую стойкость человека.
Это кабздец. Я после 2ч уже овощ.
никогда не встречал собеседования дольше часа. даже в озоне они по часу)
вряд ли поможет
бессвязный диалог
Есть вопрос про select case prioritization
Есть 2 case, один из них done, который надо выполнять приоритетно.
Если я пошлю что-то в done и закрою его, будет ли он приоретизирован?
Касательно лика горутин: в случае приложения, которое не работает долго, утечка горутин не критична, так как рантайм возвращает используемую память ОС, I.e убивает все в конце работы приложения. Другое дело, если это какой-нибудь микросервис, который вертится в кубере +- постоянно.
так и что делать, как дропнуть подвисшие горутины в контексте примера на 1:09:00
или какие есть варианты на Го?
@@dimka00706 Тоже не могу понять, как это сделать
хз по поводу кафки на вход в SD секции. ну типа, зачем усложнение подобного плана если мы и так пишем стейт?
40т просмотров и 900 лайков. Б-благодарность
в каких проектах и какие сервисы на нем востребованы ???
1:07:18 что такое потоки на уровне процессора?
Вот что интересно, кто больше считается мидлом - как в этом интервью, в теории на словах все отлично рассказал и диалог поддержал, но когда начали кодинг, тут же на первой задаче проплыл и не смог объяснить. Или тот, кто теоретически не смог бы рассказать все это про особенности, но видя код , смог бы указать на проблемные участки, решить их и поправить по логике?
По поводу 43:16
Это ошибка by design языка go. В Go FAQ на это есть ответ:
"This behavior of the language, not defining a new variable for each iteration, may have been a mistake in retrospect. It may be addressed in a later version but, for compatibility, cannot change in Go version 1."
Обходить можно так:
var numbers []*int
for _, value := range []int{10, 20, 30, 40} {
v := value
nums = append(numbers, &v)
}
Это очень правильный "mistake". Просто представь сколько памяти на стеке или даже в куче сожрал бы этот цикл, аллоцируй Go новую переменную для каждой итерации.
@@finalename7464 дополнительно сожрал бы не больше, чем размер итерируемого массива.
Не хочешь, чтобы выделялась память, итерируйся по индексу:
for i := range numbers
@@wskeal86 На самом деле больше, потому что это не массив, а значит не непрерывная память (будет выравнивание), плюс сам процесс аллокации каждой переменной в отдельности дорогой. Плюс сама такая аллокация гораздо чаще не нужна, чем нужна. Если тебе действительно надо такое поведение, напиши дополнительный код. А как поведение по-умолчанию это никак не подходит.
Если размещать на стеке, то можно непрерывно разместить, итак все будет выравнено. Функция знает какой длины слайс в нее передается, а значит может на стеке выделить кол-во переменных равной длине слайса.
По-умолчанию и не надо, достаточно чтобы как в примере из видео, если внутри цикла переменная по указателю передается куда-то, то компилятор должен это понимать и различать такие функции. Если ничего никуда не передается, то выделять память под каждую переменную не нужно.
@@wskeal86 По сравнению с динамической памятью (кучей) стек весьма мал и размещая слишком много данных в стеке легко получить stack overflow. Компилятор должен понимать и есть поведение по-умолчанию. И нет, по-умолчанию такое поведение обычно неприемлемо.
"быстрое развитие языка, введение дополнительных фич" - это точно про го?
2:32:13 это у них Paxos?
На х2 кайф)
обалденный собес, саня крут
Почему в разделе про индексы GIN засунули в геоиндексы, хотя он относится к полнотекстовым, а хэш представили как индекс для поиска неточных значений через LIKE, хотя он предназначен только для поиска точных значений? И сказали про то, что B-tree не умеет в LIKE %query?..
Че-то Сергей в разработке нотификатора куда-то ушел не туда. Зачем вся эта нашлепка с базой. Есть же NACK в брокере .
Менторская программа работает? Я заполнил инфу телеграм-боте
Напишите нашему менеджеру: t.me/skills_mentoring, мы найдем ментора для вас и во всем разберёмся
Парень на мидла вполне гуд...
Некоторые вещи сеньорские или мидл + спрашивались, а учитывая 3 часа ... так совсем
Bool это хоть и битик, но весит байтик т.к минимальная единица адресации байт.
О боже, сколько вкладок...
3 часа кажется слишком растянуто
Здравствуйте, как узнать расценки по менторской программе для студента?
Добрый вечер! Чтобы узнать стоимость занятия с ментором необходимо оставить в нашем боте: t.me/skills_mentee_bot заявку на менторство, заполнив форму, после этого менеджер свяжется с вами, предложив подходящих для вас менторов вместе с ценой за занятие.
я чуть тапком в монитор не бросил на примере с указателями на 40 минуте... Ну что он так
Лол, первый раз такое слышу что RabbitMQ устарел
все устарело, это специально, чтобы ты не расслаблялся.
быстрое введение новых фич в го? шо
вот очень интересны способы решения проблем на этом тайм коде ua-cam.com/video/ryJOS-8hmQo/v-deo.html
*dataChan:= make(chan string)*
go func() {
dataChan
Простите за глупый вопрос, реально вкатится в Го без комерческого опыта ?
Взял да сделал пару pet-projectов, пробуешься на джуна. Мне кажется как в любом другом языке
@@art3a спасибо )
Нуу!!! Гошка ?! - оччень простой язык- если вы раньше писали на плюсах /питоне /джаве - тут воообще говорить не очем - одного дня достаточно.
Но это только - язык! Друго дело технологии - тут все намного сложней. Про коммерческий опыт - тут все интересно. Например проходишь собес = там тебе
говорят "ну у нас тут все - круто - все по чистой архитектуре, все 12-ти факторно и Ci/Cd есть - все процессы налажены, тестирование - да!- все чин почину,
реальность же показывает что в компании - расцвел зоосад буйным цветом и, так как вся команда работает по аджайлу, то есть "коммуникации важней документации", то
никто не знает как "все тут устроено" -в итоге от тебя требуются недюжие коммуникативные навыки чтобы как-то что-то узнать, и
софтскилы чтобы самому разобраться в коде.
Да, вот еще - про Гошку, лично я - счастлив, что есть такой язык - на нем прогать - одно удовольствие, чего не скажешь о плюсах/джаве/шарпах.
@@user-ln2ft2mo3c " все по чистой архитектуре, все 12-ти факторно и Ci/Cd есть - все процессы налажены, тестирование - да!- все чин почину" - это про какую контору, если не секрет?
@@criss-cross Ну кстати сейчас ногие конторы - в частности Авито Озон ВК Сбермаркет = все они развивают платформу PaaS DDasS И так далее, но в отдельно взятой команде может встретится всякая дичь и, понимаете, тут все зависит от тимлида, если он реально сам прогает, занимается кодревью, - тогда в такой команде - все четенько, а если нет - то как правило кодовая база - зоосад
> 01:12:22-01:16:40 Garbage collector see sharp
SEE sharp 😅
Пофиксили, спасибо)
don't look, don't SEE 😉
Тот самый момент когда увидел отсутствие вызова функции гораздо раньше интервьюированного
мне на trainee те же самые вопросы задают))) создаёте тренды, ахаха
про потокобезопасность слайсов ничо не понял. помоему оба ничо не понимают)))
поясните ктото простым языком что хотели спросить.. и как есть на самом деле ???
Представьте ситуацию, когда у вас есть общая коробка яблок и два человека которые хотят взять по яблоку из него. У коробки есть дырка, в которую может пролезть только одна рука. Одновременно они взять по яблоку не могут, им приходится делать это по очереди, для этого же используются мьютексы. Почитайте про атомарность, мьютексы.
хайп
решение для задачи про утекшие горутины 1:10:34 play/p/vSyoIvTqxaB
каеф
Как то так себе отвечал, а джюн и то не согласен с большинством ответов с обоснованными причинами
Про что ты конкретно говоришь? По итогу, всё +- верно, были проблемы, но на более сложных вопросах. Либо ты на самом деле не джун, либо ошибаешься
мидл ваще не рубит в практике! чисто зазубрил теорию!
ужас, как же они разговаривают
совершенного бессвязная речь у обоих
не удивительно, что в приложениях все лагает
21:27 вы хотите сказать, что sync.RWMutex + map будет быстрее, чем sync.Map?
Напишите бенчмарки и убедитесь сами. Ну елки палки, вроде, сеньор собес проводит, и такие ошибки допускает…
Да какой он сеньор - просто пиарится! 5 лет всего в разработке 3- но гошке - О! - Сеньор !
@@user-ln2ft2mo3c а сколько лет коммерческого опыта в целом и в Go в частности нужно, чтобы по-вашему считаться true-синьором?
10 лет в общем и 5 лет в го это уже сеньор или еще миддл?
@@wskeal86 в целом верно - лет 10 опыта в разных компаниях - необязательно на ГО
А вы сами бенчи-то писали? sync.Map быстрее в случаях, когда у вас много чтений. Но даже при 99% чтений sync.Map может снизить перф, по сравнению с sync.RWMutex
@@VladVlad-qm3bl ну конечно писал, иначе не писал бы таких гневных комментариев😂
Этим всё сказано:
The Map type is optimized for two common use cases: (1) when the entry for a given
key is only ever written once but read many times, as in caches that only grow,
or (2) when multiple goroutines read, write, and overwrite entries for disjoint
sets of keys. In these two cases, use of a Map may significantly reduce lock
contention compared to a Go map paired with a separate Mutex or RWMutex.
пописать прерывались хоть?
Вы меня конечно простите, но в Go Сергей джун, а не мидл. Сергей, советую тебе пересмотреть своё интервью и постараться найти более чёткие и лаконичные ответы на вопросы. Мне показалось, что твоя основная слабость - это приблизительность или поверхносность знаний и поэтому ты плохо улавливаешь суть. Как только ты это исправишь, сможешь легко стать и мидлом и сеньйором. Ты вроде бы не глупый парень и я думаю, что у тебя получится.
тупое интервью, такого не бывает
автор не может связать двух слов, все рассказывает сам, вопросов не задает, кандидат отвечает хреново
нифига у него череп кривой
Бро уже поплыл после собеса. Да и я тоже.