Programista w Banku

hej,

Mam rok komercyjnego doświadczenia jako programista java + OCPJP i stwierdziłem, że czas poszukać czegoś nowego - obecnie pracuję w telekomunikacyjnym korpo, a chciałbym spróbować pracy w banku.

Pytanie do osób, które pracują w tej branży - co warto umieć na rozmowy?
Chodzi mi o konkretne algorytmy powiązane z rachunkowością i finansami, przykładowe pytania, albo motywy programistyczne, które trzeba znać np takie, jak pieniądze, które trzeba przechowywać jako BigDecimal, bo w double gubimy grosze podczas dodawania.

Fajnie też jakby podzielił się wrażeniami z pracy / rozmowy rekrutacyjnej ktoś, kto miał styczność z Credit Suisse lub EuroBankiem.

Nie wiem czego te banki moga wymagac, nie pracowalem rowniez w zadnym banku, ale bylem na paru rozmowch, i moge powiedziec ze jesli lubisz nowe technologie to to srodowisko zdecydowanie nie jest dla ciebie. Oczywiscie, moglem miec pecha i trafic na bardzo skostniale banki...

Zgadzam się z mućką, praca w bankach to zazwyczaj utrzymywanie starych systemów, które często zostały napisane w przedpotopowych technologiach.
Dlatego też zarobki są często wysokie - nie każdy ma ochotę się w tym babrać, nieliczni wytrzymują nerwowo ;)

Jako, że z sektorem bankowym mam niestety do czynienia do dawien dawna:

1. Nikt nie będzie od ciebie wymagał znajomości algorytmów finansowych - od tego są analitycy i dokumentacja w jakiś 99% przypadków. Zresztą tyś programista nie księgowy.
2. Warto "ogarniać" wspomniany problem liczenia pieniędzy i typów zmiennoprzecinkowych.
3. Trzeba dobrze znać język jako taki np. umieć odpowiedzieć składnie na pytanie co to są adnotacje (a nie yyy.. takie coś w hibernate).
4. Trzeba ogarniać najpopularniejsze frameworki/technologie (spring, hibernate, toplink, JSF).

Pisz na pw w sprawie tych banków. Coś o niech wiem ;)

micc napisał(a):

Zgadzam się z mućką, praca w bankach to zazwyczaj utrzymywanie starych systemów, które często zostały napisane w przedpotopowych technologiach.

Nie zawsze jest tak źle, czasem tworzy się nowe projekty... oczywiście w przedpotopowych technologiach. ;)

Dlatego też zarobki są często wysokie - nie każdy ma ochotę się w tym babrać, nieliczni wytrzymują nerwowo ;)

Ostatnio byłem na rozmowie w banku, dla którego 7 tys netto na fakturze było górną granicą i "bardzo wysokimi wymaganiami".

W przypadku Credit Suisse musisz być przygotowany na możliwość rozmowy kwalifikacyjnej z obcokrajowcem, oczywiście w całości po angielsku.

A jakie technologie są używane w bankach? Może bym sprobował, ale ja znam tylko C++/C# i troche Asembler.

mcoder napisał(a):

A jakie technologie są używane w bankach?

Java i .NET. I ponoć trochę tych archaicznych.

Miałem rozmowę kwalifikacyjną na programistę "architektury bankowej" (cokolwiek to jest), wymagali świetnej znajomości Javy i podstaw Scali.

W bankach używa się "wszystkiego". Generalnie są to chyba jedyne firmy nieinformatyczne gdzie jest tak duża swoboda doboru narzędzi do problemów. Przy czym pewne technologie stosuję się tylko do zadań pomocniczych np. do raportowania czasu pracy mamy narzędzie w pythonie, ale już wiki jest w php. Znowuż główny soft jest w Javie napisany. Dużo różnych technologii, ale nie wszystko widać.

No tak, wewnetrzne narzedzia to jedno, ale systemy mission-critical to co innego. Tam z tego co slyszalem wielkiego pola do popisu nie ma, dla kazdej biblioteki nalezy uzyskac pozwolenie, sa jakies precedury itp. Np. chce dodac jakas funkcjonoalnosc bo takie sa wymagania, i jest biblioteka X ale nie moge jej uzyc bo nie jest uznana w jakichstam standardach. Prawda to? Powiem tylko ze sytuacja wyglada bardzo podobnie jak sie jest podwykonawca dla wielkich firm, np. Siemens - oni maja liste tego czego mozna uzywac, liste glownych technologii, updatowanej co 5 lat, i tyle. Np. aktualnie musza u nas pisac aplikacje z ejb3.0 i jsf 2 bo takie maja przepisy, a spring i wicket nie wchodza w gre.

@mucika, może inaczej. Na ten przykład u klienta, u którego teraz pracuję wszystkie używane biblioteki i narzędzia podlegają dodatkowemu "wzbogaceniu". Instrumentalizacja kodu jet na tyle mocna, że nie ma już pojęcia Struts 1.3 - jest pojęcie "strucel". W praktyce cały kod został przeryty i zmieniony na obraz i podobieństwo wymagań wewnętrznych. Jednocześnie możemy wprowadzać nowe rozwiązania, ale muszą one przejść audyt oparte o analizę kodu. Ktoś mądry napisał testy i je męczymy. Na całe szczęście nie trzeba często tego robić.

I tu sedno sprawy, temat poruszony rowniez w dziale Java - prostytutka, Struts 1.3??!! Nie mam wiecej pytan, jesli ktos pyta o uzywanie przestarzalych technologii. Za maven central: org.apache.struts:struts-core:1.3.10 (najnowsza wersja linii 1.x) updated: 08-Dec-2008 :O (oficjalnie EoL na stronce apache).
Wiadomo, uzywacie manipulacji bytecodu zeby cos wycisnac z tej biblioteki, tworzac wlasne wersje bez zadnego wsparcia (ale i tak 1.x juz umarlo, patrz wyzej) z wlasnymi bugami itp., pewnie dlatego ze o wiele trudniej jest wziac cos nowego i przekonac do tego wlodarzy niz powiedziec 'mamy to co znacie, plus pare malych zmian', a oni nie rozumieja co znaczy manipulacja bytecodu i zezwalaja.
W sumie ten post o struts powinien zamknac ten watek, jest to definitywna odpowiedz na zadane w nim pytanie ;d

Nie mowie ze to zle, nie mowie ze technologie bleeding ekhm cutting edge sa lepsze / stabilniejsze / fajniejsze (choc to ostatnie raczej na bank, pun intended), mowie tylko, ze w bankach same starocie, a o tym w tym temacie sie rozchodzi.

Z drugiej strony masz też skalę aplikacji w bankach. To przy czym pracuję - backoffice, to jakieś 3GB dokumentacji (UC, biznesowy model danych, wymagania) co przekłada się na około 2,5 mln linii kodu. Plus oczywiście narzędzia, dodatkowe biblioteki itp. I jet to tylko wycinek tego co ma klient (są jeszcze m.n. front+system transakcyjny, hurtownia danych, system rozliczeniowo-księgowy, system kartoteki klienta). To wszystko powstało gdzieś w okolicy 2002-2003 roku zatem idąc do banku należy być przygotowanym, że raczej Scali 2.10 i Vaadin 7.1 Beta na co dzień nie uświadczysz (choć też są w użyciu).

No wlasnie, i tak trzeba bylo od razu mowic a nie czarowac ze jednak w bankach cos nowego sie uzywa.
Zdaje sobie sprawe z rozmiaru takich projektow i ich skomplikowania, ale nie o tym sie rozchodzi w temacie. Dobrze tez ze zaznaczyles ile to ma dokumentacji - tez jest nieciekawie jak taki programista musi ja pisac. Np. w Niemczech mam kumpla ktory jak zatrudniony w firmie-podwykonawcy minsterstwa obrony, i tak to maja jazde. Wiekszosc czasu to wlasnie pisanie dokumentacji i jakies wykresy w jakims RUP studio czy czyms. W banku tez tak jest?

Programiści nie piszą aż tak dużo. Jak już to tylko stricte techniczną dokumentację opisującą działanie jakiś ekwilibrystycznych konstrukcji. Większość dokumentacji piszą analitycy.

Pozwolę sobie odgrzebać temat i zapytać - czy w bankach jest coś takiego jak "dyżur" w domu, 24h pod telefonem i w weekendy też ?

Bo z tego co słyszałem od postronnych osób to od banku trzeba trzymać się z daleka bo:
-niskie pensje
-dużo obowiązków
-dyżury
-kiepskie narzędzia (co zostało już w tym wątku potwierdzone).

Czy ktoś z praktyków mógłby pozostałe elementy potwierdzić (lub nie) ?

Tak, są dyżury. Obecnie raz w miesiący mam tygodniowy dyżur i jest to mordęga. Mogą do Ciebie dzwonić o 2 w nocy, bo jakiś nikomu niepotrzebny raport się nie wygenerował. Dostajesz za to kasę, a za interwencję w weekend masz dzień wolny, ale dyżury są beznadziejna i jak się ma pecha to ma się tydzień wyjęty z życiorysu.
Pensja słaba, narzędzia słaba, praca polega głównie na wsparciu, bo jest tyle źródeł problemów, że zawsze brakuje czasu na programowanie. Nie polecam, zmywam się niedługo.

Uważajcie na te dyżury. Byłem na jednej konferencji, gdzie wystawił się ING Services i pani przy stoisku powiedziała mi, że absolutnie programiści u nich nie mają żadnych dyżurów i że jest fajna atmosfera i przyjemnie się pracuje jada jada bla bla bla. Później ta sama firma w jednej auli prezentowała swoją ofertę i tam pani powiedziała, że cenią sobie w firmie równowagę pomiędzy pracą, a czasem wolnym, dlatego w zespole tylko jedna osoba zostaje na dyżurze, a inne mają spokój, zmiana co tydzień, ale zależy od projektu.

Na rozmowie kwalifikacyjnej też was mogą wprowadzić w błąd.

W takim razie jaki jest czynnik że bankom udaje się w ogóle zrekrutować programistów na dłużej niż pół roku/rok? Ktoś napisał kasa ale z wątku wynika że opinie są podzielone ;) Chyba że praca w banku to stabilny sposób na dotrwanie do emerytury (nie w każdym się wieku chce się człowiek bawić w "ciągły rozwój") ew. pierwsze doświadczenie dla świeżaków.

Gdyby te raporty były nikomu niepotrzebne to bank by nie płacił za dyżury i nadgodziny.

Wieloetapowe testowanie systemu przed wydaniem i narzędzia do ciągłego monitoringu produkcji pozwalają na wykrycie problemów zanim ktoś zacznie dzwonić.

loza_szydercow napisał(a):

W takim razie jaki jest czynnik że bankom udaje się w ogóle zrekrutować programistów na dłużej niż pół roku/rok? Ktoś napisał kasa ale z wątku wynika że opinie są podzielone ;) Chyba że praca w banku to stabilny sposób na dotrwanie do emerytury (nie w każdym się wieku chce się człowiek bawić w "ciągły rozwój") ew. pierwsze doświadczenie dla świeżaków.

Właśnie nie wiem co ludzi kusi do pracy w banku.
Być może tak jak powiedziałeś - są ludzie, którzy zatrzymali się w rozwoju na jakiejś technologii, są w niej dobrzy i akurat w konkretnym banku właśnie ta technologia jest używana i będzie używana jeszcze przez 10 lat.

A być może trafiają tam ludzie, którzy nie mogą znaleźć pracy gdzie indziej.

Co do świeżaków to odradzałbym pchanie się tam, bo co potem można wpisać w CV ?
Że się ostatni rok rozwijało program w c#2.0 lub Oraclu 6 ?

A jak wygląda kwestia wykształcenia? W ofertach pracy korpo/banków zawsze na pierwszym miejscu jest wykształcenie wyższe. Mam wrażenie, że panuje tam ocena zero-jedynkowa. Jak kandydat nie ukończył studiów to z nim nie gadają. Zauważyłem też zależność Javy z tym wymaganiem, w odróżnieniu od takiego Pythona, czy Rubiego.

Wibowit napisał(a):

Gdyby te raporty były nikomu niepotrzebne to bank by nie płacił za dyżury i nadgodziny.

Wieloetapowe testowanie systemu przed wydaniem i narzędzia do ciągłego monitoringu produkcji pozwalają na wykrycie problemów zanim ktoś zacznie dzwonić.

Właśnie dlatego ktoś dzwoni, że narzędzia do monitoringu coś wykryły.

Raporty zwykle się wywalają nie dlatego, że nikt ich nie przetestował, tylko dlatego, że np. temp w bazie się zapełnił z niewiadomego powodu, albo baza się wywaliła, albo switch padł, albo ram sypie błędami....

To dziwnie macie. U nas dzwonią dopiero jak jest konkretny problem, np:

• raporty miały być na konkretną godzinę, a nie doszły,
• ktoś chce ściągnąć raport, a system sypie mu błędami,
• system jest przeciążony i leży, ślimaczy albo wariuje - wtedy ludzie nie mogą normalnie używać strony i zgłaszają problem,

Mamy production support team, który nie jest super sprytny, ale wiele problemów rozwiązuje samodzielnie i nikt wtedy nie musi po nas dzwonić. Zajmują się głównie rzeczami niewymagającymi głębokiej znajomości systemu, a więc mogą zwiększyć ilość miejsca na dysku czy w bazie albo coś zrestartować czy ręcznie kopnąć jakąś akcję w naszym systemie.

Najbardziej upierdliwa sprawa to to, że nasz system jest pośrednikiem między wieloma innymi systemami, ale że to nasz system oferuje UI klientom to błąd widzą na stronie naszego systemu i to do nas zgłaszają problem. Pisząc systemy tego typu po prostu trzeba nastawić się na takie problemy (z komunikacją czy z poprawnością zewnętrznych systemów) i monitorować co się da, by wykryć problem zanim ktoś zacznie szukać swoich raportów.

Niestety, to sama prawda. Pracowałem w jednym banku we Wrocławiu. Rotacja programistów jest ogromna, a z relacji osób które tam do dziś pracują wynika, że obecnie ten bank ma poważne problemy ze znalezieniem kogokolwiek(sic!) do pracy. Zwyczajnie nikt nie chce tykać starych systemów, z ogromnym długiem technicznym, bez testów i dokumentacji. Nie muszę chyba dodawać, że przez to mało kto przejmuje się jakością wydawanego software'u - "po co, skoro za pół roku mnie tu już nie będzie?". Patchowanie na produkcji nie robi na nikim wrażenia. Dyżury zdarzały się jednak wyjątkowo rzadko. Nie polecam pracy w banku w IT, szkoda nerwów.

W moim rejonie od wielu miesięcy ogłaszają się 2 banki szukając developerów .net.
Ostatnio nawet pojawił się pośrednik, który od razu lojalnie uprzedza, że szuka pracowników do renomowanego banku.

Jako, że te banki pewnie nie mają nieograniczonych potrzeb w zakresie programistów, wnioskować należy, że po prostu nikt się nie zgłasza.

I jak widać słusznie.

Ex-bank-programmer napisał(a):

w jednym banku we Wrocławiu

O kaszanie w jednym takim słyszałem już pewnie z naście lat temu, jak się jeszcze inaczej nazywał.
Hmm, jest taki park w Warszawie... ;)

Czyli się nieźle zmieniło, jak pracowałem kiedyś przy systemach bankowych, to banki kupowały takowe od firm trzecich i to te firmy się martwiły. Programista był potrzebny do jakichs nietypowych sprawozdań, ale o te wymagane przepisami zazwyczaj martwiły sie firmy trzecie.

Między systemami banki czasami migrowały z róznych powodów... wtedy rzeczywiście okres gorący - przerzucanie danych, szkolenie personelu, testy w weekendy. oraz weekend na właściwą migracje i poźniej jeszcze pierwszy tydzień - praca pod nadzorem, bo w banku mogą mieć jeszcze problemy, ale w czasie normalnym, dyżury w informatycznym dziale potrzebne nie były (co innego koniec roku i okres zamykania roku, sprawozdania ect).

Każdy większy bank ma 200, 300 i więcej systemów i to już z definicji nie może być prosta praca, bo jak to zintegrować. Do tego coraz więcej pracy narzuca KNF, wchodzi CRS i FATCA ,są raporty do BIK itp.

Z plusów to u nas jest duża grupa ludzi która widziała już wszystko i potrafi ten chaos ogarnąć. Można się od takich osób uczyć, nawet jeśli ma się już doświadczenie. Ja sobię cenie, że spotkania i agile są zredukowane do absolutnego minimum, resztę czasu mam na programowanie, ogarnięcie produkcji i szkolenia. To co jest dla mnie jest wartościowe, to fakt, że zajmujemy się rzeczami na tu i teraz, nie mamy 200 zadań w backlogu na najbliższe 3 lata.
Niewiele firm ma takie strumienie danych z eventów i dane liczone w PB.

Z minusów to dokumentacja jest słaba, trzeba fizycznie szukać odpowiedzialnych osób.
Technologia nie ma znaczenia, bo jeśli projekt piszą zdalnie kontraktorzy, którzy nie mają dyżurów to żadna kafka,java8, andżular nie sprawi, że projekt się utrzyma na produkcjii. Znam dział który ma 6 facetów w wieku 50+ i obsługują łącznie ponad kilkadziesiąt aplikacji w starych technologiach. Im to nie przeszkadza, wszystko działa jak należy, a tak to napisali by nikt ich po nocach nie budził.