W firmie produktowej mamy realny wpływ na produkt, nie tylko na jego kod i design

Jeśli zależy Wam na tym, żeby mieć realny wpływ na rozwój i kształt projektów, które realizujecie, warto wybrać firmę produktową. Od pracy w software house różni się m.in. mniejszą dynamiką projektów, dzięki czemu jest czas na dopracowanie szczegółów. Nie ma tutaj pośredników, wszyscy mają wspólną wizję i robią wszystko, by ją rozwijać. Takie podejście daje dużo większą satysfakcję z pracy.

Jak znaleźliście się w Infermedica?

Przemysław Spaczek (PS): Trafiłem tu dzięki marketingowi szeptanemu. W 2020 roku byłem mentorem na wrocławskiej edycji warsztatów Vue Vixens, tam poznałem m.in. Arka, który wtedy już pracował w firmie. Jak wiadomo, w przerwach od kodowania rozmawia się o różnych rzeczach – tu temat zszedł właśnie na Infermedicę. Zaciekawiło mnie, że głównym frameworkiem, z którego korzysta się w Infermedice jest Vue, a nie React, jak w większości firm. Ziarenko zostało zasiane i wykiełkowało w maju tego samego roku, kiedy to zacząłem rozglądać się za nową pracą. W przeciwieństwie do Arka nie miałem okazji zdawać testu w formie papierowej :). Cała rekrutacja ograniczyła się do rozmowy na Google Meets, gdzie rozmawiałem z Pawłem, naszym CTO i Tomkiem, który podpytywał mnie o aspekty techniczne. Rozmowa chyba była udana, bo od ponad roku mam przyjemność pracować w Infermedice.

Arkadiusz Szydełko (AS): W 2012 roku, gdy byłem jeszcze na studiach, po odbyciu miesięcznych praktyk w innej firmie zacząłem szukać pierwszej pracy w zawodzie. Trafiłem na ofertę pracy zbieżną technologicznie z tym, co wtedy najlepiej znałem, czyli Python i Django. Przyszedłem na rekrutację, zdałem test z Pythona w formie papierowej, pochwaliłem się stroną, którą w tamtym czasie zrobiłem dla znajomych i udało się – dostałem tę pracę. Oczywiście to tylko stare wspomnienia jeszcze z czasów, kiedy firma liczyła trzy osoby, dziś to już ponad 130, a system rekrutacji jest bardziej złożony i unowocześniony.

Jakie znaczenie miało dla Was to, że Infermedica to firma produktowa?

PS: Jeśli chodzi o wybór między software house a firmą produktową, zawsze podświadomie wybierałem to drugie. To, że praca w firmie produktowej jest dla mnie ważna, zauważyłem dopiero niedawno. Zawsze patrzyłem na to przez pryzmat wartości, jakie niesie za sobą praca w danej firmie. Dla mnie ogromną zaletą firmy produktowej jest to, że mam realny wpływ na produkt, który trafi do użytkownika. Nie tylko na jego kod i design, ale też na funkcjonalności czy chociażby wartości, jakie sprzedaje.

Oferty pracy z

Jakie wartości daje praca w tego typu firmie?

PS: Zależy mi na tym, żeby mieć realny wpływ na rozwój i kształt projektów, które realizuję – zarówno w kwestiach technicznych, jaki i funkcjonalnych. Chcę pracować dla firmy, która tworzy przestrzeń na tematy często pomijane przez innych. Mam tu na myśli dostępność (ang. accessibility), testy jednostkowe i dokumentację. Mam wrażenie, że te wartości po prostu łatwiej połączyć z firmą produktową.

AS: Jedną z najczęściej podkreślanych wartości jest chęć bycia częścią zespołu, który w pełni poświęca się budowaniu swoich rozwiązań. Nie ma tutaj pośredników, wszyscy mamy wspólną wizję i robimy wszystko, co w naszej mocy, by ją rozwijać. Takie podejście daje dużo większą satysfakcję z wykonywanej pracy. Kolejną rzeczą, tak jak wspomniał Przemek, jest chęć posiadania wpływu na rozwój realizowanych projektów. W naszej firmie każdy może zabrać głos w dowolnej sprawie i zaproponować nowe rozwiązania czy kierunki rozwoju.

Inną wartością jest kwestia wczesnego rozwoju. Wielokrotnie słyszałem o różnicach w doświadczeniu, jakie można zdobyć w korporacji a szybko rozwijającej się firmie. W korporacjach dostaje się bardziej sprecyzowane zadania, jest też wiele osób, które powiedzą nam, jak je wykonać, co daje nadzorowany rozwój. Natomiast trafiając do małej firmy produktowej, do wielu rzeczy trzeba dojść samemu, co daje zupełnie inną perspektywę rozwoju. Często się to wiąże z potrzebą szybkiego zdobycia bardziej holistycznej wiedzy, co w przyszłości owocuje szerokim wachlarzem umiejętności.

Czym różni się praca w software house od pracy w firmie produktowej?

PS: Dynamiką projektów, to na pewno. W software house pełnimy rolę wykonawczą, realizujemy wizję klienta. Co przez to rozumiem? Mamy wpływ na to, jak zaprogramujemy dane rozwiązanie, ale rzadko możemy coś wnieść od siebie do produktu. Dodatkowo ogranicza nas budżet – zarówno w postaci “dolarów”, jak i czasu, chociaż to się ze sobą łączy. Te ograniczenia często sprawiają, że skupiamy się na tym, żeby dowozić projekty, przez co nie mamy pola do nauki nowych rzeczy, korzystamy ze sprawdzonego stacku technologicznego. Dodatkowo, rekrutując się do software house, nie możemy stwierdzić w 100%, jakie dokładnie projekty będziemy realizować.

W firmie produktowej sprawa wygląda inaczej. Dynamika projektów jest mniejsza, przez co możemy dopracowywać szczegóły. Rekrutując się wiemy, jaki produkt będziemy rozwijać i możemy określić, czy jest to dla nas interesująca praca, czy nie. W firmie produktowej jest też chwila na to, żeby wprowadzić nowe rzeczy do stacku technologicznego, zacząć pisać testy jednostkowe czy dokumentację. Od osób pracujących w software housach często słyszę, że chcieliby pisać testy, ale nie mają na to czasu.

Jedni twierdzą, że lepiej zdobyć doświadczenie w pracy nad dziesięcioma małymi projektami niż nad jednym dużym. Jakie jest Wasze zdanie?

PS: To zależy, jakiego typu “małe projekty” realizujemy. Załóżmy, że nie są to “te same projekty”. Mam na myśli takie, w których mamy okazję pracować w różnym stacku technologicznym, z różnymi ludźmi i pisać różne funkcjonalności. W takim przypadku zgodzę się z tym, że to dobry sposób na zdobycie doświadczenia. Jest jednak jedno “ale”.

Moim zdaniem ten sposób zdobywania doświadczenia sprawdzi się dla Juniora i Mida, w przypadku Seniora skłaniałbym się bardziej w stronę pracy nad jednym dużym projektem. Dlaczego?

Praca nad różnymi projektami pomaga nam poznać różne technologie, narzędzia, wzorce projektowe. Napotykamy na nowe problemy, uczymy się je rozwiązywać i zdobywamy doświadczenie. Wadą jest to, że często nie znamy długofalowych skutków naszych decyzji projektowych. Praca nad jednym projektem pozwala nam je przewidzieć. Uważam, że w rozwoju Seniora bardzo ważny jest ten tak zwany big picture, a nie tylko tu i teraz.

A co z rozwojem Juniora i Mida w dużym projekcie? Moim zdaniem tego typu projekty też ewoluują, widzę to po naszym produkcie Symptom Checker, gdzie po pierwsze, backlog jest jeszcze pełen front-endowych tasków, a po drugie, weryfikujemy funkcjonalność tego, co już zostało wdrożone. Mamy na to przestrzeń, dlatego że jest to nasz produkt i to my jako Infermedica decydujemy o jego funkcjonalności.

Jakich technologii używacie do rozwoju waszych produktów?

PS: Nasze fronty piszemy w Vue.js. Nowe produkty powstają już w oparciu o trzecią wersję tego frameworka. W przeciwieństwie do software house’ów możemy sobie pozwolić na to, żeby realizować projekty przy użyciu jednego frameworka. Plusem takiego rozwiązania jest to, że w obrębie jednego frameworku można łatwiej sobie pomagać z rozwiązywaniem problemów oraz dzielić się sprawdzonymi wzorcami projektowymi.

Ponieważ nasze produkty podchodzą pod kategorię “medyczne” i posiadają odpowiednią certyfikację ISO, to my jako programiści jesteśmy zobowiązani do wytwarzania oprogramowania wysokiej jakości. Pomagają nam w tym testy jednostkowe w Jest i wykorzystanie TypeScripta w naszych projektach.

Staramy się też być na bieżąco z “nowoczesnym stackiem technologicznym”. W jednym z projektów korzystamy z maszyn stanowych w postaci XState, a w rozwoju naszego firmowego UiKita pomaga nam Storybook, którego jestem wielkim fanem!

AS: Od strony backendowej firma skupiona jest głównie na Pythonie – w przypadku aplikacji webowych z wykorzystaniem Django czy nowo trenujących rozwiązań, jak FastAPI. Python jest też ważną częścią działu R&D, gdzie zespoły data science pracują nad usprawnieniem algorytmów medycznych rekomendacji oraz nowymi rozwiązaniami z zakresu AI. Idąc jeszcze dalej w backendowe strony, to wszystkie nasze aplikacje są “dokeryzowane“. Następnie zespół DevOpsów, wykorzystując Google Cloud Platform dba o wysoką dostępność naszych serwisów. Do sprawnego zarządzania infrastrukturą wykorzystujemy Terraform oraz Helm, gdyż większość naszych wdrożeń znajduje swoje miejsce w klastrach Kubernetesowych.

Jak wygląda organizacja pracy zespołów deweloperskich w Infermedica?

PS: Zespoły produktowe w Infermedica to tak zwane zespoły cross-funkcjonalne. W skład każdego z nich wchodzą: tester manualny, designer, developer front-end, back-end lub full-stack oraz product manager. Taki zespół jest w sumie samowystarczalny. Bardzo dużą zaletą takiego rozwiązania jest stały kontekst. Razem rozwijamy jeden produkt, więc mamy pełny obraz tego, co się dzieje w projekcie. Mam tu na myśli chociażby wiedzę na temat decyzji dotyczących architektury lub działania konkretnej funkcjonalności. Osobiście cenię sobie także aspekt wymiany doświadczeń pomiędzy różnymi funkcjami w zespole, np. front-end developer i designer bardzo dużo mogą się od siebie nawzajem nauczyć.

Jaki jeden największy milestone stoi przed wami w tym roku? (podzielcie się wizją, strategią, zachęćcie kandydatów do stania się częścią tego wyzwania)

AS: Ciężko wybrać jeden milestone, natomiast z technicznej perspektywy myślę, że będzie to nowa jakość naszych aplikacji Symptom Checker’owych. Jesteśmy w trakcie przepisywania jednej z naszych głównych aplikacji klienckich na nową technologię – Vue 3, o którym wspominał Przemek. Jednocześnie tworzymy też nową aplikację skierowaną na to, by pomóc lekarzom w obsłudze pacjenta przed, po oraz w trakcie wizyty. Głównym celem jest dostarczenie informacji o pacjencie lekarzowi, przeprowadzając wstępny wywiad jeszcze przed wizytą. A także ułatwić obsługę samej wizyty poprzez redukcję czasu niezbędnego na sporządzanie notatki. W zamian lekarz może go przeznaczyć na bardziej wartościową interakcję z pacjentem.

Nowe odsłony aplikacji tworzone są z najwyższą starannością i sztuką deweloperską, duży nacisk kładziemy także na dostępność (czyli tzw. accessibility). Tak, aby każdy, niezależnie od swoich dysfunkcji, mógł w komfortowy sposób korzystać z naszych aplikacji.

Jak określilibyście Idealnego kandydata dla Infermedica? Co jest dla Was najważniejsze?

PS: Gdy prowadzę rozmowy techniczne, zwracam uwagę na dwie rzeczy.

Po pierwsze: poziom wiedzy osoby, z którą rozmawiam. Na przykład od Seniora oczekuję wymiany zdań na różne tematy techniczne, a nie cytowania dokumentacji czy odpowiadania na pytania, jak działa asynchroniczność w JavaScripcie. Staram się podrzucać różne problemy i przyglądać temu, jak kandydatka czy kandydat przedstawiają swoje rozwiązania. To bardzo dużo mówi o przyszłej koleżance/koledze z zespołu.

Po drugie: jasna ścieżka rozwoju. Swego czasu było takie powiedzenie: “Nie ma dnia bez nowego frameworku JavaScript”. Bardzo je lubię, bo pokazuje, jak świat IT szybko się rozwija. Kandydaci, którzy nadążają z rozwojem branży są na wagę złota. I nie mówię tu o tym, że trzeba być Seniorem w każdej nowej technologii. Czasami wystarczy wiedzieć, że coś takiego istnieje i do czego służy.

AS: Ja natomiast bardzo cenię sobie ludzi, dla których wykonywana praca jest także pasją. Sam mam wrażenie, że taki jestem. Tego typu osoby bardzo szybko się rozwijają, gdyż mają naturalną skłonność do wzbogacania swojej wiedzy. A to bardzo często jest powiązane z imponującymi wynikami, jeżeli chodzi o realizowane zadania. Do tego przyjemnie się z nimi pracuje, bo zależy im na wspólnym budowaniu czegoś ciekawego. Zyskują na tym i oni, bo dostają nowe wyzwania, i firma, której zależy na nieustannym rozwoju produktów.

Jeżeli chodzi o bardziej konkretne cechy to są dwie, na które najczęściej zwracam uwagę: spójność oraz dokładność wykonywanych zadań. Ta pierwsza w moim doświadczeniu przewija się od wielu lat i moim zdaniem jest bardzo istotna w wieloletniej perspektywie rozwoju projektu. Technologie czy podejścia często się zmieniają – w przypadku dużych projektów, gdyby tak każdy nowy moduł pisać w inny sposób lub z użyciem innych technologii, to po paru latach dotrzemy do poważnych problemów z jego utrzymaniem. Warto zachowywać spójność projektową, to znacznie ułatwia zarządzanie i rozwój aplikacji w przyszłości. Od razu też dodam, że ta spójność nie oznacza zamknięcia się na nowe rozwiązania, wręcz przeciwnie. Nowe rozwiązania czy technologie warto na bieżąco wdrażać, ale cały czas pamiętając o spójności: tworzyć funkcjonalności według najnowszych i najlepszych standardów, a starsze moduły migrować i utrzymywać w tym samym stylu.

Druga cecha, czyli dokładność rozwiązań również jest czymś, na co sam naturalnie zwracam uwagę w pracy. Jestem perfekcjonistą i często wynajduję coraz to nowe sposoby, żeby coś zrobić lepiej. Uważam, że w przypadku pracy w IT jest to istotna umiejętność. Metod na rozwiązanie zadań programistycznych jest wiele, ale rozwiązując te zadania, warto się przyłożyć do każdego elementu. Czyli: przeanalizowanie przypadku, dobór rozwiązania, odpowiednia implementacja, aby kod był jakościowy, a jednocześnie optymalny, super, jeżeli do tego wszystkiego będzie generyczny z dużym potencjałem re-użycia itd. Składowych w nawet najdrobniejszych zadaniach jest wiele, każda jest istotna i warta dokładnego wykonania. Taki całokształt później owocuje wysokim poziomem implementacji projektu.

Przemysław Spaczek. Senior Frontend Developer w Infermedica. W firmie pracuje przy produkcie Symptom Checker, gdzie wraz z zespołem przeprowadził zmianę stacku technologicznego z Angulara 1 na Vue 3. Poza pracą przy Symptom Checkerze odpowiada za wdrożenie i rozwój wewnętrznego UiKita wraz z dokumentacją w Storybooku. Po godzinach dzieli się swoją wiedzą na JSowych meetupach, parzy kawy speciality (szczególnie upodobał sobie ziarna z Kenii) i głaszcze pieski.

Arkadiusz Szydełko. Architekt w Infermedica, przez niektórych nazywany firmowym dinozaurem, zatrudnił się w 2012 roku i od tego czasu rozwija produkty firmy. Ma bardzo szeroko pojęte zainteresowania Full Stack’owe od CSS, przez JavaScript, Pythona, aż po Infrastrukturę i DevOpsy. Obecnie jest w dwóch zespołach. Pierwszym jest zespół infrastrukturalny, gdzie od wielu lat zajmuje się rozwojem i utrzymaniem serwerów, a w ostatnich latach także migracją do Google Cloud Platform. Drugi to zespół produktowy wewnętrznego narzędzia MetaBase, które odpowiada za gromadzenie wiedzy medycznej, na bazie której działa silnik AI, będący sercem produktów Infermedica. W MetaBase ciągle rozwija swoje umiejętności Pythona i Django, które towarzyszą my od początku kariery, w połączeniu z nowoczesnym frontend’em w Vue.js. Po pracy lubi poszerzać swoją wiedzę dziedzinową, jak i aktywnie spędzać czas — np. słuchając technologicznych podcastów, nabijając kolejne biegowe kilometry w parkach.

Zdjęcie główne pochodzi z unsplash.com.