Golang

/* Есть приложение с микросервисной архитектурой. Микросервис можно абстрагировать с помощью интерфейса Backend. Для доступа к одному экземпляру микросервиса можно использовать тип BackendImpl, который уже реализован. Для каждого микросервиса есть несколько десятков запущенных экземпляров, каждый из которых доступен по своему адресу addr. Однако отдельные экземпляры микросервиса ненадежны: они могут падать, быть недоступными либо перегруженными. Поэтому вам нужно реализовать тип Balancer, который также реализует интерфейс Backend и осуществляет client-side балансировку нагрузки между экземплярами микросервиса, выбирая каждый раз **наименее нагруженный** экземпляр. */

Какие у вас зарплатные ожидания?

Что такое panic, как обрабатывать, можно ли поймать?

Как ты продолжаешь профессионально развиваться?

Знаком ли вам механизм same-size grow в map? Что такое эвакуация в map и при каких операциях она происходит?

Какие-нибудь транзакции могут помочь или не могут?

Senior

VK

Кто должен закрывать выходной канал out — функция merge или main?

Как вы взаимодействовали между собой — были общие встречи, планирование, дейлики?

Senior

Avito

Какой уровень изоляции транзакций подойдёт в данном случае?

Senior

VK

Весь опыт официально по ТК?

Middle+

VK

По заработной плате от какой суммы рассматриваете предложение?

Senior

ВкусВилл

// Вопрос 2. Что выведет на экран package main import "fmt" func main() { { defer fmt.Println(1) } defer fmt.Println(2) panic("aaaa") defer func(){ if r := recover(); r != nil{ fmt.Println("Паника обработана", r) } } }

Какое оформление вас интересует — ИП, ГПХ или трудовая?

Какие индексы в PostgreSQL знаешь?

Пиковая нагрузка: 25k чтений / 5k записей в секунду Объем новых данных: 10 ТБ в год Пиковый параллелизм: 120k одновременных запросов Годовой рост пользователей: 30% Целевой p99 задержки: <150 мс для чтений, <400 мс для записей Целевая доступность: 99.95% Ваша задача — разработать архитектурное решение, которое позволит устранить текущие проблемы, обеспечит согласованность и отказоустойчивость, а также внедрить механизмы трассировки для полного мониторинга жизненного цикла заказа. Опишите механизм обработки сбоев, план миграции с текущей архитектуры, и объясните, как предложенное решение улучшит надёжность и прозрачность системы.

Расскажи про брокеры сообщений, с которыми работал.

Middle+

OZON

// Исправить код так, чтобы запросы были конкурентными и выводился код ответа // и в случае ошибки - выводили ее лог и продолжали обработку package main import "net/http" var addrs = []string{"[link] "[link] "[link] "[link] "[link] "[link] "[link] func main() { wg := sync.WaitGroup{} data := make(map[string]bool) for _, url := range addrs { wg.Add(1) if !data[url]{ data[url] = true go func(url string){ defer wg.Done() resp, err := http.Get(url) if err != nil { log.err return } log.info }(url) } } wg.Wait() }

Расскажи про модель GMP в Go. Как работают очереди, что такое handoff, work stealing, netpoller?

С чем связано решение уйти из Wildberries?

// Написать асинхронный обработчик задач как библиотеку // Клиент передаёт на вход некоторый объект (Task) с данными для выполнения задачи, // в нашем примере будем использовать пустую структуру. // Обработчик одновременно может обрабатывать не более N задач, // и не более X задач могут быть поставлены в очередь на обработку. // Если нет места в очереди, сразу возвращаем клиенту ошибку. // Задача берется в обработку если имеются на это свободные обработчики. // Иммитируем длительность обработки через time.Sleep(5*time.Second). // Как только очередная задача выполнилась - берём следующую задачу из очереди. // Если в очереди пусто, ожидаем новых задач от клиентов. // Со звездочкой: дополнить структуру Task и получать статусы задач через отдельный запрос