Golang
Какво е сигналът SIGTERM (kill -15) и защо е по-добре да го използвате вместо SIGKILL (kill -9)?
Какви са нивата на изолация на транзакциите? Кои сте използвали?
Спомнете си ситуация от предишния ви опит, когато видяхте, че архитектурното решение, предложено от тимлида или архитекта, не беше оптимално. Какво направихте в такава ситуация? Дали по някакъв начин защитихте своята гледна точка?
Може ли да се реализира RPC чрез REST и обратно? Каква е принципната разлика?
Какво се случва, когато капацитетът на слайса е изчерпан и се добавя още един елемент?
Какви са разликите между HTTP/1, HTTP/2 и HTTP/3?
Кой още беше в екипа освен теб и тим лидера?
Кой е част от екипа по размер?
Какво ви е по-близо — продуктова или инфраструктурна разработка?
Разкажи за архитектурата на текущия проект
Колко активен е в момента търсенето? Вече сте решили да напуснете [компанията] или все още разглеждате интересни предложения?
Актуализациите на документи постъпват в услугата message Document { string Url = 1; // URL на документа, неговият уникален идентификатор uint64 PubDate = 2; // обявеното време за публикуване на документа uint64 FetchTime = 3; // времето на получаване на тази актуализация на документа, може да се счита за идентификатор на версия. Пара (Url, FetchTime) е уникална. string Text = 4; // текстът на документа uint64 FirstFetchTime = 5; // първоначално липсва, трябва да се попълни } Документите могат да пристигат в произволен ред (не в реда, в който са били актуализирани), и може да има дублиращи се съобщения. Необходимо е на изхода да се формират същите съобщения, но с коригирани полета според следните правила (всичко по-долу важи за група документи със същото поле Url): Полето Text и FetchTime трябва да са такива, каквито са в документа с най-голям FetchTime, получен досега. Полето PubDate трябва да е такова, каквото е в съобщението с най-малък FetchTime. Полето FirstFetchTime трябва да е равно на минималната стойност на FetchTime. Тоест, във всеки момент взимаме PubDate и FirstFetchTime от първата версия, получена досега (ако ги сортираме по FetchTime), а Text - от последната. Интерфейсът в кода може да бъде реализиран така: type Processor interface { Process(doc *Document) (*Document, error) } Този код ще работи в услуга, която чете съобщения от опашка (Kafka или подобна), и също така записва резултата в опашката. Ако Process връща Null, нищо не се записва в опашката.
Представи си ситуация: ти си дошъл в проект, където кодът е писан с години, има много легаси, няма тестове, и всичко това е трудно за дишане. От къде ще започнеш работата в такава ситуация, ако трябва да въведеш нова функция?
Винаги ли pprof ще покаже, че имаш теч на памет или превишаване на лимита?
Разкажи накратко с какво си се занимавал на предишните си работни места и какви функции си реализирал.
Реализирайте функция, която приема []any и delta int. Необходимо е да увеличите с delta само първите срещания на уникални числа (int). Други типове и повторни числа оставете без промяна. Функцията трябва да върне актуализирания списък и 2 числа: updated – колко уникални числа са били променени, duplicates – колко числови елемента се оказаха дублиращи се func IncrementUniqueIntsInMixed(xs []any, delta int) ([]any, int, int) { // вашият код } // Пример: xs := []any{1, "a", 5, "b", 1, 0, 5} u, d, s := IncrementUniqueIntsInMixed(xs, 3) // xs == []any{4, "a", 8, "b", 1, 3, 5} // u == 3 // уникални числа: 1, 5, 0 // d == 2 // повторни числа: втори 1, втори 5
Каква е сложността на операциите с map в най-лошия случай при колизии?
Имате ли опит с Docker и Kubernetes? На какво ниво?
Разкажете за патърна Transactional Outbox — как работи и за какво се използва?
Имаш ли опит с оптимизация на заявки в релационни бази данни?