Most C++ home assignments fail candidates not because of bugs —
but because of weak engineering decisions.
You can deliver a working solution and still fail the interview — not because of bugs, but because of weak structure, unclear decisions, or missing engineering fundamentals.
In this article, I’ll explain how interviewers usually evaluate C++ home assignments and how to approach them in a way that reflects real-world engineering practices.
Why companies ask for it
Companies use home assignments to understand how a candidate thinks, not just whether they can produce a working solution.
Interview processes vary widely. Some include a home assignment; others don’t. The most common types are:
- LeetCode-like quizzes with a strict time limit,
- More complex exercises that require building a small application or several classes.
The purpose is to determine whether the candidate is skilled enough to proceed.
For LeetCode-style puzzles, there are usually automated tests that must pass before a human ever looks at the code. Failing tests often results in immediate rejection.
More complex exercises — such as code refactoring or implementing a simple “grep-like” tool — have looser time limits and are evaluated manually. If the code is poor, that alone may be enough to reject a candidate without conducting a call or on-site interview. Another purpose of such tasks is to have candidate-written code that can later be discussed in detail.
Questions from the interviewer
This article focuses on assignments that involve writing a small application or several classes.
When I review a home assignment, I also prepare a list of technical questions, such as:
- “How does this code behave with these parameters?”
- “Why did you choose this particular approach?”
If I see potential improvements, that becomes an opportunity to ask deeper questions.
For strong candidates, it’s even possible to discuss topics like:
- Inheritance vs. composition
- Exceptions vs.
std::expected
The purpose is to determine whether the candidate understands C++ deeply enough to choose the right approach based on requirements.
Once I reviewed an assignment where the candidate implemented the entire task inside a single 700-line main.cpp. The code worked — but I could not ask a single deep question, because there was no architecture to analyze. We rejected the candidate despite the correct output.
What is expected
A home assignment is usually done in a quiet environment over several days. Because of that, expectations are much higher than during a live coding session.
For a senior C++ position, I personally expect to see:
- Use of modern C++
- Proper error handling
- Fulfillment of all requirements
- Clear structure (possibly split into modules)
- Good formatting and readability
- Use of STL whenever appropriate
- Proper testing — positive, negative, and edge cases
Even small home assignments benefit from structure.
At a minimum, a reviewer expects to see:
- logical separation of responsibilities,
- meaningful naming,
- clear boundaries between components,
- a build system that reflects intent (not just defaults).
You don’t need overengineering — but you do need intentional design.
A simple project layout already communicates a lot about your experience level.
How you handle errors says more than the happy-path logic.
Questions interviewers implicitly ask:
- Are errors explicit or silently ignored?
- Are they propagated or swallowed?
- Is the strategy consistent across the codebase?
Using std::optional, std::expected, or structured error types shows that you think beyond “it didn’t crash”.
How to do your best
A home assignment is often one of the first impressions the interviewer gets of you.
Treat it accordingly.
Make sure all requirements are met, and that you follow the expectations above.
If you’re unsure how to solve part of the task — or how to apply modern C++ properly — ask questions or research online. There is nothing wrong with looking things up, as long as you understand them and can explain your decisions.
It’s also helpful to ask a friend or colleague for a quick review. They may spot issues or suggest improvements.
Finally, remember that a human will read your code. A few comments or a simple high-level diagram can make your solution much easier to understand.
Home Assignment Checklist
Before you submit your solution, verify that:
- ☐ All requirements are covered
- ☐ Code compiles cleanly (no warnings with
-Wall -Wextra -Werror) - ☐ Errors are handled explicitly (return values, exceptions,
std::expected) - ☐ All STL containers/algorithms are used appropriately
- ☐ No unnecessary includes or heavy headers
- ☐ Code is formatted (clang-format)
- ☐ Tests cover positive, negative, and edge cases
- ☐ README contains short build/run instructions
Estimate it properly
If the assignment is a small LeetCode-style function, it might take 1–2 hours or less.
But implementing even a simple application from scratch can take several days. You may need to prepare:
- Build system configuration (CMake, etc.)
- A separate library for business logic plus a thin executable
- Unit tests for the library
- Comments and diagrams
In any case, you should design your solution with a testable business-logic library and link it to an executable.
Often, home assignments are sent by non-technical recruiters who underestimate the effort — assuming it’s “a couple of hours.” That may be true for trivial tasks, but not for real-world, well-structured, well-tested code.
Is it worth it?
You should always remember that there’s a chance you won’t get the job, even if you do your best. Maybe another candidate was a better fit, or maybe they simply preferred a different solution style.
For me, a home assignment is something I evaluate carefully — especially if it requires building a full application from scratch. If the task takes more than 2–3 full workdays, I personally tend to decline it.
One way to make the effort worthwhile is to think about reuse:
Can you publish the project on GitHub?
Even if you don’t get the job, you’ll still have something valuable for your portfolio.
Final Thoughts
Home assignments are less about proving that you can write C++.
They’re about showing that you can think like a software engineer:
- structure problems,
- make trade-offs,
- communicate intent through code.
If you approach them with that mindset, even a simple task can become a strong signal.
If you’re interested in C++ not just as a language, but as a tool for building maintainable systems — I share this kind of thinking in my monthly newsletter From complexity to essence in C++.
I have also a book “No More Helloworlds — Build a Real C++ App” which shares how to build the real allocations with C++ on the real example