RUB
Date insuficiente · n=1

Company overview
Ultimul post: 6 august 2026
Published in the selected period
Currencies are not converted. Lower and upper bounds are calculated independently and show their own sample sizes.
Date insuficiente · n=1
Published records
Interviuri · 19
Interviuri · 12
Interviuri · 5
Interviuri · 4
Interviuri · 3
Interviuri · 2
Interviuri · 1
Interviuri · 1
Interviuri · 1
Interviuri · 1
Interviuri · 1
Interviuri · 1
Interviuri · 1
Grouped by direction
Întrebări · 203
Proiectarea unui sistem de mesagerie scalabil care suportă 150 milioane de utilizatori, 75 milioane DAU, 225 milioane MAU, 1,2 milioane QPS de citire / 300k de scriere în vârf, 5 milioane de utilizatori simultani, 60 PB de date noi pe an, creștere de 30% anual, SLA 99,95%, p99 <200 ms pentru citire, <300 ms pentru scriere. CONTEXT Este necesar să proiectăm un sistem de mesagerie distribuit, similar cu WhatsApp, care suportă chat-uri 1:1 și de grup, asigură livrarea mesajelor, afișează statusurile online ale utilizatorilor și permite transferul de fișiere multimedia (poze, videoclipuri, audio). Sistemul trebuie să asigure disponibilitate ridicată și latență scăzută, să suporte un paralelism înalt și să scaleze la nivel global. CERINȚE FUNCȚIONALE - Suport pentru chat-uri personale (1:1) și de grup cu posibilitatea de a adăuga/elimina participanți - Trimiterea și primirea de mesaje text și fișiere multimedia Nu se observă o implementare clară a mecanismului de criptare end-to-end la nivel de servicii sau clienți, în afară de o notă generală. - Lipsește o descriere explicită a sharding-ului și replicării bazelor de date după chat_id sau user_id pentru scalabilitate și toleranță la defecte. - Nu există un component sau mecanism clar pentru gestionarea sincronizării offline a mesajelor și a confirmărilor de livrare. - Nu este clar cum se face echilibrarea încărcăturii între baze de date și servicii, mai ales în perioadele de vârf. **Puncte critice de luat în considerare:**
type Response interface{} type Backend interface { Invoke(ctx context.Context, req Request) (Response, error) } var _ Backend = &BackendImpl{} // addr conține ip:port-ul unei instanțe specifice func NewBackend(addr string) *BackendImpl type backentry struct { backend Backend inflight int64 } type Balancer struct { backends []*backentry mu *sync.Mutex } var _ Backend = &Balancer{} // addrs conțin adresele tuturor instanțelor balansabile func NewBalancer(addrs []string) *Balancer { data := make([]*backentry,len(addrs)) for i,addr := range addrs{ data[i] = &backentry{ backend: NewBackend(addr), inflight: 0, } } return &Balancer{backends:data} } func(b *Balancer)Invoke(ctx context.Context, req Request) (Response, error){ b.mu.Lock() entry := b.best() atomic.AddInt64(&entry.inflight,1) b.mu.Unlock() defer atomic.AddInt64(&entry.inflight,-1) return entry.backend.Invoke(ctx,req) } func(b *Balancer) best() *backentry{ var best *backentry for _,entry := b.backends{ if best == nil || atomic.LoadInt64(&entry.inflight) < atomic.LoadInt64(&best.inflight){ best = entry } } return best }
Întrebări · 163
Care este diferența dintre metodele areContentsTheSame și areItemsTheSame în clasa DiffUtil și la ce sunt folosite?
Care este diferența dintre utilizarea metodelor subscribeOn și observeOn în RxJava și cum influențează fluxul de execuție?
Создание собственного аналога findViewById для View
Нахождение ближайшего общего предка в иерархии экранов
Разбор поведения flatMap в цепочке RxJava
Întrebări · 123
Întrebări · 109
Что выведет console.log в примере №81
Функция определения палиндромности строки
Надёжный GET‑запрос с автоматическим повтором
Проверка массива на монотонность
Определение пути перелёта между двумя пунктами
Что будет выведено в консоль в данном JavaScript‑фрагменте?
Întrebări · 97
Întrebări · 83
Întrebări · 57
Întrebări · 41
S-a folosit ML pentru selecția caracteristicilor în sarcina de clasificare a mașinilor?
A fost odată ca niciodată, un stagiar antifraudă de la Yandex Ads s-a alăturat echipei. În timp ce grupul de fraudă era activ, simulând trafic pe site-urile lor prin vizite de roboți, și astfel primind bani pentru afișări de reclame de către roboți, sarcina stagiarului era să găsească toate aceste site-uri frauduloase cu trafic fals. Interesant este că tot traficul pe aceste site-uri era generat cu substituție de IP, făcând să pară că un robot vizita din orașul A, dar în realitate, dispozitivul era într-un loc complet diferit. A trecut mult timp, iar stagiarul a încercat să acopere întregul grup de fraudă, reușind chiar să prindă unele site-uri parțial. Dar nu a reușit să prindă întreaga rețea. După un timp, a observat o știre: în orașul A, pe 02.08.2025, nu exista deloc internet mobil. Cu toate acestea, internetul prin cablu (de acasă) continua să funcționeze. Având în vedere acest lucru, cum poate stagiarul să găsească toate site-urile false? Ai loguri ale site-urilor în format tabel pentru perioada 30.07.2025 - 10.08.2025: timestamp | site_id | city_id Fiecare înregistrare corespunde unei vizite pe un site de către un dispozitiv. Se știe că traficul de roboți se schimbă mult mai puțin decât traficul real pe zi. Sarcina ta este să găsești toate site-urile al căror trafic a fost în mare parte format din roboți care și-au falsificat regiunea în orașul A. Notă Tabelul care conține datele se numește logs. Exemplu de înregistrare în tabel: timestamp | site_id | city_id [phone]:13:53 | 6e84d9b71ca44aea | A
Întrebări · 31
Întrebări · 25
Întrebări · 13
Întrebări · 12
Întrebări · 10
Întrebări · 10
Întrebări · 4
Întrebări · 4
Întrebări · 3
Întrebări · 3
Întrebări · 1