This is not in an EE context, nor in an embedded systems context, but I've worked on software for CAD/CAM and analytic geometry. I've presented this question to interview candidates:

Write a function to plot a circular arc on an x-y plane using a sequence of straight lines. Assume the graphics system gives you two functions, moveto(x,y) and drawto(x,y), where moveto positions the cursor to a spot, and drawto draws a straight line from the current position to the place you specify.

Your function will accept the x,y coordinates of the arc's center point, the radius, a start angle in radians, an end angle in radians, and a tolerance, defined as the maximum distance your straight lines are allowed to deviate from the actual ideal circle. All the numbers are of type float.

I ask the candidate to write the function out on a whiteboard, explaining what they were doing. It's OK to ask for clarifications on the problem statement as needed. I don't worry much about minor syntax errors.

In my experience, this question very clearly separated out candidates into two distinct groups. Those who thought it was so trivial that they had trouble understanding why I was wasting their time on such a kindergarten exercise, and those who didn't have a clue where to begin, and even with some coaching on where to begin, couldn't figure out the middle or end of the solution. Most candidates fell into the latter group, unfortunately.

Of course, this question isn't C++ centric; it could be done in any language. It's mostly about understanding of algorithms and basic geometry, but it's also about ability to interact and explain yourself on the fly. And since the candidates were applying for jobs involving writing code to implement geometric algorithms, this question was very fair game.

But for a different employer, where the job involved implementing code for different types of applications, I'd expect very different questions.