Продолжаю гриндить собесы

1) Было второе интервью в аутсорс-компанию на проект Reddit
Пока это валидация со стороны подрядчика, дальше 2-4 собеса уже с Reddit.

На интервью дали задачу: есть лимит (деньги) и набор монет. Нужно перебирать монеты, пока сумма не превышает лимит. Как только превышаем - это считается одной попыткой "размена", даже если сумма меньше самого лимита. Типичная задача на DP. Разложил top-down решение, на что интервьюер сказал "ай донт андерстенд", попросил после интервью скинуть решение через HR 😧 и мы просто перешли к другой задаче.

2) Собес в компанию FYST — они пилят API gateway на Go
Формат стандартный: live coding + вопросы по базам.

Первое интервью которое мне реально понравилось - нормальный темп, адекватные интервьюеры
Узнал что создание индекса через CONCURRENTLY в PostgreSQL не гарантирует что индекс создатся полностью(он может быть помечен как не валидный - не используется, но обновляется)

Потом было финальное интервью - немного странные вайбы, есть шанс что завалил

Отдельно - в LinkedIn начали стучаться рекрутеры из англоязычных стартапов/компаний.
Где-то выдали тестовое, где-то сразу позвали на техраунд.
Буду держать в курсе, что из этого выйдет😘

Апдейты по собесам

В прошлом посте писал про интервью в Reddit через аутсорс
Пришёл фидбэк - отказ Причина: нерешённая первая задача и какие-то техвопросы, на которые я не дал ответа 🤨

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

На этой неделе было три собеса: два system design, один Go на английском
Последний по деньгам ~5k, не топ, но радует что такие собесы появляются

System design #1 - Uzum
Есть существующая система (см. картинку), модифицировать нельзя
Задача - прокинуть локацию курьера клиенту через long-polling и вписаться в SLA

Это собес прошел хоть и со сложностями, моей ошибкой было прикручивать PostgreSQL и select for update при скейлинге сервиса предрассчитывающего геолокацию курьера - чтобы не обрабатывать один и тот же order-id в разных инстансах
В результате держались транзакции, пока шли запросы к другим сервисам
Изначально хотел прикрутить Redis-локи, но не знал, как они устроены - поэтому от идеи отказался

System design #2 - крипто-стартап (на англе)
Задизайнить фичу: подписка на изменение цены криптовалюты
Пользователь получает email, если цена превысила/упала ниже заданной

Тут прям зафейлил
Придумал отдельный matcher-сервис, который поллит БД: ищет подписки и пытается смэтчить с текущими ценами
Когда вместо этого можно консьюмить цены по криптовалютам -> подписки хранить в памяти консьюмера и там же мэтчить

Во-первых спасибо что подписываетесь, всех обнял 👉
Во-вторых я начал делать посты в линкедин, коннектитесь если интересно

В третьих апдейты по собесам

1) Uzum - прошло хорошо, выбрали другого кандидата
2) InDrive - ответил на все вопросы, но по ощущениям занизили грейд до мидла. Процесс на этом я закончил
3) Criteo - ворвался чисто по фану. У них нет привязки к языку - два литкод-собеса, один систем дизайн
- Первый литкод собес - sliding window
- Второй как эта задача только с бизнесовым контекстом
- Третий систем дизайн - tinyUrl

По ощущениям было изи, только в первом алгособесе интервьюер прерывал меня и не дал довести оптимальное решение. Задачку приложу в коммент, если интересно

Продолжаю дальше бежать по собесам, написали из plata и еще из пары аутсорсов

Апдейты по собесам

1) Финал в Criteo. Общался с двумя русскоязычными продактами.
Проект - система реального аукциона для показа рекламы. Показывается реклама с большим bid_id. Нагрузка - 1k rps, бэк на Lua и движок на плюсах.
Сделали предоффер, в понедельник выложу сам оффер и цифры. Финал был чиловым, один из лидов заценил мои посты в LinkedIn

2) Plata. На следующей неделе систем дизайн. Готовлюсь. Хочу закрыть неделю двумя офферами

Как приму офер, выложу табличку со статистикой, веду ее с начала лета.

Недавно общался с эйчаршей. Рассказывала, что у них в компании очень умные разработчики, потому что у всех есть вышка💀. После, попросила рекомендацию с прошлого места работы, очень странно, переписку приложу в коммент. Это ред флаг или нет, что думаете?

Оффер от Criteo

Я пока живу в Ереване, поэтому сумма в драмах (AMD). На руки выходит около $4k 😢
Плюс отсыпали акции на $15600(Скрины в комментах)

В мае ещё будет бонус.
По классике - компания делает всё, чтобы удерживать сотрудников

Просчитался, но где😔

Спасибо за тёплые слова и поздравления - всех обнял 😘

Мой забег по собесам пока закончился. Иногда буду ходить, но уже на суммы от $10k+ (если такие вакансии вообще существуют 💸)

Сейчас пробую зачилиться как мой кот на картинке, но у меня шило в одном месте, поэтому хочется двигаться и чем-то заниматься. Начал решать дейлики на литкоде, также думаю взять подписку на csprimer и закрыть пробелы по "базе", плюс подтянуть матан через mathacademy

Я тут весь в делах - с кайфом залетел в мини-стартап(парт-тайм). Постараюсь писать стабильно, чтобы не было больших пауз🤑

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

У меня начались флэшбэки с собесов и задач которые мне давали, буду по-тихоньку их разбирать. На интервью по гошке часто просят реализовать кэш. Звучит несложно, hashmap + mutex/rwmutex

get(key)
 mx.RLock()
 defer mx.RUnlock()

 val, ok := data[key]

 return val, ok


put(key, val)
 mx.Lock()
 defer mx.Unlock()

 data[key] = val

И тут всплывает главное отличие между data race и race condition.

Data race - это непредсказуемое поведение при одновременном доступе к памяти без синхронизации. У нас используется mutex, всё безопасно.

Race condition - это логическая гонка.
Даже если синхронизация есть, результат может зависеть от порядка выполнения горутин. Что если 1000 горутин будут обновлять значение по одному и тому же ключу(cache stampede). Сжигаем cpu и создаём лишнюю нагрузку - все конкурируют за один и тот же mutex, хотя данные у всех одинаковые. Важно, нижеперечисленные оптимизации работают только если значения одинаковые и важен первый write, который затирает остальные.

Если же бизнесу важен последний апдейт - эти оптимизации не помогут, нужен совсем другой подход

1) Double checking
Просто и понятно, в put мы добавляем две проверки на наличие ключа. Тем самым горутина внутри мьютекса не будет перезаписывать значение если оно уже есть. Но все равно есть конкурентный доступ к мапе

put(key, val)
 mx.RLock()
 val, ok := data[key]
 mx.RUnlock()

 if ok {
   return 
 }

 mx.Lock()
 defer mx.Unlock()
 _, ok := data[key] // second check

 if ok {
   return 
 }

 data[key] = val

2) Сын маминой подруги - single-flight😎. Реализуется через киллер-фичу гошки - каналы. Вкратце - создается еще одна мапа calls, ключ любой key и value - канал, через который другие горутины будут ждать результат. Первая горутина, которая успела захватить мьютекс, создаёт канал и кладёт его в calls. Все остальные, кто пришел с этим ключом, ждут значение через канал

getOrput(key, val)
 mx.RLock()
 val, ok := data[key]
 mx.RUnlock()

 if ok {
   return 
 }

 mx.Lock()
 if _, ok = calls[key]; ok {
  mx.Unlock()
  return <- calls[key] // читаем из канала
 }

 ch := make(chan value, 1) // буф. канал чтобы не блокировать писателя
 calls[key] = ch

 data[key] = val
 delete(calls, key) // удаляем чтобы горутины не блокировались вечно на чтение и не читали старое значение
 mx.Unlock()

 ch <- val
 close(ch)

 return val

P.S
Эта задача была в индрайв - я разложил эту задачу до атомов, упомянув все перечисленные выше оптимизации, на сеньора не прошел 😧

Собес в яндекс
Наверно после этого поста меня занесут в черный список яндекса, пу-пу-пу😧. Мое отношение к этой компании больше негативное чем позитивное, я считаю они требуют на собесе очень много и платят меньше рынка. Также я сталкивался с сильной нехваткой софт скиллов у интервьюеров.

С начала года яндекс изменили процесс интервью(не везде), теперь у них есть секция по коду, для Go обычно это имплементация load balancer. Два раза я ходил на собес и два раза мне попалась эта задача. Накидываем слайс бэкендов и атомик для round robin.

type Request interface {
}
type Response interface{}

type Backend interface {
 Invoke(req Request) (Response, error)
}

type LoadBalancer struct {
 backends []Backend
 index    int64
}

func (lb *LoadBalancer) GetBackend() Backend {
 idx := atomic.AddInt64(&lb.index, 1)
 return lb.backends[(idx - 1) % int64(len(lb.backends))]
}

func (lb *LoadBalancer) Invoke(req Request) (Response, error) {
 backend := lb.GetBackend()

 return backend.Invoke(req)
}

Далее идет follow up, нужно отправлять запросы только на живые backend, health check никто не гарантирует.
Я не нашел ничего лучше как в Invoke маркировать живые бэкенды и в GetBackend это учитывать. Но я переусложнил потому что неживым бэкендам нужно давать "второй шанс" и пытаться отправлять на них запросы. Будет мапа которая маркирует живые, неживые и спустя какое-то окно мы будем давать неживым "второй шанс".
В общем самое простое решение - отправлять запрос до тех пор пока не получим ok от бэкенда

func (lb *LoadBalancer) Invoke(req Request) (Response, error) {
 for i := 0; i < len(lb.backends); i++ {
  backend := lb.GetBackend()
  response, err := backend.Invoke(req)

  if err == nil {
   return response, nil
  }
 }

 return nil, fmt.Errorf("no live backend available")
}

Задачка я бы сказал слишком дрочная, еще есть плюс баллы за код и минус за подсказки

Отключение AWS, из-за которого легла часть пользовательских сервисов - Snapchat, Fortnite, Duolingo, Signal, в Plata часть hr-сервисов тоже не работали, произошло из-за race condition в DynamoDB.

Коротко - два инстанса применяли DNS план, отправляя DNS записи в DNS Service(Route53).

Перед этим они проверяли версию плана, чтобы убедиться в применении только новой версии. Один инстанс сделал проверку и начал применять план, из-за задержки этот план успел устареть.

За это время второй инстанс применил новый план, обновил DNS Service и удалил старые версии, включая предыдущую. Когда первый инстанс закончил, он перезаписал новый план старым, уже удалённым, в итоге все ip адреса были удалены.

Далее всё каскадно упало из-за DynamoDB

Concurrency - база получается 🗒

Ссылка на оригинал