System Analyst
Cik aprēķini būs algu un iemaksu dokumentā, ja darbinieks pusmēnesi bija pagaidu darbinieks, pēc tam pārcelts uz parciālo samaksu?
Kā nodrošināt naudas pārskaitījuma darījuma integritāti starp bankām, lai nauda netiktu zaudēta vai dubultota?
Vai jums ir pieredze ar REST API?
Uzskaitiet galvenos programmatūras prasību veidus
Kā atšķirat biznesa prasības no funkcionālajām? Parādiet ar vienu piemēru.
Kas ir nefunkcionālie pieprasījumi? Sniedziet piemērus. Vai informācijas drošības prasības ir funkcionālas vai nefunkcionālas?
UML. Kādi elementi tiek izmantoti? Pareiza lomu izmantošana. Nosauciet elementus. Identificējiet kļūdas. Definējiet formātu.
Aprakstiet datu plūsmu, pērkot grāmatu — klients ir autorizēts, atrodas grāmatas lapā, vēlas to iegādāties. Uz kurieni dosies pieprasījums no API Gateway?
Kas ir indeksi datu bāzē un kam tie ir nepieciešami?
Aprakstiet OAuth 2.0 autorizācijas secību
UML. Kādi elementi tika izmantoti?
Kā jūs izmantojat Grafana savā darbā?
Kādi ir algu aprēķina posmi?
Kādā lomā vai procentuālajā attiecībā (biznesa analītiķis vs sistēmas analītiķis) vēlētos strādāt?
Praktiskā uzdevums: Vienota paziņojumu platforma (Notification Platform) Konteksts Uzņēmumā ir 3 izkaisīti sistēmas, kas sūta paziņojumus lietotājiem: 1. CRM — sūta e-pastus un push paziņojumus par pasūtījumiem. 2. Atbalsta portāls — sūta ziņojumus par biļetēm Telegram botā. 3. Drošības sistēma — ģenerē SMS paziņojumus par aizdomīgiem pieslēgumiem. Katrs sistēma īsteno savu loģiku: * savas šablonus, hardcoded saņēmējus; * nav centralizētas paziņojumu vēstures; * lietotāji sūdzas par dublēšanos un kavēšanos; * nav vienota SLA, metriku vai vadības centra. Mērķis Izstrādāt jaunu Notification Platform, kas: * apkopo notikumus no dažādiem avotiem (CRM, Support, Security); * tos maršrutē pēc veida un kanāla (epasts, SMS, Telegram, push); * nodrošina šablonu vienotību, reģistrēšanu un novērojamību, * atbalsta SLA (p95 ≤ 3 sekundes piegādei), * ļauj mērogot un paplašināt kanālus nākotnē. Kandidāta uzdevums 1. Definēt sistēmas funkcionālos prasības. 2. Aprakstīt nefunkcionālos prasības (drošība, veiktspēja, kļūdu apstrāde). 3. Izveidot konteksta diagrammu (C4 līmenis 2). 4. Pievienot secības diagrammas shēmu. Piemēram, ziņojuma sūtīšana no CRM.
Kuru HTTP metodi jāizmanto cashback apmaiņas pogai REST API un kāpēc GET nav piemērots?
Ko var darīt, lai izstrādātāji un testētāji varētu strādāt bez tava pastāvīgā iesaistīšanās?
Vai esat saskāries ar low-code izstrādi? Kā uz to skatāties?
Kādus produkta izstrādes dzīves cikla posmus jūs zināt?
Kuri produkti ir interesantāki: iekšējie vai orientēti uz galalietotāju?