TL;DR Marzy Ci się praca z Elixirem, ale czujesz że masz za mało wiedzy/doświadczenia lub nie znasz odpowiedniej firmy? Chyba możemy sobie wzajemnie pomóc ...

Cześć, jestem Sebastian i mam propozycję, która może Cię zainteresować. Tak się składa, że na co dzień pracuję w grupie inżynierów rozwijających aplikacje Fresha oraz Shedul i aktualnie szukamy "świeżej krwi" - dodatkowych osób, które wzmocniłyby nasz zespół.

Generalnie staram się nie robić takich rzeczy, tj. unikam pisania dedykowanych, osobistych postów związanych z rekrutacją - ale chyba po raz pierwszy jestem w takiej sytuacji, że to zespół czuje się sfrustrowany tym, że tak wiele wartych uwagi rozwiązań udało się wspólnymi siłami wypracować, ale tak mało osób (poza firmą) o tym słyszało. Osób, które być może szukają właśnie takiego środowiska pracy i nie mogą znaleźć ...

Spróbujmy więc wypełnić tę lukę - chcę Ci opowiedzieć dlaczego warto się Shedulem (i Freshą) zainteresować oraz co Cię może tu czekać, jeśli zdecydujesz się związać swoją karierę właśnie z nami.

No to jedziemy.

Kilka słów o produkcie

Jesteśmy start-upem, przynajmniej pod względem kultury organizacji, bo budowana przez nas platforma jest dostępna dla użytkowników już ponad 3 lata. Opisując nasz biznes w skrócie używamy zwykle sformułowania "SaaS-enabled Marketplace for Salons", ale ktoś kiedyś określił go jako "taki Uber, tylko dla branży Beauty & Wellness" i w sumie nie jest to złe porównanie:

Z jednej strony ("Shedul") dajemy pełną obsługę informatyczną (zapisy on-line, płatności, ofertowanie, inwentarz, ...) salonom fryzjerskim, odnowy, masażu, wizażu, itd. a z drugiej strony ("Fresha") dajemy klientom takich salonów możliwość wyszukiwania interesujących ofert, oceny usług, rezerwacji wizyt, itp.

Technologia

"Pod maską" naszej platformy pracuje całkiem interesujący stack technologiczny (pełna lista na Stackshare) - historycznie zaczęliśmy od Ruby i Railsów, ale już ponad rok temu podjęliśmy strategiczną decyzję o przejściu na Elixir i Phoenix - aktualnie nowe funkcjonalności serwerowe są już pisane tylko w Elixirze, stopniowo przenosimy też te istniejące.

Nasz back-end nie jest monolitem. Rozbiliśmy go na kilkanaście luźno powiązanych aplikacji, skomunikowanych przez RPC (oparte na protocol-buffers) i kolejki RabbitMQ. Dane przechowujemy w PostgreSQL, często wykorzystywane informacje o niskiej dynamice zmian trzymamy też w Redisie. Środowiska stawiamy w sposób w pełni automatyczny (Terraform + Ansible + Jenkins) w AWS i (jeszcze częściowo, wychodzimy stamtąd) Heroku.

Nasze aplikacje klienckie są budowane przy użyciu tandemu React + Redux i posiadają wspólną bazę kodu dla aplikacji webowych i mobilnych (dzięki SSR i Apache Cordova). Chcesz się przekonać jak to działa? Nic prostszego! Rejestracja w aplikacjach nic nie kosztuje - możesz sprawdzić nasz kod w akcji bez żadnych zbędnych formalności.

Skala

Tak, określamy się ciągle jako "start-up", ale w praktyce mamy w swojej pieczy całkiem dojrzały, dynamicznie rozwijający się biznes:

• dziesiątki tysięcy obsługiwanych klientów (firm posiadających salony) na całym świecie
• miliony rezerwowanych wizyt każdego miesiąca
• dwucyfrowy (procentowo) miesięczny wzrost ruchu (każdego m-ca) - a jedyny marketing, którego używamy to ten szeptany :) czyli opinie, którymi dzielą się nasi klienci

Nasz team inżynierski to aktualnie ok. 40 osób w biurze mieszczącym się na 20-tym piętrze biurowca w samym centrum Warszawy, na chwilę obecną możemy pozwolić sobie nawet na 100%-towy wzrost liczebności, ale (to ważne!) nie kosztem wypracowanej kultury organizacji (z której jesteśmy szczerze dumni).

No ... i co z tego?

No dobra, brzmi to nieźle, ale w Warszawie jest wiele firm software'owych, które mają naprawdę ciekawe oferty i mogą się pochwalić ciekawym modelem biznesowym i/lub nowoczesnym stackiem technologicznym. Dlaczego warto mimo wszystko zwrócić uwagę właśnie na nas?

Po kilku miesiącach pracy w tym miejscu widzę trzy "grube" powody:

1. pracujemy "bez gwiazdek"
2. możesz u nas znaleźć "Krzemową Dolinę" w pigułce
3. inżynierska merytokracja

1. "Bez gwiazdek"

Nie mam tu bynajmniej na myśli "gwiazdorzenia". Po prostu widziałem już wiele firm, gdzie generalnie podobno pracuje się korzystając z najnowocześniejszych technologii, praktyk i wzorców, ale wystarczy przyjrzeć się 15 minut i głowa boli od wyjątków, uproszczeń, "lokalnych optymalizacji" i "klauzul z gwiazdką" (drobnym drukiem ...). Skutkiem czego w takim miejscu praktykuje się np.:

• pseudo-Scruma (no bo w sumie planowanie jest z góry na 6 m-cy, release'y są poprzedzone "sprintami integracyjnymi" ...)
• niezbyt Ciągłą Integrację (bo przecież wszystkie testy są ręczne i/lub wy-outsource'owane, każdy zespół pracuje w ramach własnego "projektu" na osobnym branchu, ze wzgl. na podziały właścicielstwa kodu teamy requestują sobie wzajemnie CRy ...)
• "departament DevOps" (czyli Infrastrukturę z nową etykietką - gdzie dedykowana grupa ludzi używa trochę bardziej nowoczesnych narzędzi w sposób rodem z lat 90tych ...)

No więc my nie akceptujemy dopisków małym drukiem. Jak już robimy ten Scrum, to robimy go dobrze - wdrażamy inkrement po każdym Sprincie, mamy mierzalny Produkt z konkretną definicją i metrykami, Scrum Master nie jest ukrytym Team Leaderem / "pisarzem status reportów". Nie "malujemy trawy na zielono".

To wcale nie znaczy, że uważamy że u nas jest idealnie i nie ma czego poprawić. Wręcz przeciwnie - ale zamiast narzekać, regularnie (co 2 tyg.) sami (my: inżynierowie i inżynierki) wprowadzamy kolejne zmiany i usprawnienia, pilnujemy ich wykonania, obserwujemy efekty i wyciągamy wnioski.

To jest nasz "Engineering Kaizen".

2. "Krzemowe Mazowsze"

Czasem mam wrażenie, że to już jakiś powszechny kompleks - polscy programiści-pasjonaci czytają te niesamowite historie rodem z "unicornów" z amerykańskiego Zachodniego Wybrzeża, po czym po prostu wzdychają ciężko:

"Ech, gdyby u nas tak można było ... Gdyby w Warszawie/Krakowie/Wrocławiu/Gdańsku/Łodzi/... były firmy, w których można byłoby wyprawiać takie cuda, a nie tylko siermiężna techno-cepelia ..."

No więc, prawda jest taka, że takie firmy istnieją w Polsce, i w Warszawie w szczególności. Shedul/Fresha to jedna z nich (wcale nie jedyna; wcale nie największa; podejrzewam, że wcale nie najbardziej zaawansowana inżynieryjnie):

• tak - jesteśmy cloud-first i stawiamy na rozwiązania cloud-native; tak - mamy stały wzrost ruchu, dla którego regularnie skalowanie wszerz to konieczność a nie fanaberia inżynierska; tak - potrzebujemy wysokowydajnej platformy na back-endzie (stąd Elixir, Phoenix i BEAM - które mamy na produkcji już od ponad roku)
• tak - nasza platforma jest business-critical dla klientów, więc musimy absolutnie minimalizować down-time, utrzymywać niezależność deploymentową komponentów, "pływająco" wdrażać zmiany; tak - mamy pełną automatyzację stawiania nowych śrowisk on-demand (ChatOps, Infrastructure as Software)
• tak - wdrażamy inkrement maks. co 2 tygodnie, ale konkretnie ciśniemy na Continuous Delivery; tak - każdy Sprint to konkretne, widoczne zmiany dostarczające mierzalną wartość biznesową; tak - obsesyjnie wręcz dbamy o User Experience, wygodę, spójność i wydajność naszych aplikacji

Mogę się pod tym podpisać obiema rękami - absolutnie nie mamy czego się wstydzić, nasi ludzie są dumni z tego co SAMI wypracowali. Nie będę udawać, że przyszło nam to łatwo - popełnialiśmy błędy (ba, ciągle jakieś popełniamy i ... będziemy popełniać), ale my nie szukamy wymówek, tylko pracujemy nad rozwiązaniem problemów.

3. "Inżynierska merytokracja"

Tu każdy pracuje bezpośrednio nad produktem. Czyli w przypadku zdecydowanej większości - Inżynierów - koduje.

No dobra - Scrum Master aktualnie nie. I ja też w sumie ostatnio nie miałem czasu :( (nad czym ubolewam, ale ... jestem aktualnie potrzebny do czegoś innego) Ale to jedyne wyjątki. Nie ma Project Managerów, Excel Managerów, Gantt Managerów, Reporting Managerów, ... Struktura organizacyjna jest płaska, zespoły cross-funkcyjne i niezależne.

Po prostu.

Pracujemy nad własną platformą. Ona ma się (tylko i aż) obronić komercyjnie - tu nie ma polityki, nie ma dziwnych rozgrywek, jest za to A/B testing (za pomocą feature flags uruchamiamy pewne zmiany na ograniczonej populacji klientów), iteracyjna praca nad rozwiązaniami od poziomu MVP wzwyż, zadania architektoniczno-techniczne w backlogu, repriorytetyzacja backloga w oparciu o faktyczny feedback klientów, wspólne brainstormy Produktowców i Inżynierów.

Dzięki temu każdy kolejny Sprint (2 tygodnie) to konkretny inkrement funkcjonalności. Nasze Review to nie slajdy z jakimiś abstrakcyjnymi bulletami (albo innymi wypełniaczami czasu ...), ale faktyczne prezentacje DZIAŁAJĄCEJ funkcjonalności dostarczonej w jednym Sprincie.

Po prostu.

I każdy może przyjść na takie Sprint Review - zapraszamy nawet ludzi spoza firmy.

No to co, jest idealnie?

Nie, oczywiście, że nie jest. Żeby być zupełnie szczerym, trzeba wspomnieć o tym, co nie każdemu musi się podobać:

1. płacone przez nas stawki są solidne (powiedziałbym: "uczciwe"), ale jeśli ktoś jest nastawiony przede wszystkim na pieniądze, pewnie będzie w stanie wynegocjować więcej w niejednym zdesperowanym "enterprajsie" (których - powiedzmy sobie szczerze - nie brakuje)

2. ta platforma jest naprawdę "business-critical" dla użytkowników końcowych; na razie (na szczęście) nie mieliśmy większych wtop, ale potencjalny down-time to poważny problem dla salonów korzystających z naszego oprogramowania; oznacza to zdecydowanie wyższy poziom stresu niż w przypadku wielu innych firm

3. duża skala (ruchu na platformie) i wysokie wymagania względem wydajności - mają konkretny wpływ na architekturę systemu: jest ona bardziej złożona i wymaga więcej wysiłku do zrozumienia i "wdrożenia się"

4. nasza cała baza kodu (monorepo) to "wewnętrzny Open Source" - nie trzymamy się ścisłego właścicielstwa kodu ("spadaj, to jest mój moduł!"); oznacza to zwiększony nacisk na przestrzeganie reguł jakości kodu i zgodności z architekturą oraz stawia nacisk na pracę z "cudzym" (powszechnym) kodem - nie każdy to lubi ...

5. nie jesteśmy i nie planujemy (przynajmniej na razie) być "remote first" - wprawdzie rozpoczynamy pilota pracy zdalnej, ale w ograniczonym zakresie. więc jeśli ktoś jest szuka opcji 100% remote, to się u nas nie uda ...

6. najważniejsze: bez kitu - jedziemy szybko, a nie każdemu takie tempo i intensywność musi odpowiadać; nie, nie chodzi o robocze weekendy albo zarywanie nocy - staramy się trzymać zdrowych 40h/tydzień, ale sami narzucamy sobie wysoką dyscyplinę dostarczania (wysoka granularność zadań, wszystko ma być "wdrażalne")

Kogo szukamy, co oferujemy?

Szukamy ambitnych Inżynierów Oprogramowania (obojga płci) - takich, którzy będą docelowo pracować z przynajmniej jedną z listy następujących technologii:

• JavaScript (React+Redux)
• Ruby+Rails
• Elixir+Phoenix
• Selenium+TestNG
• Ansible+Terraform+Jenkins+AWS

Czego oczekujemy na starcie?

Praktycznej umiejętności pracy z przynajmniej jedną z powyższych technologii. Nie wymagamy konkretnej ilości lat spędzonych z daną technologią (LOL) ani znajomości składni API całej biblioteki standardowej ;>, znacznie ważniejsze są:

• inżynierski common-sense (jak podchodzisz do rozwiązywania problemów, jak podejmujesz decyzje, ...)
• znajomość zasad pisania tzw. czystego kodu i obeznanie z podst. dobrymi praktykami (dla danej technologii/języka)
• odpowiednie podejście (z ang. "attitude") - jesteśmy tu przede wszystkim po to aby stworzyć świetny produkt w oparciu o zdrowe inżynierskie praktyki, a nie po to aby spróbować wszystkich możliwych wzorców projektowych, bezkrytycznie użyć każdej nowinki znalezionej w Internecie, itp.
• umiejętność pracy w autonomicznym zespole - aktywne słuchanie, wola wnikania w zagadnienia domenowe (biznesowe), otwartość na pomysły i propozycje, wspólna odpowiedzialność za sukcesy i porażki
• pasja do technologii i chęć rozwoju - przykładowo: nie musisz znać Elixira, my Cię go z chęcią nauczymy, naprawdę :) Ale to się nie wydarzy "magicznie" albo "przez osmozę" :> - przede wszystkim sam(a) musisz tego chcieć i również włożyć w to odpowiednią dozę (niemałą!) wysiłku

Miało być krótko ...

... a wyszło jak zwykle.

Nie wyczerpałem tematu - mógłbym jeszcze sporo napisać na temat naszych kontrybucji Open Source (https://github.com/surgeventures), aktywności w developerskim community (m.in. warsaw.js, WRUG) - jako sponsorzy, prelegenci i sympatycy, ale ...

... może podejdźmy do tego inaczej:

Jeśli udało mi się Ciebie zainteresować, zaaplikuj do nas lub po prostu się do mnie odezwij - przez Twittera, LinkedIn, mailowo, na którymś z meet-upów lub konferencji. Część danych kontaktowych jest na tej stronie, pozostałe nietrudno wygooglać :> Porozmawiajmy, będziesz mieć okazję żeby zadać pytania, jest możliwość zaproszenia do nas do firmy - żeby zobaczyć jak wygląda planowanie, development, prezentacja inkrementu produktu.

Zapraszam. Naprawdę warto.