Backend Language Proficiency Questions

Demonstrate strong practical knowledge of a backend programming language such as JavaScript with Node dot js, Python, Java, Go, or similar. Cover language fundamentals, idiomatic usage, standard library features, package and dependency management, common frameworks and ecosystem tools, testing strategies and tooling, error handling and observability, and patterns for maintainable server side code. Be ready to explain concurrency and asynchronous models in the language, performance considerations, security best practices, deployment and packaging approaches, and examples of backend services or APIs you built including trade offs and chosen libraries.

HardTechnical

37 practiced

A Node.js ETL service shows increasing memory over time indicating a leak. Describe how to diagnose Node memory leaks: collect heap snapshots with --inspect, use Chrome DevTools or clinic/heapdump, analyze retaining paths, and fix common patterns (unbounded caches, forgotten event listeners). Provide example code of a leaking pattern and corrected code.

Sample Answer

Start by reproducing the leak and capturing heap state over time, then analyze retaining paths and fix root causes.

Diagnosis steps- Run the ETL process with the inspector: node --inspect=0.0.0.0:9229 app.js (or --inspect-brk to pause).- Trigger typical workload; collect heap snapshots periodically in Chrome DevTools > Memory (or use clinic/heapdump or node-heapdump to write .heapsnapshot files).- Take at least two snapshots: baseline and after workload. In DevTools compare “Heap snapshot” -> Dominators / Comparison to find objects that grow.- Inspect retaining paths for large retainedSize to see what is keeping objects alive (closures, arrays, maps, listeners).- Use clinic doctor/flame to correlate CPU + heap patterns for long-running leaks.

Common leak patterns & fixes- Unbounded caches/Maps/arrays: use size limits or LRU caches (lru-cache).- Forgotten event listeners: remove listeners when task completes; prefer once or setMaxListeners when needed.- Closures over large scopes: avoid capturing entire large objects; nulll out references when done.- Timers/intervals: clearInterval/clearTimeout on shutdown or after use.

Leaking example (unbounded Map + forgotten listener):

javascript

// leaking.js (bad)
const listeners = new Map();
function processJob(id, stream) {
  listeners.set(id, stream);        // never removed
  stream.on('data', () => {/*...*/}); // listener holds closure
}

Fixed version:

javascript

// fixed.js
const LRU = require('lru-cache');
const cache = new LRU({ max: 1000 }); // bounded
function processJob(id, stream) {
  cache.set(id, stream);
  const onData = () => {/*...*/};
  stream.once('end', () => {
    stream.removeListener('data', onData);
    cache.del(id);
  });
  stream.on('data', onData);
}

Key tips- Prefer weak references (WeakMap) for metadata tied to objects you don't own.- Automate snapshot collection in staging, add alerts on heap growth slope.- After fix, re-run snapshots and verify retained size decreases.

MediumTechnical

42 practiced

Design a testing strategy and CI pipeline for a Python data ingestion microservice. Cover unit tests, integration tests against ephemeral databases (Docker/testcontainers), contract tests for downstream consumers, and end-to-end acceptance tests. Explain test-data management, seeding, and approaches to reduce flakiness in integration tests.

Sample Answer

Requirements & goals:- Fast feedback for developers, high confidence before deploy, reliable reproducibility of integration/E2E tests, validate contracts with downstream consumers, minimize flakiness.

Testing layers1. Unit tests (fast, isolated)- Use pytest, mock external calls (requests, boto3, DB drivers) with pytest-mock.- Focus on parsing, transformation, small edge cases, validation logic.- Aim for >90% coverage on business logic, run in <1s per test.

2. Integration tests (ephemeral infra)- Use testcontainers-python or Docker Compose to spin up ephemeral Postgres/Kafka/S3-compatible (MinIO) per test-suite.- Tests run against real DB/Kafka clients but isolated environments. Use pytest fixtures to start/stop containers once per session or per test class.- Seed data via transactional SQL or use SQLAlchemy + alembic migrations to apply schema then load deterministic fixtures (YAML/JSON). Use immutable fixture files under tests/fixtures.- Use healthchecks and wait-for readiness (testcontainers built-ins) rather than sleeps.

3. Contract tests- Use consumer-driven contract testing (Pact) if downstream services are HTTP consumers; for message-driven contracts validate message schema (JSON Schema/Avro) and use pact-python or schema-registry checks.- Publish provider verification artifacts to a broker (Pact Broker or internal artifact store) run in CI step that verifies provider meets consumer expectations.

4. End-to-end acceptance- Deploy the microservice and minimal dependent stack to ephemeral environment (Docker Compose, Kind/k3s) and run scenario tests that exercise full ingestion path, validating final persisted state and downstream outputs.- Keep E2E smaller and run on merge to main or nightly.

Test-data management & seeding- Keep canonical fixtures in version control (JSON/CSV/YAML). Prefer small datasets that exercise edge cases.- Use migrations to create schema deterministically; seed via transactional scripts that are idempotent.- For randomized data, use deterministic seeds and record seed values in test logs to reproduce failures.- Clean state between tests by wrapping each test in a transaction with rollback where possible, or recreate ephemeral DB per test class.

Reducing flakiness- Avoid timing-based asserts; poll with timeouts and exponential backoff for async operations.- Use readiness checks and health endpoints for services before running assertions.- Limit network dependency: run all dependencies in CI, mock external third-party APIs with VCR or local stub servers.- Run flaky tests in isolation and capture verbose logs, enable retry only as last resort with jittered backoff.- Parallelize safe tests with pytest-xdist; isolate shared resources.

CI pipeline (example stages)1. Pre-commit: black, isort, flake8, mypy2. Unit tests: run pytest for fast feedback, run in parallel3. Build & static checks: build docker image, security scanning4. Integration tests: spin ephemeral infra via testcontainers/docker-compose; run DB/Kafka integration suites5. Contract verification: fetch consumer contracts from broker, run pact/provider verification6. E2E acceptance: deploy to ephemeral k8s (kind) or Docker Compose, run smoke scenarios7. Publish: on success, tag image and promote to staging

Practical tips- Cache Docker layers and test artifacts in CI to shorten runtime.- Keep integration and E2E suites targeted and limited in data volume.- Collect and store test artifacts (DB dumps, logs, traces) on failures for debugging.- Make tests part of PR checks; allow longer E2E/contract runs to gate main branch merges.

EasyTechnical

45 practiced

Explain how to manage Python project dependencies for reproducible deployments. Describe and contrast virtualenv + requirements.txt, pipenv, poetry, and using Docker. Show an example requirements.txt snippet and explain how to pin versions and produce a lockfile for production builds.

Sample Answer

For reproducible Python deployments you want two guarantees: (1) isolated environments so dependencies don’t collide, and (2) pinned, immutable dependency graphs so builds are reproducible across machines and CI. Below I compare common approaches and show how to pin and produce lockfiles.

Virtualenv + requirements.txt- Creates an isolated interpreter per project. Simplicity and low surface area.- Use requirements.txt with pinned versions (exact equals) for reproducibility.- Produce lock: pip freeze > requirements.txt (or better, maintain manually or via pip-tools).- Good for simple pipelines; less dependency resolution intelligence.

Pipenv- Combines virtualenv management and dependency resolution; creates Pipfile (human-editable) and Pipfile.lock (deterministic).- pipenv install adds to Pipfile and lockfile; pipenv lock produces Pipfile.lock for CI.- Pros: nicer UX than raw pip; cons: slower, sometimes ecosystem quirks.

Poetry- Modern tool focused on deterministic builds, semantic versioning, and publishing. Uses pyproject.toml and poetry.lock.- poetry add PACKAGE updates pyproject.toml and poetry.lock; poetry lock produces lockfile.- Strong dependency resolver and recommended for reproducible builds in many teams.

Docker- Encapsulates entire runtime (OS + Python + dependencies). Most reproducible deployment method.- Use any of the above inside a Dockerfile and COPY your lockfile; build in CI to produce identical images.- Example workflow: use poetry/pipenv/requirements inside Dockerfile so the image is the single artifact deployed.

Example requirements.txt (pinned):

text

numpy==1.25.1
pandas==2.2.1
pyarrow==12.0.0
boto3==2.10.0
fastparquet==0.8.1

How to pin and produce lockfile for production- Pin exact versions (==) in requirements.txt or use a lockfile produced by the tool: - pip + pip-tools: pip-compile pyproject.in -> requirements.txt (deterministic). - pipenv: pipenv lock -> Pipfile.lock - poetry: poetry lock -> poetry.lock- In CI, build from the lockfile (pip install -r requirements.txt --no-deps? usually with --require-hashes or using wheel caches) or use poetry install --no-dev --no-interaction.- Best practice for data engineering: create artifacts (wheels or Docker images) in CI from a lockfile and deploy the artifact; store the lockfile in source control; rebuild images only in CI to keep production reproducible.

HardSystem Design

34 practiced

Design a zero-downtime deployment strategy for a stateful Java caching service that holds in-memory caches. Consider blue/green, rolling with draining, cache warming, client-side retries, in-flight requests, and data format migrations. Provide a step-by-step plan to deploy a change that alters cache format without taking the system offline.

Sample Answer

Requirements & constraints:- Zero downtime for clients; preserve in-flight requests and cache consistency- Stateful Java service with in-memory caches (per-instance)- Change alters cache value format (schema/version)- Support client-side retries and graceful routing- Prefer cloud-native patterns (k8s) but generic

High-level approach: multi-version compatible format + blue/green (dual readers/writers) + rolling draining + cache warming + staged migration.

Step-by-step plan:

1. Design format versioning- Define VersionedPayload {version, payload}. Implement backward/forward adapters in service to read vN and produce vM when returning to clients.- Provide conversion utilities: upgrade(old)->new and downgrade(new)->old where feasible.

2. Add compatibility layer (code change 1)- Deploy code that can read both old and new formats but continues to write the old format. This is safe and backward compatible.- Unit/integration tests for mixed-format handling.

3. Blue/Green prep & client routing- Deploy a green environment (new code) alongside blue. Use a feature-flag or service discovery flag to route a fraction of traffic to green (canary), starting at 1–5%.

4. Cache warming for green- Implement proactive warming: green instances on startup fetch hot keys from a persistent source or request active keys from blue (preload via background job). Use async population to avoid blocking requests.- Optionally use a shared read-through backing store to populate caches.

5. Canary & observe- Route small traffic to green; green reads old-format entries and serves via adapter. Monitor errors, latency, hit/miss rates, and conversion correctness.

6. Data migration (online, incremental)- Start background migration: for hot keys accessed on green, read old value, convert to new format, write new-format into cache (and optionally persist converted value back to backing store). Use write-through with a tombstone/version tag.- For keys updated by clients: write both formats (dual-write) or write new-format and also write converted old-format if downstream consumers need it.

7. Rolling upgrade with draining- Gradually increase traffic to green while draining blue instances: mark blue instance as draining in service registry, stop accepting new requests, finish in-flight requests, flush or persist cache entries if needed, then terminate.- Ensure during drain that cached state is optionally replicated to green instances (snapshot/transfer) for very hot sets.

8. Client-side resilience- Ensure clients implement retries with idempotency and exponential backoff. Clients should prefer service discovery and handle transient 5xx or 502s. Feature-flag to pick green endpoints.

9. Full switch & cleanup- After all traffic on green, ensure cache stores are predominantly new-format. Flip traffic fully to green.- Remove compatibility layer in a later deploy once no old-format reads occur (monitor metric “old-format reads = 0” for a conservative period).- Clean up any dual-write or downgrade code and migration jobs.

Key operational concerns:- Metrics: format-read counts, conversion failures, cache hit/miss, end-to-end latency- Backing store as source-of-truth for re-warm and authoritative conversion- Idempotency: ensure conversions are idempotent; include version tags with TTLs- Rollback: if green fails, route back to blue immediately; keep blue until new-format stable- Data migrations that are irreversible: snapshot backups, canary conversion on subset of keys first.

Why this works:- Compatibility-first avoids breaking reads during transition.- Canary + blue/green isolates risk and provides fast rollback.- Cache-warming and background migration minimize cold-starts and latency spikes.- Draining preserves in-flight requests and avoids losing state.

MediumTechnical

37 practiced

You need to implement an idempotent POST endpoint in Java Spring Boot to create user profiles. Design and outline the implementation focusing on idempotency: accept a client-provided idempotency-key header, store request and result, ensure concurrent duplicate requests create a single resource. Include a database table schema snippet for idempotency metadata and discuss transaction boundaries and unique constraints.

Sample Answer

Approach (brief): accept Idempotency-Key header; persist an Idempotency record (key, status, request_hash, response_payload, created_at, expires_at). Use a DB unique constraint on idempotency_key to serialize creators; wrap create-or-acquire and profile creation in a single DB transaction when possible. On concurrent requests, the first wins and others return stored response.

Database schema (Postgres snippet):

sql

CREATE TABLE idempotency (
  id BIGSERIAL PRIMARY KEY,
  idempotency_key TEXT NOT NULL UNIQUE,
  user_id UUID,                      -- populated after creation
  request_hash TEXT,                 -- optional: verify same payload
  response_payload JSONB,            -- stored response (or location header)
  status VARCHAR(20) NOT NULL,       -- PENDING, COMPLETED, FAILED
  created_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
  updated_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
  expires_at TIMESTAMP WITH TIME ZONE
);

Implementation outline (Spring Boot service):- Controller reads Idempotency-Key header, computes optional requestHash (hash of body).- Call service.createUserProfile(idemKey, requestDto).- Service logic (transactional): 1. Try insert idempotency row with status='PENDING' (INSERT ...). If insert succeeds, proceed to create user profile. 2. If insert fails due to unique constraint, SELECT row FOR UPDATE (or simple SELECT) to read status: - If status='PENDING': wait/retry with short backoff or return 409/202 depending on policy. - If status='COMPLETED': return stored response_payload. - If status='FAILED': optionally allow retry if request_hash matches. 3. After creating user (in same transaction or another depending on DB ops), update idempotency row: set user_id, response_payload, status='COMPLETED', updated_at. 4. Commit transaction and return response.

Sample service pseudo-code (key parts):

java

@Transactional
public Response createUserProfile(String idemKey, UserDto dto) {
  try {
    idempotencyRepo.insert(new Idempotency(idemKey, "PENDING", hash(dto)));
    User user = userRepo.save(mapToEntity(dto)); // creates profile
    Idempotency rec = idempotencyRepo.findByKeyForUpdate(idemKey); // optional
    rec.setUserId(user.getId());
    rec.setResponsePayload(serializeResponse(user));
    rec.setStatus("COMPLETED");
    idempotencyRepo.save(rec);
    return buildResponse(user);
  } catch (DataIntegrityViolationException e) {
    // unique constraint hit — another request in-flight or completed
    Idempotency existing = idempotencyRepo.findByKey(idemKey);
    if ("COMPLETED".equals(existing.getStatus())) {
      return deserializeResponse(existing.getResponsePayload());
    } else if ("PENDING".equals(existing.getStatus())) {
      // either poll/wait, or return 202 Accepted with retry-after
      throw new ResponseStatusException(HttpStatus.ACCEPTED, "Request in progress");
    } else {
      // FAILED or mismatch: allow retry if payload hash matches
    }
  }
}

Transaction boundaries & isolation:- Use a transaction that covers inserting the PENDING idempotency row and the creation of the user when possible. This prevents other requests from proceeding beyond unique constraint. If user creation calls external systems, consider two-phase approach: insert PENDING (commit), perform external call, then update to COMPLETED in a second transaction. That requires handling PENDING reconciliation (background job to pick up stale PENDING rows).- Use UNIQUE(idempotency_key) to enforce single creator. Optionally SELECT ... FOR UPDATE to read/lock the row for readers.- Set reasonable expires_at to garbage-collect old idempotency records.

Edge cases & best practices:- Store enough response data (location, resource id) to return identical responses.- Compute and compare request_hash to detect different payloads using same key — if mismatch, return 409.- Protect against long-running PENDING by background sweeper to mark timeouts or retries.- Consider optimistic approaches for high scale: use idempotency table in fast KV store (Redis) with atomic SETNX+value and a durable write to DB asynchronously, ensuring durability trade-offs are acceptable.

Unlock Full Question Bank

Get access to hundreds of Backend Language Proficiency interview questions and detailed answers.

Join thousands of developers preparing for their dream job.