← Hudson River Trading Interview Insights

Hudson River Trading·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Apr 2026

Summary

Low-level C++ technical screen at Hudson River Trading. Two meaty questions, both with a lot of depth expected underneath them. The kind of interview where you realize halfway through that you only half-know something you thought you fully knew.

Questions Asked (2)

Q1

What actually happens when a program requests 8 GB of memory on a machine that only has 4 GB of RAM?

System DesignTechnical Trade-offs
Author's notes

I started talking about the allocation failing and they just waited.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the context: is this a 64-bit process on a modern OS with virtual memory? Then explain the role of virtual memory, demand paging, and overcommit. Finally, discuss the consequences: thrashing, OOM killer, or allocation failure, depending on OS and configuration.

Pro tip: Mention that on Linux with overcommit enabled, malloc may succeed but the OOM killer may terminate the process later; on Windows, the allocation may fail immediately. This shows awareness of OS-specific behavior.

1. Clarify assumptions

Ask about the OS, architecture (32-bit vs 64-bit), and whether the program uses malloc or mmap. This determines the behavior.

2. Explain virtual memory

Describe how the OS provides virtual address space, allowing a process to request more memory than physical RAM. The 8 GB request is for virtual memory, not physical.

3. Describe demand paging and overcommit

Explain that physical pages are allocated on demand when accessed. Overcommit policies (e.g., Linux overcommit_memory) determine if the allocation succeeds even if RAM+swap < 8 GB.

4. Discuss consequences

If overcommit is allowed, the process may run until physical memory is exhausted, causing thrashing or the OOM killer. If not, the allocation fails immediately (e.g., malloc returns NULL).

5. Summarize trade-offs

Highlight the trade-offs: overcommit improves utilization but risks OOM; strict accounting avoids OOM but may cause allocation failures. Mention swap space's role.

Key Points to Mention

  • Virtual memory and address space
  • Demand paging and page faults
  • Overcommit policies (Linux overcommit_memory, Windows commit limit)
  • Swap space and its impact
  • OOM killer (Linux) or allocation failure
  • Thrashing and performance degradation

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

What is the purpose of the inline keyword in C++, and what are the downsides of using it?

Technical Trade-offs
Author's notes

I went straight to 'it hints the compiler to inline the function body' and they pushed back immediately.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the modern purpose of inline (enabling multiple definitions across translation units and hinting at inlining), then discuss the trade-offs: code bloat, potential instruction cache pressure, and the fact that compilers often ignore the hint. Conclude by noting that inline is now primarily used for ODR compliance in headers, not performance.

Pro tip: Mention that inline is essential for defining functions in headers without violating the One Definition Rule (ODR), and that compilers today make inlining decisions based on optimization heuristics, not the keyword. This shows you understand both the language standard and real-world compiler behavior.

1. Define inline's dual purpose

Explain that inline serves two roles: as a hint to the compiler to expand the function at the call site, and as a linkage specifier allowing multiple definitions across translation units.

2. Clarify modern usage

Note that the performance hint is largely obsolete; compilers inline aggressively regardless. The primary modern use is to avoid ODR violations when defining functions in headers.

3. Discuss downsides

Cover code bloat, increased compile times, potential instruction cache misses, and the fact that inlining can be counterproductive if overused.

4. Mention alternatives and best practices

Suggest using inline for small, frequently called functions in headers, and relying on compiler flags (e.g., -O2) for performance. Avoid forcing inline on large functions.

Key Points to Mention

  • ODR (One Definition Rule) and how inline allows multiple definitions
  • Compiler hint vs. mandatory inlining (compilers can ignore the hint)
  • Code bloat and instruction cache pressure
  • Modern compilers inline based on heuristics, not the keyword
  • Use inline for header-defined functions to avoid linker errors
  • Alternatives: static functions in headers, or moving definitions to .cpp files

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.