System Analyst
Kokį darbo formatą svarstote?
Ką reikia užfiksuoti aprašant integraciją iš analitikos perspektyvos?
Kaip vyksta reikalavimų aiškinimas proceso metu — per susitikimus, komentarus Jira, Confluence ar atskiras sinchronizacijas?
Ar jūsų pardavimo patirtis padeda jums dabartinėje analitiko profesijoje?
Kaip įvertinote užduotis — naudojant story points ar kitaip?
Kokiu kitu formatu, išskyrus YAML, gali būti aprašyti tiekėjo paslaugos?
Kokius testavimo tipus žinote?
Kodėl turime atnaujinti savo duomenų bazėje, kad kamuolys yra SAP pusėje? Kodėl SAP pats negali atnaujinti statuso?
Su kokiais architektūros tipais susidūrėte?
Ar dalyvavote priėmime ir testavime?
Papaskinkite apie savo paskutinį projektą, su kuo jis buvo susijęs, koks buvo jo sritis?
Kokiu darbo formatu dirbote: TК, GПХ ar IP?
Koks jūsų SQL lygis, kokius užklausas rašote?
Je REST užklausa, kuri trunka minutę, sinchroninė ar asinchroninė?
Ar ruošiate specifikaciją žinių bazėje ar OpenAPI formatu, ir kokią informaciją aprašote?
[vardas] paklausė: ar būtų patogu dirbti Outstaff formatu?
Praktinė užduotis: Vieninga pranešimų platforma (Notification Platform) Kontekstas Įmonėje yra 3 išsklaidyti sistemos, kurios siunčia pranešimus naudotojams: 1. CRM — siunčia el. laiškus ir push pranešimus apie užsakymus. 2. Support Portal — siunčia žinutes apie bilietus per Telegram botą. 3. Saugumo sistema — generuoja SMS pranešimus apie įtartinus prisijungimus. Kiekviena sistema įgyvendina savo logiką: * savo šablonus, hardcoded gavėjus; * nėra centralizuotos pranešimų istorijos; * naudotojai skundžiasi dėl dubliavimosi ir vėlavimų; * nėra vieno SLA, metrikų ar valdymo centro. Tikslas Sukurti naują Notification Platform, kuri: * kaupia įvykius iš skirtingų šaltinių (CRM, Support, Security), * juos maršrutizuoja pagal tipą ir kanalą (el. paštas, SMS, Telegram, push), * užtikrina šablonų vienodumą, registravimą ir stebėseną, * palaiko SLA (p95 ≤ 3 sekundės pristatymo), * leidžia mastelio keitimą ir kanalų plėtrą ateityje. Kandidato užduotis 1. Apibrėžti sistemos funkcinius reikalavimus. 2. Aprašyti nefunkcinius reikalavimus (patikimumas, našumas, klaidų tvarkymas). 3. Sukurti kontekstinį diagramą (C4 lygis 2). 4. Pridėti sekvencijos diagramos schemą. Pavyzdžiui, pranešimo siuntimą iš CRM.
Stebint mokėjimo sistemomis susijusius skaičiavimus, aptikote klaidą duomenų perdavime per tarpinių bazinių jungčių. Kokia yra efektyviausia veiksmų seka? - Nedelsiant perkrauti problematišką jungtį - Laikinai naudoti alternatyvų duomenų perdavimo kanalą - Pranešti techninei pagalbai ir laukti tolimesnių nurodymų - Analizuoti žurnalus, nustatyti priežastį ir tada veikti
Kodėl gali būti bloga idėja, jei naudotojas prašo pridėti reikalavimą prie dokumento, kad vėliau pagal jį būtų sudarytas ataskaita?
Papaskinkite apie CI/CD nustatymus ir konteinerizaciją Docker projekte — ką tiksliai darėte?