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

41 practiced

Implement a readers-writer lock (RWLock) in Java using ReentrantLock and Condition, or in Python using threading primitives. The lock should allow multiple concurrent readers but exclusive writers and should aim to prevent writer starvation. Explain how your implementation ensures fairness.

Sample Answer

Approach: implement an RWLock that allows multiple concurrent readers when no writer is active or waiting; writers get exclusive access and are prioritized if they are waiting to prevent writer starvation. Use a ReentrantLock plus two Conditions (okToRead, okToWrite). Track activeReaders, activeWriter (boolean), and waitingWriters.

java

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

public class RWLock {
    private final ReentrantLock lock = new ReentrantLock(true); // fair underlying lock
    private final Condition okToRead = lock.newCondition();
    private final Condition okToWrite = lock.newCondition();

    private int activeReaders = 0;
    private boolean activeWriter = false;
    private int waitingWriters = 0;

    // Acquire read lock
    public void readLock() {
        lock.lock();
        try {
            // If there's an active writer or writers waiting, wait.
            // This gives priority to writers and prevents writer starvation.
            while (activeWriter || waitingWriters > 0) {
                okToRead.awaitUninterruptibly();
            }
            activeReaders++;
        } finally {
            lock.unlock();
        }
    }

    // Release read lock
    public void readUnlock() {
        lock.lock();
        try {
            activeReaders--;
            if (activeReaders == 0 && waitingWriters > 0) {
                okToWrite.signal();
            }
        } finally {
            lock.unlock();
        }
    }

    // Acquire write lock
    public void writeLock() {
        lock.lock();
        try {
            waitingWriters++;
            while (activeWriter || activeReaders > 0) {
                okToWrite.awaitUninterruptibly();
            }
            waitingWriters--;
            activeWriter = true;
        } finally {
            lock.unlock();
        }
    }

    // Release write lock
    public void writeUnlock() {
        lock.lock();
        try {
            activeWriter = false;
            // Prefer waking writers first to avoid writer starvation
            if (waitingWriters > 0) {
                okToWrite.signal();
            } else {
                okToRead.signalAll();
            }
        } finally {
            lock.unlock();
        }
    }
}

Key points and fairness:- The underlying ReentrantLock is created with fairness=true to reduce scheduling bias.- waitingWriters counter and the condition in readLock prevent new readers from barging in when writers are waiting: readers wait if waitingWriters>0, so writers eventually acquire the lock.- writeUnlock signals writers first; only when no writers wait do readers proceed. This prioritization avoids writer starvation while still allowing reader concurrency when no writers are pending.- Complexity: operations are O(1) (constant-time lock state updates). Edge cases: be careful with InterruptedException if you switch awaitUninterruptibly to interruptible waits; handle reentrancy if needed (this simple implementation is not reentrant for read/write by same thread). Alternatives: reader-preference, pure fair ReentrantReadWriteLock (built-in) or track reader reentrancy per-thread.

MediumTechnical

53 practiced

Given an integer array 'nums' implement 'top_k_frequent(nums, k)' in Python that returns the k most frequent elements. Aim for O(n log k) time and O(n) space. Provide sample inputs/outputs and explain the approach using a heap and hashmap.

Sample Answer

To solve this, count frequencies with a hashmap (Counter) then maintain a min-heap of size k storing (freq, value). Push each (freq, val); if heap grows > k, pop the smallest — this keeps the k highest frequencies. This yields O(n log k) time and O(n) space.

python

from collections import Counter
import heapq

def top_k_frequent(nums, k):
    """
    Return k most frequent elements in nums.
    Time: O(n log k), Space: O(n)
    """
    if k <= 0:
        return []
    freq = Counter(nums)                 # O(n)
    heap = []                            # min-heap of (frequency, value)

    for val, f in freq.items():          # at most n distinct
        heapq.heappush(heap, (f, val))   # O(log k) amortized
        if len(heap) > k:
            heapq.heappop(heap)

    # Extract values; smallest freq at heap[0], so reverse for descending order
    return [val for (_, val) in heapq.nlargest(k, heap)]

# Examples
print(top_k_frequent([1,1,1,2,2,3], 2))  # [1,2]
print(top_k_frequent([1], 1))            # [1]

Key points:- Counter builds frequency map in O(n).- Heap size never exceeds k → each push/pop is O(log k).- Final extraction uses heapq.nlargest which is O(k log k) but dominated by earlier steps when k << n.

Edge cases:- k = 0 → return []- k >= number of distinct elements → return all distinct elements- Negative numbers and duplicates handled naturally

Alternative: Quickselect on frequency gives average O(n) but is more complex to implement.

EasyTechnical

53 practiced

Explain how parameter passing works in Python, JavaScript, and C++: which use pass-by-value, pass-by-reference, or pass-by-sharing. Show short code examples that illustrate how mutating a passed-in list/array or object affects the caller, and explain when you must copy objects to avoid side effects.

Sample Answer

Python: pass-by-object-reference (aka pass-by-sharing). Function receives a reference to the same object; mutating a mutable object (list, dict) affects caller, rebinding the parameter does not.

python

def append_item(lst):
    lst.append(4)        # mutates caller's list
def rebind(lst):
    lst = [9,9]          # rebinds local name only

a = [1,2,3]
append_item(a)
print(a)  # [1,2,3,4]
rebind(a)
print(a)  # [1,2,3,4]

JavaScript: similar to Python — objects and arrays are passed by reference to the object (pass-by-sharing). Mutations affect caller; assigning the parameter to a new object does not.

javascript

function pushItem(arr){ arr.push(4); }
function rebind(arr){ arr = [9,9]; }

let a = [1,2,3];
pushItem(a);
console.log(a); // [1,2,3,4]
rebind(a);
console.log(a); // [1,2,3,4]

C++: supports both pass-by-value and pass-by-reference. By default arguments are copied (pass-by-value) so mutating parameter doesn't affect caller. Use references (&) or pointers (*) to allow mutations of caller's object.

cpp

void mutate_by_value(std::vector<int> v){ v.push_back(4); }     // operates on a copy
void mutate_by_ref(std::vector<int>& v){ v.push_back(4); }     // mutates caller

std::vector<int> a{1,2,3};
mutate_by_value(a);
 // a == {1,2,3}
mutate_by_ref(a);
 // a == {1,2,3,4}

When to copy: if you need to modify an argument without affecting the caller, explicitly copy (e.g., list(a) or a.slice() / [...a] in JS, copy constructor or std::vector<int> copy = original; in C++). Also copy when passing to concurrent code or APIs that may mutate inputs. For large objects consider shallow vs deep copy: shallow copy duplicates top-level container but shares nested mutable elements; deep copy duplicates recursively (use copy.deepcopy in Python or implement custom cloning).

HardTechnical

49 practiced

A large single-page application has slow initial load time and high memory use. Design a plan to profile and reduce bundle size and runtime memory, covering tools and techniques: source-map analysis, code-splitting, tree-shaking, lazy loading, removing large polyfills, eliminating closures that retain DOM, and using heap snapshots to find retaining paths.

Sample Answer

Approach: treat this as two linked problems—build/bundle size (network + parse cost) and runtime memory (leaks & high heap). Use iterative profiling, small measurable changes, and CI gating.

1) Discover & quantify- Run Lighthouse/Chrome DevTools (Performance, Coverage, Network) and WebPageTest for real metrics (TTFB, TTI, JS parse+compile).- Analyze bundle contents with source maps: webpack-bundle-analyzer and source-map-explorer to map minified bytes -> original modules. Identify large modules, duplicated libs, and big polyfills.

2) Reduce bundle size (actions)- Tree-shaking: enable production mode, ensure ES module imports (import vs require), remove sideEffects in package.json. Verify with bundle analyzer that unused exports are eliminated.- Code-splitting & lazy loading: convert large routes/components into dynamic imports (React.lazy / import()). Create route-level and component-level chunks, use webpack's magic comments (/* webpackPrefetch: true */) when appropriate.- Remove/replace heavy dependencies: replace lodash imports with lodash-es cherry-picked functions or native APIs. Replace moment with date-fns or lightweight alternative.- Eliminate large polyfills: audit core-js/babel-polyfill usage. Use browserslist to only ship needed polyfills or serve them conditionally (polyfill.io) and prefer feature-detection.- Compression & caching: enable Brotli/Gzip, long-term cache headers, and deterministic chunk names.

3) Runtime memory profiling and fixes- Use Chrome DevTools Memory panel: take heap snapshots, compare snapshots to find growing retained sets. Use “Retaining path” view to identify why objects aren’t collected.- Allocation instrumentation / timeline to find allocation spikes; use DevTools Allocation profiler or Firefox performance tools.- Fix common leaks: - Remove closures that retain DOM: avoid storing DOM nodes in long-lived closures/objects (e.g., module-level variables). Instead store weak references or query when needed. Example: don't capture element in event handler factory that lives beyond element lifecycle. - Unregister event listeners and timers in component unmount/cleanup. Use AbortController for fetches. - Avoid accidental globals and large caches; limit lifetime and size of in-memory caches (LRU). - Detach references to removed DOM (innerHTML='' vs removing listeners).- Use WeakMap/WeakRef for caches keyed by DOM or component instances.- Re-run heap snapshots after fixes to verify retained size reduced and garbage-collected.

4) Validation & CI- Create performance budgets checked in CI (bundle size, main-thread work). Fail PRs exceeding budgets.- Add synthetic/regression tests: Lighthouse CI, and memory smoke tests (open page, interact, force GC, measure growth).

5) Trade-offs & monitoring- Code-splitting increases number of requests—balance with HTTP/2 or prefetching.- Lazy-loading increases first-interaction complexity; prioritize above-the-fold critical code.- Continue monitoring in production (RUM + telemetry) for bundle sizes and memory/GC metrics.

Outcome: iterative profiling → targeted removals (polyfills/deps) + structural changes (tree-shaking, code-split) and leak fixes (closures, listeners) typically reduces initial load and peak memory significantly; validate with before/after metrics (TTI, JS parse time, heap size, GC frequency).

EasyTechnical

57 practiced

Explain the differences between memory management in C++ (manual/RAII) and managed languages like C# or Java (garbage-collected). Discuss deterministic destruction, finalizers, resource management patterns, common sources of leaks in each model, and when to use smart pointers or 'using'/'dispose' patterns.

Sample Answer

C++ vs GC languages: core difference- C++: manual lifetime + RAII. Objects free resources deterministically when they go out of scope (destructor runs immediately). Use constructors/destructors to acquire/release resources; prefer smart pointers (unique_ptr for single ownership, shared_ptr for shared ownership) to avoid manual delete and dangling pointers.- Java/C#: garbage-collected memory; object memory reclaimed non-deterministically. Finalizers (~finalize / destructor in C#) run unpredictably and are expensive — avoid relying on them for timely resource cleanup.

Deterministic destruction vs finalizers- Deterministic: C++ destructors guarantee prompt release at scope exit; ideal for file handles, locks.- Finalizers: run at GC time (if at all); not suitable for timely release. In C#, implement IDisposable and call Dispose; in Java, implement try-with-resources (AutoCloseable) to ensure prompt close.

Resource-management patterns- C++: RAII + smart pointers (unique_ptr for ownership transfer, shared_ptr for ref-counted shared ownership; weak_ptr to break cycles).- C#/Java: using (C#) / try-with-resources (Java) + IDisposable/AutoCloseable for deterministic disposal; rely on GC for memory, not for other resources.

Common leak sources- C++: forgetting delete, double-free, cyclic references with shared_ptr, dangling pointers.- GC languages: holding references in long-lived structures (static collections, caches) preventing GC, unmanaged resources not disposed (DB connections, file handles), event listeners/subscriptions not unsubscribed.

When to use smart pointers or using/dispose- Use unique_ptr by default in C++; use shared_ptr only when multiple owners are required and manage cycles with weak_ptr. In C#/Java, wrap non-memory resources in IDisposable/AutoCloseable and always use using/try-with-resources to ensure deterministic cleanup.

Summary: Use RAII/smart pointers in C++ for deterministic, exception-safe resource management. In GC languages, rely on GC for memory but always explicitly dispose non-memory resources with using/try-with-resources to avoid leaks.

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.