Tylko ambitne projekty nas rozwijają. Historia SoftwareMill

W tej firmie nie ma juniorów ani PM-ów. Czy praca w tak specyficznym zespole jest efektywna i daje satysfakcję? Jak przekonują nasi rozmówcy, tak właśnie jest. Ambitne projekty, ciekawe wyzwania i ciągłe podnoszenie poprzeczki — te trzy hasła często pojawiają się w naszej rozmowie z Krzysztofem Ciesielskim i Andrzejem Ludwikowskim, deweloperami z SoftwareMill. Zapytaliśmy ich m.in. o to, czym jest dla nich rozwój.

Krzysztof Ciesielski. Software Engineer w SoftwareMill. Pasjonat programowania od wczesnych lat szkolnych. Entuzjasta ekosystemu JVM i budowania systemów rozproszonych. Aktywny twórca różnych bibliotek open source. W SoftwareMill odpowiedzialny też za ScalaTimes, newsletter w którym znajdziesz najciekawsze treści scalowe z całego świata. Miłośnik wspinaczki skałkowej i boulderingu, oprócz tego zawsze chętnie przeczyta kolejną nieprzeciętną powieść science-fiction.

Andrzej Ludwikowski. Software Journeyman w SoftwareMill. Software Journeyman z ponad 9 letnim doświadczeniem w tworzeniu komercyjnego oprogramowania. Wyznawca DDD, ES i Polyglot Persistence. Cały czas poszukujący tej idealnej (nierealnej) architektury kodu, która spełni wszystkie, najdziwniejsze trendy. Pasjonata mierzenia wydajności w systemach rozproszonych. Oprócz programowania fascynuje go poznawanie działania mózgu oraz mindfulness.

Jak wyglądała historia powstania SoftwareMill?

Krzysztof: SoftwareMill powstał w 2009 roku i wywodzi się z warszawskiej społeczności programistów Java, jednak szybko, dzięki pracy zdalnej, otworzył się na współpracę z programistami z całej Polski. Początki związane są z pracą nad własnym produktem dofinansowanym ze środków Unii Europejskiej.

Rozumiem, że produkt został porzucony po powstaniu SoftwareMill?

K: Kiedy dołączyłem do zespołu, to jeszcze w minimalnym stopniu pracowano nad aplikacją do zarządzania obiegiem dokumentów w firmie. Ten produkt był wdrożony u kilku klientów, ale też długo używaliśmy go wewnętrznie. Później zamieniliśmy go na inne rozwiązanie. Rozwijaliśmy kolejno jeszcze jeden produkt — aplikację do robienia code review — Codebrag.

W większości skupialiście się na pracy dla klientów. Jak ich znajdowaliście?

K: To zaangażowanie ludzi w projekty open source, częste techniczne publikacje na blogu firmowym i wystąpienia na meetupach przykuły uwagę klientów z RPA i Australii — współpraca z nimi była bardzo udana, co wzmocniło ukierunkowanie firmy na eksport usług IT. Później, wraz ze wzrostem, pojawiły się wyzwania organizacyjne.

O jakich wyzwaniach mowa?

K: Zaczęliśmy mocno zastanawiać się w jaki sposób przeskalować firmę, gdy założyciele dalej chcą kodować, brać aktywny udział w projektach dla klientów i dzielić się na meetupach zdobytą wiedzą. Zależało im na tym, nie chcieli utknąć w roli szefów, którzy nie robią już niczego technicznego, bo zajmują się zarządzaniem. Rozwiązaniem okazało się uwolnienie inicjatywy oddolnej, wprowadzenie całkowitej transparentności w SoftwareMill. Od 2013 roku działamy więc jako firma z oddolną inicjatywą, zarządzana w stu procentach transparentnie, zarówno pod względem operacyjnym, jak i finansowym.

Sami zarządzacie projektami?

K: Nie zatrudniamy managerów do podejmowania decyzji, zarządzania zespołem. Każdy członek zespołu ma całościowy dostęp do niezbędnej wiedzy, a podejmując decyzje musi uwzględniać konsekwencje decyzji, zarówno na poziomie osobistym, zespołu jak i całej firmy. Nie chcieliśmy zatrudniać managerów do zarządzania programistami. Tomasz Szymański, nasz CEO zainspirowany historiami dwóch firm — Valve i The Morning Star postanowił wprowadzić w SoftwareMill ideę samoorganizacji i inicjatywy oddolnej, o której wspomniałem. Początkowo uwolnienie decyzyjności w firmie przysporzyło kilka problemów.

Przypuszczam, że wydłużyło to proces podejmowania decyzji.

K: Tak, był to dosyć poważny problem na początku. Kiedy każdy ma wpływ na decyzję, podejmowanie jej trwa dłużej. Angażowanie całej firmy do podejmowania prostych decyzji blokowało płynność tego procesu, podobnie jak udzielanie rad bez idącego za tym działania. Aby przezwyciężyć problem lawiny pomysłów bez chętnych do ich realizacji, wprowadziliśmy trzy proste zasady:

• stworzyliśmy krótkie wewnętrzne szkolenie dla nowych osób, w którym inni członkowie zespołu wyjaśniają zasady jakie u nas panują i pomagają w podejmowaniu pierwszych decyzji.
• kierujemy się prostą zasadą: porada = zaangażowanie. W rezultacie udało nam się zmniejszyć tendencję do dawania porad, bez faktycznego zaangażowania w prace nad rozwiązywaniem problemów.
• wprowadziliśmy formułę grup roboczych – ta idea dotyczy bardziej złożonych i strategicznych decyzji. Tworzymy grupy robocze z osobami zainteresowanymi danym tematem, które same chcą zaangażować się w identyfikację problemu, omawianie rozwiązań, wreszcie przedstawić obrany kierunek całemu zespołowi. Kiedy decyzja zostaje zatwierdzona w głosowaniu, ostatecznie zapisujemy ją w rejestrze decyzji.

Taki system sprawdza się u nas od lat i umożliwia nam podejmowanie decyzji w samoorganizującym się otoczeniu.

Jaka jest różnica między pracą nad wewnętrznym produktem, a pracą dla klientów?

Andrzej: Pracując nad swoim produktem, klientem jesteśmy w pewnym sensie my sami, więc musimy ustalić wymagania biznesowe i priorytety techniczne. Warto też od razu założyć sobie konkretny budżet, żeby nie wpaść w pułapkę idealnego produktu w pierwszej wersji, który potem nigdy nie zostanie wdrożony albo użyty. Zupełnie inaczej wygląda to w przypadku projektu gdzie jest klient. To on jest źródłem prawdy jeśli chodzi o biznes i ma konkretną wizję tego jak powinien wyglądać efekty końcowy. My, bierzemy te wymagania pod uwagę i pomagamy przekuć jego idee w działający, skalowalny i dobrze napisany produkt.

Wróćmy na chwilę do początków SoftwareMill. Chciałbym dowiedzieć się co wy robiliście w 2009 roku, kiedy dopiero powstała firma? Czym się wtedy zajmowaliście?

A: Kończyłem studia. SoftwareMill to była moja trzecia praca i to tu pracuję najdłużej.

K: W 2009 już drugi rok pracowałem w lubelskiej firmie eLeader. Głównie tworzyliśmy aplikacje mobilne, ale częścią tych systemów były też backendy, z którymi te aplikacje mobilne się komunikowały. Od tamtych backendów zaczynałem swoją przygodę z Javą. Do SoftwareMill przyszedłem w 2013 roku. Był to ciekawy moment, bo zacząłem pracę w marcu, a w maju nastąpił przełom organizacyjny i transformacja w transparentną, samoorganizującą się firmę.

W SoftwareMill wszystkie decyzje podejmuje się oddolnie. Jakie były wasze pierwsze wrażenia odnośnie tego, że wszyscy członkowie zespołu podejmują decyzje?

A: Na pewno było to bardzo odświeżające doznanie. Nagle mogłem mieć wpływ na wszystkie rzeczy w działaniu firmy. To jest o tyle dobrze zorganizowane, że jeśli jakaś rzecz mnie nie dotyczy albo nie chcę się w coś angażować, to nie muszę, ale jeśli jest to dość istotna dla mnie sprawa, np. podwyżki, to jak najbardziej jestem zainteresowany jak to działa, co można z tym zrobić, w jaki sposób poprawić. Zdecydowanie było to coś nowego z czym wcześniej nie miałem do czynienia.

Oprócz spraw finansowych macie wpływ na to kto realizuje zadania, dany projekt dla klienta?

A: W zasadzie mamy wpływ na wszystko. To wiąże się też z większą transparentnością, zazwyczaj każdy w projekcie ma dostęp do całej komunikacji, nie ma czegoś takiego jak tematy i rozmowy zarezerwowane dla wybranych. Gdy pojawia się klient, na początku rozmawia z nim business developer. Bardzo szybko do rozmowy włączają się również programiści, ponieważ potrzeba wiedzy technicznej, żeby zrozumieć jaki klient ma problem. Bez dobrego wywiadu bardzo ciężko ustalić, kto mógłby pasować do danego projektu. Od takiej telekonferencji może zależeć to czy projekt wystartuje. Istotne jest też dla nas dobre zorganizowanie pracy w zespole. Trzeba ciągle trzymać rękę na pulsie i dbać o to, żeby development szedł do przodu i żeby plan dostosowywać do zmian. Zawsze ktoś z programistów staje się takim trochę semi-pm, czyli kimś, kto dba nie tylko o poszczególne nowe funkcjonalności, tylko trochę tak bardziej całościowo ogarnia tematy. Co ciekawe taka osoba sama się wyłania, nikt jej oficjalnie nie mianuje.

K: Dopowiem jeszcze, że na tym etapie początkowym, kiedy klient wydaje się na tyle obiecujący i pewny, że będziemy robić ten projekt, to zaczynamy powoli wewnętrznie ustalać kto pasowałby do tego projektu. Nie ma odgórnych przydziałów, staramy się oddolnie dogadywać i wspólnie ustalić skład zespołu, czy ewentualnie zmiany w niedalekiej przyszłości. Biorąc pod uwagę fakt, że pracujemy w raczej małych zespołach z ludźmi do których mamy zaufanie i którzy mają bardzo zbliżone doświadczenie zawodowe, nie potrzebujemy zewnętrznych bodźców żeby sprawnie i systematycznie pracować na dostarczaniem business value. I tutaj kto jak kto, ale programiści są mistrzami świata w optymalizacji wszystkiego co można zoptymalizować, tylko trzeba im dać trochę więcej swobody i sami to już tak poukładają, żeby klient był zadowolony.

Zobacz też

Frontend W Japonii jest więcej expatów niż miejsc. Wywiad z Grzegorzem Chuchro

Co dla programisty oznacza brak PM-ów? Kto te ostateczne decyzje odnośnie klientów podejmuje?

K: Pracujemy w projektach, które sami sobie dobieramy. Bierzemy wtedy pod uwagę swoje własne preferencje oraz dobro firmy. Pracując bez PM-ów musimy zadawać bardzo dużo pytań, ale też regularnie raportować klientowi o wszystkim, aby nie było żadnych niedopowiedzeń. Do tego potrzebna jest inicjatywa i asertywność. Czasem trzeba przekonać klienta do swojej racji, odmówić mu, lub lekko go przycisnąć aby dostarczył coś od czego zależy projekt.

A: Warto dodać, że jesteśmy bardzo wybredni, jeśli chodzi o projekty. Nie realizujemy praktycznie większości „szarych” systemów i zostawiamy sobie „wisienki”. Wyobraźmy sobie, że przychodzi klient, który chce mieć super skalowalny system, obsługiwany przez milion użytkowników. Czego trzeba więcej by zachęcić programistę do udziału w takim projekcie? W takich warunkach pracy nasza motywacja wzrasta niesamowicie. Samoorganizujące się zespoły to nie tylko modny ostatnio buzzword, faktycznie istnieją i mają się bardzo dobrze. Ja już na tyle długo pracuje w takim trybie, że często reaguję zdziwieniem kiedy klient pyta się, czy będziemy mieli PM-a w zespole.

Wy jesteście osobami, które tłumaczą klientowi jak wygląda praca programisty?

K: Zanim rozpoczniemy pracę nad projektem deweloperzy włączają się do rozmów z klientem – głównie żeby przekonać go o naszych technicznych kompetencjach. Tak jak Andrzej wspomniał, nasz business development to osoby, które potrafią zacząć rozmowę i też z punktu widzenia organizacyjnego porozmawiać z klientem, przedstawić naszą firmę, opowiedzieć jak wygląda nasz tryb pracy. Natomiast my włączamy się do rozmów, kiedy wchodzą konkrety techniczne. Wielu deweloperów ceni swoją pracę za to, że mogą się skupić na technice, a nie muszą się przejmować tematami “miękkimi”. W SoftwareMill już sam fakt regularnych telekonferencji z ludźmi odpowiedzialnymi za biznes potrafi być wyzwaniem. To dlatego przywiązujemy dużą wagę do komunikatywności, by mieć pewność, że w zdalnej, bezpośredniej pracy z klientem nie było miejsca na niedopowiedzenia.

Zazwyczaj rozmawiacie z osobami technicznymi?

K: Czasami tak, ale zdarza się, że klient jest kompletnie zielony technicznie i wtedy też deweloperzy z naszej strony muszą zaproponować jakiś wstępny model, wizję tego jak byśmy to zrealizowali. Są tacy klienci, którzy chcą mieć ekspertów i nie zastanawiać się kompletnie nad technologiami, są z kolei tacy, którzy sami są trochę techniczni, więc mają dużo własnych przyzwyczajeń, wymagań czy konkretnych wizji.

A: Dodam, że w takim modelu pracy spoczywa na nas więcej odpowiedzialności. Zespół musi robić rzeczy, które w wielu firmach są oddelegowane do innych ludzi: negocjować stawki, ustalać terminy wdrożeń, zmiany składu zespołu, analizować wątki biznesowe, czasami nawet zahaczamy o kwestie prawne ustalając szczegóły umowy. To oczywiście zależy od projektu — niektóre prowadzimy całościowo, w niektórych organizację w różnym stopniu narzuca strona klienta.

Moglibyście powiedzieć, ile godzin dziennie poświęcacie na kontakt z klientem? Ile na pracę nad danym systemem?

A: Ciężko ocenić. To nie jest tak, że codziennie rozmawiamy z klientami. Jeśli pojawia się taka potrzeba to raczej nie rozwala całego dnia/tygodnia pracy. Z reguły trzeba zarezerwować sobie godzinę, dwie, żeby porozmawiać.

K: Zdarza się taki okres, że w tygodniu codziennie jest jakiś klient, który chce porozmawiać, a czasami tygodniami nie ma nikogo. Z perspektywy pojedynczego dewelopera, a jest nas w firmie prawie 40, raczej częściej niż raz na parę dni taka potrzeba rozmowy z klientem się nie zdarza.

Jak rozumiem raczej rzadko jesteście razem w jednym projekcie?

K: Od roku jesteśmy w jednym projekcie, choć wcześniej nie mieliśmy takiej okazji.

Opowiedzcie proszę o projektach, w których uczestniczyliście, a które dały Wam najwięcej satysfakcji.

A: Projekt, bardzo ciekawy domenowo, w którym uczestniczyłem, dotyczył sterowania światłem w inteligentnym budynku w Irlandii. Dawał bardzo dużo satysfakcji, bo pisaliśmy kod, dzięki któremu mogliśmy sterować światłami w kilkupiętrowym biurowcu i testowanie odbywało się na „żywym organizmie”. Oprócz tego zbieraliśmy bardzo dużo ciekawych metryk, z których mogliśmy m.in. obliczyć ile prądu może zaoszczędzić firma korzystając z naszego systemu. Obecnie pracuję w projekcie, którego domeny niestety nie mogę zdradzić, ale z technicznego punktu widzenia musimy zapewnić klientowi bardzo dużą elastyczność w skalowalności oraz wydajność pozwalająca na obsługę ciągle rosnącej ilości użytkowników.

K: Dla mnie był to projekt dla klienta z Afryki, który zajmuje się masowym wysyłaniem SMS-ów. Klient zgłosił się do nas, ponieważ jego infrastruktura gromadzi bardzo duże ilości danych, które trzeba było przetwarzać na bieżąco. Klient potrzebował agregować dużo informacji i zbierać statystyki ze swojego systemu, musieliśmy więc nauczyć się przetwarzać duże ilości danych, generować z nich konkretne wykresy, i analizy statystyczne dla klienta, i dla klientów naszego klienta. To fajne uczucie, że Twój projekt realnie coś wnosi i daje korzyści.

Na pewno daje to sporo motywacji potrzebnej do rozwoju. Powiedzcie, czym jest dla Was rozwój?

A: Kiedyś myślałem, że rozwój to poznawanie kolejnych języków, frameworków, technologii. Od dłuższego czasu mam taką refleksję, że wszystko to zmienia się tak dynamicznie, że nie ma sensu skupiać się na poznawaniu kolejnego narzędzia, dużo lepiej zrozumieć pewne idee i prawa, które są niezmienne w naszym zawodzie. Wiedza techniczna jest oczywiście ważna, ale dużo lepszą inwestycją jest dogłębne zrozumienie pewnych problemów i sposób ich rozwiązywania. Co mnie teraz najbardziej rozwija? Nietrywialne zadania, z którymi przychodzi klient. Często jest to niestabilny, działający wolno system, który nie jest w stanie obsłużyć określonej ilości użytkowników w sensownym czasie. Wejście w taki projekt oznacza często naprawienie, bądź napisanie kodu od zera. Wracając do przykładu projektu sterowania światłami: kiedy go objęliśmy, to włączenie światła powodowało, że dopiero po trzydziestu minutach coś się zmieniało. To oczywiście przekreślało cały sens tego systemu i było nieakceptowalnym opóźnieniem.

K: Czuję, że się rozwijam zawodowo, kiedy rozwiązuję coraz bardziej ambitne problemy. Kiedy mam do czynienia z systemami, które składają się z coraz większej liczby podsystemów, albo gdy rośnie ogólny poziom odpowiedzialności za projekt – wtedy można powiedzieć, że idzie się do przodu. To jest takie uczucie, że człowiek odpowiada już nie tylko za jakiś mały trybik w machinie, ale odpowiada też za zależności między tymi trybikami i między całymi grupami kolejnych trybików.

Oferty pracy z

Poziom trudności projektów zmieniał się wraz z liczbą pracowników? Czy kiedyś były tak samo trudne projekty jak teraz?

A: Myślę, że to cały czas się zmienia i idzie w kierunku ciągłego podnoszenia poprzeczki. Obecnie mocno inwestujemy w technologię blockchain, w której jest bardzo niewielu ekspertów, szczególnie na Polskim rynku. Dodatkowo ze względu na coraz większe doświadczenie i rozpoznawalność na rynku zgłaszają się do nas klienci z prośbą o consulting ekspercki. Są to krótsze projekty (1-3 mc), w których mierzymy się z zaawansowanymi problemami, z którymi często nie radzą sobie działy IT takich klientów.

K: Tak jak Andrzej wspomniał wcześniej, myślę że jesteśmy dużo bardziej wybredni niż kiedyś. Zgłaszają się do nas klienci z różnymi pomysłami i myślę, że wraz z rozwojem wybieramy ciekawsze problemy, bardziej złożone technicznie rzeczy, które pomogą nam pójść do przodu, zdobyć nowe doświadczenie, żebyśmy przy następnym kliencie mogli powiedzieć: „robiliśmy system, który ma tyle i tyle node’ów, który jest tak złożony i możemy zrobić też dla was złożony system”. Nasza branża ma to do siebie, że wymaga nieustającej nauki, bo technologie i wzorce zmieniają się w ogromnym tempie. Chcemy nadążać, poznawać nowości, a jednocześnie mieć wyczucie kiedy warto odwołać się do starych sprawdzonych rozwiązań.

Przez ciągłe podnoszenie poprzeczki nie zatrudniacie juniorów w firmie?

K: Od początku firma zatrudniała doświadczonych ludzi. Z juniorami jest takie wyzwanie, że niestety proces ich mentoringu wymaga na początku dużo więcej zaangażowania osób z doświadczeniem. Idealnie sprawdza się do tego pair programming i takie dzielenie się wiedzą ramię w ramię. Wtedy z naszych doświadczeń taki junior najszybciej się wdraża w dany projekt. W pracy zdalnej też stosujemy pair programing, aczkolwiek nie na taką skalę jak w pracy z biura.

A: Staramy się, żeby naszą domeną nie była niska cena, tylko wysoka jakość. Dzięki temu klient dostaje team złożony ze specjalistów, a nie jednego specjalistę i pięciu juniorów. Te słynne przysłowie branżowe, że każdy program da się napisać skończoną liczbą studentów, może i jest śmieszne, ale nie da klienta. Dodam, że mentoring juniorów w pracy zdalnej jest dość trudny. Juniorzy mają też to do siebie, że boją się pytać, a mid i senior wie czego nie wie i jeśli trafi na przeszkodę, to nie traci dwóch-trzech dni na przeszukiwanie internetu i wynajdywania koła na nowo, tylko po prostu pyta.

Co poradzilibyście zatem juniorom? Jak rozpocząć swoją ścieżkę, gdzie szukać pracy, jak przygotować się do jej szukania?

A: Usłyszałem kiedyś świetne zdanie od jednej z osób, którą bardzo cenię. Powiedziała mi, żeby na początku nie sugerować się kasą, bo można przez dziesięć lat zarabiać umiarkowane pieniądze, ale bardzo dobrze rozwijać się, by potem w jeden rok zarobić cztery razy tyle, co w te dziesięć lat łącznie. Z reguły korporacje kuszą ludzi zaraz po studiach bardzo wysokimi widełkami, ale nie zawsze umożliwiają rozwój w pożądanym kierunku. Czasami trafiamy do ciekawego projektu, a czasami zamiast się rozwijać to następuje stagnacja. Jeśli jest się juniorem, to trzeba moim zdaniem na to uważać.

K: Tak, łatwo wpaść w taką pułapkę. Dodałbym tylko, żeby juniorzy trzymali rękę na pulsie, jeśli chodzi o technologie i rozwój. Chociażby poprzez udział w konferencjach. Bywając na tego typu wydarzeniach, jak i na lokalnych meetupach, można dowiedzieć się i poczuć co jest w tym momencie technicznie ważne, w co warto iść. Mi osobiście pierwsze kilka konferencji otworzyło oczy na to, w którym kierunku chcę się rozwijać. W SoftwareMill przykładowo od 6 lat organizujemy konferencję Scalar, dla entuzjastów programowania funkcyjnego. Druga rada: ważne jest wejście w środowisko open-source. W naszym przypadku, kiedy zatrudniamy ludzi, to duży plus, kiedy ktoś ma jakieś repozytoria na GitHubie, czy może pokazać, że robił coś open-source’owego. Fajnie, jeśli ma się czym pochwalić, nawet jeśli są to jakieś proste projekty, czy niewielkie zmiany w innych projektach. Świadczy to o tym, że interesuje się tym, co się dzieje w branży. To jest rada dla juniorów, żeby się nie wahali próbować w tym swoich sił.

A: Zdecydowanie powinni często wychodzić ze swojej strefy komfortu, bo prawdopodobnie to jest ten etap w ich życiu, gdzie przyjdzie im to najłatwiej. Warto skupić się na generalnych prawdach, a nie poznawaniu kolejnego języka po trochu. Pewne rzeczy w programowaniu czy w całej inżynierii oprogramowania są dosyć uniwersalne. Tak naprawdę implementujemy rzeczy, które były wymyślone w latach osiemdziesiątych, a nawet siedemdziesiątych. Chodzi o to, żeby nie skupiać się na “młotkach” aż tak bardzo jak na ogólnych prawach, które rządzą w tym biznesie.

Opowiedzcie, co was zaskoczyło w samym programowaniu. Z jakimi spotkaliście się mitami w pracy programisty?

K: Idąc do pierwszej pracy musiałem mocno przebudować u siebie hierarchię wartości. Okazało się, że w prawdziwym świecie rysowanie diagramów na tablicy to jest ciekawy dodatek. Na studiach nauczyłem się wielu zbędnych rzeczy, których później musiałem się oduczać w pracy. Jednym z tych mitów było właśnie to, że w potężnej dokumentacji pełnej bardzo zaawansowanych diagramów to, czy strzałka jest prosta, czy jest przerywana jest szalenie istotne. To się kompletnie nie sprawdza w większości przypadków i nie ma tak naprawdę znaczenia. Różne inne rzeczy mają znaczenie.

A: Trzeba uważać na generatory kodu. Niektóre nam pomagają i usprawniają pewne rzeczy, ale to nie jest tak, że narysujemy diagramy, linie proste i przerywane, i nagle będziemy mieli działającą aplikację skrojoną pod użytkownika.

K: To mi przypomina jeszcze jedną rzeczy. Mój początkowy podziw do kodu, który jest misterny, skomplikowany. Pamiętam, że jak widziałem kod starszych kolegów, którego nie mogłem zrozumieć, kiedy byłem juniorem, to na początku bardzo mi imponowało i dla mnie było takim wyznacznikiem tego, że ktoś jest bardzo zaawansowanym devem. Życie zweryfikowało ten mit w taki sposób, że tego typu kod jest bardzo trudny w utrzymaniu. Prostota i to, że inni mogą kontynuować po Tobie pracę, rozumiejąc co napisałeś, to jedna z tych ważniejszych lekcji, które musiałem przerobić jako początkujący.

Na koniec opowiedzcie o procesie rekrutacji. Wy go już przeszliście, ale na pewno wielu chciałoby do Was dołączyć.

K: Bardzo poważnie traktujemy proces rekrutacji i przeprowadzamy go sami, nie uświadczysz u nas działu HR. Sam proces jest dość standardowy, a w jego trakcie:

• poznaje się zespół, z którym będzie się pracować;
• otrzymuje się kompleksową informację zwrotną do zadania technicznego, niezależnie od jakości jego wykonania.

Zaczynamy od bardzo krótkiej rozmowy, na której zawsze są te same podstawowe pytania. To jest taka rozmowa zapoznawcza, na której od razu sprawdzamy też język angielski. Przez ten etap praktycznie wszyscy przechodzą, ale następny jest trudniejszy. Kandydat musi rozwiązać zadanie programistyczne u siebie w domu, w dowolnym czasie (choć w rozsądnych granicach), korzystając ze wszelkich środków do jakich ma dostęp. Bardziej zależy nam na jakości rozwiązania, a nie na czasie wykonania, bo jako firma bardzo stawiamy na dobry kod.

Kto sprawdza to zadanie dostarczone przez kandydata?

K: Dwie osoby, które rozpoczynają dyskusję na temat efektu, a jeżeli są jakieś kontrowersje, to odsyłamy kandydatowi recenzje i sprawdzamy jak zareaguje. Czy będzie miał uwagi do naszych uwag, czy po prostu wszystko poprawi, czy może będzie argumentował swoje zdanie. To też daje nam sygnał jak będzie wyglądała komunikacja, a jej jakość jest niezwykle istotna w naszym zdalnym modelu pracy. Następny etap to dłuższa rozmowa techniczna. Dwie osoby – najlepiej inne niż te, które oceniały zadanie – zadają konkretne pytania techniczne w zależności od tego, na jaką pozycję ta osoba startuje. Nie pytamy o niskopoziomowe rzeczy, bardziej zależy nam na podejściu do rozwiązywania problemów, tworzenia architektury niż dogłębną znajomość jakiejś konkretnej biblioteki, bo narzędzia się zmieniają, a uniwersalna wiedza z naszej branży jest aktualna cały czas. Po tym następuje ostatni etap. Spotykamy się na żywo, zazwyczaj na lunch. Rozmawiamy i tam już nikt nie jest maglowany jak na rozmowie technicznej. Chcemy po prostu trochę lepiej poznać tę osobę.

A: Proces jest długi i z reguły trzeba na niego zarezerwować miesiąc. Ten miesiąc sam w sobie jest sitem rekrutacyjnym, bo odsiewa kandydatów, którzy są tzw. „skoczkami”. My chcemy ludzi, którzy nas znają czy to z konferencji, czy z community, czy jakoś inaczej i chcą pracować konkretnie u nas, a nie gdziekolwiek. Pozwala nam to utrzymać bardzo małą rotację pracowników, bo ludzie, którzy chcą pracować z nami, gdy coś pójdzie nie tak, najpierw podejmą wysiłek, żeby sytuację naprawić, a nie od razu wyślą CV do dziesięciu innych firm.

Domyślam się, że każdy z kandydatów musi mieć podobne wartości do Waszych. Jestem ciekaw jakie to są wartości?

A: Dla mnie jedną z najważniejszych wartości tej firmy są po prostu ludzie. Kiedy rekrutowałem się do SoftwareMill chciałem z tymi ludźmi pracować, chciałem się od nich uczyć, zbierać doświadczenie. Co do samej wizji firmy, to właściciele chcą tworzyć najlepsze miejsce do pracy dla programistów.

K: SoftwareMill w dużym stopniu oparty jest na zaufaniu, dlatego jesteśmy tak otwarci. Co miesiąc spotykamy się na żywo i na takich spotkaniach często poruszamy tematy, które wymagają bardziej intensywnej burzy mózgów i wymiany zdań. Czasami to jest kontynuacja pracy jakiejś grupy roboczej, czasem zupełnie oddzielny temat. Najważniejsze jest to, żeby ludzie od pierwszego dnia pracy czuli, że ich głos wszędzie się liczy tak samo i że mogą faktycznie wpływać na to jak działa ta firma. Nasza firma jest nietypowa, więc też nie możemy oczekiwać od zatrudnianych ludzi super inicjatywy na dzień dobry. Czasami trzeba wyleczyć się ze złych nawyków z korporacji. Jeśli widzimy podczas rekrutacji, że ludzie są obiecujący w tym kierunku, to jest to bardzo ważne przy podejmowaniu ostatecznej decyzji.

Zobacz też

Wywiady Rzuciła podróże, by pracować w IT. Wywiad z Michaliną Macek ze State Street Bank