A technical interview can feel chaotic: unfamiliar people, time pressure, and the need to explain your thinking clearly.
The good news is that most interviews follow the same patterns.
In this article, I’ll turn that complexity into a simple system — based on what I’ve learned as both a candidate and an interviewer.
What’s the purpose of a technical interview?
A technical interview is not an exam. It’s a signal-gathering session.
Interviewers usually evaluate:
- problem-solving (can you make progress with incomplete information?)
- C++ fundamentals relevant to their codebase (STL, lifetimes, complexity, UB basics)
- engineering judgement (trade-offs, API design, debugging mindset)
- communication (can you explain what you’re doing and why?)
- collaboration (are you constructive and easy to work with?)
New hires always ramp up on project details. What matters is whether you can learn fast and deliver reliably.
Communication: the simplest way to look senior
Silence feels like “I’m stuck”. Talking shows your thinking.
A simple answer structure that works in most interviews:
- Restate the problem
- Propose an approach
- Discuss trade-offs
- Complexity
- Edge cases
- Test with an example
Useful phrases:
- “Let me restate the problem to confirm I understood it…”
- “A first approach could be…, complexity would be…”
- “Trade-off: this is faster but uses more memory…”
- “Edge cases I want to handle are…”
- “Let’s test quickly with a small example…”
Keep time in mind: don’t get stuck in silence
If you’re stuck for ~2–3 minutes, switch to collaboration:
- explain what you tried
- ask a targeted question
- move forward with a rough solution
Example:
“I’m not fully sure about the optimal approach yet. Would it be acceptable if I start with a correct O(n log n) solution and then optimize if needed?”
Treat interviewers like teammates: show progress and adapt.
Code quality: modern, but not over-engineered
The goal is readable, correct code — not showing every feature you know.
Good signals:
- clear names, small functions
- RAII and safe ownership
- STL containers/algorithms where they simplify the code
- basic error handling (
std::optional/std::expected) if it genuinely clarifies the API
Avoid:
- clever template tricks
- unnecessary abstractions
- “feature showcase” code
Rule of thumb:
Prefer clarity over cleverness. Show judgement, not tricks.
Self-learning (without burnout)
Interview performance improves when learning is continuous.
A realistic routine:
- 30–60 minutes/day
- one focused topic per week (e.g., STL + complexity, lifetimes/RAII, concurrency basics)
- quick notes: “concept → typical bug → how to avoid it”
If you want more “from complexity to essence” deep dives on Modern C++ and CMake, I write a monthly newsletter: From complexity to essence in C++.
(And my book No More Helloworlds — Build a Real C++ App is for those who want a practical end-to-end C++ project workflow.)
Conclusion
If this interview didn’t work out — don’t panic.
It doesn’t mean you’re “not good enough”. It usually means you’ve just found the next gap to close.
Treat it as feedback, not a verdict:
- write down what felt weak while it’s fresh
- turn it into a small plan for the next 7–14 days
- and come back stronger
You didn’t lose. You gained time — and clarity on what to improve.