Najpopularniejsze pytania rekrutacyjne z TypeScript (z odpowiedziami)

Rozmowa techniczna z TypeScript rzadko jest egzaminem z całej dokumentacji. Najczęściej to te same kilkanaście tematów, przy których rekruter sprawdza, czy rozumiesz, co kompilator robi za ciebie, a czego nie robi wcale. Poniżej znajdziesz pytania, które wracają na rozmowach na stanowisko juniora, razem z tym, jak na nie odpowiadać. Jeśli zastanawiasz się jeszcze, czy w ogóle warto zacząć, najpierw przeczytaj, dlaczego TypeScript jest dobrym krokiem po JavaScript, a ten tekst potraktuj jako listę kontrolną. Pytania o sam język (closures, this, Promise) są w artykule o pytaniach rekrutacyjnych z JavaScript, bo na rozmowie z TypeScript prawie zawsze padają obok tych z TypeScript.

Przykłady z tego artykułu skompilowaliśmy w TypeScript 5.6.3 z włączonym trybem strict, dlatego komunikaty błędów w komentarzach to faktyczne komunikaty kompilatora, a nie zgadywanie.

Jak odpowiadać na pytania rekrutacyjne z TypeScript?

Najlepiej w trzech krokach: jedno zdanie definicji, krótki przykład (kilka linijek kodu albo sytuacja z projektu) i informacja, kiedy to ma znaczenie w praktyce. Taka odpowiedź zajmuje 30–60 sekund i pokazuje, że rozumiesz mechanizm, a nie wkułeś formułkę. Jeśli czegoś nie wiesz, powiedz, co wiesz, i rozumuj na głos. Rekruterzy oceniają sposób myślenia, a nie tylko wynik.

Pytania są ułożone od podstaw do tematów, które częściej pojawiają się przy ofertach na mid-poziom.

Podstawy TypeScript

Czym jest TypeScript i czym różni się od JavaScript?

TypeScript to nadzbiór JavaScript, który dodaje statyczne typowanie: typy wartości sprawdza kompilator, zanim kod trafi do przeglądarki lub na serwer. Każdy poprawny kod JavaScript jest poprawnym kodem TypeScript, ale nie odwrotnie. Przeglądarka i Node.js nie uruchamiają TypeScript wprost. Kod jest najpierw kompilowany (a dokładniej transpilowany) do zwykłego JavaScript. Zysk to błędy wychwycone w edytorze, a nie u użytkownika, lepsze podpowiedzi i bezpieczniejsze zmiany w dużym kodzie.

Po co w ogóle są typy, skoro kod i tak działa?

Bo największym kosztem w projektach nie jest pisanie kodu, tylko jego zmiana i szukanie błędów. Typy działają jak umowa: funkcja mówi, co przyjmuje i co zwraca, a kompilator pilnuje, żeby nikt jej nie złamał. Gdy zmienisz nazwę pola w obiekcie, kompilator wskaże każde miejsce, które przestało działać. W JavaScript dowiedziałbyś się o tym dopiero w czasie uruchomienia. Dobrą odpowiedzią jest przykład z życia, np. literówka w nazwie pola, która w TypeScript jest błędem w edytorze.

Czy typy istnieją po uruchomieniu programu?

Nie. Typy są usuwane podczas kompilacji i w wynikowym JavaScript ich nie ma (ang. type erasure). Konsekwencje wracają w wielu pytaniach: nie możesz sprawdzić typeof na typie ani zrobić instanceof na interface. Nasz test:

type Id = number;

if (typeof Id === "string") {}
// error TS2693: 'Id' only refers to a type, but is being used as a value here.

Wniosek, który rekruter chce usłyszeć: kompilator sprawdza kod, który napisałeś, ale nie sprawdza danych, które przyjdą w czasie działania (z API, formularza, localStorage). O tej pułapce jest też osobne pytanie niżej.

Co to jest inferencja typów i czy trzeba wszędzie pisać typy?

Inferencja (type inference) to wnioskowanie typu przez kompilator z wartości, np. const count = 3 ma typ number, więc nie musisz pisać const count: number = 3. Typy pisze się jawnie (type annotation) tam, gdzie kompilator nie ma skąd ich wziąć: w parametrach funkcji, w publicznych interfejsach modułów i przy pustych strukturach (const items: string[] = []). Zwracany typ funkcji często można pominąć, ale w kodzie, który ktoś będzie czytał jako dokumentację, jawny zapis bywa lepszy. Słaba odpowiedź: „wszędzie, bo bezpieczniej”. Dobra: „tam, gdzie kompilator nie wywnioskuje, i na granicach modułów”.

Jakie są podstawowe typy w TypeScript?

string, number, boolean, null, undefined, tablice (string[] lub Array<string>), krotki (tuple, np. [string, number]), obiekty, funkcje oraz typy specjalne any, unknown, void i never. Tuple to tablica o stałej długości i znanych typach na poszczególnych pozycjach: próba przypisania ["a", "b"] do [string, number] kończy się błędem Type 'string' is not assignable to type 'number'.

any, unknown i never

Czym różni się any od unknown?

any wyłącza sprawdzanie typów: możesz zrobić z taką wartością cokolwiek i kompilator nic nie powie. unknown oznacza „nie wiem, co to jest”: przypisać do niego możesz wszystko, ale zanim użyjesz wartości, musisz ją zawęzić (sprawdzić jej typ).

let a: any = "tekst";
a.toFixed(); // brak błędu w kompilacji, błąd dopiero w czasie działania

let k: unknown = "tekst";
k.toUpperCase();
// error TS18046: 'k' is of type 'unknown'.

if (typeof k === "string") {
  k.toUpperCase(); // OK, w tym bloku k jest stringiem
}

Rekruter chce usłyszeć, że unknown jest bezpieczną wersją any: wymusza sprawdzenie, zamiast je pomijać. Dlatego dane z zewnątrz typuje się jako unknown, a any zostawia na naprawdę wyjątkowe sytuacje. Z tym tematem wiąże się częsty komunikat o niejawnym any, który opisujemy w artykule o błędzie implicitly has an any type.

Czym różni się void od never?

void oznacza, że funkcja nie zwraca żadnej użytecznej wartości (np. loguje coś i kończy się normalnie). never oznacza, że funkcja w ogóle nie dochodzi do końca (zawsze rzuca wyjątek albo działa w nieskończoność) albo że dana gałąź kodu jest nieosiągalna. never przydaje się przy sprawdzaniu, czy obsłużyłeś wszystkie przypadki; pokazujemy to niżej, przy typach unijnych.

Jak typować zmienną w bloku catch?

W trybie strict zmienna w catch ma typ unknown, bo w JavaScript rzucić można dowolną wartość, nie tylko Error. Przed użyciem message trzeba więc sprawdzić, co złapałeś:

try {
  throw new Error("coś poszło nie tak");
} catch (e) {
  console.log(e instanceof Error ? e.message : String(e));
}

interface, type i typy złożone

Czym różni się interface od type?

To jedno z najczęstszych pytań. Oba opisują kształt obiektu i w większości zastosowań są wymienne. Różnice, które warto znać:

Scalanie widać w teście: dwa interface User z różnymi polami dały jeden typ z oboma polami, a dwa type Point o tej samej nazwie dały error TS2300: Duplicate identifier 'Point'.

interface User { id: number }
interface User { name: string }
const u: User = { id: 1, name: "Ala" }; // OK, pola się scaliły

type Point = { x: number };
type Point = { y: number };
// error TS2300: Duplicate identifier 'Point'.

Dobra odpowiedź nie rozstrzyga „który jest lepszy”, tylko podaje regułę: interface dla kształtu obiektów i kontraktów klas (zwłaszcza w bibliotekach, gdzie ktoś może chcieć je rozszerzyć), type dla unii, krotek i typów wyliczanych. W zespole ważniejsza od wyboru jest konsekwencja.

Co to są typy unijne i literalne?

Typ unijny (union) mówi, że wartość może mieć jeden z kilku typów: string | number. Typ literalny zawęża typ do konkretnych wartości: "admin" | "user". Razem dają bezpieczne odpowiedniki list stałych: próba przypisania "boss" do typu "admin" | "user" kończy się błędem Type '"boss"' is not assignable to type 'Role2'. Z wartością o typie unijnym możesz zrobić tylko to, co jest dozwolone dla wszystkich wariantów, dopóki jej nie zawęzisz.

Co to jest zawężanie typów (type narrowing)?

To przejście od szerokiego typu do węższego dzięki sprawdzeniu w kodzie. Kompilator rozumie typeof, instanceof, porównania, in oraz własne funkcje sprawdzające (type guards).

function f(x: string | number) {
  return x.toFixed();
  // error TS2339: Property 'toFixed' does not exist on type 'string | number'.
}

function g(x: string | number) {
  if (typeof x === "number") return x.toFixed(); // tu x to number
  return x.toUpperCase(); // tu x to string
}

Co to są unie rozłączne (discriminated unions) i po co jest never?

Unia rozłączna to unia obiektów ze wspólnym polem-znacznikiem (np. kind), po którym kompilator rozpoznaje wariant. Połączona z never daje sprawdzenie kompletności: jeśli dodasz nowy wariant i zapomnisz go obsłużyć, kod się nie skompiluje.

type Shape =
  | { kind: "circle"; r: number }
  | { kind: "square"; a: number }
  | { kind: "tri"; b: number };

function area(shape: Shape): number {
  switch (shape.kind) {
    case "circle": return Math.PI * shape.r ** 2;
    case "square": return shape.a ** 2;
    default: {
      const unreachable: never = shape;
      // error TS2322: Type '{ kind: "tri"; b: number; }' is not assignable to type 'never'.
      return unreachable;
    }
  }
}

Błąd w tym teście pokazuje dokładnie, który wariant pominęliśmy (tri). To dobry przykład z życia, bo wskazuje wartość typów, a nie tylko ich definicję.

Czym różni się enum od typu unijnego z literałów?

enum tworzy obiekt w czasie działania, więc zostaje w wynikowym JavaScript, a typ unijny z literałów znika po kompilacji. Numeryczny enum ma jeszcze pułapkę: tworzy mapowanie w obie strony. Nasz enum Role { Admin, User } dał w runtime Object.keys(Role) równe ['0', '1', 'Admin', 'User'], więc przy iteracji po wartościach dostajesz podwójną listę. Popularna alternatywa to obiekt z as const i typ wyliczony z niego:

const Status = { Active: "active", Blocked: "blocked" } as const;
type Status = (typeof Status)[keyof typeof Status]; // "active" | "blocked"

const st: Status = "active";

Rekruter nie oczekuje, że zakażesz enumów. Chce usłyszeć, że znasz koszt (kod w runtime, dwukierunkowe mapowanie liczb) i że wiesz, czym je zastąpić.

Wartości puste i tryb strict

Co robi tryb strict i dlaczego warto go włączyć?

"strict": true w tsconfig.json włącza grupę restrykcyjnych sprawdzeń, m.in. strictNullChecks (wartości null i undefined nie pasują do innych typów) i noImplicitAny (zakaz domyślnego any). Bez tego TypeScript łagodnie przepuszcza wiele błędów, więc trudno nazwać go wtedy bezpiecznym. W nowych projektach strict jest standardem, a w starszych włącza się go stopniowo, flagę po fladze.

Jak działa strictNullChecks i skąd błąd „possibly undefined”?

Przy włączonym strictNullChecks typ string nie obejmuje undefined. Jeśli funkcja przyjmuje string | undefined, musisz obsłużyć brak wartości, zanim jej użyjesz:

function len(s: string | undefined) {
  return s.length;
  // error TS18048: 's' is possibly 'undefined'.
}

function len2(s?: string) {
  return s?.length ?? 0; // opcjonalne wywołanie i wartość domyślna
}

Operator ?. zwraca undefined zamiast błędu, gdy po lewej jest null lub undefined, a ?? podstawia wartość domyślną tylko dla null i undefined (w odróżnieniu od ||, który reaguje też na 0 i pusty napis). Pytanie uzupełniające dotyczy operatora ! (non-null assertion): mówi kompilatorowi „zaufaj mi, tu nie ma undefined”, ale niczego nie sprawdza. Jeśli się mylisz, błąd wyskoczy w czasie działania. Dobra odpowiedź: używam go oszczędnie, a zwykle zastępuję prawdziwym sprawdzeniem.

Dlaczego element tablicy nie jest „możliwe undefined”?

Domyślnie items[5] ma typ string, nawet jeśli tablica ma dwa elementy. Kod const len: number = items[5].length kompiluje się, a w czasie działania zwraca błąd. Dopiero flaga noUncheckedIndexedAccess (nie wchodzi w skład strict) zmienia typ takiego odczytu na string | undefined, co w naszym teście skończyło się błędem 'x' is possibly 'undefined'. To dobry przykład rozbieżności między tym, co mówi kompilator, a tym, co dzieje się w runtime.

Generyki i utility types

Co to są generyki i po co się je stosuje?

Generyki (generics) pozwalają napisać funkcję lub typ działający dla wielu typów bez utraty informacji o nich. Zamiast any używasz parametru typu T, który kompilator ustala na podstawie argumentów:

function first<T>(arr: T[]): T | undefined {
  return arr[0];
}

const n = first([1, 2, 3]);   // number | undefined
const s = first(["a"]);       // string | undefined
const bad: string = first([1]);
// error TS2322: Type 'number | undefined' is not assignable to type 'string'.

Gdybyśmy napisali first(arr: any[]): any, wynik byłby any i kompilator nie zauważyłby błędu w ostatniej linii. To jest odpowiedź na pytanie „czym generyk różni się od any”: zachowuje informację o typie.

Jak ograniczyć generyk i do czego służy keyof?

Ograniczenie (extends) zawęża, jakie typy są dozwolone. keyof T zwraca unię nazw pól typu T. Razem pozwalają bezpiecznie odczytać pole po nazwie:

function getProp<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

getProp({ a: 1 }, "a"); // OK
getProp({ a: 1 }, "b");
// error TS2345: Argument of type '"b"' is not assignable to parameter of type '"a"'.

Co to są utility types i które trzeba znać?

To wbudowane typy generyczne, które przekształcają inne typy, żeby nie pisać ich od nowa:

Przykład z testu: Pick<Todo, "id" | "title"> nie przyjął obiektu z dodatkowym polem done (error TS2353: Object literal may only specify known properties), a przypisanie do pola typu Readonly<Todo> dało error TS2540: Cannot assign to 'done' because it is a read-only property.

Jak dodać pole do pustego obiektu bez błędu „property does not exist”?

Pusty obiekt {} ma typ bez żadnych pól, więc obj.name = "x" kończy się błędem Property 'name' does not exist on type '{}'. Rozwiązania, od najlepszego: zdefiniować typ obiektu z góry (interface), albo użyć słownika Record<string, string>, gdy nazwy kluczy nie są znane. Rzutowanie {} as any też usuwa błąd, ale razem z nim cały sens typów.

as, readonly i granica kompilatora

Czym jest asercja typu (as) i czym różni się od zwykłego typowania?

Asercja (type assertion, value as Type) mówi kompilatorowi „wiem lepiej, to jest ten typ” i nic nie sprawdza w czasie działania. To najczęstsze źródło fałszywego poczucia bezpieczeństwa. W naszym teście JSON.parse('{"id":"nie-liczba"}') as { id: number } skompilowało się bez błędu, a typeof data.id w runtime wyniosło string, więc wywołanie data.id.toFixed(2) rzuciło TypeError: toFixed is not a function.

const data = JSON.parse('{"id":"nie-liczba"}') as { id: number };
console.log(typeof data.id); // "string", mimo że typ mówi number
data.id.toFixed(2);          // błąd w czasie działania

Dobra odpowiedź: asercja nie zamienia danych na dany typ, tylko ucisza kompilator. Dane z zewnątrz (API, formularze, JSON) należy zwalidować w czasie działania: własnym sprawdzeniem (type guard) albo biblioteką do walidacji schematów, np. Zod, która jednocześnie wylicza typ.

Czy private i readonly chronią dane w czasie działania?

Nie. To zabezpieczenia kompilatora. W naszym teście pole private balance było poza zasięgiem dla zwykłego odczytu (error TS2341: Property 'balance' is private and only accessible within class 'Account'), ale po rzutowaniu na any odczytało się normalnie, a Object.keys pokazało je na liście. Podobnie zmiana pola typu Readonly<Todo> przez rzutowanie na zwykły typ zadziałała w runtime. Prawdziwą prywatność daje składnia #pole z JavaScript, a prawdziwą niemutowalność Object.freeze. To częsty podchwytliwy wątek: „czy private naprawdę ukrywa pole?”.

Klasy i interfejsy

Do czego służą modyfikatory dostępu i implements?

public, private i protected ograniczają, kto może używać pola lub metody (z każdego miejsca, tylko z tej klasy, z tej klasy i klas pochodnych). Skrót constructor(public owner: string) deklaruje i przypisuje pole jednocześnie. implements mówi, że klasa spełnia kontrakt opisany przez interface, więc kompilator sprawdzi, czy ma wymagane metody. Dobry przykład z praktyki: interfejs Logger, który implementuje i konsola, i wersja wysyłająca logi na serwer, bo reszta kodu zależy tylko od kontraktu.

TypeScript w praktyce

Jak typuje się propsy i stan w Reaccie?

Propsy opisujesz typem lub interfejsem i dajesz go jako typ parametru komponentu, a stan typujesz generykiem: useState<string | null>(null). Warto znać też typy zdarzeń (np. React.ChangeEvent<HTMLInputElement>). Szersze pytania o samą bibliotekę znajdziesz w artykule o pytaniach rekrutacyjnych z Reacta.

Jak przenieść istniejący projekt z JavaScript na TypeScript?

Stopniowo. W tsconfig.json włączasz allowJs, żeby pliki .js i .ts mogły współistnieć, i zmieniasz rozszerzenia po jednym module, zaczynając od plików, które nie zależą od innych (narzędzia, stałe, modele danych). Tryb strict włączasz na końcu albo flaga po fladze, bo zrobienie tego od razu daje setki błędów naraz. Dobra odpowiedź podkreśla, że celem nie jest zero błędów w pierwszym dniu, tylko stały postęp bez zatrzymywania pracy zespołu.

Jakie zadania z kodem pojawiają się na rozmowach z TypeScript?

Najczęściej: napisanie typów dla danych z API (interface lub type dla odpowiedzi), generyczna funkcja pomocnicza (np. first, groupBy, pick), typowanie funkcji z unią i zawężaniem, poprawienie kodu z błędami kompilatora oraz zadanie typu „dodaj do tego JavaScript typy”. Rekruter patrzy, czy dobierasz unknown zamiast any, czy obsługujesz undefined i czy nie ratujesz się rzutowaniami. Umiejętności wymagane od juniora frontendowego zbiera artykuł o tym, co musi umieć junior frontend developer.

Co powie kompilator? Mini-test na rozgrzewkę

Rekruterzy lubią pytanie „czy to się skompiluje i co zrobi w runtime?”. Spróbuj odpowiedzieć na trzy poniższe, zanim zajrzysz do odpowiedzi. Wszystkie sprawdziliśmy w TypeScript 5.6.3 z strict.

Zadanie 1. Czy ten kod się skompiluje?

function len(s: string | undefined) {
  return s.length;
}

Odpowiedź: nie. error TS18048: 's' is possibly 'undefined'. Poprawka: s?.length ?? 0 albo wcześniejsze sprawdzenie if (s === undefined).

Zadanie 2. Co wypisze program i czy kompilator zgłosi błąd?

const data = JSON.parse('{"id":"nie-liczba"}') as { id: number };
console.log(typeof data.id);

Odpowiedź: kompilator nie zgłosi błędu, a program wypisze string. Asercja as nie sprawdza danych w czasie działania.

Zadanie 3. Czy ten kod się skompiluje?

interface Todo { id: number; title: string; done: boolean }

const preview: Pick<Todo, "id" | "title"> = { id: 1, title: "x", done: true };

Odpowiedź: nie. error TS2353: Object literal may only specify known properties, and 'done' does not exist in type 'Pick<Todo, "id" | "title">'. Typ Pick zawiera tylko id i title, więc dodatkowe pole w literale obiektu jest błędem.

Jak przygotować się do rozmowy z TypeScript?

Samo czytanie odpowiedzi nie wystarczy, bo pytania uzupełniające szybko pokazują, czy rozumiesz temat. Skuteczniej działa przepisanie małego projektu z JavaScript na TypeScript z włączonym strict oraz głośne tłumaczenie decyzji komuś innemu, na przykład mentorowi. Dla porządku:

Na czym juniorzy najczęściej tracą punkty?

Nie na trudnych tematach, tylko na trzech drobiazgach, które wychodzą dopiero przy pytaniach uzupełniających:

1. any „na chwilę”. Użycie any wyłącza kontrolę typów dokładnie tam, gdzie była potrzebna. Nie wystarczy powiedzieć „unikam any”. Pokaż, że w jego miejsce użyjesz unknown i zawężenia albo generyka.
2. Wiara w as. Rzutowanie danych z API na interfejs wygląda jak walidacja, ale niczego nie sprawdza. Wyjaśnij, że typy znikają po kompilacji, więc dane z zewnątrz trzeba sprawdzić w czasie działania.
3. Mylenie typu z wartością. interface, type i typy generyczne istnieją tylko w kompilatorze, więc nie sprawdzisz ich przez typeof ani instanceof. Sprawdza się wartości, a typ wynika z tego sprawdzenia (zawężanie).

Na co zwraca uwagę mentor, gdy sprawdza kod w TypeScript?

Przy code review kodu z TypeScript mentor zwykle zaczyna od dwóch pytań, które pasują też do rozmowy rekrutacyjnej.

Pierwsze: „Co się stanie, jeśli API zwróci coś innego, niż obiecuje typ?” Pytanie pada przy każdym as na danych z zewnątrz. Typ w kodzie jest deklaracją, a nie gwarancją, więc dane z API, formularza czy localStorage trzeba sprawdzić w czasie działania (własnym sprawdzeniem albo biblioteką do walidacji, np. Zod). Kto potrafi odpowiedzieć na to pytanie, rozumie granicę między kompilatorem a runtime, czyli sedno całego TypeScript.

Drugie: „Od której flagi zacząłbyś w starym projekcie?” Odpowiedź „włączę strict wszędzie” brzmi dobrze, ale w projekcie z setkami plików daje setki błędów naraz i zespół cofa zmianę. Lepsza odpowiedź to plan: najpierw noImplicitAny w nowych plikach, potem strictNullChecks moduł po module, a strict na końcu. Pokazuje, że umiesz wprowadzać zmiany bez zatrzymywania pracy zespołu, a rekruterzy cenią to bardziej niż znajomość listy flag.

Jak brzmi dobra odpowiedź, a jak słaba?

Weźmy pytanie o any i unknown:

Ten sam schemat działa przy każdym pytaniu z tego artykułu: definicja, mechanizm, przykład użycia.

Co zrobić, gdy nie znasz odpowiedzi?

Nie zgaduj i nie milcz. Powiedz, co wiesz na pewno, a potem rozumuj na głos, np.: „Nie pamiętam dokładnej nazwy tego typu pomocniczego, ale wiem, że szukam czegoś, co zrobi z wszystkich pól opcjonalne, więc sprawdziłbym to w dokumentacji TypeScript.” Taka odpowiedź pokazuje, że potrafisz sobie poradzić w pracy, a umiejętność znalezienia odpowiedzi jest w codziennej pracy ważniejsza niż pamięć do szczegółów.

Dobrze też wiedzieć, jak wygląda sama rozmowa i od czego zacząć naukę. W podcaście Michał Miszczyszyn opowiada o TypeScript dla juniorów: czym jest i jak zacząć naukę.

Znajomość odpowiedzi to połowa sukcesu, drugą jest znalezienie rozmów, na które warto się umówić. Jeśli szukasz ofert, sięgnij po darmowy poradnik o tym, jak szukać pracy w 2026 roku, w którym zebraliśmy 3 sposoby poszukiwania pracy, które u naszych podopiecznych dają najlepsze efekty. Całość procesu, od CV po rozmowę, opisuje artykuł o tym, jak przejść cały proces rekrutacyjny na juniora, a o zadaniach i portfolio piszemy w poradniku jak przygotować się do rekrutacji na juniora developera.

Jeśli braki wyjdą przy generykach albo zawężaniu typów, to sygnał, że warto uporządkować wiedzę z mentorem. W kursie React, TypeScript i Next.js jest moduł o statycznym typowaniu, generykach i migracji kodu z JavaScript do TypeScript, a zadania i projekt z tej tematyki sprawdza mentor w code review.