TypeScript

Co piszą w ogłoszeniach

• „Good knowledge of HTML5, CSS3, JavaScript, and/or TypeScript.”

  emagine Polska · Frontend React Developer

• „Poszukujemy dwóch doświadczonych Front-End Engineerów, którzy chcą rozwijać nowoczesne aplikacje webowe z wykorzystaniem React, TypeScript, Vite oraz AWS Cloudscape.”

  Upvanta sp. z o.o. · Front-End Engineer (React / TypeScript / AWS)

• „praktyczna znajomość TypeScript – minimum 2 lata doświadczenia lub 3 projekty”

  Randlab · React Developer – (K/M/N)

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

1. 1

   type vs interface: czym się różnią w praktyce?

   Moja odpowiedź

   Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

   Pokaż odpowiedź

   Dla przedszkolaka: To dwa rodzaje etykiet. Etykietę „interface” można dokleić drugi raz i obie się połączą. Etykieta „type” umie za to opisać „albo to, albo tamto”.

   Na rozmowę: Oba opisują kształt obiektu. interface można rozszerzać przez extends i scalać przez ponowną deklarację (declaration merging), przydatne w bibliotekach i przy rozszerzaniu typów globalnych. type obsługuje unie, typy warunkowe, mapped types i tuple. W praktyce: type do unii i wyliczeń, interface do publicznych kształtów obiektów. Najważniejsze to być konsekwentnym w projekcie.

   Umiem? Nie Średnio Tak

   Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające Oceń moją odpowiedź
2. 2

   Jak napisać generyczny komponent lub hook (np. lista z dowolnym typem elementu)?

   Moja odpowiedź

   Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

   Pokaż odpowiedź

   Dla przedszkolaka: Generyk to pudełko z pustą etykietą, na której piszesz dopiero wtedy, gdy wiesz, co włożysz. Raz to klocki, raz cukierki, a pudełko pilnuje, żeby się nie pomieszały.

   Na rozmowę: function List<T>({ items, renderItem, getKey }: { items: T[]; renderItem: (item: T) => ReactNode; getKey: (item: T) => string }). T wnioskuje się z items, więc renderItem dostaje poprawny typ bez rzutowania. Ograniczenia przez extends, np. <T extends { id: string }>, gdy potrzebuję pola id. Tak samo hooki: useFetch<T>(url): { data: T | undefined }.

   Umiem? Nie Średnio Tak

   Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające Oceń moją odpowiedź
3. 3

   Union types i zawężanie (narrowing): jak modelować stany typu loading / success / error?

   Moja odpowiedź

   Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

   Pokaż odpowiedź

   Dla przedszkolaka: Sygnalizator ma kilka świateł. Gdy wiesz, że świeci „gotowe”, wiesz też, że w środku są cukierki. Gdy świeci „błąd”, w środku jest kartka z wiadomością.

   Na rozmowę: Discriminated union: { status: 'loading' } | { status: 'success'; data: T } | { status: 'error'; error: string }. Po sprawdzeniu status TS zawęża typ, więc data istnieje tylko w success i nie da się pokazać danych w stanie błędu. To lepsze niż trzy niezależne flagi isLoading/isError/data, które dopuszczają niemożliwe kombinacje. W switchu default z never wymusza obsłużenie każdego nowego stanu.

   Umiem? Nie Średnio Tak

   Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające Oceń moją odpowiedź
4. 4

   unknown vs any vs never: kiedy którego używasz?

   Moja odpowiedź

   Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

   Pokaż odpowiedź

   Dla przedszkolaka: any to pudełko bez etykiety, do którego wszystko wejdzie i nikt nie sprawdza. unknown to paczka od nieznajomego: najpierw zajrzyj, co jest w środku. never to pudełko, do którego nic nie wolno włożyć.

   Na rozmowę: any wyłącza sprawdzanie i zaraża resztę kodu, więc unikam go (ewentualnie przy migracji). unknown to bezpieczny odpowiednik: przyjmie wszystko, ale przed użyciem trzeba zawęzić typ (typeof, instanceof, schemat Zod). Dobre dla danych z zewnątrz i bloku catch. never to typ bez wartości: wynik funkcji, która zawsze rzuca, i narzędzie do exhaustive check w switchu.

   Umiem? Nie Średnio Tak

   Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające Oceń moją odpowiedź
5. 5

   Jak typować odpowiedzi z API, skoro TypeScript nie sprawdza ich w runtime? (Zod, walidacja)

   Moja odpowiedź

   Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

   Pokaż odpowiedź

   Dla przedszkolaka: Etykieta na pudełku znika, kiedy aplikacja trafia do ludzi. Paczkę z internetu trzeba więc sprawdzić ręcznie przy drzwiach, zanim wpuścisz ją do domu.

   Na rozmowę: Typy znikają po kompilacji (type erasure), więc „as User” na wyniku fetch to tylko obietnica. Na granicy systemu waliduję dane schematem, np. Zod: User = z.object({...}), a typ wyprowadzam przez z.infer<typeof User>. Wtedy jest jedno źródło prawdy, błędne dane wychodzą od razu w jednym miejscu, a nie jako undefined gdzieś w UI. Alternatywa to typy generowane z OpenAPI lub GraphQL.

   Umiem? Nie Średnio Tak

   Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające Oceń moją odpowiedź
6. 6

   Utility types: Partial, Pick, Omit, Record. Podaj realny przykład użycia.

   Moja odpowiedź

   Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

   Pokaż odpowiedź

   Na rozmowę: Partial<User> do formularza edycji lub patcha, gdzie każde pole jest opcjonalne. Pick<User, 'id' | 'name'> do lekkiego widoku listy. Omit<User, 'password'> do odpowiedzi publicznej albo Omit<ButtonProps, 'onClick'> przy wrapperze. Record<Status, string> do mapy etykiet: kompilator pilnuje, żeby każdy status miał tłumaczenie. Do tego ReturnType, Parameters i Awaited przy typach wyprowadzanych z funkcji.

   Umiem? Nie Średnio Tak

   Zapytaj Claude RozwińPrzepytaj mniePytania pogłębiające Oceń moją odpowiedź

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.