To jest 77. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o quant developerze. 

Partnerem odcinka jest firma Credit Suisse, która posiada w Polsce kilkudziesięcioosobowy zespół quantów i quant developerów. Jeśli zainteresuje Cię praca opisana w tym odcinku, skontaktuj się z jednym z gości za pośrednictwem sieci społecznościowych w celu uzyskania większej liczby szczegółów, opisu ról i możliwości aplikowania na nią. 

Przypominam, że w poprzednim odcinku rozmawiałem o trendach w cyberbezpieczeństwie. 

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/77. 

Jeśli jeszcze tego nie zrobiłeś, to wystaw ocenę lub recenzję podcastowi w aplikacji, w której tego słuchasz. Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty będę to robił z sukcesem.

Już dzisiaj możesz mnie wesprzeć w tej misji, zostając patronem na platformie Patronite. 

Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły! 

Jednocześnie bardzo dziękuję moim obecnym patronom.

Nazywam się Krzysztof Kempiński i życzę Ci miłego słuchania!

Odpalamy! 

 

Cześć, dzisiejszy odcinek będzie pod wieloma względami nieco wyjątkowy, ponieważ będę miał przyjemność rozmawiać aż z trzema gośćmi jednocześnie. 

A dzisiaj będą to Piotr Jarecki, programista F#, software development lead w Credit Suisse, zarządzający zespołem odpowiedzialnym za aplikacje frontendowe dla traderów. Jego hobby to gry planszowe i narciarstwo.

Paweł Kołtuniuk, programista z dziesięcioletnim doświadczeniem, lead software development engineer w Credit Suisse, zarządzający zespołami i projektujący wewnętrzne systemy dla banku. Wcześniej pracował w Microsoft, gdzie zajmował się tworzeniem frameworków testujących dla aplikacji webowych.

Andrzej Sokolicki, absolwent Elektroniki i Telekomunikacji, wcześniej pracował jako software testing engineer w Intelu i UTC, a także programista C++ w Nokii. Obecnie pracuje jako quantitative developer w Credit Suisse, w codziennej pracy łączy technologię zarządzania zespołem i styk z biznesem. W wolnym czasie uwielbia podróże, wspinaczkę oraz dobre filmy i jazdę na snowboardzie. 

Dzisiaj z tymi trzema panami porozmawiam sobie o temacie jak dla mnie totalnie nowym, z tym po raz pierwszy będę miał okazję się zetknąć, także traktuję też tę rozmowę jako formę nauczenia i dowiedzenia się czegoś nowego. Mianowicie będzie to temat quant developera. Witam was serdecznie w podcaście! Niezmiernie mi miło, że tak liczne grono będę tutaj gościł! 

Na początku zapytam was o to, o co zawsze pytam moich gości – czyli czy słuchacie podcastów, jeśli tak to, jakich najczęściej?

 

[Piotr] Cześć, Krzyśku! To może ja sobie pozwolę zacząć. Też bardzo mi miło trafić do ciebie. Jeżeli chodzi o pytanie, zdecydowanie podcasty to jest coś co lubię, coś, co słucham, jeżeli chodzi o naszą stronę, czyli software inżynierską, to słucham oczywiście ciebie, słucham też twojego konkurenta, czyli Maćka Aniserowicza z Devstyle’em oraz ostatnio taki nowy podcast, który powstał od strony ludzi z Bottega IT Better software design, który bardziej jest skonkretyzowanym na programowanie, a pisanie kodu na podstawie domain driven design i to, co oni promują. Jeżeli chodzi o poza to dość szeroko od bardziej politycznych, światowych, na przykład Dział Zagraniczny, Raport o stanie Świata, poprzez biznesowe jak na przykład Mała, wielka firma albo APP Jacka Santorskiego. 

I tak poza tym, to co ktoś poleci dobrego. 

 

[Andrzej] Cześć, Krzyśku! Mnie również bardzo miło być u ciebie. Ze swojej strony powiem szczerze, że głównie w związku z tym, że brakuje w polskich mediach informacji o tym, co się dzieje na świecie, to właśnie Dział Zagraniczny i Raport o stanie Świata to są takie dwa podcasty, na które poświęcam w każdym tygodniu jakiś czas, żeby odsłuchać. 

 

Super, dziękuję!

 

[Paweł] Cześć, z tej strony Paweł! Osobiście preferuję blogi i czytanie na temat większości nowych technologii lub tym, czym zajmuję się w pracy lub w domu. Ale zdarza mi się słuchać podcasty i to w większości dzięki mojemu managerowi, Michałowi Małeckiemu, którego teraz tutaj pozdrawiam. Michał bardzo namiętnie słucha podcastów i kiedykolwiek znajdzie coś ciekawego, to podsyła mi i w tym momencie mam okazję zapoznać się z bardzo ciekawymi tematami. 

 

Pewnie! Dobrze jest mieć takie źródło, bo faktycznie scena podcastowa rośnie i nie raz nie da się wyśledzić wszystkich nowości, które się pojawiają, także taki filtr, który nam wstępnie przeselkcjonuje te podcasty jest na wagę złota. Super. 

Dzięki wielkie za wasze rekomendacje. Myślę, że dla wielu słuchaczy to pojęcie quand developera jest czymś zupełnie nowym, z czym stykają się, z resztą podobnie jak ja, po raz pierwszy. Dlatego wyjdźmy może od jakiejś definicji – spytam was, kim jest taka osoba, czym się zajmuje na co dzień?

 

[Paweł] Jeżeli chodzi o quant developera, to tak naprawdę to jest spektrum osób, które się tym zajmują, gdzie z jednej strony moglibyśmy powiedzieć – osoby, które my wewnętrznie nazywamy quanci. To są z reguły matematycy, fizycy, którzy zajmują się modelowaniem instrumentów finansowych, też muszą potrafić programować i przenieść te modele na kod, aż po ludzi, którzy rozumieją jak działa bankowość inwestycyjna, w jaki sposób budowane są instrumenty, ale niekoniecznie rozumieją matematykę, która jest pod spodem i są bardziej skoncentrowani na technologii, której się używa do wyceny czy obliczenia w chmurze, w jaki sposób przedstawić użytkownikowi bardziej skomplikowane aspekty związane właśnie z handlem instrumentami finansowymi, aż po ludzi, którzy tak naprawdę zajmują się na przykład infrastrukturą. Oni też muszą mieć jakąś wiedzę domenową związaną z bankowością inwestycyjną, ale tutaj oni są bardzo mocno technologiczni, to jest dla nich najważniejsze – technologia, niż wiedza domenowa. W skrócie takim quant developerem to jest programista software engineer, który ma wiedzę domenową z zakresu bankowości inwestycyjnej, a rozległość tej wiedzy jest tak naprawdę różni się od tego, w którym miejscu banku jesteśmy. Czy jesteśmy tymi typowymi quantami, którzy tworzą modele czy jesteśmy bardziej programistami, którzy używają tych modeli i tworzą na przykład aplikacje webowe czy desktopowe dla końcowych użytkowników. 

 

Okej. W nazwie tego stanowiska jest developer, dlatego zastanawiam się, jakie są różnice czy też podobieństwa w stosunku do takiego standardowego software developera? 

 

[Paweł] Myślę, że tak jak przed chwilą powiedziałem. To jest software developer, tylko tak samo, jak masz back end developera, front end developera, który ma swoją specjalność w tym ogólnie pojętym software developement, to tak samo quant developer to jest programista, który w takim bardzo dużym uproszczeniu ma znajomość rynków finansowych. 

 

[Piotr] Pozwoliłbym sobie dodać do tego, co powiedział Paweł – dużym wyznacznikiem jest ta ilość wiedzy biznesowej, której quant developer musi posiadać. Tak jak sobie mówiliśmy tutaj o pewnym spektrum stanowisk, które byśmy nazywali quant developerem, to im bardziej się przybliżamy do tych konkretnych modeli finansowych, konkretnych wyliczeń, które się opierają o czystą matmę, czyste modelowanie zachowań rynków finansowych, tym więcej tej wiedzy biznesowej przychodzi i tym mniej można się oprzeć na takich czystych wymaganiach funkcjonalnych, które byśmy dostali czy jakieś VRD, tym więcej trzeba mieć pełne zrozumienie, żeby móc to zakodować, odpowiednio zaprogramować, zaimplementować. 

 

[Paweł] To jest troszeczkę jak w przypadku analityków biznesowych, którzy są między programistami a klientem końcowym – tutaj raczej to się troszeczkę spłaszcza, w sensie, że ty musisz być też analitykiem, żeby zrozumieć jak do danego problemu podejść. 

 

Dobrze, to porozmawiajmy chwilę o progu wejścia, bo tu faktycznie tak jak powiedzieliście, to jest połączenie trochę różnych kompetencji. Z jednej strony takiego klasycznego software engineera, z drugiej osoby, która potrafi posługiwać się takimi narzędziami, potrafi posługiwać się matematyką, tworzyć modele, wreszcie ma jakąś wiedzę domenową. Połączenie różnych pól, konieczność rozwijania się w tych licznych polach, dlatego zastanawiam się jak trudno jest się nauczyć tych kwestii quantowych, związanych bardziej ze specyfiką tej branży i czy ten próg wejścia leży wysoko czy bardzo wysoko? 

 

[Paweł] Myślę, że tutaj każdy z nas ma swoją historię, ponieważ żaden z nas nie jest z wykształcenia quant developerem, jeśli można tak powiedzieć, tylko przychodził do Credit Suisse jako programista, który musiał nauczyć się kwestii quantowych. Co jest warte zaznaczenia, jeżeli chodzi o zachód, kiedy przychodzi programista na stanowisko quant developera, naprawdę musi mieć bardzo mocną wiedzę finansową, ponieważ jest to coś, czego ludzie uczą się na uczelniach, na stażach. 

W Polsce jeszcze, chociaż powoli to się zmienia, nie mamy za bardzo ludzi, którzy są świeżo po uczelni albo z innych miejsc pracy, mają wiedzę quantową. Taka firma jak Credit Suisse otwarta jest na programistów, którzy są gotowi na to, żeby nauczyć się kwestii quantowych. U mnie wyglądało to tak: ja przyszedłem co Credit Suisse z Microsoftu, gdzie byłem programistą i nie do końca nawet wiedziałem jak te rynki finansowe działają poza takim zainteresowaniem jak wybuchł kryzys, co to jest akcja, opcja, ale niewiele więcej. Tutaj była bardzo duża pomoc, ponieważ najpierw miałem miesięczne szkolenie w Londynie, w którym ludzie uczyli mnie podstaw matematyki, gdzie tak naprawdę próg wejścia to jest matematyka, którą mamy w liceum, trochę na studiach. Po prostu nie można się bać takich podstaw. 

 

W Polsce jeszcze, chociaż powoli to się zmienia, nie mamy za bardzo ludzi, którzy są świeżo po uczelni albo z innych miejsc pracy, mają wiedzę quantową. Taka firma jak Credit Suisse otwarta jest na programistów, którzy są gotowi na to, żeby nauczyć się kwestii quantowych.

 

Reszty można się nauczyć. Ciężko jest to zrobić samemu, dużo łatwiej, jak ktoś ci to wytłumaczy no i mieliśmy takie szkolenia, z drugiej strony w trakcie pracy też mamy już w Polsce wielu ludzi, którzy są ekspertami w swoich dziedzinach. Nawet skomplikowane tematy, gdybym się miał tego nauczyć, powiedziałbym, że próg wejścia jest kosmiczny, ciężko. Ale kiedy masz osobę, do której możesz podejść, ma na to czas i jest w stanie ci to wytłumaczyć krok po kroku i często ukryć te szczegóły matematyczne, ponieważ sam jako programista, który ma użyć modelu niekoniecznie musi rozumieć, jak działa całka stochastyczna albo w ogóle jak ją obliczono, to zmniejsza ten próg wejścia. 

Dla kogoś, kto chciałby nauczyć się tego w domu wydaje mi się to bardzo duże, ale jeżeli ktoś nie boi się matematyki i chciałby jej używać w pracy, to jest do zrobienia. Kwestia chęci. 

 

[Andrzej] Jeżeli mógłbym coś dodać od siebie, to właśnie – jak powiedziałeś na wstępie. Też nie wyszedłem z żadnego backgroundu finansowego, bankowego albo innego, ekonomicznego, tak byśmy to nazwali. Tak jak Pawła, zawsze mnie interesowały te kwestie, dlaczego wybuchł kryzys w 2008, 2009, dlaczego upadło Lehman Brothers i tak dalej, i tym podobne, ale nie miałem mocnego backgroundu. I to, co ja zauważyłem, to jeżeli chodzi o uczenie się samodzielnie kwestii quantowych, czyli po prostu tłumacząc jak działają rynki finansowe, na czym polegają dane instrumenty finansowe, dlaczego one są w pewien sposób unikalne, czy one się między sobą różnią, to na rynku ogólnie jest bardzo dużo darmowych lub płatnych, ale pomocy bardzo podstawowych. Na przykład investopedia, która ci potrafi powiedzieć bardzo dużo o tym właśnie czym jest obligacja, czym jest akcja, jaka jest różnica pomiędzy akcją i obligacją. 

Jest też bardzo dużo materiałów zaawansowanych, które wchodzą w szczegóły jak dany instrument finansowy wygląda, jak on się zachowuje, jak on jest handlowany na rynkach światowych i tak dalej, i tym podobne. Ale to są bardzo eksperckie materiały. A brakuje tej części pośredniej. Czyli czegoś, co by pozwoliło przeskoczyć od tej wiedzy takiej bardzo podstawowej, takiej – był taki film, Big Short, który właśnie podstawową pokazywał, jak to wygląda, ale żeby przejść do bardziej zaawansowanych kwestii. I tutaj jak Paweł powiedział, mi się też wydaje, że bez wsparcia ludzi, którzy już się na tym, znają, którzy już pracują w banku byłoby ciężko się samemu tego nauczyć. Szczególnie tutaj ja jestem ciekawym przykładem, ponieważ przychodząc do Credit Suisse przyszedłem do tych zespołów bardzo mało quantowych, które zajmowały się wsparciem infrastruktury, zbudowaniem continuous integration, odpowiednich tuli testowych i tak dalej, i tym podobne, a potem przeskoczyłem do zespołu, który jest już bardzo quantowy i de facto chyba z naszej trójki ja jestem najbliższej tych modeli finansowych i dopiero jak weszła taka mocna pomoc ludzi z wiedzą ekspercką, czy to od nas z polskiego oddziału Credit Suisse wrocławskiego czy może z zagranicy, z londyńskiego oddziału, nowojorskiego, z Zurychu, to dopiero pozwoliło mi tak w pełni zrozumieć i w pełni być w stanie zaimplementować ze wszystkimi szczegółami te modele, które są w mojej odpowiedzialności, żeby je dostarczyć. 

Ponownie powiem, że naszym niesamowitym, cennym assetem jest to, że mamy tych ludzi, których możemy się zapytać i fajne jest to, że chyba – myślę, że mogę to powiedzieć – w całym banku jest taka atmosfera, że nie ma głupich pytań, zawsze można się zapytać, zawsze można poprosić o wytłumaczenie i jest na to pełna otwartość wszystkich. 

 

[Piotr] To jest też trochę tak jak w firmach informatycznych często jest jakiś tam mind board, gdzie dyskutuje się jakąś architekturę czy graf, jak użytkownik będzie używał jakiejś aplikacji no to tutaj często się widzi, jak siedzi informatyk z matematykiem i rozmawiają o co chodzi w tej transformacji macierzy czy jak tutaj będą wypłacone kupony dla jakiegoś instrumentu finansowego no i tak naprawdę no to na tym chyba wszyscy bazujemy. 

Też studiowałem automatykę i robotykę, więc na starcie może miałem trochę łatwiej z matematyką w porównaniu do innych, ale też pamiętam, że jak musiałem coś zmienić w modelu i z macierzą korelacji, to nie spodziewałem się, że będzie tak na starcie z dość wysokiego C, natomiast to to też oczywiście jest wiedza, którą się zdobywa przez lata. Jak ktoś idzie do Nokii no to też pewnie musi się bardzo dużo wiedzy wewnętrznej nauczyć czy w jakiejś innej branży. 

 

[Paweł] Pozwolę sobie jeszcze na koniec oddać, że bardzo ważna jest chęć, żeby się tego nauczyć. Trzeba się przygotować na to, że jeżeli chcę pracować w quantach, muszę chcieć się tego nauczyć, a dzięki pomocy ludzi, których mamy już na pokładzie, będzie to możliwe. 

 

Wiele razy tutaj padły różne zagadnienia związane z matematyką: macierze i tak dalej. Zastanawiam się, na ile znajomość matematyki jest kluczowa w tym co robicie na co dzień i czy podczas rozmowy kwalifikacyjnej trzeba rozwiązać równanie różniczkowe czy też może wychodzi to później, że te kompetencje poszerzacie w trakcie pracy, natomiast niekoniecznie trzeba być na wejściu super matematykiem?

 

[Paweł] Jeżeli chodzi o rozwiązanie równania różniczkowego, jeżeli ktoś idzie typowo na rolę quantową, to będzie musiał to rozwiązać, ale myślę, że raczej Piotr zaczynając jako quant musiał coś takiego robić, ale ja na przykład nie musiałem rozwiązywać żadnych zadań matematycznych na rozmowie. To, co w moim zespole jest oczekiwane, to że ktoś nie będzie się bał. Jeżeli powiem mu, że musisz napisać funkcję, która przybliża pochodną, to nawet nie musi znać tych metod. Po prostu będzie umieć porozmawiać z tym matematykiem, który mu to wyjaśni, w jaki sposób to ma być zakodowane i tak jak mówiłem wcześniej. Wydaje mi się, że ta wiedza to jest takie naprawdę liceum i podstawy ze studiów. To jest wystarczające, żeby zrozumieć, ale daje to też trochę satysfakcji. Bo większość ludzi miała te różne rodzaje matematyki na studiach i zastanawiałem się, po co mi to jest. Osobiście, kiedy nagle się okazuje, że cała ta analiza numeryczna, odejmowanie bliskich liczb albo błędy numeryczne, po co ja się tego uczyłem i okazuje się, że mogę to zastosować w praktyce i zdarzyło mi się raz, że nawet wyciągnąłem skrypt ze studiów, żeby sobie zrozumieć jakiś problem, dzięki temu mogłem rozwiązać coś w pracy, to dało mi dużo satysfakcji. Szczerze muszę się przyznać, że czeka, aż będę mógł zastosować mnoży skróconego mnożenia. 

 

Może kiedyś nadejdzie ten piękny dzień. 

 

[Paweł] Kiedyś nadejdzie. Ale nawet w pracy bardzo quantowej jeszcze mi się to nie zdarzyło. 

 

[Andrzej] Z mojej strony, z tego, co robimy, dodam taki mały szczegół, że bardziej niż typowa analiza matematyczna albo algebra to po naszej stronie ważne jest zrozumienie probabilistyki i statystyki. I ponownie, jak mówiliśmy przedtem. To nie jest tak, że my od razu na wejściu będziemy męczyć ludzi z rozkładów prawdopodobieństwa albo dystrybuanty i czym ona się różni od gęstości, ale jeżeli te modele, zwłaszcza takie duże, portfelowe, które biorą wszystkie trade’y, które bank zrobił i wyciągają z nich jakieś statystyczne wartości typu, chociażby wartość średnia oczekiwana strat lub zysków i trzeba, chociażby dostarczyć parametrów do tych modeli, no to warto jest to rozumieć jak te parametry wiążą się z teorią statystyki, żeby prawidłowo to zakodować. Ponownie wracamy do tego, że im więcej mamy wiedzy domenowej, tym lepiej jesteśmy w stanie to zaimplementować. Ponownie do tego wrócę, żeby nie przestraszyć naszych słuchaczy – to nie jest tak, że to jest must have na wejściu. To jest coś, na co trzeba się mentalnie przygotować, znaczy być może trzeba będzie wejść w temat. 

 

bardziej niż typowa analiza matematyczna albo algebra to po naszej stronie ważne jest zrozumienie probabilistyki i statystyki.  

 

To, co Andrzej powiedziałeś, że coraz bardziej cenieni są programiści z wiedzą domenową dodatkowo, to myślę, że jest trendem, który też coraz bardziej obserwuję. Inny taki trend, który już dosyć mocno się zakorzenił, to jest przesuwanie rozumienia IT nie jako kosztu, ale trzonu całego biznesu. 

W Credit Suisse – to nie jest firma, która pozycjonuje się jako firma technologiczna jako taka. Pomimo swojego zaawansowania technologicznego. Zastanawiam się, jak wam się pracuje w takiej firmie, wam jako programistom, w firmie, która zajmuje się domenowo czymś innym – nie opiera wszystkiego na technologii. 

 

[Piotr] Credit Suisse składa się z kilku dywizji, części. Ciężko wrzucić 50 000 osób na całym świecie pod ten sam mianownik. W tej części bankowości inwestycyjnej, no to my jesteśmy zaraz za traderami czy osobami, które bezpośrednio zajmują się kupnem, sprzedażą instrumentów finansowych, tworzeniem portfela dla banku i strategii inwestycyjnej, no to quanci, quant deweloperzy razem z nimi są pierwszą linią frontu. Oni rozumieją, że bez tych modeli matematycznych i całej otoczki IT, która idzie razem z nią – bank inwestycyjny nie jest w stanie funkcjonować w żadnym stopniu. 

Bankowość inwestycyjna jest dużo bardziej technologiczna niż bankowość prywatna czy bankowość komercyjna, którą również Credit Suisse oferuje. Tutaj jest dużo mniej kontaktu z klientem, a dużo więcej na technologię i na poprawną wycenę instrumentów, bo tutaj są ogromne transakcje między firmami, gdzie koszt złych obliczeń jest wielokrotnie większy niż w innych częściach. 

 

[Paweł] Myślę, że tutaj, jeżeli chodzi o to, że firma się nie pozycjonuje jako technologiczna, to ma takie swoje plusy i minusy. Jeżeli jest firma technologiczna, tak naprawdę byś oczekiwał, że jest jakaś konkretna metodologia czy na przykład scrum. Od samej góry do samego dołu. 

U nas z tego względu, że na pewnym poziomie są ludzie, którzy nie są technologiczni, są bardzo mocno biznesowi, później są też ludzie, którzy mają mocną wiedzę technologiczną. Mamy naprawdę dużą dowolność, jeżeli chodzi o proces wytwarzania oprogramowania. Czyli mamy zespoły, które pracują w scrumie, w kanbanie, inne decydują się na jakieś inne modele pracy, co na przykład dla mnie jest super. Dla moich zespołów mogę wybrać to, co jest najlepsze, ale też ma to swoje minusy, bo jednak spójność, kiedy wszystkie zespoły pracują w dokładnie tej samej metodologii, jak to się dzieje z reguły w firmach technologicznych, ułatwia coraz wyższemu managementowi zarządzanie projektami. 

Powtórzę się, że jako dla mnie, że zarządzam zespołem jest bardzo fajne to, że mogę sobie dowolnie wybierać, przez to, że to nie jest firma technologiczna, to nikt by nam nie narzucił metodologii programowania, ale z drugiej strony boli mnie, to kiedy współpracuję z wieloma, innymi zespołami, że jest trochę tego tarcia, żeby dopracować pracę, kiedy każdy pracuje w innej metodologii, ma inne release cycle, używa innych narzędzi do zarządzania projektem. 

 

[Andrzej] Powiedziałbym tutaj o takich dwóch przykładach, które by wynikały z tego, co Paweł powiedział. Na przykład, jeżeli ja współpracuję z moim managerem, który jest bardziej matematykiem, fizykiem, który też jest programistą i ja mogę z nim porozmawiać o pointerach w C++, to jednak do takich rzeczy, które są powszechnie przyjęte w świecie software developmentu, ja nie mogę do niego podejść, że on to naturalnie wie. Jeśli na przykład rozmawiamy o tym, że dostarczamy pewną funkcjonalność, to tutaj akurat to jest ciekawe, że ja muszę się bardzo trzymać mocno scrumowego podejścia, że jak dostarczamy, to dostarczamy w wersji gold, a nie takie, że dostarczamy cokolwiek, a potem to zrefaktorujemy jak już dostaniemy błogosławieństwo, bo mój manager sam z siebie nie rozumie, dlaczego my mamy zmieniać coś, co już działa. Przecież dostarczyliśmy, działa? No to idziemy dalej z funkcjonalnościami. To jest taka pierwsza rzecz. 

Z drugiej strony mój manager absolutnie nie ma problemu, że ja zarezerwuję ten czas, żebyśmy dostarczyli w wersji gold. Trzeba się troszkę samemu pilnować, żeby nie pójść czasem na łatwiznę, tylko wykonać tę robotę dobrze od A do Z. A druga rzecz, którą zauważyłem, to jest to, że – trochę pochodna tego, co powiedziałem – że pewne rzeczy musimy dużo mocniej uzasadnić. Na przykład, jeżeli chcemy przejść z .Neta w wersji 4.6 do .Net core’a, to my naprawdę musimy pokazać, gdzie jest ta wartość biznesowa, jak to będzie wyglądało w ilości błędów, które się zmniejszą dzięki temu. Jak będzie to dużo bardziej skalowalne, dużo prostsze do obsługi i jak to koniec końców przełoży się na naszą wyższą produktywność, niż to byłoby naturalne w firmach technologicznych, gdzie każdy praktycznie do samego CEO wie, że takie rzeczy trzeba zrobić. 

 

Kontynuując ten temat chciałem też zapytać o wpływ na wybór technologii. Do banku czy w ogólności jakiejś instytucji powiedzmy finansowych taka trochę przylgnęła łatka, że korzystając z przestarzałych technologii rzadko próbują takich nowinek czy też wszystko musi być bardzo mocno uzasadnione i zabezpieczone od tron technologicznych, żeby takich zmian czy takich właśnie prób dokonać. Chciałem się zapytać, czy to jest prawda – czy z waszej pracy też wynika raczej przeświadczenie, że stare, ale sprawdzone technologie i raczej nie tykamy czegoś, co jeszcze jest bardzo świeże? Czy też może jest to po prostu mit, który możecie od razu obalić?

 

[Piotr] Jestem na co dzień programistą F#, który nie jest – co prawda już jest teraz ugruntowany, ale jeszcze jak zaczynałem parę lat temu, no to był to powiedzmy język, który dopiero się tworzył. Jeszcze mieliśmy kod w wersji 1.9, jak jeszcze był w wersji beta i nawet z Microsoftu trzeba było ściągać developerów, żeby tutaj pomogli w tych pierwszych latach pracy. Akurat tutaj mogę się posłużyć przykładem, że nie do końca. Też eksperymentujemy z F Starem, w którym robiliśmy ostatnio pull requesta do kompilatora tego języka, więc to nie jest do końca prawda. Na pewno czasem jest problem domeny. Jeżeli Credit Suisse podpisuje z kimś kontrakt na 20 lat, to my jako Credit Suisse musimy przez 20 lat być w stanie taki instrument finansowy wyceniać. Policzyć jego ryzyka, być w stanie klientowi powiedzieć, dlaczego te kupony będą wypłacone w taki, a nie inny sposób. To nie jest taki zawsze green field development, że teraz od początku zaczynamy z nowym projektem i zapominamy o tym, co było, więc jednak trzeba mieć zawsze z tyłu głowy, że to musi działać. Na tyle jest to główny asset banku, że za 10 lat będzie działać bez problemu. 

Natomiast akurat wydaje mi się, że quanci w takiej części bankowości, są troszeczkę takim działem R&D, w sensie, że tutaj są tworzone nowe modele, których później reszta używa. Tutaj są rozwiązywane najtrudniejsze problemy biznesowe, które też często wymagają nowego podejścia. Wydaje mi się, że oczywiście jest tutaj zawsze taki trade off, ale nie czuje się tak, że jesteśmy w jakichś bardzo starych technologiach. 

 

Natomiast akurat wydaje mi się, że quanci w takiej części bankowości, są troszeczkę takim działem R&D, w sensie, że tutaj są tworzone nowe modele, których później reszta używa. Tutaj są rozwiązywane najtrudniejsze problemy biznesowe, które też często wymagają nowego podejścia.

 

[Andrzej] Pozwolę sobie skomentować do tego co Piotr powiedział o tym, że mamy instrumenty dwudziestoletnie albo trzydziestoletnie, też jak najbardziej. Ostatnio jak grzebałem po danych do mojego modelu to zauważyłem, że mamy referencje do jeszcze Wschodnich Niemiec I Czechosłowacji. Najprawdopodobniej chodzi o to, że wtedy obligacje były też wydawane i wtedy też trzeba było je obsłużyć. 

Nie mniej to nie jest tak, że ten kod został napisany w ’89 i teraz musimy utrzymywać jakiegoś starego Haskella, nie. My to ciągle update’ujemy, ciągle release’ujemy, ciągle podwyższamy nasze frameworki. Te modele wyceny są też przepisywane. Kiedyś praktycznie wszystko było w C++.

 

[Piotr] W Excelu jeszcze było! 

 

[Andrzej] Nawet w Excelu! 

 

[Piotr] A w polskich bankach dalej Excel jest królem. 

 

[Andrzej] A teraz my głównie stoimy na .Necie. Pozwolę sobie jeszcze tak hasłowo rzucić, żeby nikt nie myślał, że my tu jesteśmy starzy Excelowcy i Haskellowcy, bo jeżeli przyjdzie się do nas, mikroserwisy są. Sam jestem w trakcie migracji na GIT. To nie jest tak, że mamy stare repozytorium, jeszcze clear case’a IBM-a sprzed lat. 

Mamy właśnie też – może nie jesteśmy totalnie bleeding edge, ale z wersjami .Neta ciągle migrujemy, tak samo z wersjami C++. To jest. To nie jest tak, że ktoś przyjdzie do nas to utknie w najstarszych technologiach, ale też jedno, co trzeba pamiętać, że bank musi bazować na sprawdzonych technologiach, bo to jest bezpieczeństwo finansowe. 

 

Okej. To teraz chwilkę może w innym kierunku pytanie – w kierunku kompetencji, które są potrzebne w ogólnie rozumianym quant developmencie. W waszym przypadku to jest taka rola łącząca wiedzę techniczną, domenową, biznesową i jeszcze związaną z zarządzaniem ludźmi. Jak wygląda przykładowa ścieżka quant developera? W jaki sposób on może swoją karierę rozwijać? 

 

[Piotr] Na pewno są dwie podstawowe ścieżki, też jak w firmach technologicznych, czyli jedna to jest bardziej taki people manager, project manager, czyli zarządza się grupą programistów, albo jakimś projektem. Bardziej migruje się w stronę bardziej taką miękką, gdzie te kompetencje miękkie są kluczowe natomiast druga część jest taka bardziej jak osoba, która ma taką specjalność technologiczną, jakby jego głównym narzędziem jest to, że jest bardzo dobry technologicznie. 

Natomiast to, co jest pewnie szczególnie w tej ścieżce takiej technologicznej, ta działka quantowa jest na tyle duża, zbudowana, że można przez kilkanaście, czy dwadzieścia-parę lat tę wiedzę quantową poszerzać i budować na tym całą swoją karierę. 

 

[Paweł] Tak samo, jeśli chodzi o wiedzę technologiczną, czyli jakby tak obrazowo opisać – nie skupiajmy się na tej managerskiej, tylko bardziej, co jest warte podkreślenia – jest wielu ludzi na bardzo wysokich stanowiskach w Credit Suisse, którzy nie są managerami. Są osobami, które są techniczne i są doceniane w firmie. To nie jest regułą w wielu firmach technologicznych. Czyli nie ma konieczności stania się managerem, aby coraz wyżej wspiąć się na ścieżce kariery. Zaczyna się od osoby, która przychodzi i jest świeżo po studiach albo gdzieś już pracowała, zaczyna zdobywać te umiejętności quantowe, wiedzę techniczną. Często ludzie w tym momencie, czasami niektórzy – mamy kilka przypadków, że osoby bardziej się kierowały – pomimopomimo że przyszły jako programiści, to tak im się spodobała ta kwestia modelowania, że bardziej szły w stronę modelowania, a osoby, które przyszły jako ludzie, którzy modelują, ale te kwestie technologiczne tego, w jaki sposób masz zrównoleglić kilkadziesiąt tysięcy godzin obliczeń tak, żeby one się wykonały w ciągu jednego dnia. W jaki sposób zarządzać taką dużą ilością kodu szły bardziej w stronę technologiczną i można powiedzieć, że na początku jesteś soft engineerem, później zdobywasz coraz więcej wiedzy quantowej, ważna jest też ta miękka umiejętność rozmowy z klientem. 

Dużo naszej pracy to albo ja rozmawiam z quantem, albo rozmawiam z tym maklerem, traderem, albo z kimś, kto potrzebuje jakiś raport i muszę mieć umiejętność tego, żeby dowiedzieć się, jaki jest problem tego kogoś i jak ja go mogę rozwiązać albo pisząc kog, albo dając już to, co było napisane. Im wyżej jest się w hierarchii, tym bardziej trzeba umieć rozmawiać z klientem.

Nasz idealny pracownik to taki, który będzie umieć pójść, zdiagnozować problem, zaproponować rozwiązanie albo samemu zaimplementować. Często ne jest możliwe, żeby jedna osoba zaimplementowała albo zaproponować jak cały zespół jest w stanie to rozwiązać. 

Dojście do tego momentu to są lata. Tak bym w skrócie opisał ścieżkę kariery, jeżeli chodzi o quant developera. Od programisty czy matematyka do osoby, która ogarnia naprawdę duży aspekt biznesowej części, jest w stanie nie tylko to zrozumieć, ale także w razie potrzeby zakodować. 

 

[Andrzej] Z kolei bym trochę rozwinął to co Paweł powiedział. Dodał tę kwestię zrozumienia banku. Ponieważ zróbmy takie dwa kroki w tył. Credit Suisse to jest jeden z czołowych banków inwestycyjnych na świecie, będących w pierwszej dziesiątce. To się tam trochę zmienia, ale jak powiemy pierwsza dziesiątka to jak najbardziej. On działa na wszystkich rynkach finansowych na świecie, od Azji przez Europę, skończywszy na USA czy Brazylii. To jest dla bardzo różnych regulatorów, czyli nadzorów finansowych i to może być właśnie chiński nadzór finansowy, japoński – bo też mamy działy w Tokio. Europejski, też z Europy wychodzi Wielka Brytania, wiec też brytyjski, który zawsze był w pewien sposób niezależny, teraz będzie jeszcze bardziej niezależny. 

Wszystkie praktycznie instrumenty finansowe też podchodzą w ten trading. I teraz mnogość tego wymusza, że mamy też mnogość systemów, które zostały stworzone, żeby to ogarnąć, żeby utrzymać, żeby wycenić i żeby dać możliwość też wyliczenia ryzyka z tym związanego. 

Dochodzi do tego ten moment, o którym mówiliśmy wcześniej. Takiego business analityka, który musi rozumieć nie tylko ten kawałek kodu, który pisze, ale jak on się wkomponuje w ten cały ekosystem systemów do przetrzymywania trade’ów, do wyceny trade’ów, do wyliczenia ryzyka związanego z danym tradem i tak dalej, i tym podobne. Dla mnie, personalnie, to jest naprawdę bardzo satysfakcjonująca rzecz, że ja potrafię w głowie poukładać sobie klocki tych systemów. Jak jedne na siebie wpływa, jak ten trade, który jest zrobiony przez maklera w Nowym Jorku jest zapisany u nas w systemie, jak on jest potem wyceniany. Jak ryzyko z nim związane jest wyliczane, jak on jest potem zaciągany do mojego modelu, który jest następnie przedstawiany do zarządu banku, żeby pokazać, jakie jest takie całościowe ryzyko. Jeżeli ktoś lubi takie naprawdę wyzwania technologiczne względem działania całego systemu, uważam, że my jako bank jesteśmy jedną z czołowych firm, które mogą dać takie wyzwania właśnie programistom, ludziom technicznym. 

 

Z tego, co mówicie wynika, że to jest taka specjalizacja mimo wszystko rzadka. Wymaga różnych umiejętności, rozwoju kariery, nierzadko latami. 

Chciałem was zapytać, jak wygląda wobec tego rynek pracy i zapotrzebowanie tego typu specjalistów w Polsce czy też na świecie. 

 

[Andrzej] Jeśli chodzi o świat, to wydaje mi się, że to jest bardzo duże. Ciekawa rzecz, którą obserwowaliśmy, że często ludzie przychodzili do Credit Suisse biorąc pod uwagę to, że nie mamy takiego wysokiego progu wejścia, z myślą o tym, że nauczą się kwestii quantowych tutaj, w Polsce, a później ruszą w świat, gdzie często zarobki są duże. Okazuje się, że rzadko to się zdarza. Jak ktoś już w to wsiąknie, tak mu się u nas podoba, że dosłownie jest jeden albo dwa przypadki, gdzie znam dużo więcej osób, które mówiły tak, że to był początkowy cel. Przyjdę, nauczę się – w Polsce to coraz bardziej rośnie. W skali, koledzy może bardziej znają rynek, mogą powiedzieć jak to jest rozpowszechnione. 

 

[Piotr] Cały rynek tego quant developmentu głównie jest związany z Center of Excellence, które się pojawiły w Polsce 10 lat temu i tak naprawdę no to on rośnie razem z tym rynkiem, bo bardzo dużo banków przeniosło ze względu na gigantyczne koszty zarówno powierzchni biurowej, jak i wypłat w Londynie czy w Zurychu, Nowym jorku. Starają się to więc gdzieś przenosić. W Polsce Credit Suisse był jednym z pierwszych, przyszedł też BNY Mellon, przyszedł EBS, Goldman Sachs, Standard Chartered z takich ciekawszych firm też w Warszawie otworzył biuro. 

Oczywiście, to nie jest tak, że wszystkie pozycje to są pozycje quantowe w Center of Excellence, ale dużo takich działów też jest przenoszonych tutaj do Polski. Ten rynek się jeszcze tworzy i jeszcze jest na fali wznoszącej w Polsce. 

 

[Paweł] Dodam tutaj taką kwestię, że zostając quant developerem to nie znaczy, że już nie możesz zostać żadnym innym developerem. To nie zamyka drogi. 

Tak jak mówimy – ten rynek quant developmentu w Polsce jeszcze się rozwija, ale tą wiedzą, którą tutaj mamy, z wiedzą czysto programistyczną albo wiedza technologiczną, tak jak właśnie gdzieś wchodzimy w chmurę, albo wchodzimy w te mikro serwisy, spokojnie można potem pójść w inne kierunki. Ten quant development daje możliwość wejścia w jeszcze nowy kierunek, który się bardzo mocno rozwija i pracowania w tych instytucjach finansowych. I do tego, co powiedział Paweł, to właśnie na świecie ten quant developer, jeżeli już ma tę wiedzę finansową na wysokim poziomie, jest traktowany troszkę jak taka elita programistów i w Londynie zostać quant developerem to jest bardzo często – może nie to, że zwieńczenie kariery, ale naprawdę istotny krok i duże osiągnięcie. 

 

Bardzo fajnie zachęcacie developerów czy osoby myślące o tego typu karierze, to może, żeby jeszcze trochę podsycić ten płomień, to powiedzcie, z jakim wynagrodzeniem można się liczyć na takich stanowiskach. 

 

[Paweł] Gdyby tutaj nas widzieli słuchacze, to każdy z nas się uśmiecha, ponieważ jest to pytanie, na które z wielu względów nie możemy wprost odpowiedzieć. To, co możemy powiedzieć, że Credit Suisse stara się bardzo uczciwie podchodzić, jeżeli chodzi o wynagradzanie pracowników i rzadko się zdarza, żeby ktoś zmieniał pracę, opuszczał nasze szeregi ze względu na wynagrodzenie. 

 

[Andrzej] Mogę sobie pozwolić, może jeszcze trochę ten rąbek tajemnicy uchylę – z naszych obserwacji wynika, że my raczej płacimy troszkę wyżej niż średnia rynkowa. Nie możemy podać tutaj konkretnych liczb, ale myślę, że można powiedzieć, że będąc tutaj jest się zadowolonym i z takiej corocznej rundy podwyżkowej zdecydowanie jest się zadowolonym. Pamiętam to z moich poprzednich firm – no to tutaj to zdecydowanie lepiej wyglądało. 

 

Bardzo dyplomatyczne odpowiedzi, dzięki za nie. Teraz może wróćmy do tego, jak wy jako quant developerzy współpracujecie z takimi, nazwałbym to typowymi działami IT? Powiedzieliśmy o różnicach, podobieństwach – jak to się wpasowuje w kooperację z programistami, którzy nie mają takiej wiedzy domenowej albo na przykład z jakąś częścią infrastruktury albo innymi elementami całościowego działu IT?

 

[Andrzej] Myślę, że z tego, co sobie powiedzieliśmy wcześniej, to najbardziej przybija ta wiedza biznesowa. Z mojego punktu widzenia bym powiedział, że to jest taki wyznacznik. Zauważyłem, że przykładowo, jak ostatnio rozmawiałem o problemie z performance’em, czyli wyliczenie pewnych wymogów kapitałowych liczyło się u nas z 20 minut, co było za dużo na to, co się spodziewaliśmy i rozmawiałem właśnie z takim typowym działem IT, który dostarcza nam platformę obliczeniową, na której my mamy zaimplementować nasz model, to rozmowa potoczyła się w kierunku business case’u, gdzie ja mówiłem biznesowym troszkę językiem, co my liczymy, w jakiej skali i dlaczego uważamy, że te 0 minut to jest za dużo, a w pewnym momencie członek działu IT powiedział, stop Andrzej, hola, hola! Nie rozumiem, co ty mówisz. Spróbujmy pomówić językiem kodu. I tak mogliśmy rozwiązać ten problem, ale było coś takiego, że musimy mieć w tyle głowy, że działy IT nie quantowe mają troszkę mniej tej wiedzy biznesowej i to my musimy dostosować ten poziom, żebyśmy się rozumieli. 

 

Dobrze. Wiadomo, musicie się rozwijać tak jak pewnie każdy pracujący w IT na takim stanowisku. 

Wobec tego zapytam was: skąd czerpiecie wiedzę, w jaki sposób rozwijacie swoje umiejętności, żeby pozostać na bieżąco z jednej strony z rozwojem technologii, a z drugiej strony z rozwojem tej dziedziny, w której pracujecie? 

 

[Paweł] Takim kluczowym źródłem nowej wiedzy w takim formacie są inni ludzie. Na przykład w zespole bardzo się cieszę, kiedy jesteśmy w stanie zatrudnić kogoś – taką świeżą krew. Nowe pomysły, nowe podejścia. Wiadomo, osobiście zdarza mi się jeździć na konferencje, czytam blogi, słucham podcastów, jeżeli ktoś mi podeśle, ale nic nie zastąpi tego, kiedy masz możliwość spotkania z osobą, która była w stanie w rzeczywistym projekcie wykorzystać jakąś technologię. 

Na papierze, w materiałach marketingowych wszystko wygląda świetnie, a dopiero kiedy ktoś jest w stanie ci pokazać: „Patrz, to dzięki temu jesteś tak banalnie prosto rozwiązać taki problem” albo „To wygląda fajnie, ale może nie idź w tym kierunku, bo spróbowaliśmy tego i okazało się, że jest tyle problemów. Z punktu widzenia technologicznego to staramy się na innych ludziach i też na przykład ja osobiście bardzo dużo czasu w pracy poświęcam na tworzenie takich proof of concept. Zanim my zaproponujemy konkretnie biznesowi powiedzmy: „Przejdźmy na .Net core’a”, to spróbujmy jakiś mały fragment przekonwertować, który uważamy, że zyskamy. Na przykład jakieś manipulacje na stringach, gdzie zyskamy na ilości pamięci dzięki rzeczom, które są w .Net Corze i to jest w trakcie pracy uczymy się nowych technologii, eksperymentujemy, idziemy dalej. Jeżeli chodzi o te kwestie typowe quantowe, to już musieliby odpowiadać quanci w jakiś sposób. Oni też są na bieżąco z nowinkami matematycznymi, ponieważ w tej kwestii jestem tą osobą, która ma to rozumieć, a nie wymyślać nowe sposoby modelowania. 

 

[Andrzej] To ja będąc najbliżej chyba tej części typowo quantowej, typowo modelarskiej, to powiem, że te kwestie finansowe na tym podstawowym poziomie można się dużo dowiedzieć z tego podstawowego Internetu, tak to nazwijmy. Stron takich jak Investopedia, przechodząc po YouTube jest coś takiego, co się nazywa Khan Academy, gdzie bardzo ładnie są wytłumaczone dosyć skomplikowane zagadnienia, ale w sposób prosty i zrozumiały nawet dla ludzi, którzy nie mają dużej wiedzy biznesowej i finansowej. 

Ponownie, jak dochodzimy do momentu, w którym musimy wejść troszkę głębiej, to musimy oprzeć się na ludziach, którzy pracują i to jest główne źródło wiedzy quantowej, a potem ewentualnie pogłębić to książkami. Tu dochodzą albo jakieś klasyczne tytuły, które bardzo często po prostu ci quanci, nasi modelarze są w stanie nam polecić albo też trzeba troszkę samemu poszperać. Powiem taką ciekawą historyjkę, że jak ja przechodziłem z tego działu bardziej quantowego technologicznego do quantowego modelarskiego, to jako prezent pożegnalny od kolegów, też od Pawła i Piotra dostałem Quantitative analysis for dummies. I zaczytywałem się w domu, żeby zrozumieć, co ja naprawdę teraz będę robił. Troszkę wracamy do takiego podstawowego, tradycyjnego, że trzeba jak najwięcej samemu się rozwijać i czytać albo poszukać na Internecie. 

 

[Piotr] Staramy się też co jakiś czas, przed pandemią przede wszystkim, każdego miesiąca mieliśmy też wizyty ludzi z Londynu, z Nowego Jorku, takich już bardzo doświadczonych ekspertów w danych dziedzinach i też każdy z nich miał jakąś prezentację. Z takich przykładów to dotąd jest bardzo głośny temat, że odchodzimy od stopy wyboru i innych stopów opartych na właśnie uzgodnieniach na pożyczkach międzybankowych. Też mieliśmy z tego szkolenia, żeby zrozumieć – to będzie prawdopodobnie najgłośniejszy temat bankowości przez najbliższy rok albo dwa. 

 

To jeszcze teraz takie bardzo mięsiste pytanie. Jakie narzędzia, języki programowania wykorzystujecie w codziennej pracy?

 

[Piotr] 90% kodów tworzę w F#, to jest taka funkcyjna wersja C#. To jest o tyle ciekawe, że Credit Suisse jest największym pracodawcą w Polsce, który używa tego języka. Natomiast też C#, C++, z takiej DevOpsowej no to TeamCity, JIRA. 

 

[Paweł] Sam z kolei siedzę większość czasu w czystym C#, ale też mamy dostęp do kodu F#, co prawda innego niż Piotr i też troszkę tam piszemy. Teraz z kolei dochodzimy do takiej fazy testowania modelu gdzie myślimy, żeby zastosować Pythona i tak poza tym prototyp naszego modelu został napisany w R, w tym dobrym dla celów statystyki, gdzie bardziej musimy go zrozumieć, niż napisać, co nie jest trudne, bo to jest bardzo czytelny język. Natomiast różnica pomiędzy mną a tym, co robi Piotr jest taka, że mój zespół w minimalnym stopniu zajmuje się kwestiami DevOpsowymi i tu nastąpiło takie rozdzielenie, gdzie my mamy skupić się na stworzeniu modelu a wszystko wokół, DevOpsowe, czyli właśnie konfiguracja TeamCity, które jest i które działa w cyklu continuous integration albo jakie biblioteki użyć, albo wersja frameworku, to wszystko jest na dziale bardziej IT, mniej quantowych. 

 

[Andrzej] Jeżeli chodzi o mnie, to trochę wygląda to inaczej. My tworzymy bardzo duży framework używany w banku i mamy bardzo duży wpływ na to, jaka to technologia będzie użyta. Co bardzo ciekawe – historycznie mieliśmy dwa frameworki, które robią praktycznie to samo. Jeden napisany w F#, drugi w C#. Jest to niezwykle ciekawe, bo teraz pracuję nad tymi dwoma projektami, widzieć jak te same rzeczy są zaprogramowane w języku funkcyjnym i obiektowym. 

To jest bardzo szeroki temat, ale naprawdę to nie jest takie czarne i białe, że jedno jest lepsze lub gorsze, tylko czasami widać, że niektóre rzeczy dużo lepiej wyglądają, są zakodowane i tworzą się nawet w języku funkcyjnym. W innych miejscach okazuje się, że jednak języki obiektowe też mają swoją siłę. Jeżeli chodzi o technologię Visual studio to jest nasze ID do programowania. Wiadomo, continuous integration to jest coś, co musi być i w tym wypadku używamy TeamCity. Inna, ciekawa rzecz jest na przykład nawiązując do pytania, jeśli chodzi o stare technologie – ponieważ my jako bank uruchamialiśmy obliczenia w chmurze, kiedy rzeczy typu Azure, Amazon Web Services dopiero raczkowały no i z tego powodu dalej mamy tę chmurę zbudowaną wewnątrz banku, ale też potrafimy dokładnie te same obliczenia i to jest jeden z projektów, nad którymi pracuję. Też potrafię uruchamiać na komercyjnej chmurze. 

Zapomniałem o Pythonie, który jest uwielbiany przez matematyków, więc bardzo dużo wysiłku wkładamy w to, żeby te wszystkie narzędzia .Netowe, C#, żeby dało się z nich korzystać w Pythonie. 

 

No to bardzo szeroki przekrój technologii, muszę przyznać. To na koniec jeszcze co do przyszłości pytanie – czy według was ta dziedzina będzie się rozwijać? Jeśli tak, to w jakich kierunkach? I komu moglibyście polecić wybór właśnie takiej ścieżki kariery?

 

[Andrzej] Na pewno się będzie rozwijać, nie ma wątpliwości. Cała ta działalność bankowa, banków inwestycyjnych musi się opierać o technologie, to co mówiliśmy wcześniej. Powstają kolejne startupy, tzw. też hedge fund’y, które jeszcze bardziej, dużo mocniej opierają się o technologie, niż my to robimy. Przykładowo, bardzo często ten quant developer od razu jest też typowym modelerem quantem, ale i nawet traderem w jednej osobie. Jest to więc jakiś trend, który idzie. Mamy też silną komórkę tzw. algo tradingu, czyli właśnie trading w oparciu o parametry algorytmów, a nie maklera, który wykonuje transakcje kupno-sprzedaży. Jest ten tzw. high frequency trading, czyli podejście, kiedy trading jest znowu oparty o algorytmy, które są zaprogramowane tak, żeby bardzo często wykonywały transakcje, które dają minimalny zysk, ale jeżeli założymy, że w sekundzie jesteśmy w stanie wykonać tysiąc razy taką transakcję, to ten zysk już odpowiednio rośnie. 

Spektrum rozwoju całej branży jest ogromny. Pamiętam, był nawet jeden wykład Bjarne Stroustrup’a u nas w Credit Suisse, który mówił, że naszą konkurencją za 10 lat nie bedą inne banki, tylko będzie uber finansowy z Doliny Krzemowej, który jeszcze bardziej postawi na technologie, postawi na sztuczną inteligencję. Myślę, że z tej ścieżki nie ma odwrotu. Komu polecić taką ścieżkę kariery? 

Powiem troszkę bardziej o moim zespole, Piotr i Paweł powiedzą o swojej stornie. Na pewno ludziom, którzy są ciekawi świata finansowego, którzy chcą wejść, zrozumieć, na czym to polega, na czym polegają instrumenty finansowe, jaka jest różnica pomiędzy opcją, akcją, obligacją a na przykład future’em czy forwardem, którzy nie chcą się zamknąć w programistyczny archetyp, że z jednej strony dostajemy FRT BRD oraz pizzę, a z drugiej strony wypluwamy kod, tylko chcą całościowo szukać rozwiązań, które będą optymalne zarówno dla danego modelu, jak i dla całego banku. Tutaj bym też zwrócił uwagę, że dla ludzi, którzy nie są tacy usztywnieni, którzy chcą podchodzić racjonalnie, że mamy pewne wzorce, są optymalne, podejście architektoniczne, ale też metodologii pracy czy to też właśnie scrum czy kanban czy jakiś inny agile, ale pozwolą sobie być racjonalni, używać tego, co się sprawdza, to co jest dobre, a nie to, co jest napisane w książce. Też ze względu na to, że my pracujemy w takim otoczeniu biznesowym i nie, to co mówiliśmy sobie wcześniej, stricte technologicznym. Trzeba się w pewien sposób dostosować, co jak mówiliśmy ma swoje plusy i minusy, jak to w życiu bywa. 

Na pewno też dla ludzi, którzy chcą pracować z innymi i dostarczać takie pełne, przemyślane rozwiązania pod wieloma aspektami. Zarówno biznesowym, technologicznym, jak i też systemowym. Tak bym t określił. 

 

[Paweł] Chciałem powiedzieć, że dla kogo to jest – kogo szukamy? Szukamy podobnych ludzi jak największe firmy technologiczne. Po pierwsze, szukamy ludzi, którzy są – jeżeli jesteś lub czujesz, że chcesz być mocnym programista, po drugie chcesz się uczyć. W naszym przypadku to jest wiedza quantowa, w innych dużych firmach też jest coś, czego trzeba się nauczyć. U nas jest ta chęć wiedzy quantowej i na pewno nie możesz bać się matematyki, ponieważ jeżeli przeraża cię matematyka – co wydaje się zaskakujące, że zostałeś programistą – ale jeżeli już zostałeś, to może być ciężko. Chęć tego, żeby rozwiązywać problemy dotyczące oprogramowania. To nie jest – na Credit Suisse zasadnicza praca quanta, to nie jest miejsce, w którym ktoś stworzy Jira i dokładnie opisze co ma być zrobione, a ty tylko napiszesz rozwiązania. Ty mas zaproponować rozwiązania. Musisz rozmawiać z ludźmi. 

To nie znaczy wcale, że to jest praca tylko dla ekstrawertyków. Mamy wielu introwertyków. Chodzi o to, że trzeba być osobą, która jest gotowa pójść i zrozumieć dogłębnie problem i go rozwiązać a nie oczekiwać, że dostanie tylko jasne instrukcje jak napisać kod. Są takie miejsca i ludzie, którzy to lubią i niestety albo na szczęście, bo dzięki temu, że nikt mi nie mówi, co robić po kroku, ja mogę sam kreatywnie zaproponować i to jest dla mnie ogromną zaletą. Wymaga też dużo więcej wysiłku niż po prostu napisanie na podstawie jasnej specyfikacji co ma być zrobione, stworzenie samemu specyfikacji, przekonanie innych do tego i zaprogramowanie. 

Może nie tak krótko, ale jeżeli ktoś widzi siebie w tym, co ja opisałem, to właśnie dla takiej osoby praca quant developera byłby dobrym miejscem. 

 

[Andrzej] Mi się tu ciśnie na usta taki buzzword, że trzeba być proaktywnym. Otwartym i proaktywnym. 

 

trzeba być proaktywnym. Otwartym i proaktywnym.

 

[Piotr] Jeżeli chodzi o przyszłość branży, no to wydaje mi się, że branża miała taki problem na starcie, że firmy nie otwierały działów quantowych, bo nie było quantów a quant developerów nie było, bo nie było też pracy dla nich. To jest o tyle fajne, że widać kilka tych pierwszych banków weszło zatrudniło quant developerów, są już na rynku i oczywiście szczególnie w Warszawie to widać, że tych firm jest już na tyle dużo, że każda kolejna firma wchodzi, już ma jakiś procent ludzi na rynku, których może ściągnąć z innych firm, więc to się bardzo fajnie w tej chwili rozwija. 

 

Nie chce też dublować dla kogo, tylko dodam, że na pewno, jeśli ktoś lubi języki funkcyjne, to ich jest zdecydowanie więcej w bankowości niż w każdej innej dziedzinie takiego software developmentu, więc tutaj jest na pewno dużo więcej pracy, którą można znaleźć. Czy w F#, czy w Scali, w zależności od banku. 

 

Okej! Piotr, Paweł, Andrzej, bardzo wam dziękuję za ciekawą rozmowę, z przybliżenie stanowiska jak quant developer. Za też skuteczne zareklamowanie, bo naprawdę przebijało przez was zadowolenie z tego co robicie, taka pasja i spełnienie. Myślę, że jak gdyby fajnie jest pracować w takim miejscu, gdzie można się i rozwijać i realizować coś, co przynosi komuś jakąś wymierną korzyść. Także z mojej strony wielkie dzięki za poświęcony czas i rozmowę i powiedzcie proszę, gdzie was można znaleźć w Internecie, gdyby ktoś miał może jakieś pytania co do waszej pracy?

 

[Andrzej] Myślę, że można zaprosić naszych słuchaczy na standardowe portale społecznościowe, jak najbardziej na LinkedIna, gdzie można mnie znaleźć po prostu pod Andrzej Sokolnicki – Credit Suisse. 

 

[Paweł] Uważam, że akurat, jeżeli chodzi o portale społecznościowe i tematy związane z profesjonalną pracą LinkedIn jest bardzo dobrym miejscem kontaktu. Zawsze można śledzić oficjalną stronę Credit Suisse, ale wiadomo, tam jest tysiące ofert na tysiąc stanowisk, więc jeżeli ktoś byłby bardziej zainteresowany taką pracą quantów, to kontakt bezpośrednio na LinkedInie jest jak najbardziej na miejscu. 

 

Świetnie. Dobrze, to oczywiście podlinkuję namiary na was w notatce do tego odcinka. Z mojej strony jeszcze raz wielkie dzięki no i do usłyszenia, cześć! 

 

[Andrzej] Dzięki bardzo! 

 

[Piotr] Dziękujemy!

 

[Paweł] Cześć, cześć! 

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Mam nadzieję, że teraz wiesz już kim jest i jaką rolę sprawuje quant developer. 

Jeśli doceniasz to co robię, wesprzyj mnie na Patronite. To taka platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 złotych miesięcznie. 

Mój profil znajdziesz pod adresem porozmawiajmyoit.pl/wspieram 

Link również w notatce do tego odcinka. 

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. 

Jeśli spodobał Ci się ten odcinek i nie chcesz przegapić kolejnych epizodów podcastu, zasubskrybuj go w swojej aplikacji podcastowej. Jeśli nie wiesz jak to zrobić, wejdź na stronę porozmawiajmyoit.pl/subskrybuj.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o quant developerze. 

Zapraszam do kolejnego odcinka już za tydzień! 

Cześć!