Technical Background and Programming Skills Questions

Clearly communicate your programming experience, including languages you're proficient in (C#, C++, JavaScript, Python). Mention any relevant coursework in data structures, algorithms, computer graphics, or physics simulation. Be honest about knowledge gaps while showing willingness to learn.

MediumTechnical

52 practiced

Write a Python function merge_intervals(intervals: List[Tuple[int,int]]) -> List[Tuple[int,int]] that merges overlapping intervals and returns the merged list sorted by start time. Describe the time and space complexity and how you'd adapt this to handle intervals expressed as floats or datetime objects.

Sample Answer

Approach: Sort intervals by start, then iterate merging current with next when they overlap (next.start <= current.end). This is O(n log n) due to sort and O(n) scan.

python

from typing import List, Tuple

def merge_intervals(intervals: List[Tuple[int,int]]) -> List[Tuple[int,int]]:
    """
    Merge overlapping intervals and return list sorted by start.
    """
    if not intervals:
        return []
    # Sort by start time
    intervals = sorted(intervals, key=lambda x: x[0])
    merged = []
    cur_start, cur_end = intervals[0]
    for s, e in intervals[1:]:
        if s <= cur_end:            # overlap or touch
            cur_end = max(cur_end, e)
        else:
            merged.append((cur_start, cur_end))
            cur_start, cur_end = s, e
    merged.append((cur_start, cur_end))
    return merged

Key points:- Sorting ensures we only need one linear pass to merge.- Handles touching intervals (e.g., (1,2) and (2,3)) as overlapping; adjust condition to s < cur_end if you treat touching as separate.

Time complexity: O(n log n) dominated by sort. Space complexity: O(n) for output and O(1) extra if sort in place (Python sort uses O(n) auxiliary).

Adaptation for floats or datetimes:- Code works unchanged for floats as comparisons and max work the same.- For datetime, ensure intervals are tuples of datetime objects (from datetime import datetime). Comparisons and max still valid. If input mixes types, normalize to a common comparable type (e.g., timestamps via .timestamp()) before merging, then convert back.

MediumTechnical

40 practiced

Design and implement a compact binary serializer for NumPy ndarrays in Python that includes dtype, shape, and raw bytes. Provide code (or pseudocode) for serialize/deserialize, discuss endianness, alignment, and backward compatibility/versioning. Explain when you'd prefer using Apache Arrow or Protobuf instead.

Sample Answer

Approach: pack a small header (magic, version, dtype str, shape length + dims) followed by raw ndarray.tobytes(). Store dtype as its str (e.g. "<f8"), shape as integers, and data length. Use struct for deterministic binary layout and include explicit endianness in the dtype string. Provide version number to allow backward-compatible changes.

python

import struct
import numpy as np

MAGIC = b'NPYB'   # magic bytes
VERSION = 1       # 1 byte version
HEADER_FMT = '<4sBHI'  # magic(4), version(1), dtype_len(2), ndim(4) - little-endian

def serialize(arr: np.ndarray) -> bytes:
    dtype_str = arr.dtype.str.encode('ascii')  # includes endianness like '<f8' or '>i4' or '|u1'
    dtype_len = len(dtype_str)
    ndim = arr.ndim
    shape = arr.shape
    # pack header
    header = struct.pack(HEADER_FMT, MAGIC, VERSION, dtype_len, ndim)
    # pack dtype string and shape ints (each int64)
    shape_fmt = '<' + 'q'*ndim
    shape_bytes = struct.pack(shape_fmt, *shape)
    body = arr.tobytes(order='C')  # explicit C-contiguous bytes
    length = struct.pack('<Q', len(body))  # uint64 length of body
    return header + dtype_str + shape_bytes + length + body

def deserialize(buf: bytes) -> np.ndarray:
    off = 0
    magic, version, dtype_len, ndim = struct.unpack_from(HEADER_FMT, buf, off)
    off += struct.calcsize(HEADER_FMT)
    assert magic == MAGIC, "bad magic"
    dtype_str = buf[off:off+dtype_len].decode('ascii'); off += dtype_len
    shape_fmt = '<' + 'q'*ndim
    shape = struct.unpack_from(shape_fmt, buf, off); off += struct.calcsize(shape_fmt)
    (body_len,) = struct.unpack_from('<Q', buf, off); off += 8
    body = buf[off:off+body_len]
    # interpret dtype (includes endianness); use np.dtype to parse
    dtype = np.dtype(dtype_str)
    arr = np.frombuffer(body, dtype=dtype)
    return arr.reshape(shape, order='C').copy()  # copy to detach from buffer

Key points:- Endianness: dtype.str contains byte-order; we preserve it. When transferring between machines with different endianness, numpy will handle byte-swapping when you .astype() to native byteorder. Alternatively, normalize to little-endian on serialize to simplify receivers.- Alignment: storing raw bytes sequentially avoids alignment gaps; shapes as int64 keep parsing simple. Use C-order consistently or include order flag in header.- Versioning/backward compatibility: VERSION field lets you add fields later. When reading, handle unknown older/newer versions gracefully (ignore optional sections, provide compatibility code paths).- Safety: validate magic/version and bounds for lengths to avoid malformed inputs.- Complexity: serialization is O(n) time and O(1) extra mem if using tobytes (may allocate); deserializing with frombuffer can avoid copy but risks referencing external buffer — choose .copy() if safety required.

When to prefer Arrow or Protobuf:- Use Apache Arrow when you need high-performance, zero-copy analytics across languages and efficient columnar memory format (many large arrays, columnar operations, IPC between processes, in-memory analytics).- Use Protobuf when you need a schema-driven, language-neutral RPC/message format with strict typing and forwards/backwards compatibility for complex messages (but Protobuf doesn't natively carry raw n-dimensional array efficiency — you'd typically embed bytes or use helper libs).- Use this custom serializer when you need a minimal, fast, self-contained binary for numpy arrays with low overhead and simple interop (Python-centric workflows). For cross-language, at-scale analytics, choose Arrow; for RPC/messages with structured fields, choose Protobuf.

EasyTechnical

56 practiced

Compare error/exception handling models across Python (exceptions), Java/C# (checked/unchecked distinctions), and C++ (throw/catch). For a production ETL pipeline, propose an error-handling strategy that preserves reproducibility, enables safe retries, and keeps clear audit logs. Give examples of when to raise, retry, or swallow errors.

Sample Answer

Brief comparison:- Python: runtime exceptions only. Raising and catching is flexible; no compiler-enforced handling. Good for rapid prototyping but requires disciplined docstrings/types and custom exception hierarchies for clarity.- Java/C#: checked (Java) vs unchecked (runtime) distinction — Java’s checked exceptions force callers to handle or declare, encouraging early handling; C# uses unchecked-only like Python but with rich exception types. Checked exceptions can bloat signatures; unchecked simplify APIs.- C++: throw/catch with value-or-reference semantics, RAII and destructors affect cleanup. Exception safety levels (basic/strong/no-throw) are important for resource-managed code.

Production ETL strategy (goals: reproducibility, safe retries, clear audit):1. Error taxonomy & types: define transient (network, DB deadlocks), permanent (schema mismatch, corrupt file), and soft/non-fatal (missing optional field). Map to exception classes.2. Deterministic processing & idempotency: make steps idempotent (write-to-temp then atomically move), include input hashes and processing parameters in metadata so reruns are reproducible.3. Centralized error handler & audit logs: capture exception type, stack, input ID, input checksum, parameters, timestamp, and pipeline stage to an append-only audit store (e.g., structured logs + DB).4. Retry policies: automatic exponential backoff for transient errors with limited attempts; on each retry log attempt number and snapshot of relevant state. Use circuit-breakers to avoid thrashing.5. Fail-fast vs continue: fail the job on permanent errors; for large batches, isolate and mark bad records (dead-letter queue) so the rest proceeds.

When to raise, retry, or swallow:- Raise: schema mismatch, corrupted file, or invariant violation — these are permanent and should abort so you can fix data/contract.- Retry: network timeouts, temporary DB locks, rate limits — implement retry with backoff and attempt limits.- Swallow (but log and mark): missing optional fields, minor parse warnings — continue processing but record counts and examples for downstream QA.

Example: reading S3 file fails with HTTP 500 → retry up to 5 times with exponential backoff and log each attempt. File fails JSON schema validation → raise, write filename + error to dead-letter table, alert owner. Missing optional "middle_name" field → swallow, set null, increment metrics.

This approach preserves reproducibility (store inputs/checksums and parameters), enables safe retries (idempotent steps + controlled backoff), and provides clear audit trails for debugging and compliance.

HardTechnical

56 practiced

In C++, design a compact and efficient serialization layout for a vector<MyStruct>, where MyStruct contains fixed-size numeric fields and variable-length strings. Provide a layout that minimizes copies (fixed region + string offsets + packed string blob), discuss alignment and padding, endianness, and how to safely evolve the schema (versioning) while enabling zero-copy deserialization where possible.

Sample Answer

Approach: store N fixed-size records (MyStructFixed) in a contiguous fixed region, then an offsets table (uint32/64 per string per record) that points into a packed string blob that immediately follows. This avoids per-string pointers and enables zero-copy mapping of blob into memory; only offsets need relocation if mapped. Include schema header with magic, version, counts, and endian marker.

Layout (byte order):[Header: magic(4), version(2), flags(2), count(u32), fixed_region_size(u64)] [Fixed region: N * MyStructFixed] [Offsets region: for each record: offset(s) and length(s) as u32] [String blob: concatenated UTF-8 bytes]

Example C++ types and (de)serialization skeleton:

cpp

struct Header { uint32_t magic; uint16_t version; uint16_t flags; uint32_t count; uint64_t fixed_size; };
#pragma pack(push,1)
struct MyStructFixed { int64_t id; double score; uint32_t str1_off; uint32_t str1_len; uint32_t str2_off; uint32_t str2_len; };
#pragma pack(pop)

// Serialize: write Header, write vector<MyStructFixed> with string offsets computed, write offsets region if separate, then string blob (no per-string copying beyond concatenation).
// Zero-copy read: mmap file, verify header, treat fixed region as array<MyStructFixed>, and for each string use pointer = base + fixed_region_size + offset.

Alignment & padding:- Use #pragma pack(1) for on-disk layout to avoid compiler padding; in-memory structs can be different—copy into packed struct when needed.- Align fixed region size to 8 or 64 bytes if mmap performance requires it.

Endianness:- Store in network (big-endian) or choose little-endian with an endian flag in header. Convert on read/write when host differs using fast SIMD/byte-swap when needed.

Versioning & schema evolution:- Header version number + feature flags. Design fixed region with reserved bytes or a TLV extension table after fixed region for optional fields. For additive changes, append new fields into an "extensions" blob; older readers ignore unknown extension tags. Use field IDs for compatibility.

Zero-copy safety:- Keep all offsets relative to start-of-string-blob (or start-of-file) so they don't contain pointers. Ensure memory-mapped buffer remains immutable while views reference it. Validate bounds on all offsets/lengths before using. For security, bound-check and fail fast on corrupt data.

Trade-offs:- Minimal copies and fast bulk reads vs complexity for random updates (in-place string growth is hard). Use copy-on-write or log-structured updates for mutability.

EasyTechnical

84 practiced

In JavaScript implement a function makeCounter() that returns an object with methods increment() and value() using closures to keep the internal count private. Explain why closures are useful and give a practical example where this pattern helps in a data visualization front-end (for example, tracking user interactions or debounced counters).

Sample Answer

To implement makeCounter with a private internal count, use a closure that encloses the count variable and returns an object exposing controlled methods:

javascript

function makeCounter(initial = 0) {
  // `count` is private to the closure
  let count = initial;

  return {
    // increments and returns the new value
    increment() {
      count += 1;
      return count;
    },
    // returns the current value without exposing `count` directly
    value() {
      return count;
    }
  };
}

// Example usage:
const c = makeCounter(10);
c.increment(); // 11
c.value();     // 11

Why closures are useful:- They encapsulate state (count) so external code cannot mutate it directly, enforcing invariants and reducing bugs.- They provide a simple, memory-safe way to maintain per-instance state without classes.- Methods share the same lexical environment, so multiple independent counters can exist without interference.

Complexity:- increment(): O(1) time, O(1) additional space.- value(): O(1) time, O(1) space.

Edge cases / notes:- initial can be validated (e.g., ensure numeric). If you need decrement/reset, add explicit methods rather than exposing count.- For many counters or long-lived pages, be mindful of memory if closures capture large structures.

Practical front-end data-visualization example:Imagine tracking user brushing/hover interactions on a chart. You want a debounced counter of hover events that only sends an analytics ping after a threshold:- Use makeCounter to keep a private hover count per chart instance.- On hover, call increment() and schedule a debounced flush that reads value() and sends the count to the backend, then resets via an added reset() method.This prevents exposing internal state, keeps each chart's counts isolated, and simplifies cleanup when the component unmounts.

Unlock Full Question Bank

Get access to hundreds of Technical Background and Programming Skills interview questions and detailed answers.

Join thousands of developers preparing for their dream job.