C++ Interview Idioms: The Shortcuts That Actually Save Time

You have 45 minutes. The problem needs a priority queue, a sorted vector, and a custom comparator. That time needs to go to thinking, not typing. But if you're still writing vector<int>::iterator it = v.begin() in 2026, you're paying a 10-minute ceremony tax while your interviewer watches, silently, from across the screen.

These idioms exist. Use them.

auto and Structured Bindings: Stop Writing Types

auto isn't lazy. It's precise. The compiler knows the exact type. You don't, and that's fine.

// the pain
for (vector<pair<int,int>>::iterator it = v.begin(); it != v.end(); ++it) {
    cout << it->first << " " << it->second;
}

// the relief
for (auto& [dist, node] : v) {
    cout << dist << " " << node;
}

Structured bindings (C++17) turn every pair and tuple into named variables. You get auto [a, b] = make_pair(1, 2) and that's it. No .first, no .second, no inner monologue about which one was which.

The & in auto& [a, b] matters: without it, you copy every element on each iteration. For a map traversal, you almost always want the reference.

map<string, int> freq;
for (auto& [word, count] : freq) {
    count++;  // mutation sticks because count is a reference
}

Structured bindings work for any aggregate, including your own structs. On const containers, the compiler gives you const references automatically.

STL Algorithms Replace Most Manual Loops

The <algorithm> and <numeric> headers contain about 80 algorithms. You need maybe 15 of them. The other 65 exist. They are there. Don't worry about them.

Accumulate and initialization:

#include <numeric>

int total = accumulate(v.begin(), v.end(), 0);
int product = accumulate(v.begin(), v.end(), 1, multiplies<int>());

// fill with 0, 1, 2, 3, ...
vector<int> indices(n);
iota(indices.begin(), indices.end(), 0);

// set everything to -1
fill(v.begin(), v.end(), -1);

Counting and finding:

int zeros = count(v.begin(), v.end(), 0);
int evens = count_if(v.begin(), v.end(), [](int x){ return x % 2 == 0; });

auto it = find(v.begin(), v.end(), target);
if (it != v.end()) { /* found at index it - v.begin() */ }

auto it2 = find_if(v.begin(), v.end(), [](int x){ return x > 100; });

Min and max:

auto it = min_element(v.begin(), v.end());
int smallest = *it;
int idx = it - v.begin();  // index as a bonus

auto [lo, hi] = minmax_element(v.begin(), v.end());

Binary search on sorted ranges:

sort(v.begin(), v.end());
auto pos = lower_bound(v.begin(), v.end(), target);  // first element >= target
auto pos2 = upper_bound(v.begin(), v.end(), target); // first element > target

bool exists = binary_search(v.begin(), v.end(), target);

// count elements in [lo, hi]
int in_range = upper_bound(v.begin(), v.end(), hi)
             - lower_bound(v.begin(), v.end(), lo);

lower_bound and upper_bound as free functions on a set are O(n). They can't use pointer arithmetic on tree iterators. Use the member function versions for O(log n). That's an easy complexity mistake to make under pressure, and "actually that's O(n) not O(log n)" is exactly what interviewers write down. See hash map vs tree map trade-offs for more.

Permutations and k-th element:

sort(v.begin(), v.end());
do {
    // process permutation
} while (next_permutation(v.begin(), v.end()));

// puts k-th smallest at v[k], O(n) average
nth_element(v.begin(), v.begin() + k, v.end());
int kth = v[k];

nth_element is Quickselect under the hood. If your interviewer asks for k-th largest in O(n), this is the one-liner. For why Quickselect beats sorting for selection problems, see the full analysis.

Write Comparators Inline, Never Subtract

Use lambdas instead of free functions at the top of the file. It's cleaner, it's local, and it won't confuse you 20 minutes later when you've forgotten what cmpBySecondDescending was doing.

// sort pairs by second element descending
sort(v.begin(), v.end(), [](const auto& a, const auto& b) {
    return a.second > b.second;
});

// sort strings by length, then lexicographically
sort(words.begin(), words.end(), [](const string& a, const string& b) {
    if (a.size() != b.size()) return a.size() < b.size();
    return a < b;
});

Never use subtraction in a comparator. return a - b looks fine until a = INT_MIN and b = 1. The subtraction overflows, the sort silently produces garbage, your test cases might still pass, and you submit a broken solution with complete confidence. Use return a < b always.

The same pattern for priority_queue:

auto cmp = [](const pair<int,int>& a, const pair<int,int>& b) {
    return a.first > b.first;  // min-heap by first element
};
priority_queue<pair<int,int>, vector<pair<int,int>>, decltype(cmp)> pq(cmp);

For the common cases, built-in comparators save typing:

priority_queue<int> maxpq;                                // max-heap (default)
priority_queue<int, vector<int>, greater<int>> minpq;    // min-heap
priority_queue<pair<int,int>,
               vector<pair<int,int>>,
               greater<>> minpair;                        // min-heap of pairs

Container Initialization in One Line

Skip the sequential push_back calls:

vector<int> v = {3, 1, 4, 1, 5};
vector<vector<int>> grid(m, vector<int>(n, 0));    // m x n grid of zeros
unordered_map<char, int> score = {{'a', 1}, {'b', 3}};

Use emplace_back instead of push_back for objects. It constructs in place rather than constructing and then copying.

vector<pair<int,int>> edges;
edges.emplace_back(1, 2);    // constructs pair directly in the vector
edges.push_back({1, 2});     // constructs pair, then moves it in

For int and other primitives there's no meaningful difference. For objects with non-trivial constructors, emplace_back avoids the extra move.

GCC Built-ins: Don't Write These By Hand

These work on LeetCode, HackerRank, Codeforces, and virtually every judge you'll encounter.

__builtin_popcount(x)     // count set bits (unsigned int)
__builtin_popcountll(x)   // count set bits (unsigned long long)
__builtin_clz(x)          // count leading zeros (undefined for x == 0)
__builtin_ctz(x)          // count trailing zeros (undefined for x == 0)
__builtin_parity(x)       // parity of set bits, 0 or 1

These compile down to single instructions on modern hardware. Your interviewer has seen the hand-rolled bit-counting loop before. Many times. They are so tired of the loop.

C++17 gives you std::gcd and std::lcm from <numeric>:

#include <numeric>
int g = gcd(12, 8);   // 4
int l = lcm(4, 6);    // 12

std::gcd handles negative inputs correctly. The GCC builtin __gcd has implementation-defined behavior on negatives. Prefer the standard version.

For numeric limits, include <climits>:

INT_MAX    // 2,147,483,647
INT_MIN    // -2,147,483,648
LLONG_MAX  // 9,223,372,036,854,775,807

A practical shorthand: use 1e9 as readable infinity when the math stays within int range. Watch the type though. 1e9 is a double. Assign to long long with (long long)1e18 or the literal 2000000000LL.

String Conversions: One Trap to Avoid

string s = to_string(42);
int n = stoi("42");
long long ll = stoll("123456789012");
double d = stod("3.14");

string sub = s.substr(start, length);  // (pos, len), NOT (start, end)

size_t pos = s.find("abc");
if (pos != string::npos) { /* found */ }

// character classification (from <cctype>)
isalpha(c), isdigit(c), islower(c), isupper(c)
tolower(c), toupper(c)

substr takes (position, length), not (start, end). Python uses (start, end). Java uses (start, end). Go uses (start, end). C++ decided to be different, and now you will debug this at least once in your life. Possibly during an interview. Pause and double-check every time you call it.

Scope Your Map Lookups

if (auto it = m.find(key); it != m.end()) {
    cout << it->second;
}  // it goes out of scope here

The C++17 if-with-initializer scopes the iterator to the block. Without it, it leaks into the enclosing scope where you'll never use it again. Not a correctness bug. Just a variable sitting there, unused, judging you silently for the rest of the function.

std::remove Doesn't Remove Anything

This one. This is the one.

std::remove and std::remove_if do not remove elements from the container. They shuffle matching elements toward the end and return an iterator to the new logical end. The vector still has the same .size(). The elements are still there, lurking.

If you forget to call .erase() afterward, nothing gets removed. The function is named remove and it does not remove things. Welcome to C++.

Three steps, one pitfall: remove_if moves elements, erase deletes them. Skip the second step and you've just rearranged the mess.

// wrong: elements still in vector, just shuffled to the end
remove_if(v.begin(), v.end(), [](int x){ return x < 0; });

// correct: the erase-remove idiom
v.erase(remove_if(v.begin(), v.end(), [](int x){ return x < 0; }), v.end());

// deduplicate (sort first)
sort(v.begin(), v.end());
v.erase(unique(v.begin(), v.end()), v.end());

unique only removes consecutive duplicates. Sort first, always.

C++ Interview Idioms: Quick Reference

Task	Idiom	Header
Sum	accumulate(b, e, 0)	<numeric>
Fill with 0,1,2...	iota(b, e, start)	<numeric>
Count matches	count_if(b, e, pred)	<algorithm>
First match	find_if(b, e, pred)	<algorithm>
Min/max element	*min_element(b, e)	<algorithm>
Binary search	lower_bound(b, e, x)	<algorithm>
k-th element, O(n)	nth_element(b, b+k, e)	<algorithm>
All permutations	next_permutation(b, e)	<algorithm>
Remove and shrink	erase-remove idiom	<algorithm>
Deduplicate	sort + unique + erase	<algorithm>
GCD	gcd(a, b)	<numeric> (C++17)
LCM	lcm(a, b)	<numeric> (C++17)
Count set bits	__builtin_popcount(x)	GCC builtin
Min-heap	priority_queue<T, vector<T>, greater<T>>	<queue>
Pair to names	auto& [a, b] = pair	C++17
Scoped map lookup	if (auto it = m.find(k); it != m.end())	C++17

Fluency Is Table Stakes. Recognition Wins.

None of these idioms help if you don't recognize the pattern fast enough to use them. Knowing nth_element exists saves you from writing Quickselect by hand. Knowing lower_bound exists saves you from writing binary search. Neither saves you if you spend the first eight minutes staring at constraints trying to name what the problem actually wants.

The real gap for most C++ candidates isn't vocabulary. It's that 20-second delay between reading a problem and naming what it needs. That delay disappears with deliberate out-loud practice, not more syntax review.

SpaceComplexity runs voice-based mock interviews where you practice the full loop: recognize the pattern, name your approach, implement it, and defend the complexity analysis under real time pressure. If you're fluent in C++ but still losing time in 45-minute windows, that's almost always where it's going.

For a broader look at STL data structures and their complexity guarantees, see the C++ for Coding Interviews guide. If you're debating whether C++ is the right language choice, the language comparison lays out the tradeoffs honestly.

Further Reading

• cppreference: <algorithm>
• cppreference: <numeric>
• cppreference: Structured Bindings
• GCC Built-in Functions
• ISO C++ Core Guidelines