Kompletny Przewodnik - Rozmowa Rekrutacyjna Node.js Backend Developer 2026
Rozmowa na stanowisko Node.js Backend Developer w 2026 roku to nie jest już tylko "napisz CRUD w Express". To sprawdzian z całego ekosystemu - od głębokiej znajomości runtime'u, przez framework, bazy danych, po architekturę systemów i bezpieczeństwo. Kandydaci, którzy przychodzą znając tylko podstawy Express.js, odpadają na pytaniach o event loop czy streaming.
W tym przewodniku znajdziesz kompletną mapę tego, co sprawdzają rekruterzy na rozmowach backend Node.js, jakie pytania padają najczęściej, i jak się do nich przygotować. Każda sekcja zawiera linki do szczegółowych artykułów, gdzie znajdziesz konkretne pytania z odpowiedziami.
Co sprawdzają na rozmowie Node.js Backend Developer
Zanim zagłębimy się w szczegóły, musisz zrozumieć strukturę tego, co rekruterzy oceniają. Rozmowa Node.js Backend składa się z sześciu głównych obszarów:
| Obszar | Waga | Co sprawdzają |
|---|---|---|
| Node.js Core | 25-30% | Event loop, streams, cluster, worker threads, modules |
| Framework | 20-25% | Express.js lub NestJS - zależnie od stanowiska |
| Bazy danych | 20-25% | MongoDB i/lub SQL (PostgreSQL, MySQL) |
| REST API & Design | 10-15% | Projektowanie API, wersjonowanie, HATEOAS |
| Architektura | 10-15% | Microservices, wzorce, skalowanie |
| Bezpieczeństwo & Auth | 5-10% | JWT, OAuth, OWASP, sanitization |
Wagi różnią się między firmami. Startupy mogą kłaść większy nacisk na szybkie prototypowanie i znajomość frameworka. Korporacje często sprawdzają głębiej Node.js core i architekturę. Firmy fintech pytają więcej o bezpieczeństwo i bazy danych SQL. Ale Node.js core jest fundamentem wszędzie - bez zrozumienia jak działa event loop, cała reszta się wali.
Node.js Core - Fundament Każdej Rozmowy
Możesz być ekspertem od NestJS, ale jeśli nie potrafisz wyjaśnić jak działa event loop albo po co są streams, rozmowa skończy się szybko. Node.js core to fundament i rekruterzy zaczynają właśnie od niego.
Event Loop - Najważniejszy Temat
Event loop to serce Node.js. Musisz rozumieć nie tylko że "Node jest asynchroniczny", ale jak dokładnie to działa:
// Klasyczne pytanie: w jakiej kolejności wyświetlą się logi?
console.log('1 - sync');
setTimeout(() => console.log('2 - setTimeout'), 0);
setImmediate(() => console.log('3 - setImmediate'));
process.nextTick(() => console.log('4 - nextTick'));
Promise.resolve().then(() => console.log('5 - Promise'));
console.log('6 - sync');
// Odpowiedź: 1, 6, 4, 5, 2, 3 (lub 1, 6, 4, 5, 3, 2)
// Kolejność: sync → nextTick → microtasks (Promise) → timers → check (setImmediate)Fazy event loop - musisz znać kolejność: timers → pending callbacks → idle/prepare → poll → check → close callbacks. I wiedzieć, gdzie wykonują się różne typy operacji.
process.nextTick vs setImmediate - nextTick wykonuje się przed każdą fazą event loop (przed microtasks!), setImmediate w fazie check. To częste pytanie pułapka.
Streams - Obsługa Dużych Danych
Streams to kluczowa koncepcja dla backendu. Zamiast ładować cały plik do pamięci, przetwarzasz dane kawałek po kawałku:
const fs = require('fs');
const zlib = require('zlib');
// Bez streams - zły sposób (cały plik w pamięci)
fs.readFile('huge-file.txt', (err, data) => {
const compressed = zlib.gzipSync(data);
fs.writeFileSync('huge-file.txt.gz', compressed);
});
// Ze streams - dobry sposób (małe zużycie pamięci)
fs.createReadStream('huge-file.txt')
.pipe(zlib.createGzip())
.pipe(fs.createWriteStream('huge-file.txt.gz'));Typy streams - Readable, Writable, Duplex, Transform. Musisz wiedzieć kiedy użyć którego.
Backpressure - co się dzieje gdy producent generuje dane szybciej niż konsument je przetwarza? Jak to obsługuje Node.js?
Cluster i Worker Threads
Node.js jest single-threaded, ale możesz wykorzystać wiele rdzeni:
const cluster = require('cluster');
const numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
console.log(`Master ${process.pid} is running`);
// Fork workers
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker) => {
console.log(`Worker ${worker.process.pid} died, spawning new one`);
cluster.fork();
});
} else {
// Worker process - tu uruchamiasz serwer HTTP
require('./server');
}Cluster vs Worker Threads - cluster tworzy oddzielne procesy (izolacja pamięci, dobre dla HTTP), worker threads dzielą pamięć (dobre dla CPU-intensive tasks).
Moduły CommonJS vs ES Modules
// CommonJS (starszy, synchroniczny)
const express = require('express');
module.exports = { app };
// ES Modules (nowszy, asynchroniczny)
import express from 'express';
export { app };Musisz znać różnice: kiedy używać którego, jak działa require cache, co to jest circular dependency i jak jej unikać.
Szczegółowe pytania z Node.js core z odpowiedziami: Jak Przygotować się do Rozmowy Node.js →
Express.js - Najpopularniejszy Framework
Express.js dominuje rynek Node.js backend. Jest minimalny, elastyczny i ma ogromny ekosystem middleware. Jeśli rekrutujesz na stanowisko z Express, musisz znać go dogłębnie.
Middleware - Serce Express
Middleware to funkcje, które mają dostęp do request, response i next. Wykonują się w kolejności dodania:
const express = require('express');
const app = express();
// Middleware logujący - dla wszystkich requestów
app.use((req, res, next) => {
console.log(`${req.method} ${req.path} - ${Date.now()}`);
next();
});
// Middleware parsujący JSON body
app.use(express.json());
// Middleware autoryzacji - tylko dla /api/*
app.use('/api', (req, res, next) => {
const token = req.headers.authorization;
if (!token) {
return res.status(401).json({ error: 'No token provided' });
}
// verify token...
next();
});
// Route handler
app.get('/api/users', (req, res) => {
res.json({ users: [] });
});
// Error handling middleware - MUSI mieć 4 argumenty!
app.use((err, req, res, next) => {
console.error(err.stack);
res.status(500).json({ error: 'Something went wrong' });
});Pytanie pułapka: Dlaczego error handling middleware musi mieć 4 argumenty? Bo Express rozpoznaje error handler po liczbie argumentów!
Routing i Struktura Aplikacji
// routes/users.js
const router = require('express').Router();
router.get('/', getAllUsers);
router.get('/:id', getUserById);
router.post('/', createUser);
router.put('/:id', updateUser);
router.delete('/:id', deleteUser);
module.exports = router;
// app.js
const usersRouter = require('./routes/users');
app.use('/api/users', usersRouter);Popularne Pytania Express
- Jak działa
app.use()vsapp.get()? - Jak obsłużyć async errors w Express?
- Czym jest
res.localsi kiedy go używać? - Jak zaimplementować rate limiting?
- Jak obsłużyć CORS?
Szczegółowe pytania z Express.js z odpowiedziami: Express.js - Pytania Rekrutacyjne i Przewodnik →
NestJS - Enterprise Framework
NestJS to framework enterprise-level zbudowany na Express (lub Fastify). Wymusza strukturę, używa TypeScript, i implementuje wzorce znane z Angulara (DI, moduły, dekoratory). Jeśli rekrutujesz do korporacji lub dużego projektu, prawdopodobnie spotkasz NestJS.
Architektura NestJS
// users.module.ts
@Module({
imports: [TypeOrmModule.forFeature([User])],
controllers: [UsersController],
providers: [UsersService],
exports: [UsersService],
})
export class UsersModule {}
// users.controller.ts
@Controller('users')
export class UsersController {
constructor(private readonly usersService: UsersService) {}
@Get()
findAll(): Promise<User[]> {
return this.usersService.findAll();
}
@Get(':id')
findOne(@Param('id') id: string): Promise<User> {
return this.usersService.findOne(+id);
}
@Post()
@UsePipes(new ValidationPipe())
create(@Body() createUserDto: CreateUserDto): Promise<User> {
return this.usersService.create(createUserDto);
}
}
// users.service.ts
@Injectable()
export class UsersService {
constructor(
@InjectRepository(User)
private usersRepository: Repository<User>,
) {}
async findAll(): Promise<User[]> {
return this.usersRepository.find();
}
}Kluczowe Koncepcje NestJS
Dependency Injection - NestJS ma wbudowany DI container. Musisz rozumieć scope providers (DEFAULT, REQUEST, TRANSIENT) i hierarchię modułów.
Guards, Interceptors, Pipes - trzy warstwy przetwarzania requestu:
- Guards - autoryzacja (przed controller)
- Interceptors - transformacja request/response (przed i po)
- Pipes - walidacja i transformacja danych wejściowych
Kolejność wykonania:
Middleware → Guards → Interceptors (before) → Pipes → Handler → Interceptors (after)Exception Filters - globalna obsługa błędów z możliwością customizacji per-controller lub per-handler.
Szczegółowe pytania z NestJS z odpowiedziami: NestJS - Pytania Rekrutacyjne i Przewodnik →
Bazy Danych - MongoDB i SQL
Na rozmowach backend pytania o bazy danych są nieuniknione. W ekosystemie Node.js najczęściej spotkasz MongoDB (z Mongoose) i PostgreSQL (z Prisma, TypeORM lub Knex).
MongoDB - Dokumentowa Baza Danych
MongoDB to naturalny wybór dla Node.js ze względu na format JSON. Musisz znać:
CRUD Operations:
// Mongoose example
const userSchema = new mongoose.Schema({
name: { type: String, required: true },
email: { type: String, unique: true, required: true },
orders: [{ type: mongoose.Schema.Types.ObjectId, ref: 'Order' }]
});
// Create
const user = await User.create({ name: 'Jan', email: 'jan@example.com' });
// Read with population
const userWithOrders = await User.findById(id).populate('orders');
// Update
await User.updateOne({ _id: id }, { $set: { name: 'Jan Nowak' } });
// Delete
await User.deleteOne({ _id: id });Aggregation Pipeline - to częsty temat na rozmowach:
// Przykład: średnia wartość zamówień per użytkownik
const result = await Order.aggregate([
{ $match: { status: 'completed' } },
{ $group: {
_id: '$userId',
avgOrderValue: { $avg: '$total' },
orderCount: { $sum: 1 }
}},
{ $sort: { avgOrderValue: -1 } },
{ $limit: 10 }
]);Indeksy - kiedy tworzyć, jakie typy (single field, compound, text, geospatial), jak analizować z explain().
Embedding vs Referencing:
// Embedding - dane w jednym dokumencie (dobre dla 1:few)
{
name: 'Jan',
address: { city: 'Warszawa', street: 'Marszałkowska' }
}
// Referencing - osobne dokumenty z referencją (dobre dla 1:many, many:many)
{
name: 'Jan',
orders: [ObjectId('...'), ObjectId('...')]
}Szczegółowe pytania z MongoDB z odpowiedziami: MongoDB - Pytania Rekrutacyjne i Przewodnik →
SQL - PostgreSQL/MySQL
Nawet w ekosystemie Node.js, SQL jest wszędzie. Szczególnie w projektach wymagających transakcji ACID:
Podstawowe zapytania:
-- JOIN - najczęstsze pytanie
SELECT u.name, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC;
-- Subquery
SELECT * FROM users
WHERE id IN (SELECT user_id FROM orders WHERE total > 1000);
-- Window functions (dla senior)
SELECT
name,
total,
ROW_NUMBER() OVER (ORDER BY total DESC) as rank,
SUM(total) OVER (ORDER BY created_at) as running_total
FROM orders;Indeksy w SQL:
-- B-tree index (default)
CREATE INDEX idx_users_email ON users(email);
-- Composite index
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);
-- Partial index (PostgreSQL)
CREATE INDEX idx_active_users ON users(email) WHERE is_active = true;Transakcje:
// Prisma transaction
await prisma.$transaction(async (tx) => {
const user = await tx.user.update({
where: { id: userId },
data: { balance: { decrement: amount } }
});
await tx.order.create({
data: { userId, amount, status: 'completed' }
});
});N+1 Problem - klasyczne pytanie:
// Problem N+1 - 1 query na users + N queries na orders
const users = await User.findAll();
for (const user of users) {
const orders = await Order.findAll({ where: { userId: user.id } });
}
// Rozwiązanie - eager loading
const users = await User.findAll({
include: [{ model: Order }]
});Szczegółowe pytania z SQL z odpowiedziami: SQL - Pytania Rekrutacyjne →
REST API Design
Projektowanie API to kluczowa umiejętność backend developera. Rekruterzy sprawdzają nie tylko czy potrafisz napisać endpoint, ale czy rozumiesz dobre praktyki.
Konwencje REST
GET /api/users # Lista users
GET /api/users/123 # Pojedynczy user
POST /api/users # Tworzenie user
PUT /api/users/123 # Pełna aktualizacja
PATCH /api/users/123 # Częściowa aktualizacja
DELETE /api/users/123 # Usunięcie
# Zasoby zagnieżdżone
GET /api/users/123/orders
POST /api/users/123/orders
# Filtrowanie, sortowanie, paginacja
GET /api/users?status=active&sort=-createdAt&page=2&limit=20HTTP Status Codes
Musisz znać najważniejsze i kiedy ich używać:
| Code | Kiedy używać |
|---|---|
| 200 OK | Sukces GET, PUT, PATCH |
| 201 Created | Sukces POST (zasób utworzony) |
| 204 No Content | Sukces DELETE |
| 400 Bad Request | Błędne dane wejściowe |
| 401 Unauthorized | Brak/nieprawidłowy token |
| 403 Forbidden | Brak uprawnień do zasobu |
| 404 Not Found | Zasób nie istnieje |
| 409 Conflict | Konflikt (np. duplikat email) |
| 422 Unprocessable Entity | Walidacja nie przeszła |
| 500 Internal Server Error | Błąd serwera |
Wersjonowanie API
# W URL (najpopularniejsze)
/api/v1/users
/api/v2/users
# W header
Accept: application/vnd.myapp.v1+json
# Query param
/api/users?version=1Obsługa Błędów
// Standardowy format błędu
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid input data",
"details": [
{ "field": "email", "message": "Invalid email format" },
{ "field": "password", "message": "Must be at least 8 characters" }
]
}
}Architektura i Wzorce
Na stanowiskach mid i senior spodziewaj się pytań o architekturę. To odróżnia programistów, którzy "piszą kod" od tych, którzy "budują systemy".
Layered Architecture
┌─────────────────────────┐
│ Controllers │ ← HTTP request/response
├─────────────────────────┤
│ Services │ ← Business logic
├─────────────────────────┤
│ Repositories │ ← Data access
├─────────────────────────┤
│ Database │
└─────────────────────────┘// Controller - tylko HTTP
@Controller('users')
export class UsersController {
constructor(private usersService: UsersService) {}
@Post()
async create(@Body() dto: CreateUserDto) {
return this.usersService.create(dto);
}
}
// Service - business logic
@Injectable()
export class UsersService {
constructor(private usersRepository: UsersRepository) {}
async create(dto: CreateUserDto) {
// Validation, business rules
const existingUser = await this.usersRepository.findByEmail(dto.email);
if (existingUser) {
throw new ConflictException('Email already exists');
}
return this.usersRepository.create(dto);
}
}
// Repository - data access
@Injectable()
export class UsersRepository {
constructor(@InjectRepository(User) private repo: Repository<User>) {}
async findByEmail(email: string) {
return this.repo.findOne({ where: { email } });
}
}Microservices vs Monolit
| Aspekt | Monolit | Microservices |
|---|---|---|
| Złożoność | Niska | Wysoka |
| Deployment | Prosty | Skomplikowany |
| Skalowanie | Pionowe | Poziome (per service) |
| Zespół | Mały (do ~10 osób) | Duży (wiele zespołów) |
| Kiedy | MVP, mały projekt | Duża skala, niezależne domeny |
Komunikacja między microservices:
- Synchroniczna: REST, gRPC
- Asynchroniczna: Message queues (RabbitMQ, Kafka, Redis Pub/Sub)
// RabbitMQ example
// Publisher
channel.sendToQueue('orders', Buffer.from(JSON.stringify(order)));
// Consumer
channel.consume('orders', (msg) => {
const order = JSON.parse(msg.content.toString());
processOrder(order);
channel.ack(msg);
});CQRS i Event Sourcing
CQRS (Command Query Responsibility Segregation) - oddzielne modele do odczytu i zapisu:
// Command (zapis)
class CreateOrderCommand {
constructor(
public readonly userId: string,
public readonly items: OrderItem[]
) {}
}
// Query (odczyt)
class GetOrdersQuery {
constructor(
public readonly userId: string,
public readonly status?: string
) {}
}Szczegółowe pytania o architekturę z odpowiedziami: Wzorce i Architektura Backend →
Bezpieczeństwo i Uwierzytelnianie
Bezpieczeństwo to krytyczny temat dla backendu. Rekruterzy sprawdzają czy rozumiesz zagrożenia i jak się przed nimi chronić.
JWT Authentication
const jwt = require('jsonwebtoken');
// Generowanie tokena
const token = jwt.sign(
{ userId: user.id, role: user.role },
process.env.JWT_SECRET,
{ expiresIn: '1h' }
);
// Weryfikacja tokena (middleware)
const authMiddleware = (req, res, next) => {
const token = req.headers.authorization?.split(' ')[1];
if (!token) {
return res.status(401).json({ error: 'No token provided' });
}
try {
const decoded = jwt.verify(token, process.env.JWT_SECRET);
req.user = decoded;
next();
} catch (err) {
return res.status(401).json({ error: 'Invalid token' });
}
};Access Token vs Refresh Token:
- Access token: krótki czas życia (15min - 1h), używany do autoryzacji
- Refresh token: długi czas życia (dni/tygodnie), używany do odświeżania access token
OWASP Top 10 - Co Musisz Znać
- Injection (SQL, NoSQL):
// ŹLE - SQL Injection
const query = `SELECT * FROM users WHERE email = '${email}'`;
// DOBRZE - Parametrized query
const query = 'SELECT * FROM users WHERE email = $1';
await db.query(query, [email]);- Broken Authentication - słabe hasła, brak rate limiting, sesje nie wygasają
- Sensitive Data Exposure - niezaszyfrowane hasła, tokeny w URL
- XSS (Cross-Site Scripting):
// DOBRZE - sanityzacja danych wejściowych
const sanitizeHtml = require('sanitize-html');
const clean = sanitizeHtml(userInput);- CSRF - używaj tokenów CSRF dla formularzy
Hashowanie Haseł
const bcrypt = require('bcrypt');
// Hashowanie hasła przy rejestracji
const salt = await bcrypt.genSalt(10);
const hashedPassword = await bcrypt.hash(password, salt);
// Weryfikacja przy logowaniu
const isMatch = await bcrypt.compare(password, user.hashedPassword);Dlaczego bcrypt a nie SHA-256? bcrypt jest celowo wolny (brute-force resistant) i ma wbudowaną sól.
Testowanie
Testowanie to część pracy backend developera. Na rozmowach pytania o testy padają regularnie.
Unit Tests
// users.service.spec.ts
describe('UsersService', () => {
let service: UsersService;
let repository: MockRepository<User>;
beforeEach(() => {
repository = createMockRepository();
service = new UsersService(repository);
});
describe('create', () => {
it('should create a new user', async () => {
const dto = { email: 'test@example.com', name: 'Test' };
repository.findOne.mockResolvedValue(null);
repository.create.mockResolvedValue({ id: 1, ...dto });
const result = await service.create(dto);
expect(result.email).toBe(dto.email);
expect(repository.create).toHaveBeenCalledWith(dto);
});
it('should throw if email exists', async () => {
const dto = { email: 'existing@example.com', name: 'Test' };
repository.findOne.mockResolvedValue({ id: 1, ...dto });
await expect(service.create(dto)).rejects.toThrow(ConflictException);
});
});
});Integration Tests
// users.e2e-spec.ts
describe('Users API (e2e)', () => {
let app: INestApplication;
beforeAll(async () => {
const moduleFixture = await Test.createTestingModule({
imports: [AppModule],
}).compile();
app = moduleFixture.createNestApplication();
await app.init();
});
it('/users (POST)', () => {
return request(app.getHttpServer())
.post('/users')
.send({ email: 'test@example.com', name: 'Test' })
.expect(201)
.expect((res) => {
expect(res.body.email).toBe('test@example.com');
});
});
afterAll(async () => {
await app.close();
});
});Test Pyramid
/\
/ \ E2E Tests (few)
/----\
/ \ Integration Tests (some)
/--------\
/ \ Unit Tests (many)
/____________\Plan Przygotowań: 3 Tygodnie do Rozmowy
Oto sprawdzony harmonogram przygotowań. Zakłada 1.5-2 godziny dziennie.
Tydzień 1: Node.js Core i Podstawy
Dni 1-3: Node.js Core
- Event loop - fazy, microtasks vs macrotasks
- process.nextTick vs setImmediate
- Streams - typy, backpressure, pipe
- Praktyka: napisz CLI tool używając streams
Dni 4-5: Cluster i Worker Threads
- Kiedy cluster, kiedy worker threads
- Jak działa load balancing w cluster
- Praktyka: zaimplementuj serwer HTTP z cluster
Dni 6-7: Moduły i Error Handling
- CommonJS vs ES Modules
- Error handling patterns
- Uncaught exceptions i unhandled rejections
Tydzień 2: Framework i Bazy Danych
Dni 1-3: Express.js lub NestJS
- Middleware pipeline
- Routing i struktura
- Error handling
- Praktyka: zbuduj REST API od zera
Dni 4-5: MongoDB
- CRUD operations
- Aggregation pipeline
- Indeksy i optymalizacja
- Mongoose - schemas, middleware, population
Dni 6-7: SQL
- JOINs i subqueries
- Indeksy i optymalizacja
- Transakcje
- N+1 problem i eager loading
Tydzień 3: Architektura, Bezpieczeństwo i Mock Interviews
Dni 1-2: REST API Design
- Konwencje i best practices
- Wersjonowanie
- Error handling
Dni 3-4: Architektura
- Layered architecture
- Microservices vs Monolit
- Message queues
- CQRS basics
Dni 5-7: Mock Interviews
- Odpowiadaj na pytania na głos
- Rozwiązuj zadania praktyczne z timerem
- Przygotuj pytania dla rekrutera
Najczęstsze Błędy Kandydatów
Błąd 1: Znajomość Frameworka bez Node.js Core
"Znam Express" ale nie potrafi wyjaśnić jak działa event loop. Framework to abstrakcja nad Node.js - bez znajomości runtime'u, nie zrozumiesz dlaczego rzeczy działają.
Błąd 2: Ignorowanie SQL
Kandydat zna tylko MongoDB i pada na pytaniach o JOINy. Nawet jeśli firma używa MongoDB, SQL jest w 90% ofert. Musisz go znać.
Błąd 3: Brak Wiedzy o Bezpieczeństwie
"Jak zabezpieczyć endpoint?" - cisza. Bezpieczeństwo to podstawa backendu. Musisz znać OWASP Top 10 i podstawowe zabezpieczenia.
Błąd 4: Nieznajomość Architektury
Senior który nie potrafi wyjaśnić różnicy między monolitem a microservices. Na wyższych stanowiskach architektura jest kluczowa.
Błąd 5: Brak Praktycznego Doświadczenia
Teoria bez praktyki. Rekruterzy szybko wyczują, czy naprawdę budowałeś systemy, czy tylko czytałeś dokumentację.
Podsumowanie: Checklist Przed Rozmową
Node.js Core:
- Rozumiesz event loop i jego fazy
- Znasz różnicę nextTick vs setImmediate
- Wiesz jak działają streams
- Rozumiesz cluster i worker threads
Framework:
- Znasz middleware pipeline
- Potrafisz zbudować REST API od zera
- Rozumiesz error handling
- Znasz najnowsze features frameworka
Bazy danych:
- MongoDB: CRUD, aggregation, indeksy
- SQL: JOINs, subqueries, transakcje
- Rozumiesz N+1 problem i jak go rozwiązać
Architektura:
- Znasz layered architecture
- Rozumiesz microservices vs monolit
- Wiesz co to CQRS
- Potrafisz zaprojektować REST API
Bezpieczeństwo:
- JWT authentication
- OWASP Top 10 basics
- Hashowanie haseł (bcrypt)
Testowanie:
- Unit tests
- Integration tests
- Mocking
Zobacz też
- Jak Przygotować się do Rozmowy Node.js - Node.js core deep dive
- Express.js - Pytania Rekrutacyjne - middleware, routing, praktyki
- NestJS - Pytania Rekrutacyjne - moduły, DI, Guards, Interceptors
- MongoDB - Pytania Rekrutacyjne - CRUD, aggregation, modelowanie
- SQL - Pytania Rekrutacyjne - JOINs, indeksy, optymalizacja
- REST API Best Practices - projektowanie API, bezpieczeństwo, dokumentacja
- GraphQL - Pytania Rekrutacyjne - queries, mutations, resolvers, N+1, DataLoader
- Redis - Pytania Rekrutacyjne - caching, data structures, persistence, Cluster
- WebSockets - Pytania Rekrutacyjne - Socket.IO, skalowanie, rooms, heartbeats
- Authentication i JWT - Pytania Rekrutacyjne - OAuth 2.0, refresh tokens, bcrypt, Passport.js
- Backend Testing - Pytania Rekrutacyjne - unit, integration, API testing, mocking, TDD
- Microservices w Node.js - RabbitMQ, Kafka, Saga, Circuit Breaker
- Wzorce i Architektura Backend - layered, microservices, CQRS
Chcesz Więcej Pytań na Rozmowę Node.js Backend?
Ten artykuł to mapa - pokazuje, co musisz wiedzieć. Ale prawdziwe przygotowanie wymaga praktyki z konkretnymi pytaniami.
Mamy zestawy pytań dla każdej technologii backend - Node.js (100 pytań), Express.js (42 pytania), NestJS (42 pytania), MongoDB (44 pytania), SQL (50 pytań) i więcej. Każde pytanie z odpowiedzią w formacie "30 sekund / 2 minuty" - dokładnie tak, jak wyglądają prawdziwe rozmowy.
Zdobądź Pełny Dostęp do Wszystkich Pytań →
Napisane przez zespół Flipcards, na podstawie doświadczeń z rozmów rekrutacyjnych w firmach technologicznych i software house'ach w Polsce i za granicą.
Chcesz więcej pytań rekrutacyjnych?
To tylko jeden temat z naszego kompletnego przewodnika po rozmowach rekrutacyjnych. Uzyskaj dostęp do 800+ pytań z 13 technologii.