Backend Engineer

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·StarterA client times out and retries automatically. For which request is a blind retry unsafe without extra protection?

   POST /payments creating a paymentGET /orders?page=2DELETE /sessions/abcPUT /users/42 with the full user body
2. Question 2 of 4·StarterA properly logged-in user calls an admin-only endpoint. Which status code fits?

   401 Unauthorized, because the user lacks the permission422 Unprocessable Content, because the role field is invalid403 Forbidden, because the identity is known but not allowed400 Bad Request, because the request targets the wrong endpoint
3. Question 3 of 4·StarterA frontend at https://app.example.com calls the API with cookies. The server returns Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true, but the browser still blocks it. What is the right fix?

   Echo back whatever Origin value the client sendsAdd the Access-Control-Allow-Origin header to the frontend fetch requestReturn the specific origin from an allowlist, such as https://app.example.com, with Vary: OriginTurn off CORS on the server with Helmet
4. Question 4 of 4·StarterThe app runs behind a load balancer and logs show every request coming from 10.0.0.5. What is the right fix?

   Ask clients to send their IP in a custom headerUse req.socket.remoteAddress instead of req.ipConfigure the app to trust only your own proxy (trust proxy) so it reads the client IP from X-Forwarded-ForAlways read X-Forwarded-For from every request regardless of source

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·StarterWhy does one JSON.parse on a 200MB payload slow down every concurrent request?

   Because JSON.parse uses the libuv thread pool, which has only 4 threadsBecause Node creates a process per request and they share memoryBecause V8 pauses all network I/O while parsing JSONBecause it runs synchronously on the single JavaScript thread, so the event loop cannot run other callbacks until it finishes
2. Question 2 of 4·StarterA handler runs await Promise.all(images.map((img) => resizeInJs(img))), where resizeInJs is async but pure JavaScript computation. What happens?

   Each image runs in its own microtask, so other requests are not blockedNode automatically moves async functions to the libuv thread poolThe resizing still runs sequentially on the main thread and blocks the event loop; worker_threads are needed to use more coresThe images are processed in parallel on several cores thanks to Promise.all
3. Question 3 of 4·StarterAn endpoint must return a 2GB CSV built from the database. What is the right approach?

   Chain dbCursorStream.pipe(toCsvTransform).pipe(res) and skip error handlingBuild the whole CSV as one string and call res.send(csv)await pipeline(dbCursorStream, toCsvTransform, res) so backpressure and errors are handled end to endWrite the CSV to a temp file with writeFile, then readFile it and send the buffer
4. Question 4 of 4·StarterA team wants to run a NestJS app with node src/main.ts using Node's built-in type stripping. What breaks?

   Only tsconfig path aliases stop workingOnly ESM imports fail; everything else runs normallyNothing, type stripping is equivalent to compiling with tscDecorators are not transformed and cause a parse error, and no decorator metadata is emitted; Nest needs a real compile step

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·StarterWhy is keyset pagination better than offset on a large, constantly changing table?

   Because OFFSET cannot be combined with ORDER BYBecause keyset needs no index at allBecause OFFSET must scan and discard earlier rows and shifts when new rows are inserted, while keyset uses an index and stays stableBecause keyset lets you jump straight to any page number
2. Question 2 of 4·StarterWhy is returning 200 with { "error": "not found" } in the body a bad design?

   Because clients cannot read the body when the status is 200Because caches, retry logic and monitoring all treat it as successBecause a 200 must include a Content-Length headerBecause JSON bodies may not contain an error key
3. Question 3 of 4·StarterA client sends POST /payments with Idempotency-Key: k1 and amount 100, then resends key k1 with amount 500. What should the server do?

   Process it as a new payment of 500Reject the second request with an error because the key was used with a different bodySilently return the stored result for the 100 paymentOverwrite the stored result with the 500 payment
4. Question 4 of 4·StarterYou need to rename the user_name field to username in a public API. What is the right approach?

   Add username, keep user_name marked deprecated with the Deprecation and Sunset headers, then remove it in a later versionRename it and bump the minor versionReturn both fields forever without telling anyoneRename it in place because only one known client uses it

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateA NestJS route has a middleware, a guard, an interceptor and a ValidationPipe. In what order do they run before the handler?

   Guard, middleware, pipe, interceptorMiddleware, guard, interceptor, pipeMiddleware, pipe, guard, interceptorMiddleware, interceptor, guard, pipe
2. Question 2 of 4·IntermediateWhy should you not make a provider request-scoped just to read the current user?

   Because request-scoped providers cannot access the request objectBecause request scope makes the provider shared across requestsBecause Nest does not allow guards to inject request-scoped providersBecause the scope bubbles up to every provider that injects it, so the whole chain is recreated per request and performance suffers; use AsyncLocalStorage such as nestjs-cls instead
3. Question 3 of 4·IntermediateCreateUserDto only has email and name. An attacker adds "isAdmin": true. Which ValidationPipe config returns a 400 instead of silently dropping the field?

   { transform: true }{ whitelist: true }{ forbidUnknownValues: true }{ whitelist: true, forbidNonWhitelisted: true }
4. Question 4 of 4·IntermediateOrderService catches every error and returns null, and the controller returns 200 with an empty body when an order is missing. What is the right fix?

   Log the error in the service and keep returning nullCheck for null in every controller and set 404 manuallyThrow a domain error such as OrderNotFoundError and map it to 404 in an exception filterReturn an empty object {} instead of null

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateThe code runs a SELECT to check whether an email exists, then an INSERT. Why can duplicate emails still appear?

   Because two concurrent requests both see no row and both insert; a UNIQUE constraint in the database is neededBecause PostgreSQL SELECT ignores recently committed dataBecause the ORM caches the SELECT resultBecause the INSERT runs before the SELECT in the same transaction
2. Question 2 of 4·IntermediateWhen using the Serializable isolation level in PostgreSQL, what must the application do?

   Retry the transaction when it fails with a serialization failureDisable autocommit on the whole connection poolAdd FOR UPDATE to every SELECT or Serializable has no effectNothing, Serializable only waits for other transactions so it never errors
3. Question 3 of 4·IntermediateThe query WHERE tenant_id = $1 AND created_at > $2 ORDER BY created_at is slow. Which index fits best?

   A GIN index on tenant_idTwo separate indexes on tenant_id and created_at(tenant_id, created_at)(created_at, tenant_id)
4. Question 4 of 4·IntermediateYou must add a required status column (derived from existing data) to a 50 million row table under constant writes. Which approach avoids long write locks?

   Create an index CONCURRENTLY on the new column so NOT NULL does not lockRun the ALTER TABLE during off-peak hours and accept the table lockAdd a nullable column, backfill in batches, add CHECK (status IS NOT NULL) NOT VALID, then VALIDATE it in a separate stepAdd a nullable column, run one UPDATE over the whole table, then SET NOT NULL in the same migration

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateWhy are long-lived JWTs (say 30 days) a problem when a user logs out or is disabled?

   Because long-lived JWTs cannot carry an aud claimBecause long JWTs make the cookie exceed its size limitBecause JWTs are stateless and stay valid until they expire, with no revocation unless you add a denylistBecause JWTs are encrypted, so the server cannot read the exp claim
2. Question 2 of 4·IntermediateWhat does PKCE protect the authorization code flow against?

   It binds the authorization code to the client that started the flow, so a stolen code cannot be exchanged for tokensIt lets clients skip HTTPS when exchanging the codeIt replaces the need to register redirect URIsIt encrypts the access token so nobody can read it
3. Question 3 of 4·IntermediateThe GET /invoices/:id handler runs after an auth guard and calls invoiceRepo.findById(id). What is wrong and how do you fix it?

   The id may be invalid; adding ParseIntPipe is enoughBOLA: any logged-in user can read other users' invoices; scope the query by the authenticated principal's owner or tenantMissing rate limiting; add a throttler to the routeNothing, because the auth guard already checked the token
4. Question 4 of 4·IntermediateWhat is the right way to store user passwords?

   AES encryption with a key stored in an environment variableHash with Argon2id or bcrypt using suitable cost parametersStore the MD5 of the password concatenated with the emailSHA-256 with a random per-user salt

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateA hot cache key expires and 1,000 requests hit the database at once. What reduces this?

   Request coalescing (single-flight) so only one request reloads the key, plus jitter on TTLsIncrease the database connection pool sizeRemove the TTL so the key never expiresUse identical TTLs for every key so expiry is predictable
2. Question 2 of 4·IntermediateWhy use a transactional outbox instead of publishing the event right after the commit?

   Because if the process crashes between commit and publish the event is lost; the outbox writes the event in the same transaction and relays it laterBecause the outbox makes the broker process events fasterBecause the outbox guarantees each event is delivered exactly onceBecause brokers reject events sent from request code
3. Question 3 of 4·IntermediateA BullMQ job that sends a welcome email sometimes runs twice. What is the right fix?

   Record the processed job or message key with a unique constraint and skip it if it already existsDrop the worker concurrency to 1Set attempts: 1 so the job never retriesEnable removeOnComplete so finished jobs are deleted immediately
4. Question 4 of 4·IntermediateRedis, used as a cache, goes down. How should the service behave?

   Crash the process so the orchestrator restarts itReturn empty lists from endpoints that read from the cacheReturn 503 for every request until Redis is backRead straight from the database with a short timeout on the Redis client, slower but still correct

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateWhy is heavily mocking the ORM in repository tests a weak approach?

   Because mocks always break when the ORM version is upgradedBecause mocks make tests slower than a real databaseBecause the test only verifies mock calls and proves nothing about the real SQL, constraints or migrationsBecause ORMs cannot be mocked in TypeScript
2. Question 2 of 4·IntermediateWhy are integration tests against real PostgreSQL via Testcontainers better than in-memory SQLite?

   Because Testcontainers runs faster than in-memory SQLiteBecause SQLite cannot be used with an ORMBecause the same engine and version as production means SQL dialect, constraints, jsonb and migrations are actually exercisedBecause SQLite does not support transactions
3. Question 3 of 4·IntermediateHow do you test that the OrderPaid event consumer is idempotent?

   Check that the handler does not throw when receiving the eventDeliver the same message twice and assert the side effect (such as a ledger entry) happens onceSnapshot the event payloadCheck that retries are enabled on the queue
4. Question 4 of 4·IntermediateYou need to test token expiry after 15 minutes. What is the right approach?

   Change production code to read Date from an overridable globalSet the expiry to 1 second through an env variable and sleep 2 secondsLet the test actually wait 15 minutes in CIInject a clock or use fake timers and advance time past 15 minutes

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·AdvancedWhat is BOLA (broken object level authorization), the top item in the OWASP API Security Top 10?

   Calling the API without logging inResponses returning too much data and slowing clients downThe server calling a URL controlled by the attackerAn authenticated user accessing another user's objects just by changing an ID in the request
2. Question 2 of 4·AdvancedWhy redact sensitive fields in the logger config (for example Pino redact paths) instead of at each log call site?

   Because redacting in the logger makes logs smaller and cheaperBecause Pino cannot remove fields after they are loggedBecause doing it centrally means it cannot be forgotten at a new call siteBecause log platforms skip redacted fields when searching
3. Question 3 of 4·AdvancedA link preview endpoint fetches a user-supplied URL. An attacker sends http://169.254.169.254/latest/meta-data/. What is the right fix?

   Check that the URL starts with http or httpsSet a 2-second timeout on outbound requestsAllow only valid hosts, resolve DNS and block internal and link-local IP ranges before sending the requestAdd rate limiting to the endpoint
4. Question 4 of 4·AdvancedThe team suffers from alert fatigue. Which alert should stay for the checkout service?

   Every time a single 500 appears in the logsNode heap above 1GBCPU above 80% for 5 minutes on any podError budget burn rate for the checkout latency and error SLO above threshold over 1 hour

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·AdvancedWhy should the liveness probe not check the database connection?

   Because liveness only runs once when the container startsBecause a database blip marks every pod dead and restarts them all at once, making the incident worse; dependency checks belong in readinessBecause liveness probes are not allowed to open network connectionsBecause the database will block connections from probes
2. Question 2 of 4·AdvancedWhy do retries need exponential backoff with jitter?

   So clients do not retry in sync, preventing a small outage from becoming a retry stormSo each request is guaranteed to succeed on the second tryBecause jitter helps requests hit the CDN cacheSo the server can tell original requests from retries
3. Question 3 of 4·AdvancedAn API key exceeds its requests-per-minute limit. What is the right response?

   403 Forbidden503 Service Unavailable429 Too Many Requests with a Retry-After header200 with { "error": "rate limited" }
4. Question 4 of 4·AdvancedA user updates their profile (written to the primary), and the next page reads from a read replica and still shows old data. What is the right fix?

   Add more read replicasRetry the read in a loop until the change appearsAdd a cache layer in front of the replicaEnsure read-your-writes: read from the primary for that user briefly after a write, or wait until the replica catches up to the write position