DEV Community: Dimitris Platis

Questions YOU should ask when being interviewed

Dimitris Platis — Sun, 06 Dec 2020 15:38:50 +0000

🔄 Reverse interview questions for Software Engineers

As a Software Engineer, you will go through several interviews in your career. These interviews are typically set up by the potential employers to evaluate your cultural and technical fitness for the role.
From the candidate's point of view, the interview process should not just be about convincing the employer. That is of course important, however, it should not be your primary concern unless you are in dire need of a job. Instead, you should mainly aim to understand what the company works with, how your future teammates operate, what would your development be, and so on.
In other words, you should strive to collect the necessary information which will allow you to assess the technical and cultural suitability of the workplace, its tech and the people in it.

This is what lead me to create a set of reverse interview questions.
It is tailored for product companies and, nonetheless, should be adjusted depending on the setting as well as common sense. Do not try to blindly follow it irrespective of the flow of the conversation, it will just be awkward.
Usually, the interviewer will ask you if you have any questions. This is your chance to start with them, taking into consideration what has already been discussed. No need to ask all of them, or in a particular order either. The context matters!
Most, if not all, questions are open-ended and there is no "correct" answer. More precisely, it is up to you to determine whether the responses satisfy you or not. They are also best-addressed towards individuals involved with development. Do not ask them to a human resources representative or a recruiter. Furthermore, topics that should be covered in every interview, such as benefit package, working hours, salary etc, are not included.

Overall, personal experience shows these questions make it easier for the interviewers to illustrate in depth how and what they work with. Thus far, they have been warmly welcomed and even helped to make a good impression. To say the least, they show the candidate is highly interested and seriously engaged with the process.
More importantly, they enable you, as a Software Engineer, to make well-informed career decisions.

👩‍💻 Technology stack 👨‍💻

Question(s)	Comments
What does your technology stack look like?	Unless already mentioned, do not forget to ask about programming languages, target operating system, build system or framework, continuous integration and version control software.

⚙️ Way of Working ⚙️

Question(s)	Comments
Before a team member starts working on a task, what preparatory work has taken place and what occurs after?	Is the task is written down in some tool and who writes it? Are the tasks derived from a certain set of requirements? Who maintains those requirements? How is traceability ensured? How does the code get peer-reviewed?
Do you have a specific workstation setup in regards to the operating system, the IDE etc?	In some projects, there is a very well-defined toolset, either due to company guidelines or constraints set by the product domain. Others let developers freely select their own. The latter is not always the better choice since it may be trickier to set up an efficient workflow.
Do you use any containers for your development environment and/or the product?	Using containers makes it easier to get all necessary dependencies, however, may be less flexible.
Do you do pair programming?	Some like pair-programming, some do not. In any case, it is something good to know in advance.
How do you ensure knowledge sharing?	Knowledge sharing is important and there are different ways to do it, which may or may not suit you.
Are there usually person-specific tasks or can everything be taken up by anyone?	This is one of the most important questions for me. I strongly prefer it when everyone can potentially take up any task in the team. However, others like to go deep and specialize in particular sub-domains.
How do you write documentation?	Do they maintain separate documents, is it contained in the code, or is everything self-documenting so there is no need for extra documentation?
How do you work with bugs?	What happens after a bug is discovered? Who usually reports them? How does the emergence of a bug affect their planning?
How do you collaborate with other sites?	It is often fun to work with colleagues located in different parts of the world, however, this does come with its set of challenges.
When developing a feature, is the team able to complete it in its entirety?	This will give you a hint on the size of the system you will be working with as well as how vertical the team's domain of responsibility is.

🚅 Agile 🚅

Question(s)	Comments
Do you follow any development methodology, e.g. Agile? If so, how?	Are there daily standups, retrospectives etc?
How do you write tasks?	Are they formulated as user stories? Are they estimated?
How do you release software?	How often do the releases take place? Are they automatically built and deployed?

🚀 Open source 🚀

Question(s)	Comments
Are you working with open source software? If so, how?	Can they name some open source packages they heavily utilize? Do they upstream any changes? Working with open source can be a valuable experience to carry with to the next job and upstreamed changes offer great visibility. On the other hand, there may be multiple do's and don'ts which can make your life difficult.

🧑‍🤝‍🧑 Relations with customers 🧑‍🤝‍🧑

Question(s)	Comments
How do you collaborate with the customers?	Dependencies, communication and collaboration with the customer can vary between projects or even teams in the same project. There are those who enjoy being tightly engaged with the customer while others prefer working more isolated.
How smooth do customer deliveries usually go?	Delivering software may require intense collaboration with the customer for the new software to be integrated. Some thrive in such situations and view them as a chance to understand the customer needs better. Others try to avoid them.

🐜 Testing 🐜

Question(s)	Comments
How do you test your code?	Testing and verification may happen at different levels. From unit and integration tests to manual verification and trying things out in hardware or software in the loop rigs.
What test frameworks do you use?	Not all frameworks appeal the same to everyone. It is good if you know this in advance.
What are your thoughts on Test Driven Development?	Do they use TDD? If not, why?

🤵 Career path 🤵

Question(s)	Comments
What do you think I will love about this job?	A good indicator of the extent they have understood your personal goals and style as well as the incentives they have to offer.
Where do you see me in 5 years?	A question often addressed to you as an interviewee. Reversing it offers you insights on the available career development paths.
How common is it for employees from this branch/department/team to advance in the higher organizational hierarchy?	Are the ones on the top coming from a different background from yours? Can your loyalty potentially pay off?

📚 Self-development 📚

Question(s)	Comments
How often do your employees attend conferences, courses, seminars or hackathons?	All companies claim they care for the personal development of their employees. However few have concrete examples of how they do it. Not all activities will satisfy all engineers, therefore getting input on this can be crucial.

🤝 Collaboration with 3rd parties 🤝

Question(s)	Comments
Do you work with external suppliers? If so, how?	Working with external suppliers can be both fun and/or challenging. It is good if you can find out how this synergy works.
Do you collaborate with academia? If so, how? If not, would you be open to?	Participating in research projects can be interesting and rewarding. However, it may consume a portion of your time and it is not everyone's cup of tea.

💡 Innovation 💡

Question(s)	Comments
Who comes up with novel features and how?	Does the responsibility for coming up with new features lie with the customer or the company's higher management? Is there an "advanced engineering" team that is tasked with this? Do the employees themselves often propose novel product functionality? Or is it interns that get to experiment with the fun stuff?
What kind of functionality are you mostly working with, in this branch? Commodity functionality constitutes all functionality that customers typically expect in a product or system, but that is also offered by competing companies. Differentiating functionality contains the functionality that makes customers select our products or systems over those from competitors. Innovation functionality is experimental functionality. Company experiments with different innovative ideas to identify new future differentiation.	The three types of functionality are found in Jan Bosch's 3LPM. [1], [2]

Question(s)

Comments

Who comes up with novel features and how?

Does the responsibility for coming up with new features lie with the customer or the company's higher management? Is there an "advanced engineering" team that is tasked with this? Do the employees themselves often propose novel product functionality? Or is it interns that get to experiment with the fun stuff?

What kind of functionality are you mostly working with, in this branch?

Commodity functionality constitutes all functionality that customers typically expect in a product or system, but that is also offered by competing companies.
Differentiating functionality contains the functionality that makes customers select our products or systems over those from competitors.
Innovation functionality is experimental functionality. Company experiments with different innovative ideas to identify new future differentiation.

The three types of functionality are found in Jan Bosch's 3LPM. [1], [2]

Top 10 practices I hate in C++

Dimitris Platis — Tue, 29 Sep 2020 00:00:00 +0000

After working with C++ for the past years, I have developed some relatively strong opinions about several things people do, when writing C++. This inspired me to come up with the TOP 10 C++ practices, I hate most.

Before we begin I would like to clarify the following things:

Aside of the top 3, all the rest are random order.
I do not claim these practices to be inherently bad. It depends a lot on the context. Even so, in some cases I may be just expressing opinions that are more like personal preferences rather than a best practice or a "rule". That being said, if there is a relevant C++ Core guideline I will mention it.
I will assume there are no technical constraints keeping you from using C++11 or newer.
The code in the examples may be oversimplified
The pointed out issues may not be exclusive to C++

(10) Not using a range-for loop, when there is a choice

I just don't understand why people still insist on using an incrementing index to iterate over a collection of values instead of a ranged-for loop. That is, if and where there is a choice of course.
I am under the impression this happens because they have been taught for loops that way, in a Programming 101 course long ago and since then they have been instinctively using it. I find ranged-for loops much safer and readable

// DON'T LIKE
for (std::size_t i = 0; i < v.size(); ++i)
{
    std::cout << v[i] << '\n';
}

// DON'T LIKE
for (auto p = v.begin(); p != v.end(); ++p)
{
    std::cout << *p << '\n';
}

// DO LIKE
for (const auto& x : v)
{
    std::cout << x << '\n';
}

The first two ways of iterating over v are just... bad! You simply cannot tell what the loop actually iterates over, just "how many times". On the other hand, when you iterate over v using the ranged-for loop, it becomes immediately clear that you want to do something "for every element x in v".
The related C++ Core Guidelines is ES.71, so whenever I see a ranged-for loop not being used during a code review, my next step is to see if it can be used instead.

(9) Manual memory management using raw pointers

Despite all the memory leaks and the bad reputation C++ has gotten from them, people just don't learn do they?
They keep using their new operators and their malloc with total disregard of smart pointers, RAII and standard library containers. I don't know about you, but I instantly get very suspicious when I see these particular keywords in a modern C++ codebase.

int main()
{
    // DON'T LIKE: Raw owning pointer of Foo instance
    Foo* f1 = new Foo();
    // DO LIKE: the Foo instance is owned by a unique pointer
    auto f2 = make_unique<Foo>();

    return 0;
}

As a matter of fact, it is very rare I come across good and unavoidable usage of the so-called owning raw pointers and memory allocation with malloc. In most cases, it involves the usage of a legacy, or simply bad, API.
Some relevant C++ Core guidelines are R.3 and R.10.

(8) Misused smart pointers ignoring conventions on lifetime & ownership

From how I see it, the C++ Core guidelines are very clear on when one should use smart pointers.
More importantly, they have very well documented implications on a practical as well as a semantic level in regards to lifetime and ownership.

struct Bar
{
    Bar(std::unique_ptr<Foo> f) : mFoo{std::move(f)} {}
    void useFoo() { mFoo->blop(); }
private:
    std::unique_ptr<Foo> mFoo;
};

int main()
{
    // DON'T LIKE: Bar does not need to *own* the Foo instance
    // since it does not reseat or destroy it.
    // Additionally, `f` will always exist as long as `b`
    // does, so no need to worry about it going out of scope.
    auto f = std::make_unique<Foo>();
    Bar b{std::move(f)};

    return 0;
}

Typical issues I see is using a smart pointer when a raw, non-owning pointer or a reference would have been perfectly fine. Another one is using shared pointers aimlessly without no particular excuse.
There are many rules from the C++ Core Guidelines that cover their usage such as F.7, R.21, R.30 etc.

(7) Cryptic abbreviations (I don't want to guess what they mean)

Unfortunately, weird abbreviations and acronyms are often part of the culture and one has to guess misunderstand or awkwardly wait until a brave soul inquires about their meaning.
This trait spans across many domains and programming languages, however I have noticed it is especially common in some low end embedded systems. Possibly a trait of C developers? Who knows! 😆

I sincerely think it's a very bad behavior we should leave behind as soon as possible. I hope you know there is no
performance boost if you omit the vowels from a variable name, right?
There's a very interesting read on this, by Elon Musk:
Acronyms Seriously Suck.
Please take it into consideration when writing software!

(6) Avoiding to use "auto" (Why sadistically repeat redundant types?)

To tell you the truth, my personal preference is rather on the extreme side of this. I typically like to use auto as much as possible. Specifically, I like to use auto only when I intend to implicitly convert the value on the right side, for example when I want a number with a specific range or a sequence of characters as a std::string.

Parameter getParameter();
std::vector<std::vector<std::byte>> getFrameBuffer();

int main()
{
    // DON'T LIKE: Isn't the type super obvious?
    std::unique_ptr<Parameter> p1 = std::make_unique<Parameter>();
    // DON'T LIKE: Isn't the API descriptive enough?
    Parameter p2 = getParameter();
    std::vector<float> numbers(10);
    // DON'T LIKE: Even if it wasn't obvious, do you really need
    // to know they are float? You may even end up doing an
    // implicit conversion by mistake
    for (float& n : numbers) { /* ... */ }
    // DON'T LIKE: Use `auto` or at least an alias for the type!
    std::vector<std::vector<std::byte>> fb = getFrameBuffer();

    return 0;
}

You don't have to be as extreme as me. However you should try to avoid repeating type names. And I am not taking just about when using ranged-for loops.
I believe that if you have good API names, then by using auto your code is not only as understandable, safe, but also easily maintainable across small API changes.
A relevant C++ Core guidelines rule is ES.11.

(5) C-style strings and arrays (This isn't 1998 boomer)

Frankly, I get puzzled when I still see these things in modern C++ codebases.
In regards to the C-style arrays, compared to modern standard library containers such as the std::vector and the std::array, the difference in performance is usually insignificant. Their elements are even continuously stored in memory so you can always fall back to a pointer.
Same goes for std::string.
The most important advantage of the modern data structures, aside of making your life easier with their extra features, is the readability and safety they offer.

void someLowLevelAPI(char* payload);

int main() {
    // DON'T LIKE: Use a std::vector or std::array
    int temperatures[7] = {-10, -5, 0, -2, 4, 6, 0};
    // DON'T LIKE: Just don't, we have beautiful std::string now
    char* name = "Dimi";
    char name[] = {'D', 'I', 'M', 'I', '\0'};
    someLowLevelAPI(name);
    // DO LIKE: std::string's are so much easier, safer, fancier
    std::string name{"Dimi"};
    someLowLevelAPI(name.c_str());

    return 0;
}

In case you "need" to use an C-style array or character pointer because of a legacy or external API that utilizes those types then my suggestion would be to use their modern equivalents and convert to the legacy types only when you invoke the API that needs them.
Some of the related C++ Core guidelines are R.14 and SL.str.1.

(4) Old style casting does look better but let's stop doing it

Ideally, you'd want to avoid casts all together but there are indeed some cases where they are necessary. That being said, what you should definitely not do is C-style casts.
I like their looks, however, people sometimes tend to do nasty shortcuts using them, so let's just steer clear of them, shall we?

std::optional<int> getElement(int index)
{
    static const std::vector<int> elements { 1, 2, 3, 5};
    // DON'T LIKE: It may look nicer than static_cast but in the name of
    // safety, let's generate warnings with -Wold-style-cast and eventually
    // treat them as errors
    if ((std::size_t) index < elements.size())
    {
        return std::make_optional(elements.at(index)); 
    }
    return std::nullopt;
}

If there's a need to cast, then use a named cast, in which case a static_cast will be the thing you'd want in most scenaria.
Some cast related C++ Core guidelines include ES.48 and ES.49.

(3) Optimizing for "performance" and other excuses to write unmaintainable code

This could be broken down to multiple practices, but the reason behind them can be traced back to the same cause:
Someone using performance optimization as an excuse to write 💩, hard to test and error-prone software.

First of all, Worse is better.
If you want to optimize something, the first question you need to ask yourself is if this makes sense from a business perspective. Does this bring value to your product or component?
You can discover this by defining one or more quantifiable metrics you want to improve. Then you need to prove the relation of this metric to the perceived value of your product offering. For example, you can set up an experiment with your users to verify if loading a screen 20 milliseconds faster, improves their experience.
After you have formulated your optimization goal and mapped it to the business, you want to measure how does your system
currently perform in regards to the particular metrics. You will end up with a difference, a delta.
Is this delta considerable enough to warrant action on this?
Is a solution that increases the technical debt of your system, by the business gains?
It may be so, but before you make any decisions that are detrimental to the sustainability of your product, do ask yourselves all these questions. Evaluate the implications before adopting a singleton pattern, not using modern C++ or utilizing your own implementation of a standard library container just because you think it "suits your needs better" etc. 😅
Naturally, there aren't any C++ Core guidelines for this, but instead, I encourage you to adopt the 3 rules of optimization.

(2) Abstractions leaking details (Coupling to implementation defeats their purpose)

When you come to think of it, it's an oxymoron, isn't it?
An abstraction is meant to, abstract, generalize and be implementation agnostic. Once your abstract class starts giving clear hints on the underlying implementation, then you have essentially lost the benefits of using an abstraction.
You start coding against the interface and not the implementation only in name and not in practice. You violate the Liskov substitution principle
and therefore you hurt the reusability of your code.
You claim to follow object oriented programming best practices but... you actually don't. You are simply an imposter! 😱
OK, I may be kidding, but honestly this is an indication of a bad design. If not already, you will face its consequences very soon.

struct Camera
{
    // DON'T LIKE: cv::Mat of OpenCV is an implementation-specific detail
    virtual cv::Mat getFrame() = 0;  
};

struct HardwareAbstractionLayer
{
    // DON'T LIKE: The layer is NOT agnostic, it implies Arduino is used
    virtual void pinMode(int pin, int mode) = 0;
    virtual void digitalRead(int pin)       = 0;
    virtual int digitalWrite(int pin)       = 0;
};

There are two ways of leaking details through an abstraction.

Using implementation specific types for the return value or the function arguments. For example, having a supposedly agnostic Camera interface with a getFrame function that returns an OpenCV matrix, does constrain you, well, in using OpenCV matrices for handling the frames! My suggestion would be to use something more generic, such as a vector of bytes or your own implementation-agnostic structure, to be able to switch among implementations that utilize different computer vision libraries.
Exposing an underlying implementation by having the abstraction mirror its API. When creating an abstraction, the interface is supposed to reflect the business value its consumer should expect. The abstraction is generalized so that the different concrete classes that specialize it can be utilized seamlessly by the consumers. By creating a very thin and supposedly abstract wrapper over an existing concrete implementation, does not allow you to reap the benefits of using an abstraction, because well, you simply aren't. Take a look at the HardwareAbstractionLayer interface. Its name implies that it abstracts hardware, so that higher-level components don't care what kind of platform we are running on. However, if you pay close attention and you are familiar with the Arduino library, you will notice that the various function names imply that Arduino should be used underneath. As a result, if we wanted to migrate our higher-level components to another platform we would have to adapt the particular hardware drivers to conform to the Arduino API and its constraints. Considering the the Arduino library was first created to be used on 8-bit microcontrollers, having to use that very same API on a x86_64 machine, could be severely constraining. Similarly, let's assume we want to do Inter Process Communication and want to create an implementation agnostic interface that can work on different machines with different IPC mechanisms. If our abstraction simply mirrors a specific API, let's say that of D-BUS, then once we want to switch to another IPC software, it would be difficult to adjust our supposedly platform independent higher-level components that are consuming the, D-BUS inspired, abstraction.

Overall, if your goal is to create abstractions, then make them abstract. Let them be general. Don't reflect a particular implementation in the exposed types or functions. If you do that you will be doing exactly what you wanted to avoid: Effectively coupling the your high-level functionality to a concrete lower-level implementation.
Naturally, since this is more of a design concern, there isn't an explicit C++ Core guidelines rule about this. However, I do find the following somewhat relevant as they imply that abstract classes should be generic:
I.25, C.121.

(1) Interface names with prefixes (Unnecessary tautology implying bad design)

This is my absolute worst nightmare when it comes to C++!
I am talking about this I before an abstract class name or an Interface in the end. Seriously, unless you are developing code for an existing framework that is already using this bad convention then you should simply just STOP doing this. Especially taking into consideration the drawbacks which will be illustrated below, there is literally
NO GOOD ENOUGH reason to put something in a class' name to indicate it is an abstract interface.
The first question is, why should you care?
If you would like to use a class and want to find its abstract base, then simply look at what it is inheriting. It saves you little to NO TIME to have an I prefix before it. I have YET to find a good argument on supporting this very bad practice. Every book and article I have seen on the topic,
advises against it, yet in every project I have been in, people just do it.
Overall, the consumer of an abstraction, shouldn't care it's using an abstraction and, similarly, a class that is specializing an interface, typically already knows its parent is an abstraction.
However, the biggest problem isn't in the name itself.

// DON'T LIKE: Tautology
// DON'T LIKE: Why should the user of IFoo care it's an interface?
struct IFoo
{
    virtual void bar() = 0; 
};
// DON'T LIKE (and happens too often): No generalization!
// The fact that a particular Camera sensor offers GPS coordinates
// does not mean they all do.
struct ICamera
{
    virtual Coordinates getGPSCoordinates() = 0;
    virtual Image getFrame() = 0;
};
// DON'T LIKE: What happens when you get another camera?
// ICamera indicates that it should be implemented by Camera
struct Camera : public ICamera
{
    Coordinates getGPSCoordinates() override;
    Image getFrame() override;
};

The biggest problem with prefixing, is its consequences: Abstractions leaking details.
This usually happens when someone first creates a class, let's say Foo. Then, to conform to the "supposed" object oriented design of their product, they create an IFoo interface.
There, we have two issues:

The name of the interface dictates the implementation. IFoo indicates that a Foo concrete class must be used. But... what happens if we want to have variants, let's say a Bar? We would either have to make the naming inconsistent have a Bar class specializing the IFoo interface OR do the correct thing and find out what is the business value we want to get from those two classes. Then we'd reflect that in the interface name. So why not do the correct thing from the beginning? However, that is not the most important problem.
The biggest concern is the specialization being created AFTER the abstraction. Ideally, you should first identify what is the business value you want from a class, reflect that to the abstract interface in an implementation agnostic manner and then move on implementing its specializations. If you do this the other way around, you run into the risk of the concrete class influencing the supposedly generic design of your interface. For example, if you have a camera module that includes a GPS sensor, you naturally create a Camera class with a getFrame and a getCoordinates functions. If you create an ICamera class simply by mirroring the concrete class' API, you have implicitly made the assumption that "all camera modules must have a GPS sensor too". An application specific detail just made it into the generic/domain logic!

To summarize, this is why I hate prefixes and suffixes indicating a class is an interface:

This extra notation is meaningless, redundant and verbose, causing inconsistencies in naming schemes.
It results in abstractions leaking implementation details. This is observed on two levels:
- On a semantic level If you have an IFoo, then the name implies that the implementation is, well... Foo! So whoever is using the IFoo interface, already knows/suspects that Foo will be used as the implementation.
- On a practical/design level To be fair, this is not necessarily always the case but I have seen it happen over and over: Interfaces that come with a prefix to point out they are interfaces, are typically created after the concrete implementation. Therefore, they are made to mirror the concrete API. When someone designs the abstraction after the specialization, they are prone to insert implementation-specific details into the design of the supposedly implementation-agnostic API of the abstraction.

Youtube

This article also exists as a video form on YouTube. Feel free to smash the Like button share the video and subscribe
to my channel! 🎉

How to write SOLID C++

Dimitris Platis — Mon, 22 Jun 2020 16:36:29 +0000

We all know, or should know, about SOLID. The question is, do we write C++ according to the SOLID principles?

The reason for creating this tutorial is that despite a lot of great resources and videos on the SOLID principles, I could not find anything that uses C++ for its examples. Naturally, there isn't any fundamental difference in the SOLID principles themselves when writing in C++. The problem is that, as a C++ developer, when you hear people preaching about a certain way of working and you do not find any examples you can directly relate to, then you may feel reluctant and disconnected.
I find the SOLID principles not only compatible with but also, directly or indirectly promoted by the latest C++ core guidelines. Therefore, the goal of this tutorial is to show that the SOLID principles are not only relevant to C++, but also very beneficial for software targeting specialized domains such as embedded systems.

Before moving on to concrete C++ examples on how to write and refactor C++ according to SOLID principles, let's get over the practicalities. What is SOLID?
As I mentioned before there are a lot of great resources online on the principles so I will not expand on this further. Go do your research. I will just quote the Wikipedia introduction on the topic:

SOLID is an acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. They are a subset of many principles promoted by Robert C. Martin. Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for agile development.

Source: wikipedia.org/wiki/SOLID

In a nutshell, if you work agile, these are probably some principles you want to look into.
Let's have a deeper look into the SOLID principles.
I will be first running a short introduction and then showing code that does not comply with each principle. In the end, I will offer suggestions on how to refactor it.
I do warn you that the examples will not necessarily be "textbook cases" since I often find them hard to relate to. Instead, I will show you examples inspired by real projects.

Single Responsibility principle

A class should have only one reason to change

As the name implies it requires each module, let's say class, to have responsibility for one and only one purpose.
To put it differently, the class should only have one "reason" to change.
By reason, we may for example mean a change in the specification of -a- requirement.
This principle enables you to write software with high cohesion and robustness since it's not going to be influenced as much as your system evolves. Below are some examples.

struct PhotoUploader {
   PhotoUploader(Camera& camera, CloudProvider& cloudProvider);
   Image getImage();
   Image resizeImage(int x, int y, const Image& image);
   void uploadImage(Image& image);
};

Have a look at the PhotoUploader class.
It depends on two resources: a Camera and a CloudProvider. The dependencies, combined with the name of the class, which implies that it merely uploads photos, should start making you suspicious.
If we move towards the member functions, we can see that the class has more than one responsibility. It takes pictures as well as resizes the images (which depending on the context you may count as one or two purposes already) and uploading images.
The problem with this class is that as soon as we encounter a change in the way that we upload stuff on the internet, the size of the image, or the way we use the camera, this class has to be refactored.

This was a relatively straight forward example, but let's discuss one with a slightly more subtle violation of the Single Responsibility principle.

const string kPrefix = "user-";
struct UserManager {
   UserManager(Database& database) : db{database} {}
   void createUser(string username) {
       if (!username.startsWith(kPrefix)) {
           username = kPrefix + username;
       }
       db << "insert into users (name) values (?);" << username;
   }
   string getUsersReport() {
       vector<string> users;
       db << "select name from users" >> [&users](string user) {
           users.push_back(user.erase(0, kPrefix.length()) + ",");
       };
       return users;
   }
};

For the better or the worse, violations of the single responsibility principle are not always going to be so straight forward.
We have UserManager which depends on some kind of Database. It can create users and fetch the users' report.
One could argue, that creating a report may be counted as an additional purpose, but let's be lenient and claim this is considered part of the same responsibility.
My first and weakest objection would be the inclusion of the SQL query into a higher level class. I would argue that the database schema should not be something that modules except the database should be concerned with. But in any case, let's assume that the Database class is a very thin wrapper.

The biggest issue I see is that the UserManager class is responsible for the formatting of the user name both before inserting it into the database but also when extracting it out.
This effectively means that the UserManager class becomes responsible for two things:

Input and output from the database based on a certain schema
Formatting strings that get stored in the database

If we get any requirement change in the database schema or the way we are supposed to store names in it, we will have to refactor the class.
Additionally, if we want to reuse UserManager for a different product, we will either be forced to adopt the same schema and username format or rewrite the class!
My solution to this would be to split things up in classes that have a single purpose.

struct DatabaseManager {
   virtual ~DatabaseManager() = default;
   virtual void addUser(string username) = 0;
   virtual vector<string> getAllUsers() = 0;
};
struct MyDatabaseManager : public DatabaseManager {
   MyDatabaseManager(Database& database);
   void addUser(string username) override;
   vector<string> getAllUsers() override;
};

struct UsernameFormatter {
   virtual ~UsernameFormatter() = default;
   virtual string format(string username) = 0;
   virtual string getReadableName(string input) = 0;
};

First, we create the DatabaseManager abstract class. It offers the capability to add and retrieve users. Its concrete implementations most likely will be using the Database itself and be responsible for the SQL queries and the project-specific schemas.
Second, I would add a UsernameFormatter interface. This interface would encapsulate the project-specific way of formatting usernames when importing and exporting from the database.
This would leave us with a UserManager class, that depends on the DatabaseManager and UsernameFormatter interfaces. It is only responsible for handling the high-level user and user report creation.
This would allow the UserManager class to be reused across projects and also be indifferent to changes in the schema and the format of the database contents.

Next up? The Open/closed principle!

Open/closed principle

Software entities should be open for extension, but closed for modification

The open/closed principle is an interesting one, mainly because it evolved through time along with the programming languages. The principle dictates the software modules are open for extension but closed for modification. This allows new functionality to be added without changing existing source code.

In practice, the best way to achieve this with C++ is polymorphism. Particularly, with the use of abstract interfaces, we can extend a class and specialize its behavior without changing the interface specification. This principle allows for reusable and maintainable software.
Let's start by looking at a counterexample. Something you should not do.

enum class SensorModel {
   Good,
   Better
};

struct DistanceSensor {
   DistanceSensor(SensorModel model) : mModel{model} {}
   int getDistance() {
       switch (mModel) {
           case SensorModel::Good :
               // Business logic for "Good" model
           case SensorModel::Better :
               // Business logic for "Better" model
       }
   }
};

In this snippet we have a DistanceSensor class, that depending on the way we have initialized it, it effectively represents a different sensor.
Unfortunately, our class design does not allow the behavior to be extended unless we modify the source.
For example, if we want to add a new sensor model, we would have to change the DistanceSensor class to accommodate the new functionality.
By defining and implementing an interface, we avoid having to alter that switch statement in a way that can make things quickly very inconvenient for us.

struct DistanceSensor {
   virtual ~DistanceSensor() = default;
   virtual int getDistance() = 0;
};

struct GoodDistanceSensor : public DistanceSensor {
   int getDistance() override {
       // Business logic for "Good" model
   }
};

struct BetterDistanceSensor : public DistanceSensor {
   int getDistance() override {
       // Business logic for "Better" model
   }
};

We start by defining what we want a DistanceSensor to do in general. Remember, a DistanceSensor is something generic, i.e. it does not have a model, therefore it does not make any sense to have a concrete instance of it.
Therefore we need to define DistanceSensor as a pure abstract class or, an interface, as we would say in other languages such as Java.

Then, we create specializations of the interface, for each of the different DistanceSensor models that we have. Every time we want to add a new sensor, we can create a new child class that implements the DistanceSensor interface, without changing any of the existing classes.

Liskov substitution principle

If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g. correctness)

This principle requires subclasses to not only satisfy the syntactic expectations but also the behavioral ones, of its parents.
To view things from a different perspective, as a user of a class, I should be able to utilize any of its children that may be passed to me without caring about which particular child I am calling.
This means we have to ensure that the arguments as well as all the return values of the children are consistent.

The code examples illustrate why we must be able to switch or substitute among any of the parent's children, without altering the behavior specified by the parent, in particular, the interface.

struct InertialMeasurementUnit {
   virtual ~InertialMeasurementUnit() = default;
   virtual int getOrientation()       = 0;
};
struct Gyroscope : public InertialMeasurementUnit {
   /**
    * @return orientation in degrees [0, 360)
    */
   int getOrientation() override;
};
struct Accelerometer : public InertialMeasurementUnit {
   /**
    * @return orientation in degrees [-180, 180)
    */
   int getOrientation() override;
};

Here we have an InertialMeasurementUnit. The IMU.
The IMU is something generic but specifies a behavior for every class that specializes it. Particularly, it provides its users with the ability to get the sensor's orientation.
The problem begins when different sensors, that is, the different children that implement the interface, return the orientation in different ranges. For example, we have a Gyroscope that returns an orientation that is always positive, between 0 and 360 degrees, while the Accelerometer provides an output that can be negative. Something between -180 and positive 180.

If we had a class that should be able to use any IMU sensor, that class would read results that should be interpreted differently depending on the underlying sensor.
Naturally, this would cause problems if not addressed. Architecturally, having a class that is supposed to work with any kind of sensor but actually needs to know what kind of sensor it is, is a definite smell.
In practice, you will see the violation of this principle manifesting itself either in bugs or calls to methods that reveal information about the child specializing the interface. For example a getIMUModel() function in the abstract interface.

struct InertialMeasurementUnit {
   virtual ~InertialMeasurementUnit() = default;
   /**
    * Sets the frequency of measurements
    * @param frequency (in Hertz)
    * @return Whether frequency was valid
    */
   virtual bool setFrequency(double frequency) = 0;
};
struct Gyroscope : public InertialMeasurementUnit {
   // Valid range [0.5, 10]
   bool setFrequency(double frequency) override;
};
struct Accelerometer : public InertialMeasurementUnit {
   // Valid range [0.1, 100]
   bool setFrequency(double frequency) override;
};

As previously mentioned, the child classes have to be behaviorally consistent not just in the return values, but also in the arguments they receive.
Above, we have an example where we must supply a frequency to a child of the InertialMeasurementUnit class, but different children receive arguments in different ranges. If an invalid argument is supplied, the children may throw an exception, return an error value, or even worse, behave in an undefined manner since the actual sensor would not be able to make sense of the information we pass to it.

There are two ways to solve this. The first one is to ensure that all children behave consistently. We should be able to substitute any of the children and the classes that use them to be valid.
If that is for serious reasons not possible, we should reflect on whether it makes sense to have the particular class hierarchy. We should ask ourselves:

Does that interface make sense?
Must we really enforce the particular child-parent relationship?

The second way would be our last resort. We may try to expose as little information about the child as possible:

struct InertialMeasurementUnit {
   virtual ~InertialMeasurementUnit() = default;
   /**
    * Sets the frequency of measurements
    * @param frequency (in Hertz)
    * @throw std::out_of_range exception if frequency is invalid
    */
   virtual void setFrequency(double frequency) = 0;

   /**
    * Provides the valid measurement range
    * @return <minimum frequency, maximum frequency>
    */
   virtual pair<double, double> getFrequencyRange() const = 0;
};

Interface segregation principle

No client should be forced to depend on methods it does not use

Moving on, time to contemplate the interface segregation principle.
This principle is rather straightforward and advocates for the creation of small and atomic interfaces.
Specifically, it is better to have many single-purpose interfaces, than a single (or few) multi-purpose ones.
This enables our software to be more reusable and customizable since we don't have to rely upon or implement functionality we don't use.

struct Runtime {
   virtual ~Runtime() = default;
   virtual void sendViaI2C(vector<byte> bytesToSend) = 0;
   virtual vector<byte> readViaI2C(int numberOfBytesToRead) = 0;

   virtual void sendViaUART(vector<byte> bytesToSend) = 0;
   virtual vector<byte> readViaUART(int numberOfBytesToRead) = 0;

   virtual void setPinDirection(int p, PinDirection d) = 0;
   virtual void setPin(int pin) = 0;
   virtual void clearPin(int pin) = 0;
};

Here's a possible specification of an interface that represents a Hardware Abstraction Layer for an imaginary microcontroller.
The problem is that this interface will get progressively larger as we want to utilize more and more different parts of the hardware layer.
The larger the interface gets, the less maintainable and reusable it becomes. For example, additional work will be required if we wanted to port it to a different system.
To make things worse, having to implement a large interface means that you may have to implement things you don't have any use of.

A very characteristic indication the Interface Segregation principle is violated, are child classes with functions that have an empty implementation. The functions are merely there to satisfy the interface specification, not a meaningful specialization.

struct SerialManager {
  virtual ~Manager() = default;
  virtual void registerReceiver(function<void(string)> receiver) = 0;
  virtual void send(string message) = 0;
  virtual void readLine() = 0;
};

struct MySerialManager : public SerialManager {
  void registerReceiver(function<void(string)> receiver) override;
  void send(string message) override;
  void readLine() override;
};

There are more subtle violations of the Interface Segregation principle.

Let's assume the SerialManager interface. It exposes functionality to send, receive and subscribe on keys sent via the serial port.
Then, we have a MySerialManager implementation that exposes the said functionality.
The problem arises if we take into consideration the different objectives of the classes that utilize the interface and the ones that implement it.
Particularly, users of the SerialManager interface just want to communicate over UART and don't really care about reading the stream directly.
That's why we have the MySerialManager class there.
How we want these users to operate is by subscribing on certain keys and then wait for the callback they have registered to be invoked. Additionally, they may opt to send something back.

The problem with exposing the readLine() function to the users of the SerialManager is that the interface relays an ambiguous intent to its users. Specifically, we give the users two possible ways to do things, but in reality, we only want them to use one!

struct SerialClient {
  virtual ~SerialClient() = default;
  virtual void registerReceiver(function<void(string)> receiver) = 0;
  virtual void send(string message) = 0;
}

struct SerialReader {
  virtual ~SerialReader() = default;
  virtual void readLine() = 0;
};

struct MySerialManager : public SerialClient, public SerialReader {
  void registerReceiver(function<void(string)> receiver) override;
  void send(string message) override;
  void readLine() override;
};

To comply with the Interface Segregation principle, we can break down the old SerialManager interface into two separate ones.
A SerialClient interface that exposes the functionality of a typical client that wants to communicate over UART by subscribing to keys. This is the interface that other classes most likely want to depend on.
Then we have a SerialReader interface that only includes the readLine function. If someone needs to read from serial, they can use that interface.

Here, you should note that the implementation of the MySerialManager does not change. It remains the same. The only difference is it now implements two interfaces instead of a single one.

Dependency of Inversion principle

High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

Last but absolutely not least, we have the Dependency Inversion principle.
This is one of my favorite principles and goes hand in hand with Inversion of Control design patterns.
What do the principle's dimensions practically mean?

In traditional layered architectural styles, the higher-level components which implement the system's application logic, depend on lower-level components that contain the domain logic. Let's delve into a simplified case common in embedded Linux systems:

We are building middleware that receives signals from the UI and, depending on the business rules, sends messages over serial.
The components that decide what should happen depending on the received messages are the high-level ones, while the ones responsible for the communication with the UI and the Serial port are the low-level ones.

As expected from a layered architecture, the business or application logic components would be using the communication components.
In this example, we have DecisionMaker which uses, or depends on, the UserInterfaceCommunicator and the SerialInterfaceCommunicator.
The problem is that our application logic is tightly coupled with the domain logic. To put it differently, even if our DecisionMaker operates depending on the business rules, it won't be reusable in different settings for example in different products. That is, unless we use exactly the same implementation for the user interface and the microcontroller that we talk to.
We don't want to be forced to use the same implementation because our product needs to evolve and differentiate. So how do we fix this?

We abstract the essence of the lower-level components in interfaces. Then, we design our higher-level component to depend on those interfaces instead of the implementation.
Now, we can migrate our DecisionMaker to different hardware as long as the interface to talk with the UI and the Serial port remains the same.
This effectively allows us to create new products or new iterations of the same product, without having to excessively rewrite unrelated software. We can respond to changes in the environment or the customer's needs quickly, in an agile manner.

This is how it could look like:

struct AwsCloud {
   void uploadToS3Bucket(string filepath) { /* ... */ }
};

struct FileUploader {
   FileUploader(AwsCloud& awsCloud);
   void scheduleUpload(string filepath);
};

We need to schedule the upload of some files to the cloud, let's say AWS, and thus we create the FileUploader class.
The AwsCloud class handles uploading to the S3 Bucket where the term "S3 bucket" is specific to Amazon's Cloud services.
I see two potential violations of the Dependency Inversion principle:

Our high-level component depends on some lower-level functionality. This is fine.
Unfortunately, we do not depend on an interface, which means that we are coupled to a very specific implementation.
This means, that if we at some point decide to move to a different cloud provider, we will need to reimplement the FileUploader class, which contains logic that should be pretty much independent. Why should the FileUploader care about whether we use Azure, AWS, or Google? It just wants to schedule uploads!

We need to refactor this to decrease coupling.

struct Cloud {
   virtual ~Cloud() = default;
   virtual void uploadToS3Bucket(string filepath) = 0;
};

struct AwsCloud : public Cloud {
   void uploadToS3Bucket(string filepath) override { /* ... */ }
};

struct FileUploader {
   FileUploader(Cloud& cloud);
   void scheduleUpload(string filepath);
};

A bit better now.
The Cloud interface was now created. It exposes the uploadToS3Bucket function which does the uploading and FileUploader depends on it.
However, this is still problematic. We have an abstraction, the Cloud interface, that... depends on a detail! The S3 Bucket is being mentioned.
This means that if we were to switch to another cloud provider, we would have to either add another function named after the other provider (thus complicating everything and violating other SOLID principles) or use an inaccurate name.

Both alternatives bad. It is not enough to take the header file of a concrete class and create an abstract interface out of it.
We need to carefully determine the purpose, or the capabilities we want to offer. Then, name the functions as well as the abstraction itself appropriately. We must decide names and signatures that do not leak or impose implementation details.

Ideally, our design should be specified like this:

struct Cloud {
   virtual ~Cloud() = default;
   virtual void upload(string filepath) = 0;
};

struct AwsCloud {
   void upload(string filepath) override { /* ... */ }
};

struct FileUploader {
   FileUploader(Cloud& cloud);
   void scheduleUpload(string filepath);
};

Takeaways

Now that you have some examples of how to apply the SOLID principles in C++, I hope you will go forward and build or refactor your systems. On a technical level, you should be as agile as you claim your team's or company's processes to be.

If you feel what you heard does not apply to you, due to domain constraints or because you use a language that is not object-oriented, such as C, you should know that this may not be true!
From talking and watching some pioneers in the embedded software industry, the spirit of the SOLID principles is indeed applicable when using C as your programming language. It's primarily the semantics that change.
I do encourage you to look more into this yourselves.

That was about it folks. Please don't forget to like and share this tutorial to promote better software.