C++ Quant Developer Interview: 5 Worked Cases

The view does not own the characters. When the local string is destroyed at function exit, the returned view no longer designates a live string's storage. Reading it has undefined behavior; an apparently correct output does not validate the lifetime.

Return an owning string when the caller needs its own result:

#include <cassert>
#include <string>

std::string make_symbol() {
    return std::string("ALPHA");
}

int main() {
    auto symbol = make_symbol();
    assert(symbol == "ALPHA");
}

Do not add std::move to every return in an attempt to improve it. Understand value return and copy elision first. If you instead return a view of caller-owned input, document that the input must outlive every use of the view and that storage-changing mutations can invalidate it.

For a required borrowed object, const Config& communicates inspection without ownership transfer. std::unique_ptr<Config> passed by value communicates transfer of unique ownership. A caller moves its pointer into the function and must account for losing that ownership. std::shared_ptr<const Config> can express shared ownership with read-only access through that handle when sharing is actually required. Other mutable aliases could still change the object; the handle alone does not establish global immutability.

These choices follow the C++ Core Guidelines' resource-management guidance, including RAII and explicit smart-pointer ownership. They are interface decisions, not interchangeable syntax preferences.

Ask what happens if the function throws halfway through setup. A resource managed by a completed automatic object's destructor is released during stack unwinding. A manually paired acquisition/release can miss the release on an exceptional path. RAII applies to locks, files and other resources as well as memory.

Use a head index and a count. The next insertion position is (head + count) % capacity; a separate count removes the ambiguity between full and empty.

#include <cassert>
#include <cstddef>
#include <optional>
#include <stdexcept>
#include <vector>

class IntQueue {
    std::vector<int> data;
    std::size_t head = 0;
    std::size_t count = 0;
public:
    explicit IntQueue(std::size_t capacity) : data(capacity) {
        if (capacity == 0) throw std::invalid_argument("zero capacity");
    }
    bool push(int value) {
        if (count == data.size()) return false;
        data[(head + count) % data.size()] = value;
        ++count;
        return true;
    }
    std::optional<int> pop() {
        if (count == 0) return std::nullopt;
        int value = data[head];
        head = (head + 1) % data.size();
        --count;
        return value;
    }
};

int main() {
    IntQueue q(2);
    assert(!q.pop());
    assert(q.push(10));
    assert(q.push(20));
    assert(!q.push(99));
    assert(q.pop().value() == 10);
    assert(q.push(30));
    assert(q.pop().value() == 20);
    assert(q.pop().value() == 30);
    assert(!q.pop());
    IntQueue one(1);
    assert(one.push(7));
    assert(!one.push(8));
    assert(one.pop().value() == 7);
    bool rejected = false;
    try { IntQueue invalid(0); }
    catch (const std::invalid_argument&) { rejected = true; }
    assert(rejected);
}

The invariants are count <= capacity and head < capacity. Each successful operation performs constant work, and the vector allocates its storage during construction. The example assumes an allocation small enough that index arithmetic cannot overflow. It is a practice implementation, not a claim of production suitability for arbitrary capacities or element types.

No. The count, head and slot contents form a protocol. An atomic count alone does not establish safe publication of a completed element, protect every shared access or define when a slot can be reused. Concurrent access to the original queue is unsupported.

Start with a mutex-protected interface and specify blocking, shutdown and full-queue behavior. A specialized single-producer/single-consumer queue needs a different proof from a multi-producer/multi-consumer queue. The Core Guidelines' concurrency section emphasizes avoiding data races and minimizing shared writable state.

A smaller illustration is an independent shared counter:

#include <atomic>
#include <cassert>
#include <thread>

int main() {
    std::atomic<int> count{0};
    auto work = [&] {
        for (int i = 0; i < 1000; ++i)
            count.fetch_add(1, std::memory_order_relaxed);
    };
    std::thread a(work), b(work);
    a.join();
    b.join();
    assert(count.load() == 2000);
}

Compile this example with thread support, for example adding -pthread. Relaxed increments suffice for this isolated count; they are not a ready-made message-publication protocol. The thread joins occur before the final check.

Define the workload first: operation mix, active element count, access pattern, allocation behavior and producer/consumer arrangement. A container that improves sequential scans may have different insertion, deletion or address-stability costs.

Record the compiler, optimization flags, machine, dataset and timing boundary. Keep setup outside the timed region unless setup is part of the intended workload. Ensure the computation's result is consumed so the compiler cannot simply remove it. Repeat runs, account for warmup and inspect variation.

For latency, distinguish per-operation latency from total throughput. A fast average can conceal occasional slow allocations or cleanup. Report the distribution your application cares about, with sufficient observations to support tail estimates. Do not invent a universal nanosecond target or infer live performance from a tiny warm-cache loop.