Backend - Senior

Candidate information

Full name

Phone (optional)

Years of experience

CV / Resume Accepted formats: PDF, DOC, DOCX. Maximum 5MB

Knowledge questions

This Eloquent code has a performance problem: `$posts = Post::all(); foreach ($posts as $post) { echo $post->author->name; }`. What is the issue?

Should use `Post::get()` instead of `Post::all()` because `get()` is more efficient using lazy loading optimized internally by Eloquent

The problem is using native PHP `foreach` instead of the collection `->each()` method, which is optimized for iterating Eloquent models

N+1 Query Problem: 1 query for posts + N additional queries (one per post to load the author). Solution: `Post::with("author")->get()` (eager loading)

Missing pagination in the query; without `->paginate()` Eloquent loads all records into memory causing a server timeout

This Laravel middleware does not work: `public function handle($request, Closure $next) { if (!$request->user()->isAdmin()) { abort(403); } $next($request); }`. What is missing?

Missing the `Closure` class import at the top of the middleware file so PHP can resolve the type hint correctly

Should use `$request->user` as a property without parentheses instead of `$request->user()` as a method, since it is an Eloquent accessor

The `abort(403)` should be `throw new HttpException(403)` because `abort()` does not stop middleware execution in Laravel 10+

The response from `$next($request)` is not returned. Must be `return $next($request);` — without the return, the response is lost and the client receives an empty response

How does the Symfony DI Container work and what are tagged services?

The DI Container manages creation and lifecycle of services, resolving dependencies automatically. Tagged services group services under a tag for batch processing (e.g., event listeners, voters, twig extensions)

The container only serves to instantiate classes manually via the factory pattern, without automatic dependency resolution or injection

Tags in Symfony are exclusively for documentation and have no functional effect on service resolution from the container

Symfony does not have its own DI container; it uses a service locator pattern where each class looks up its dependencies in a global registry

This asyncio code has a race condition: `counter = 0; async def increment(): global counter; temp = counter; await asyncio.sleep(0); counter = temp + 1`. With 100 concurrent tasks, what happens?

counter will always be exactly 100 because asyncio executes coroutines sequentially and the `await` does not allow task interleaving

counter will be less than 100: the `await` allows other coroutines to read the same `temp` value before incrementing, losing increments. Solution: `asyncio.Lock()` to protect the critical section

asyncio cannot have race conditions because it is single-threaded and Python GIL prevents any concurrent access to shared variables

The error is simply using `global` instead of passing counter as a parameter; switching to parameter eliminates the race condition automatically

FastAPI endpoint returns 422: `@app.post("/users") async def create(user: UserCreate): ...` with body `{"name": "John", "age": "twenty"}` and `class UserCreate(BaseModel): name: str; age: int`. Why?

The endpoint should use PUT method instead of POST for resource creation, since POST does not support automatic body validation in FastAPI

Missing the `async` keyword in the function definition; without it FastAPI cannot process the request body asynchronously

`BaseModel` from Pydantic does not support `int` as a field type; it only accepts `str`, `float`, and `bool` as valid primitive types

Pydantic cannot convert the string "twenty" to `int` — type validation fails automatically and FastAPI returns 422 Unprocessable Entity with validation error details

When to use asyncio vs threading vs multiprocessing in Python?

Always use asyncio because it is superior in absolutely all use cases, regardless of whether the task is I/O-bound or CPU-bound

threading is always better than asyncio for I/O operations because OS threads are more efficient than coroutines for handling connections

asyncio: I/O-bound with many concurrent connections (HTTP, DB). threading: I/O-bound with libraries without async support. multiprocessing: CPU-bound (heavy calculations) because it avoids the GIL by running in separate processes

multiprocessing only works on Linux systems and is not compatible with Windows or macOS due to fork() limitations on those operating systems

Memory leak in Express: `app.post("/upload", (req, res) => { const data = req.body; processLater(() => { analyze(data); }); res.send("ok"); });` where `processLater` stores in a global array. Why?

The closure in `processLater` retains a reference to the `data` object (potentially large) indefinitely in the global array. Without cleanup, memory grows with each request. Solution: extract only needed fields and clean after processing

The problem is accessing `req.body` directly without cloning the object first; Express reuses the body buffer between requests causing corruption

Express does not support large request bodies (>1MB) and attempting to process them causes memory fragmentation in the V8 heap

The memory leak is caused by `res.send("ok")` which keeps the HTTP connection open indefinitely without closing the client socket

How to scale a Node.js application?

Just increasing server RAM is sufficient to scale any Node.js application regardless of load type or number of connections

Node.js is inherently non-scalable and the only viable solution is to migrate to Java or Go for high-concurrency applications

Just using PM2 as a process manager is sufficient to handle any level of load without needing additional architecture

Cluster mode (multiple processes across all cores), Worker Threads (CPU-bound tasks), horizontal scaling (instances behind load balancer), and message queues (Redis/RabbitMQ) for heavy async tasks

Deadlock in Go: `func main() { ch := make(chan int); ch <- 42; fmt.Println(<-ch) }`. Why?

Missing `close(ch)` call before attempting to read from the channel, since non-closed channels do not allow read operations in Go

Unbuffered channel: `ch <- 42` blocks until someone reads, but the reader is on the next line which is never reached. Solution: goroutine to send or buffered channel `make(chan int, 1)`

The problem is using `fmt.Println` with the result of a channel read; must assign to a variable first before printing

The syntax `make(chan int)` is invalid in Go; the buffer size must always be specified as a mandatory second argument

What is idiomatic error handling in Go and when to use panic vs error returns?

Always use panic for all errors because it is more concise and allows centralizing error handling with recover at a single point

Go uses try/catch like Java and C# for exception handling; panic/recover is a legacy mechanism that should not be used

Explicit error returns (`val, err := fn(); if err != nil {...}`). `panic` only for unrecoverable programmer errors. Errors are wrapped with `fmt.Errorf("context: %w", err)` to maintain the chain

Error returns are an obsolete pattern that will be removed in Go 2; the Go team has confirmed adoption of traditional exceptions

This query is slow: `SELECT * FROM orders WHERE total > (SELECT AVG(total) FROM orders WHERE user_id = orders.user_id)`. How to optimize?

Adding `LIMIT 1000` to the main query is sufficient to resolve the performance problem without needing to restructure the query

The correlated subquery executes per row. Solution: convert to JOIN with CTE (`WITH avg_totals AS (SELECT user_id, AVG(total) as avg FROM orders GROUP BY user_id)`) + index on (user_id, total)

The only problem is using `SELECT *`; changing to specific columns completely resolves the query performance problem

Switching to a NoSQL database like MongoDB automatically resolves this type of performance problem in analytical queries

What are SQL transaction isolation levels and what problems does each prevent?

Only two levels exist: READ and WRITE, which control whether a transaction can read or write data respectively

Isolation levels are a concept exclusive to NoSQL databases and do not apply to relational systems like PostgreSQL or MySQL

All SQL databases use SERIALIZABLE by default because it is the only level that guarantees complete consistency without configuration

READ UNCOMMITTED (allows dirty reads), READ COMMITTED (prevents dirty reads), REPEATABLE READ (prevents non-repeatable reads), SERIALIZABLE (prevents phantom reads). Higher isolation = lower concurrency

How to model a many-to-many relationship in MongoDB? Embedding vs referencing?

Embedding: when related data is read together and is small (e.g., tags on a post). Referencing: when data is large, updated independently, or the relationship is unbounded (e.g., users in a group). Hybrid: embed a subset and reference the rest

Always use embedding without exception because MongoDB does not support references between documents or lookup operations between collections

Always use referencing exactly like in relational SQL, creating an intermediate join collection for all many-to-many relationships

MongoDB cannot model many-to-many relationships in any way; for this type of relationship a relational database is mandatory

Race condition in cache-aside with Redis: Thread A reads cache (miss), Thread B updates DB and invalidates cache, Thread A writes stale data to cache. How to prevent?

The only solution is to not use cache at all; any caching system inevitably introduces inconsistencies that cannot be mitigated

Redis has no race conditions because all operations are atomic and single-threaded, making it impossible to write stale data

Use short TTL as safety net, write-through instead of cache-aside for critical data, or versioning/timestamps in cache entries to detect stale writes. Also can use distributed lock for write operations

Use `MULTI/EXEC` (Redis transactions) on absolutely all read operations to guarantee complete isolation between threads

How to implement a distributed rate limiter with Redis? Sliding window vs token bucket?

Just using `INCR` with `EXPIRE` on a simple key is sufficient to implement precise rate limiting without needing more complex algorithms

Rate limiting cannot be implemented in a distributed way; each server instance must maintain its own independent local counter

Only a web server middleware (nginx/Apache) is needed and it is not necessary to involve Redis or any external store for rate limiting

Sliding window log: stores request timestamps in sorted set, counts within sliding window (precise but more memory). Token bucket: counter that refills periodically (efficient, allows bursts). Implementation with Lua scripts for atomicity

What are the advantages and disadvantages of Event Sourcing vs traditional CRUD?

Event Sourcing is always superior to CRUD in all possible scenarios and should be the default pattern for any new application

Event Sourcing: complete audit trail, state reconstruction, temporal queries, event replay. Disadvantages: complexity, eventual consistency, growing storage, complex queries require projections. CRUD: simple, direct queries, but loses change history

Traditional CRUD does not support database transactions and that is why Event Sourcing is necessary to guarantee data consistency

Event Sourcing is a pattern exclusively designed for chat and real-time messaging applications, with no applicability in other domains

How to implement a distributed Saga for a payment flow? Orchestration vs choreography?

Sagas are not needed when using microservices because each service manages its own transaction completely independently

Always use distributed transactions (2PC - Two Phase Commit) instead of sagas because 2PC guarantees strong consistency without compensations

Orchestration: a central coordinator directs steps (more control, single point of failure). Choreography: each service reacts to events (decoupled, but hard to trace). For payments: reserve stock → charge → confirm, with inverse compensations if any step fails

Sagas only work with SQL databases and are not compatible with systems using NoSQL databases or event stores

From OWASP Top 10, what are 5 common vulnerabilities and how to prevent them?

OWASP Top 10 only applies to applications developed in Java and is not relevant for other programming languages or modern frameworks

Only SQL Injection is still relevant in 2024; the other OWASP Top 10 vulnerabilities have been eliminated by modern frameworks

The OWASP Top 10 is completely solved with just a WAF (Web Application Firewall) without needing changes to the application code

Injection (prepared statements), Broken Auth (MFA, session management), XSS (output encoding, CSP), SSRF (whitelist URLs, validate inputs), Security Misconfiguration (hardening, secure headers). Each requires defense in depth

What is the difference between unit, integration, and e2e tests, and what is the testing pyramid?

Unit: isolated function (fast, many). Integration: interaction between modules/services (real DB, APIs). E2E: complete user flow. Pyramid: many unit (base), fewer integration (middle), few e2e (top). Higher = slower but more confidence

Only e2e tests are needed because they cover the entire stack and make both unit tests and integration tests redundant

The testing pyramid indicates having more e2e tests than unit tests because e2e provides greater confidence in the complete system

Integration tests completely replace unit tests because they test the same functionality with greater coverage and real context

This code has a bottleneck: `async function exportUsers() { const users = await db.query("SELECT * FROM users"); return JSON.stringify(users); }` with 10K+ records. What is the problem?

The problem is using `async/await` instead of traditional callbacks; callbacks are more efficient for large database operations

Loads all records into memory at once and JSON serialization blocks the event loop. Solution: use streaming (DB cursor/pagination + JSON streaming with chunks or libraries like `JSONStream`) to process incrementally

`JSON.stringify` is always instant regardless of input size because V8 executes it in a separate thread automatically

The problem is exclusively the SQL query without WHERE clause; adding a filter resolves the bottleneck without needing architecture changes

Coding challenge

Design and implement a real-time notification system combining REST API with WebSockets, message queue with Redis pub/sub, and retry with exponential backoff. Include integration tests and document architectural decisions.

Requirements

REST API to manage subscriptions and query notification history
WebSocket server for real-time delivery with automatic reconnection
Message queue with Redis pub/sub to decouple producers and consumers
Retry with exponential backoff for failed deliveries (max 5 attempts)
Integration tests covering the full flow (send → queue → delivery)

Examples

Input:

POST /api/notifications { "userId": "123", "type": "order_update", "payload": { "orderId": "456", "status": "shipped" } }

Output: Notification queued in Redis, delivered via WebSocket to connected user, with delivery confirmation

Accepted technologies

Node.js + Socket.io/ws
Python + FastAPI + websockets
Go + gorilla/websocket
TypeScript + NestJS
Elixir + Phoenix Channels

Solution submission

Repository URL * Supported platforms: GitHub, GitLab, Bitbucket Enter a valid repository URL (https://github.com, gitlab.com, or bitbucket.org followed by owner/repository)