HR & Behavioural Full Stack with Node.js Interview Questions

Situation: our team needed real-time order tracking and nobody had used WebSockets. Task: I owned the feature with a two-week deadline. Action: I spent two evenings on the Socket.IO docs, built a small prototype, shared a short demo with the team and then added rooms and Redis adapter for scaling. Result: we shipped on time, and I wrote an internal guide others reused.

Situation: our search API p95 latency jumped from 200 ms to 2 seconds after a release. Task: as on-call engineer I had to find the cause fast. Action: I checked APM traces, saw a new synchronous JSON transform blocking the event loop, moved it to a cached precomputed field and added an event loop lag alert. Result: latency returned to normal within a day and we added a performance check to code review.

Situation: customers occasionally received two invoices. Task: I had to find why it happened only in production. Action: I added request IDs to logs and found a forEach with async callbacks plus a retry triggering a second save before the first finished. I replaced it with for...of, added a unique index on invoice number and made the job idempotent. Result: duplicates stopped completely.

I use a restaurant analogy. One waiter takes an order, gives it to the kitchen and serves other tables instead of waiting at the stove; when the dish is ready, the kitchen rings a bell. Node.js works the same: it starts a database or network task, handles other requests and resumes when the result is ready. Then I show a short code example with async and await.

Situation: I joined a project where Express routes contained SQL, business logic and responses in 300-line handlers. Task: reduce bugs without stopping feature work. Action: I proposed a controller-service-repository structure, added an error handler, validation with zod and tests for each refactored route, and moved one module per sprint. Result: bug reports dropped and new developers onboarded faster.

Situation: a senior wanted to store sessions in server memory for a new API. Task: I believed it would break when we scaled to multiple pods. Action: I prepared a short comparison, showed a demo where users were logged out after a restart, and suggested Redis sessions or JWT. Result: we agreed on Redis, and the senior asked me to document the decision for the team.

I would first understand why it is needed and who consumes the API. Then I explain the impact on existing clients, propose a non-breaking path such as adding a new field or a v2 endpoint, and estimate effort and risk. Result in a past case: we shipped the additive change on time and scheduled removal of the old field for the next quarter.

Situation: our support team used spreadsheets to track refunds. Task: I designed a refund API used by the admin panel and payment service. Action: I wrote the OpenAPI spec first, reviewed it with frontend and finance, added idempotency keys, clear error codes and pagination, and wrote contract tests. Result: integration took two days instead of a week, and refund errors dropped sharply.

Situation: during code review I noticed an admin export route that only hid the button in the frontend. Task: make sure no regular user could call it. Action: I reproduced it with a normal user token, reported it privately to my lead, added role middleware and tests, and checked similar routes. Result: we fixed four endpoints before release and added an authorisation checklist to pull requests.

I follow the Node.js security release announcements and OWASP cheat sheets, read GitHub security advisories for packages we use and keep Dependabot alerts on. I also practise with labs like OWASP Juice Shop. In my last project I used this to propose helmet, rate limits and stricter input validation, and I shared a short security checklist that the team adopted in pull request reviews.

Situation: I added a NOT NULL column with a default to a large MySQL table during business hours. Task: the migration locked the table and checkout slowed down. Action: I rolled back, rewrote it as add nullable column, backfill in batches, then add the constraint, and ran it at low traffic after testing on a production-size copy. Result: no downtime, and we added a migration review checklist.

Situation: our payment callback endpoint started failing after a deploy on a Friday evening. Task: I was on call. Action: I checked error logs, saw a missing environment variable, rolled back within ten minutes, then added startup config validation and a post-deploy smoke test. Result: impact was limited to a few failed callbacks we replayed, and I wrote a blameless postmortem the team used to improve deploy checks.

I inform my lead early with what I know, what I have ruled out and the risk. I propose a safe mitigation, such as a feature flag to disable the path or a rollback, and add extra logging to capture more data. In one case this let us release on time with the feature off, and the new logs revealed the cause two days later.

I would start by understanding why: lack of time, knowledge or examples. Then I pair with them on one feature, writing a test first for a real bug so they see the value. I share a small template for service and route tests, review their tests kindly in pull requests and celebrate when a test catches a regression. Over a few sprints, testing becomes a habit.

Situation: sales needed a partner API in one week for a client launch. Task: deliver fast without creating a mess. Action: I agreed with my manager to ship the core endpoints with validation, auth and tests, and to defer caching and admin tooling, logging them as tickets with dates. Result: the partner went live on time, and we completed the deferred work in the next sprint as planned.

I enjoy building the systems behind products: APIs, data models and integrations. Node.js lets me use JavaScript across the stack and ship features quickly, and I like solving problems around performance and reliability. In my projects I built a REST API with authentication, MongoDB and Docker deployment, and I want to grow by working on real traffic and learning system design from experienced engineers.

I list the requests with their business impact, deadlines and effort, then discuss priority with my manager or product owner rather than deciding alone. I communicate clear timelines to each team, look for shared solutions such as one generic endpoint serving two needs, and protect time for urgent production issues. This keeps expectations realistic and avoids half-finished work.

Situation: our five Node services used different logging and error formats, making incidents slow to debug. Task: as tech lead I wanted one standard. Action: I wrote a short RFC comparing options, built a shared package with pino, request IDs and an error handler, collected feedback and migrated one service as a pilot. Result: all services adopted it within a month and mean time to resolve incidents fell noticeably.

The PDF generation is CPU-bound and blocks the single event loop, so every other request waits. Fixes: move the work to a worker_threads pool such as Piscina, or push it to a background job queue like BullMQ with Redis and return a job ID that the client polls. Also break large loops into chunks and measure event loop lag to confirm the fix.

Synchronous file calls block the event loop for the whole read, so under load every request queues behind disk I/O and latency spikes. In a route, use fs.promises.readFile with await, or stream the file with fs.createReadStream and pipe it to the response. Sync calls are acceptable only at startup, for example reading a config file once before the server listens.