.NET Developer – 2nd Line Support (On-call / Standby)
Miquido
Jesteś doświadczonym programistą .NET pracującym w modelu dyżurów (on-call/standby), który zajmuje się drugą linią wsparcia technicznego w projekcie. Otrzymujesz zgłoszenia już po wstępnej analizie po stronie klienta, a Twoim zadaniem jest diagnoza i naprawa błędów w aplikacjach .NET, praca z REST API oraz bezpośrednia komunikacja z klientem. To rola wsparcia, a nie typowego developmentu nowych funkcji – główny nacisk kładzie się na reakcję na incydenty i ich rozwiązywanie.
Brak jawnych widełek — wynagrodzenie do ustalenia podczas rekrutacji.
Brakuje: brak informacji o przewidywanej liczbie dyżurów na miesiąc., nie podano średniego obciążenia pracą (liczba zgłoszeń tygodniowo)..
Jesteś doświadczonym programistą .NET pracującym w modelu dyżurów (on-call/standby), który zajmuje się drugą linią wsparcia technicznego w projekcie. Otrzymujesz zgłoszenia już po wstępnej analizie po stronie klienta, a Twoim zadaniem jest diagnoza i naprawa błędów w aplikacjach .NET, praca z REST API oraz bezpośrednia komunikacja z klientem. To rola wsparcia, a nie typowego developmentu nowych funkcji – główny nacisk kładzie się na reakcję na incydenty i ich rozwiązywanie.
- ✓Harmonogram dyżurów ustalany z wyprzedzeniem – przewidywalność.
- ✓Zgłoszenia są już wstępnie przeanalizowane przez klienta – to nie jest pierwsza linia wsparcia.
- ✓Nowoczesny stack technologiczny (ASP.NET Core, Docker, Redis, RabbitMQ).
- −Stawka za dyżur (180 PLN za dzień powszedni, 250 PLN za weekend) może być niska jak na 24-godzinną gotowość – warto dopytać o średnią liczbę godzin pracy podczas dyżuru.
- −Brak informacji o liczbie dyżurów w miesiącu – możliwe, że trzeba być dostępnym często.
- −Rola ma charakter wsparcia, a nie typowego developmentu – osoby nastawione na budowanie nowych funkcji mogą być rozczarowane.
- !Nie podano przewidywanego tygodniowego wymiaru pracy ani liczby zgłoszeń.
- !Brak informacji o wielkości zespołu i strukturze projektu.
- !Nie wspomniano o możliwości rozwoju lub przejścia do roli bardziej developerskiej w przyszłości.
- !Model on-call 24h może być uciążliwy – brak informacji o limitach czasu pracy.
- ?Brak jawnych widełek — wynagrodzenie do ustalenia podczas rekrutacji
- •Obsługa zgłoszeń serwisowych (2nd line support) – analiza i diagnoza problemów w aplikacjach .NET
- •Naprawianie błędów w istniejącym kodzie (bug fixing)
- •Praca z REST API – debugowanie i testowanie integracji
- •Współpraca z innymi deweloperami (backend, frontend, mobile) przy rozwiązywaniu problemów
- •Testowanie poprawności wdrożonych poprawek
- •Bezpośrednia komunikacja z klientem dotycząca zgłoszonych problemów
- •Dyżury on-call/standby według harmonogramu ustalanego z zespołem
- •Korzystanie z narzędzi monitorujących i logujących (jeśli występują)
Oferta skierowana do developerów z doświadczeniem komercyjnym (Mid).
Deweloper .NET z co najmniej 3-letnim stażem, który zna wymagane technologie (C#, ASP.NET Core, EF Core, SQL Server, Docker, Redis, RabbitMQ) i jest gotowy do pracy w systemie on-call. Brak doświadczenia w supportcie nie dyskwalifikuje, jeśli ma silne umiejętności techniczne.
Junior bez 3 lat doświadczenia, osoby szukające pełnego etatu i stabilnych godzin pracy, programiści preferujący rozwój nowych funkcji nad utrzymanie i wsparcie, oraz osoby nieakceptujące dyżurów pod telefonem.
- ?Ile średnio dyżurów w miesiącu ma jeden deweloper i jak wygląda rotacja?
- ?Jaki jest rzeczywisty średni czas pracy podczas dyżuru (liczba godzin spędzonych na rozwiązywaniu zgłoszeń)?
- ?Czy są jakieś okresy, w których dyżury są częstsze (np. wdrożenia)?
- ?Jak duży jest zespół developerski i ilu deweloperów jest zaangażowanych w support?
- ?Czy istnieje możliwość przejścia na pełny etat lub zmiany na bardziej rozwojową rolę w przyszłości?
- ?Jaki jest stosunek czasu spędzonego na bug fixing do czasu na rozwijanie nowych funkcji?
- ?Jakie narzędzia monitorujące i logujące są używane w projekcie?
- ?Czy na dyżurze trzeba być stale dostępnym przez 24h, czy są jakieś przerwy?
- −Brak informacji o przewidywanej liczbie dyżurów na miesiąc.
- −Nie podano średniego obciążenia pracą (liczba zgłoszeń tygodniowo).
- −Brak danych o zespole (liczba osób, role).
- −Nie wspomniano o procesie rekrutacyjnym (etapy, rozmowy, testy).
- −Nie podano, czy istnieje okres wdrożeniowy lub szkolenie z projektu.
Zespół składa się z programistów i koordynatora (PM), panuje bezpośrednia komunikacja z klientem. Kultura pracy opiera się na wzajemnym ustalaniu harmonogramów i klarownym raportowaniu dostępności.