class to typ referencyjny, a struct to typ wartościowy.

W praktyce oznacza to różne zachowanie przy kopiowaniu i przekazywaniu do metod.

Na rozmowie warto dodać, że struct ma sens dla małych, prostych danych bez złożonej logiki i bez potrzeby dziedziczenia klasowego.

Ogólna zasada jest podobna do innych języków .NET: == i .Equals() mogą zachowywać się inaczej zależnie od typu i przeciążenia operatora.

Na rozmowie najlepiej powiedzieć, że trzeba rozumieć semantykę konkretnego typu (value vs reference, custom equality) oraz pamiętać o spójności z GetHashCode().

String w C# jest niemutowalny, więc każda „modyfikacja” tworzy nowy obiekt.

Na rozmowie warto powiedzieć, że to poprawia bezpieczeństwo i przewidywalność, ale przy wielu operacjach składania tekstu lepiej użyć StringBuilder.

GC w .NET automatycznie zarządza pamięcią obiektów i usuwa te, do których nie ma już referencji.

Na rozmowie ważne jest zrozumienie, że GC nie zwalnia z dbania o zasoby niezarządzane (np. pliki, połączenia), dlatego używa się IDisposable i using.

IDisposable służy do jawnego zwalniania zasobów, które nie są zarządzane automatycznie przez GC (np. uchwyty, streamy, połączenia).

using gwarantuje wywołanie Dispose(), nawet gdy pojawi się wyjątek.

To bardzo praktyczny temat rekrutacyjny, bo pokazuje czy rozumiesz różnicę między pamięcią zarządzaną a zasobami systemowymi.

async/await upraszcza pracę z asynchronicznością i pozwala pisać kod, który wygląda jak synchroniczny, ale nie blokuje wątku podczas oczekiwania.

Na rozmowie warto podkreślić, że to nie „tworzenie nowego wątku”, tylko wygodny model pracy z zadaniami (Task).

Thread to niskopoziomowy wątek systemowy, a Task to wyższy poziom abstrakcji do pracy asynchronicznej i współbieżnej.

W praktyce aplikacyjnej częściej używasz Task/Task<T> niż ręcznego zarządzania wątkami.

Na rozmowie dobra odpowiedź: wybieram wyższy poziom abstrakcji, chyba że mam szczególny powód zejść niżej.

ConfigureAwait(false) mówi, że po await nie trzeba wracać do oryginalnego kontekstu synchronizacji.

To bywa ważne w bibliotekach i starszych typach aplikacji UI/ASP.NET, gdzie niepotrzebny powrót do kontekstu może powodować problemy lub narzut.

Na rozmowie warto zaznaczyć, że decyzja zależy od kontekstu aplikacji, a nie jest regułą \"wszędzie zawsze\".

LINQ pozwala pisać zapytania do kolekcji w stylu deklaratywnym (filtrowanie, mapowanie, grupowanie itp.).

Na rozmowie warto zaznaczyć, że LINQ poprawia czytelność, ale trzeba rozumieć kiedy wykonanie jest odroczone (deferred execution) i jaki to ma wpływ na wydajność.

IEnumerable zwykle oznacza operacje wykonywane w pamięci na kolekcji, a IQueryable pozwala budować zapytania, które mogą zostać przetłumaczone np. na SQL przez ORM.

To częsty temat w kontekście Entity Framework.

Na rozmowie warto pokazać, że rozumiesz gdzie wykonywana jest logika: po stronie aplikacji czy bazy.

Dependency Injection to przekazywanie zależności do klasy z zewnątrz zamiast tworzenia ich wewnątrz.

W .NET (szczególnie ASP.NET Core) to standardowy sposób budowania testowalnych i luźno powiązanych komponentów.

Na rozmowie dobrze podać przykład serwisu zależnego od repozytorium i wspomnieć o rejestracji w kontenerze DI.

Interfejs definiuje kontrakt, a klasa abstrakcyjna pozwala dodatkowo współdzielić implementację i stan.

Na rozmowie dobra odpowiedź to kontekst użycia: interfejs do ról/umów między komponentami, abstract class gdy masz wspólne zachowanie i bazową implementację.

C# używa wyjątków do obsługi błędów i sytuacji wyjątkowych. try obejmuje kod ryzykowny, catch obsługuje wyjątek, a finally służy do cleanupu.

Na rozmowie warto podkreślić, że łapiemy konkretne typy wyjątków i nie ukrywamy błędów bez logowania.

Entity Framework to ORM dla .NET, który mapuje obiekty na tabele bazy danych i ułatwia pracę z danymi.

Na rozmowie warto powiedzieć pragmatycznie: przyspiesza development CRUD i integrację z bazą, ale trzeba rozumieć generowany SQL i uważać na wydajność zapytań.

record to wygodny typ do modelowania danych (szczególnie immutable), z sensowną semantyką porównywania po wartościach.

Na rozmowie warto wspomnieć, że świetnie nadaje się do DTO i modeli danych, gdy ważna jest czytelność i mniejszy boilerplate.

Nullable reference types pomagają ograniczyć błędy typu NullReferenceException przez lepsze modelowanie intencji w kodzie.

Zamiast traktować wszystko jako potencjalnie null, jawnie oznaczasz co może być null, a co nie.

Na rozmowie warto powiedzieć praktycznie: to nie jest magia runtime, tylko wsparcie kompilatora i lepsza jakość kodu.

yield return pozwala tworzyć sekwencje zwracane element po elemencie bez budowania całej kolekcji od razu.

To jest przydatne przy dużych zbiorach danych i leniwej iteracji.

Na rozmowie warto połączyć to z ideą iteratorów i oszczędności pamięci.

delegate to typ reprezentujący referencję do metody, a event to mechanizm oparty o delegaty, który kontroluje sposób subskrypcji/wywołania.

W praktyce event używasz do publikowania zdarzeń, a delegaty są podstawą techniczną tego mechanizmu.

Na rozmowie dobra odpowiedź pokazuje, że rozumiesz wzorzec publisher-subscriber, a nie tylko składnię.

Middleware w ASP.NET Core to łańcuch komponentów, przez które przechodzi request i response.

Każdy middleware może coś zrobić przed i po wywołaniu następnego elementu, albo przerwać pipeline i zwrócić odpowiedź od razu.

Na rozmowie warto podać przykłady: logging, auth, exception handling, routing.

Najczęściej zaczyna się od testów jednostkowych dla logiki biznesowej: warunki, walidacje, edge casey i zachowanie metod.

Na rozmowie warto powiedzieć, że testujesz to, co daje wartość i stabilność, a zależności zewnętrzne izolujesz mockami/stubami tam, gdzie ma to sens.

Dobra odpowiedź to też rozróżnienie testów unit, integration i e2e zamiast wrzucania wszystkiego do jednego worka.