System Analyst
Érti a telekommunikációs platformhoz tartozó számlázási rendszer leírt projektjét?
Részt vettél már olyan rendszer reverse engineeringben, ahol nincs dokumentáció, és meg kell értened a forráskódot?
Milyen típusú integrációkkal dolgoztál? Szinkron és aszinkron interakciós tapasztalat?
Milyen típusú kapcsolatok nevezhetők meg a táblák között?
Vannak most más cégek ajánlatai vagy végső szakaszban van más cégekkel?
Rendszerszintű konfliktusok megelőzésének példái
Mi az az offset?
Szüksége volt már REST API szerződések leírására?
Létrehozott már ERD-t (Entitáskapcsolati diagramokat)?
Hogyan értékeled az integrációs tervezési tapasztalatodat, a REST és SOAP munkát?
Részt vettél már ipari környezetben (gyártás) incidensek elemzésében és kivizsgálásában?
Gyakorlati feladat: Egységes értesítési platform (Notification Platform) Környezet A cégnél 3 széttagolt rendszer van, amelyek értesítéseket küldenek a felhasználóknak: 1. CRM — e-maileket és push értesítéseket küld a megrendelésekről. 2. Support Portál — üzeneteket küld a jegyekről a Telegram boton keresztül. 3. Biztonsági rendszer — SMS értesítéseket generál gyanús bejelentkezésekről. Minden rendszer saját logikát valósít meg: * saját sablonok, hardcoded címzettek; * nincs központi értesítési történet; * a felhasználók duplikátumokról és késedelmekről panaszkodnak; * nincs egységes SLA, metrikák vagy irányítási központ. Cél Új Notification Platform tervezése, amely: * eseményeket gyűjt különböző forrásokból (CRM, Support, Security), * azok típus és csatorna szerint (email, SMS, Telegram, push) irányítja, * egységes sablonokat, naplózást és megfigyelhetőséget biztosít, * támogatja az SLA-t (p95 ≤ 3 másodperc a kézbesítéshez), * lehetővé teszi a csatornák skálázását és bővítését a jövőben. Feladat a jelölt számára 1. Határozza meg a rendszer funkcionális követelményeit. 2. Írja le a nem funkcionális követelményeket (megbízhatóság, teljesítmény, hibakezelés). 3. Készítsen kontextusdiagramot (C4 Szint 2). 4. Adjon hozzá egy szekvenciadiagram vázlatot. Például, CRM-ből történő üzenetküldés.
Milyen tényezők fontosak számodra egy új hely keresésekor? Mi a zöld zászló és mi a piros zászló?
Mi az a piszkos olvasás, és mikor lehet hasznos?
Mi a különbség a REST-integráció és az üzenetközvetítők között?
Mit csináltál a jelenlegi projekt munkafolyamata során?
Mi a különbség a PUT és a PATCH között?
Milyen gyorsan alkalmazkodik egy új környezethez? Rugalmasságnak tartja magát?
Milyen adatbázisokkal dolgozott, és pontosan mit csinált?
4. eset: Védekezni kell a csalás ellen az attribúció során, amikor az eseményeket közvetlenül a szerverünkről küldjük az AppsFlyer szerverére. Kontextus: az alkalmazás emulátor támadásoknak, telepítési csalásoknak, hamis kérdőív kitöltésének van kitéve. Az AppsFlyer alap anti-fraud (Protect360) része blokkolja a forgalom egy részét, de az üzlet belső egyedi validáció bevezetését írja elő, mielőtt a végső eseményeket elküldenénk a reklámcsatornákhoz. A reklámcsatornák a click_id-t továbbítják, amely alapján szűrni kell az eseményeket — csak a hitel kiadásáért fizetünk. API-interakciós séma és üzleti szabályok kidolgozása szükséges a biztonságos konverzióátvitelhez: milyen feltételek mellett jelölhető egy esemény érvényesnek és küldhető a partnernek, és mikor nem érvényes, valamint hogyan kezeljük minden esetben.