Wiza sprawia, że mamy mniejszy wybór. Historia Marka Publicewicza

Marek Publicewicz, senior z osiemnastoletnim doświadczeniem, o wizę H1B starał się mniej więcej od 2013 roku. W latach 2012-2017 znajdował pracodawców, którzy złożyli w sumie 10 wniosków. – Dopiero w 2017 roku JEDEN z nich został wylosowany. Przy czym po wylosowaniu został zakwestionowany, co oznaczało kolejną pracę prawnika na udokumentowaniu, dlaczego to konkretne stanowisko wymaga takich i takich umiejętności – mówi.

Z Markiem rozmawialiśmy o problemach z wizami, o tym dlaczego amerykańskie firmy wolą pracę w biurze od pracy zdalnej oraz o tym, kim dzisiaj jest senior developer.

Masz osiemnaście lat doświadczenia w branży. To znaczy, że możesz przebierać w ofertach, a rekruterzy biją się o możliwość zatrudnienia Ciebie?

Dostaję sporo wiadomości od rekruterów na Linkedin, ale wiem, że z ich punktu widzenia to gra na statystykę. Wysyłają wiadomości do stu ludzi licząc na to, że 5-8% okaże się ”trafione”. Zatem nie jarałbym się liczbą wiadomości od rekruterów.

Ale lata doświadczenia robią swoje, prawda?

Same lata doświadczenia też niewiele mówią – można robić to samo przez 18 lat i zmieniać pracę/projekt co rok. Pozostaje więc opis umiejętności, znajomość technologii itp., ale to też się zmienia. Co z tego, że kiedyś głównie pracowałem z Perlem, skoro dziś to niewiele mówi.

Poza tym uważam, że ciekawej/odpowiedniej pracy nikt Ci nie da i sama nie przyjdzie; zamiast czekać na rekruterów, trzeba i warto uderzać bezpośrednio do firm, które Cię interesują.

Przejdźmy do Twojej ścieżki kariery. Jak to się stało, że zacząłeś pracę dla zagranicznych firm?

Jakieś 15 lat temu “odkryłem”, że pracując z Polski zdalnie dla firm z USA można zarobić kilkakrotnie razy więcej, niż dla najlepszych firm w Polsce. Kultura pracy też wydawała się nieco lepsza, więc to stało się dla mnie kolejnym kryterium (oferta z Polski? Nie, dziękuję). Choć od paru lat ta różnica się zmniejsza i bardzo się z tego cieszę – powoli przestajemy być tanią siłą roboczą “dla zagranicy” i stajemy się coraz bardziej postrzegani jako “wykwalifikowana siła robocza”.

Pracodawcy w Stanach zwracają uwagę na narodowość programistów?

Teoretycznie nie powinni, ale moim zdaniem tak robią. Zaobserwowałem różne poziomy i powody. W firmie, z którą współpracowałem kilka lat temu, była zdecydowana preferencja na zatrudnianie “obcokrajowców” (czyli formalnie: ex-studentów, którym kończyła się wiza studencka F1, “specjalistów” na wizę H1B albo J1, jako pewna furtka dookoła ograniczeń wokół systemu regulującego przydział wiz H1B). Oficjalnie tłumaczyli to tym, zależało im na “różnorodności”, ale moim zdaniem powody były stricte ekonomiczne.

Ekonomiczne, czyli jakie?

Osoba “na wizie” ma ograniczone pole wyboru co do zmiany pracodawcy, więc taki pracownik jest “bezpieczniejszy”, bo raczej tak łatwo nie odejdzie (jak osoba ze stałym/swobodnym prawem pracy). Małe szanse ma zwłaszcza w miejscu takim jak Dolina Krzemowa, gdzie cały czas trwa “wojna o talent”. Zwykle takie osoby są bardziej pracowite, mają też mniejsze wymagania, co do płacy i standardów/wygody życia, czyli można powiedzieć, że są ”bardziej głodne”. Taki model wpisuje się trochę w historię USA, która było budowana na emigrantach szukających “lepszego życia”.

Podejście, o którym wspominasz dotyczy zwykle dużych firm?

Widzę tę strategię również w obecnej firmie, która jest 10x mniejsza, ale założyciel – imigrant – również wychodzi z założenia, że “nie-amerykanom bardziej się chce”. I jest to ciekawy model samoregulacji, w świecie teoretycznie zdominowanym przez wygodę i nadmierną konsumpcję.

Niezależnie od tego, na pewno funkcjonują tu stereotypy związane stricte z krajem pochodzenia: my + inni mieszkańcy Europy Wschodniej/Środkowo-Wschodniej. Mamy bardzo dobrą opinię, zarówno jeśli chodzi o “talent”, jak i o “pracowitość”.

W jaki sposób uzyskałeś wizę na pobyt i pracę w USA?

Po pierwsze, pozyskanie wizy rozpoczyna się od znalezienia pracodawcy, który złoży wniosek o wizę H1B (jeśli mówimy o wizie dla specjalisty w dziedzinie iT) i pokryje koszty, czyli min. ustawowe ~$1,500. Wizy procesowane są raz do roku, poczynając od 1. kwietnia. Kruczek polega na tym, że USA co roku “wpuszcza” limitowaną liczbę osób na tej wizie – 65 tys. osób + 20 tys. z tytułem magistra z uczelni w USA. I od 2012 roku liczba chętnych (czytaj: złożonych wniosków) przekracza tę sumę, więc urząd imigracyjny robi losowanie/loterię.

Loterię? Co to znaczy?

Jeśli liczba otrzymanych wniosków w pierwszym tygodniu kwietnia przekroczy limit, Ambasada przestaje je przyjmować po 5 roboczodniach. A następnie robi (podobno) komputerowe losowanie – również zakładając, że jakiś % wniosków zostanie odrzucony z przyczyn formalnych.

Oznacza to tyle, że nawet jeśli znalazłeś pracodawcę, to w 2019 roku miałeś jakieś 65,000/201.000 szansy na to, że Twój wniosek zostanie wylosowany i będzie dalej procesowany, czyli sprawdzany pod kątem poprawności formalne, jak i “weryfikacji” danej oferty pracy, stanowiska itp.

Jak wyglądał zatem proces pozyskania wizy do USA w Twoim przypadku?

U mnie wyglądało to tak, że o tę wizę starałem się mniej więcej od 2013 roku. I w latach 2012-2017 znajdowałem pracodawców, którzy złożyli w sumie 10 wniosków (w 2015 miałem trzech niezależnych pracodawców i trzy wnioski), dopiero w 2017 JEDEN z nich został wylosowany. Przy czym po wylosowaniu został zakwestionowany, co oznaczało kolejną pracę prawnika na udokumentowaniu, dlaczego to konkretne stanowisko wymaga takich i takich umiejętności.

Plusem wizy H1B (w porównaniu do np. L1 albo J1) jest to, że mimo, iż jest przywiązana do konkretnego pracodawcy, to w każdej chwili możesz znaleźć nowego pracodawcę, który może wystąpić i nową wizę H1B. I jeśli jesteś już ”w systemie”, to nie ma loterii ani procesowania raz do roku. Taki nowy wniosek jest przetwarzany od ręki, przy czym oczywiście może zostać odrzucony. Oznacza to też, że możesz mieć dwóch pracodawców jednocześnie (np. 2 x H1B na pół etatu), nie ma tu prawa “wyłączności”. Jednak nadal kluczem pozostaje “wylosowanie”, na co niestety nie mamy wpływu.

Być może dlatego wiele firm z USA otwiera się na pracę zdalną?

Wydaje mi się, że jest odwrotnie. Firmy z USA bardzo dużą wagę, co prawdopodobnie jest pochodną systemu edukacji, przykładają do pracy zespołowej. A idąc tym tropem, w 90% miejsc ludzie uważają, że nic nie zastąpi spontanicznej i naturalnie łatwej komunikacji w obrębie jednego biura. Oczywiście znajdziemy dużo wyjątków/firm 100% opartych na pracy zdalnej, ale według moich doświadczeń większość firm z USA sięga po pracowników zdalnych z konieczności, a nie z wyboru.

W jaki sposób oceniasz dzisiaj przysyłane oferty? Które odrzucasz od razu, a które zachowujesz “na później”?

Od ponad 10 lat nie rozważałem pójścia “do pracy” – wyjątek zrobiłem dopiero w tym roku, co związane było z istotną zmianą w moim życiu (przeprowadzką do USA). Nawet teraz, po jakichś trzech miesiącach szukania pracy uznałem, że jednak odpuszczam i nagle pojawiła się oferta z miejsca, w którym dzisiaj pracuję. A w czym okazała się ”dobra”? Po pierwsze zaważyła lokalizacja, po drugie nietuzinkowy właściciel/szef, po trzecie budowanie czegoś praktycznie od zera (a co za tym idzie: mała struktura, zerowa biurokracja i środowisko pracy zorientowane na wyniki, a nie politykę) i po czwarte atrakcyjne wynagrodzenie.

Jak wyglądał proces rekrutacji do Skool.com, czyli do firmy, w której dzisiaj pracujesz?

Proces był kilkuetapowy i nie do końca szablonowy. Pierwsza była ponad godzinna rozmowa z założycielem, która miała na celu sprawdzić ”dopasowanie kulturowe”. Następnie miałem rozmowę stricte techniczną, która nie poszła mi zbyt dobrze. Oryginalnie aplikowałem na stanowisko “backend engineer” i pomimo negatywnej rekomendacji po rozmowie technicznej, dostałem szansę na “sprawdzenie się” w kategorii frontend. Tutaj zamiast rozmowy dostałem zadanie napisania aplikacji przy użyciu React + Redux, pobierającej dane z istniejącego serwisu na co miałem 4h.

Jak zareagowałeś na tę propozycję?

Mimo że moja pierwsza myśl była “proste – zrobię!”, głównie ze względu na fakt, że w poprzednich projektach wykorzystywałem Reacta, to jednak siedziałem nad nim praktycznie do ostatniej minuty. I mimo że po wysłaniu nie byłem zadowolony, okazało się, że napisałem ją dużo lepiej, niż każdy z poprzednich kandydatów “frontendowych”. Później jeszcze była rozmowa z CTO odnośnie tego, co bym zmienił/dodał, gdybym miał więcej czasu, po czym finalne interview było już w “biurze”.

Ciekawostką jest to, że “biuro” w tamtym okresie oznaczało dom przy plaży, wynajmowany przez właściciela, z zaadaptowanym piętrem. Od paru miesięcy pracujemy już w “prawdziwym” biurze, które jednak nadal bardziej przypomina twórczą przestrzeń, niż nudne plastikowo-metalowe aranżacje.

Po przejściu rekrutacji i dołączeniu do zespołu stanąłem po drugiej stronie, czyli poza pracą “na bieżąco”, zająłem się rekrutacją do zespołu frontend. Wskazanie miałem jedno – zatrudnij osobę lepszą od siebie. Z perspektywy czasu nie wiem, czy jest to do końca dobrze postawiony cel, bo mimo wszystko każdy nosi w sobie pewne uprzedzenia (lubimy ludzi podobnych do siebie). Niemniej udało mi/nam prawie przekonać osobę, która pracowała kilka lat w Microsoft przy kompilatorze C#, na następnie w SpaceX – nadal rozmawiamy, ale jest duża szansa, że do nas dołączy.

Jak wygląda rzeczywistość seniora? Rzeczywiście ma “życie usłane różami”, czy to nadal ciężka i wyczerpująca praca?

Z całym szacunkiem do programistów i samego siebie, nie uważam, że jest to ciężka i wyczerpująca praca. Nie pracujemy w kopalni ani na pustyni, ani na platformie wiertniczej – siedzimy wygodnie w klimatyzowanych pomieszczeniach na nietanich fotelach przy nietanim sprzęcie i pracujemy “tylko” umysłowo.

Moim zdaniem największe wyzwanie “seniora” to umiejętność zdecydowania o tym:

1. Czy warto zrobić X?
2. Czego użyć do zrobienia X?
3. Jakie będą tego konsekwencje?

ale też:

4. Umieć doprowadzić X do końca.

Do tego dochodzi cały “warsztat”, więc znajomość konkretnych narzędzi, bibliotek i frameworków, robienie/nierobienie TDD, pisanie dokumentacji, ale moim zdaniem kluczowe są decyzje “czy” oraz “jak”, połączone z maksymalnym upraszczaniem tego, co się tworzy.

Ważny jest ostatni punkt – każdy potrafi “coś” zacząć, czy to w pracy, czy jakiś projekt hobbystyczny, być może open source. Ale jest duża różnica pomiędzy “zacząć” a “skończyć” i wydaje mi się, że pojęcie “seniora” mocno wpisuje się właśnie w tę umiejętność.

Przez te lata zrealizowałeś setki projektów. Które wbiły się Tobie najbardziej w pamięć?

Niestety te, które skończyły się porażkami, a kilka ich było. Na przykład kiedyś pracowałem przez 18 miesięcy przy “innowacyjnym i przełomowym” mobilnym kliencie do poczty – programowałem tam głównie backend, pisany w Railsach oraz nie-Railsowym Ruby, jak również pisałem kawałki natywnego klienta pod iOS (wówczas w Objective-C). Całość nadzorował gość, który przyjął taktykę ”wszystko albo nic” – zamiast podejścia iteracyjnego, gdzie produkt tworzony byłby “po kawałku” i testowany na mniejszej grupie użytkowników, zdecydował, że dnia X odpalimy (słabo przetestowaną) “całość”. I odpaliliśmy, licząc na szczęście, choć okazało się, że go nie mieliśmy. Całość poległa na nieodpowiedniej konfiguracji bazy danych, bez której nic poprawnie działać nie mogło. Inwestor się zdenerwował, zabrał pieniądze i był przykry finał.

Na podstawie jakich czynników określałeś kiedyś trudność danego zadania, a jak robisz to teraz?

Kiedyś z góry zakładałem, że potrafię zrobić wszystko, a jeśli czegoś nie umiem, to jestem w stanie się tego nauczyć. O dziwo dobrze się to sprawdzało, a przynajmniej przy zadaniach/projektach, które były na poziomie skomplikowania do ogarnięcia przez jedną osobę. Takie optymistyczno/agresywne podejście sprawdza się pod warunkiem, że ma się dużo czasu do siedzenia po nocach i nadrabiania zaległości w znajomości X i Y.

Jeszcze około roku 2000 “zakochałem się” w filozofii XP (extreme programming) Kenta Becka, która mocno powiązana była z tworzonym wówczas Agile. A to z definicji zakładało ograniczone planowanie – i tak podchodziłem do projektów, trochę na zasadzie “zróbmy to, co można teraz na podstawie obecnej wiedzy, a później zmienimy w miarę jak wiedza będzie się powiększać”. Niestety to podejście okazało się zgubne przy “większych” projektach – teraz staram się spędzać więcej czasu na ogólnym “planowaniu”, a może raczej zrozumieniu istoty problemu, namierzeniu miejsc “szczególnego ryzyka” (albo niepewności) i przygotowaniu kilku sposobów na ich rozwiązanie. Choć nadal uważam, że nadmierne planowanie może być zabójcze (bądź w najlepszym razie paraliżujące)

Ale często dochodzą czynniki nietechniczne; nauczyłem się, że ważne jest wyczucie klienta, jak również wczucie się w jego skórę i zrozumienie czego potrzebuje. Zdarza się, że mimo iż wiem, że potrafię jakiś problem rozwiązać, to na podstawie analizy “profilu klienta” odmawiam – wydaje mi się, że z czasem wypracowałem pewien obraz klienta idealnego i to również staram się brać pod uwagę.

Wielu seniorów staje przed decyzją o tym, czy dalej być engineerem, czy pójść w stronę managera, lidera. Ciebie nigdy ta ścieżka nie kusiła?

Nigdy. A raczej już dawno stwierdziłem, że dopóki mi się to nie znudzi i/albo nie będę w stanie utrzymać odpowiednio wysokiego poziomu – to chcę na co dzień zajmować się programowaniem, choć najchętniej połączonym z kontaktem z klientem/użytkownikiem i analizą wymagań. Więc może nie jest to taki czysty “engineer”, ale bardziej “konsultant” – mimo wszystko nadal oparty o programowanie i “tworzenie” niż jakiekolwiek zarządzanie.

Trzeba wiedzieć, albo umieć się dowiedzieć, co się chce w życiu robić. A potem zacząć to robić (cytując klasyka). Ale tak jest, jeśli chcesz być programistą, nie trać czasu na być-może-budowanie ścieżki managera, i odwrotnie. Idź na całość w tym, co czujesz, że Ci pasuje.

Senior z takim doświadczeniem powinien bez problemu znaleźć ”pracę marzeń”, czyli – według wielu, szczególnie juniorów – w korpo takim jak Facebook, Amazon czy Google. Dlaczego nie szukałeś pracy właśnie w takich miejscach?

Szukałem, ale zawsze odpadałem podczas rekrutacji. Może po prostu jestem za słaby, a może moje silne strony nie liczą się tak mocno w kontekście pracy w tych firmach. Odwracając pytanie, nie uważam tych firm za “pracę marzeń” – bezpośrednia praca “z klientem” i tworzenie rozwiązań pod jego wymagania daje dużą satysfakcję (pod każdym względem), a nie jest obarczona korporacyjnymi bolączkami (OKRs, procesy, rutynowe spotkania, procedury itp.). Bardzo cenię sobie też nienormowany czas pracy i brak konieczności codziennego siedzenia w i dojazdów do biura.

Często wspominasz o pracy bezpośrednio z klientem. Czego uczy poznawanie jego perspektywy projektu, który chcesz zrealizować?

Żeby dobrze wykonać robotę, czyli stworzyć narzędzie, które ma rozwiązać konkretny problem “biznesowy”, musisz spędzić odpowiednią ilość czasu na zrozumieniu, gdzie leży istota problemu i dlaczego nie została do tej pory rozwiązana (alternatywnymi gotowymi narzędziami, być może generycznymi typu Excel, Google Sheets czy Airtable). Oczywiście można próbować tę wiedzę uzyskać przez pośredników, ale z mojego doświadczenia to strata czasu, a przynajmniej mało efektywny sposób. Trzeba rozmawiać z osobą, która “czuje ból” i w efekcie tego wykłada pieniądze na to, co masz zrobić.

Z perspektywy czasu poleciłbyś wszystkim taką ścieżkę kariery jaką obrałeś? Czyli na początku praca w firmie produktowej, później realizacja zleceń jako freelancer, a teraz etat w startupie? Co daje, a co zabiera taki tryb pracy?

Poleciłbym taką ścieżkę osobom, które nie boją się ryzyka, lubią eksperymentować i wierzą w swoje umiejętności. Na pewno daje to ogromną wszechstronność – albo będziesz w stanie nauczyć się szybko wielu rzeczy – pewnie metodą prób i błędów, albo utoniesz. Na pewno równie istotna jest umiejętność zarządzania własnym czasem i stawiania priorytetów pod szybkie wyniki. Jeśli ktoś potrzebuje wskazówek “z góry” odnośnie tego, co powinien danego dnia robić, to pewnie lepszym miejscem jest korpo albo praca w software-housie.

Czuję się szczęściarzem, bo jeszcze w liceum wymarzyłem sobie, żeby “zarabiać pisząc programy na zlecenie”. I cel osiągnąłem po “zaledwie” 5-ciu latach.

Kiedy pierwszy raz poczułeś, że Twoje umiejętności są zadowalającym poziomie? Wiele osób po kursach programowania chce zrobić coś jeszcze, by zainteresować pracodawców. Jak wyglądał ten proces kilkanaście lat temu?

Do tej pory “aplikując” do projektów, a również do ostatniej pracy, wysłałem “próbki kodu”, a dodatkowo nagrałem screencasty pokazujące 2-3 aplikacje, nad którymi pracowałem. Więc to oznacza, że trzeba mieć ”coś”, co można pokazać – choć równie dobrze może być to jakiś projekt open source lub typowo “prywatny” projekt hobbystyczny. Kluczowe wydaje mi się zawsze to, że trzeba się wyróżnić i to nie zależy od poziomu zaawansowania. Jeśli jesteś ”seniorem”, to konkurujesz z innymi seniorami, jeśli juniorem, to z juniorami – tak czy inaczej musisz zrobić/powiedzieć/pokazać/napisać coś, co Cię wyróżni, to jedna z rzeczy, które musiałem się nauczyć, konkurując z freelancerami z całego świata.

Jednocześnie nie ma czegoś takiego jak “zadowalający poziom”. Jeśli wiesz, czego nie wiesz, to powinieneś ”zamknąć lukę” i się tego nauczyć albo douczyć. Nikt jednak nie umie wszystkiego, więc to co liczy się najbardziej, to umiejętność rozwiązywania problemów. Postaw się w sytuacji pracodawcy: on nie szuka ludzi, bo lubi zatrudniać lub jego hobby to “szukanie seniorów” czy “juniorów”. Zatrudnia, bo ma jakiś problem, który jest na dzień dzisiejszy nierozwiązany i uznał, że warto jest go rozwiązać. Szukając pracy, niezależnie od doświadczenia, musisz mu pokazać, że będziesz w stanie mu w tym pomóc. Tyle.

Marek Publicewicz. Frontend Engineer w Skool.com. Programowaniem zainteresował się jeszcze w podstawówce. W liceum poznał asembler, C i nieco C++. Na drugim roku studiów zaczął realizować komercyjne projekty. W 2005 roku zaczął realizować zlecenia głównie dla klientów z USA. Rok później po raz pierwszy zobaczył Kalifornię „od środka” i przez kolejnych dwanaście lat zdalnie realizował zlecenia dla firm i startupów z USA. Od roku mieszka w Hermosa Beach.

Oferty pracy z