CV .NET / C# Developera: jak opisać backend pod ofertę korpo

.NET to jeden z największych segmentów rynku korpo w Polsce. Banki, ubezpieczyciele, software house'y na zagranicznych kontraktach i duże systemy wewnętrzne bardzo często stoją na C# i ASP.NET Core. Ofert jest dużo, ale brzmią niemal identycznie: spis bibliotek prosto z .csproj. ASP.NET Core, Entity Framework Core, SQL Server, REST, Azure, do tego „mikroserwisy” i „chmura” jako słowa-wytrychy. Rekruter techniczny czyta to i robi w głowie checklistę. Potem otwiera twoje CV, w którym pod stanowiskiem stoi „.NET Developer”, a niżej dokładnie ta sama ściana logotypów, z której nie widać, czy ty te biblioteki kiedyś dotknąłeś, czy postawiłeś na nich system obsługujący ruch produkcyjny.

Na stanowisku backendowym w .NET nie chodzi o to, ile metod LINQ znasz na pamięć, tylko czy potrafisz zaprojektować serwis, który trzyma latencję pod kontrolą, nie zarzyna SQL Servera i da się go skalować, gdy ruch urośnie dziesięciokrotnie. Lista technologii tego nie pokaże, bo każdy kandydat na .NET ma identyczną. Pokaże to dopiero opis, w którym widać skalę, efekt twoich decyzji i konkretną liczbę za zapytaniem, a nie ogólnik „optymalizowałem wydajność”. Poniżej masz, co wyeksponować nad fold, jak opisać projekt przez wpływ na latencję, RPS i czas zapytania, i jak ustawić akcent między czystym backendem a fullstackiem z Blazorem albo Angularem.

Co wyeksponować nad fold: C#, .NET, baza, chmura

„Nad fold” to ta część CV, którą rekruter widzi bez przewijania. Pod ofertę .NET ma tam być widać cztery rzeczy: wersję C# i .NET, sposób pracy z bazą, to jak budujesz API i czy ruszasz się w chmurze. To rdzeń roli, reszta jest wsparciem. Ułóż umiejętności w kolejności istotności dla oferty, nie alfabetycznie:

• Rdzeń: C#, .NET (z wersją, np. .NET 8 albo 9), ASP.NET Core, Entity Framework Core, REST, SQL Server (albo PostgreSQL, ta z oferty na pierwszym miejscu).
• Realne wsparcie: Azure (App Service, Functions, Service Bus), Docker, testy (xUnit, NUnit, Moq), kolejki (Service Bus, RabbitMQ), cache (Redis), Dapper tam, gdzie liczy się surowy SQL.
• Reszta: narzędzia CI (Azure DevOps, GitHub Actions), monitoring (Application Insights), front jeśli dotyczy, niżej i mniejszą wagą.

Jeśli oferta wymienia technologię, której realnie używasz na produkcji, na przykład Azure Service Bus albo SQL Server, ma być widoczna od razu, nie zakopana między dwudziestą a trzydziestą pozycją. Rekruter w banku czy software house skanuje pod kątem zgodności z ogłoszeniem, nie kompletności twojej kariery. Wersja też ma znaczenie: „.NET Framework 4.7” i „.NET 8” to sygnał, w jakim kodzie się poruszasz i czy utrzymujesz wyłącznie legacy.

Jak opisać projekt efektem, nie zadaniem

To miejsce, gdzie większość CV .NET-owca się wykłada. Ludzie wypisują, co robili („pisałem kontrolery w ASP.NET Core”, „obsługiwałem bazę przez EF Core”), a to są obowiązki, nie dokonania. Nie widać skali ani tego, czy po twojej robocie cokolwiek działało szybciej. Pokaż zmianę i jej efekt, mierzony tym, co w backendzie się liczy: latencja, RPS, czas zapytania, rozmiar danych.

Słaby zapis, który czyta się jak zakres obowiązków:

Pisałem endpointy w ASP.NET Core i zajmowałem się komunikacją z bazą przez Entity Framework.

Ten sam fakt, ustawiony pod ofertę backendową:

Zaprojektowałem REST API w ASP.NET Core obsługujące 1500 RPS przy p99 poniżej 110 ms. Po zdiagnozowaniu problemu N+1 w EF Core, przepisaniu najcięższego zapytania na Dapper i dodaniu indeksów oraz cache w Redisie skróciłem czas najwolniejszego widoku z 900 ms do 50 ms na bazie SQL Server z 40 mln rekordów.

Druga wersja opisuje dokładnie to samo, co robiłeś, ale pokazuje punkt wyjścia, zmianę i efekt w liczbach. Widać skalę (1500 RPS, 40 mln rekordów), zmianę (eliminacja N+1, Dapper, indeksy, cache) i wpływ (z 900 do 50 ms). To odróżnia kogoś, kto sklejał kontrolery z tutoriali, od kogoś, kto rozumie, gdzie backend traci czas i pieniądze.

Mocne akcenty pod .NET i ich konkrety: latencja (p95, p99 w milisekundach), przepustowość (RPS, komunikaty na sekundę przez Service Bus), czas zapytania (z X do Y ms po optymalizacji EF Core albo przejściu na Dapper), skala danych (rozmiar bazy SQL Server, liczba rekordów), niezawodność (uptime serwisu w Azure, liczba błędów po refaktorze).

Backend .NET czy fullstack z Blazorem albo Angularem: ustaw akcent

W świecie .NET często jesteś gdzieś między czystym backendem a fullstackiem. Część ofert w bankach i ubezpieczeniach szuka kogoś, kto siedzi wyłącznie w API i bazie. Część software house'ów chce, żebyś dowiózł też front: Blazor po stronie .NET albo Angular jako osobny SPA spięty z twoim API. To dwa różne CV, choć stack rdzeniowy ten sam.

Czytaj, czego naprawdę chce ogłoszenie. Jeśli pada „backend”, „API”, „mikroserwisy”, „integracje”, zepchnij front niżej i wyeksponuj projektowanie serwisów, optymalizację zapytań i pracę z kolejkami. Jeśli pada „Blazor”, „Angular”, „fullstack”, pokaż konkretnie, co dowoziłeś po stronie front: ile widoków, jaka integracja z API, czy ruszałeś stan i routing. W obu wariantach to ten sam projekt, inny pierwszy plan, bez przepisywania historii. Jeden projekt zwykle daje materiał na kilka odcieni tej samej roli: backend produktowy, integracyjny, fullstackowy. Mechanikę pokazujemy w jeden projekt, cztery role.

Słowa kluczowe z ofert .NET

Oferty .NET w korpo powtarzają konkretny zestaw zwrotów: c#, .net (z wersją), asp.net core, entity framework core, rest api, sql server, azure, docker, microservices, ci/cd, dapper, redis, service bus, xunit albo nunit, blazor albo angular. To twoje słowa kluczowe. Wyciągnij must-have z konkretnej oferty i sprawdź, które masz pokryte realnym przykładem z projektu, a których lepiej nie wpisywać, bo zweryfikują je na rozmowie technicznej w pięć minut. Jak czytać ogłoszenie pod tym kątem, rozkładamy w jak wyciągnąć słowa kluczowe z oferty IT.

Mechanika jest ta sama, co w świecie Javy: rdzeń stacku zostaje stały, akcenty przestawiasz pod ogłoszenie. Jeśli pracujesz na styku obu ekosystemów, porównaj podejście w CV Java/Spring Developera. Rekruter pod backend nie szuka najdłuższej listy, tylko zgodności z must-have i dowodu w projektach.

Częste błędy

• Ściana NuGetów bez kontekstu. Trzydzieści logotypów ze świata .NET wrzuconych obok siebie nie mówi, czy stawiałeś na nich produkcję, czy przerobiłeś tutorial. Zostaw rdzeń, resztę podaj niżej i pokaż użycie w projektach z konkretnym efektem.
• Brak skali i metryk. „Optymalizowałem zapytania w EF Core” bez liczb jest puste. Baza na tysiąc rekordów to inna liga niż baza na 40 mln. Dopisz rozmiar danych, RPS, latencję przed i po. Bez liczby to deklaracja, nie dokonanie.
• Mieszanie .NET Framework z .NET bez rozróżnienia. Wrzucenie „.NET” bez wersji pozostawia rekrutera w niepewności, czy utrzymujesz wyłącznie legacy na Frameworku 4.x, czy pracujesz na .NET 8. Podaj wersje i pokaż, gdzie dotknąłeś nowszego stacku, choćby przy migracji.

Jak złożyć CV .NET w ZłóżCV

Pod ofertę .NET ZłóżCV bierze z twojej bazy projekty, w których realnie projektowałeś API, optymalizowałeś SQL Server i budowałeś serwisy w Azure, układa stack pod wymagania ogłoszenia i przepisuje opisy tak, żeby było widać skalę, efekt i decyzje architektoniczne, a nie samą listę bibliotek. Ustawia też akcent: czysty backend albo fullstack z Blazorem czy Angularem, zależnie od oferty. Wklejasz link, dostajesz dopasowane CV w PDF. Złóż CV pod ofertę .NET, dwa pierwsze za darmo, bez karty.

Najczęstsze pytania

Mam głównie ASP.NET Core i CRUD-y, jak pokazać coś więcej niż endpointy? Wyciągnij z tych CRUD-ów decyzje, które miały efekt: indeks, który skrócił zapytanie, przejście z EF Core na Dapper tam, gdzie liczył się czas, paginacja, która odciążyła SQL Servera. Nawet zwykły endpoint ma metrykę: ile rekordów obsługuje, jaki ma czas odpowiedzi. To zamienia „pisałem endpointy” w konkretny wpływ.

Wpisywać wersję C# i .NET? Tak. „.NET 8” i „C# 12” to sygnał, że pracujesz na aktualnym stacku, a nie utrzymujesz wyłącznie legacy na .NET Framework. Jeśli pracowałeś na starszych wersjach, nie kłam, ale pokaż też, gdzie dotknąłeś nowszych, choćby przy migracji z Frameworka na .NET.

Oferta wymaga Azure, a ja robiłem tylko on-premise, co wtedy? Nie dopisuj usług Azure, których nie dotykałeś, bo pytanie o Service Bus albo Functions wyłoży to na rozmowie. Pokaż pokrewne kompetencje: konteneryzację (Docker), kolejki, które znasz, pracę z CI/CD. Jeśli głęboka znajomość Azure jest twardym must-have, a ty siedziałeś wyłącznie on-premise, to po prostu nie jest oferta pod ciebie.

Profilować CV na backend czy fullstack? Pod konkretną ofertę, nie raz na zawsze. Jeśli ogłoszenie mówi „backend” i „API”, zepchnij front niżej i wyeksponuj serwisy i bazę. Jeśli mówi „Blazor” albo „fullstack”, podnieś front i opisz, co dowoziłeś po tej stronie. Ten sam projekt obsłuży oba akcenty.