Design a set to classes to report battery/power status of different Alexa devices

Well, I feel like this deserves an answer somewhere, even if it's probably off-topic here. So I'm just going to write an answer and mark it as a community-wiki:

---

The task:

Depending on how this stage of the interview was conducted, the interviewers may have been more interested in your process (how you think about the design, what you ask about, etc.) than in the actual code produced. But either way, producing well-formed, compileable code (or as close as you can get) shows off your skills better.

The specification given is not detailed enough for any "real" code to be produced immediately. I know I'd have a lot of questions about this:

• Where is the code running: On the device? but then there's no need for a "set of classes" to simulate other devices - or if each class is only running on the relevant device, there's no need for polymorphism within those classes). On a server somewhere? that might make more sense... but raises questions about why we need to simulate all these devices there at all.

• It looks like the "say" and "display" responses are always the same... so why are we splitting them into two? We could feed a single message to the device, and then let it decide how to do the displaying. (It seems like we're expected to handle three separate processes here: querying each device for the power status, turning that power status into a message (the details of this step we don't care about too much), and then giving that message back to the device to do the relevant output).

• Are they actually expecting you to output (what seems to be) well-formatted JSON? (This is an annoying complexity without using a library). Is that supposed to go to std output?

• The linked Microwave appears (at a first glance) to have a screen too rudimentary to display the supplied message. What to do there?

• With multiple displays, do we actually need to add more messages with the "display" key (which has JSON implications), give each one a unique name, or stick to a single message?

If they gave you an opportunity to ask questions like this, it's important to take it! If not, pick an option that seems sensible, and write a short comment in the code to say why you made that decision.

In short: this is a very hypothetical exercise, with little "real-world" value. But... perhaps they can tell a lot about how a candidate approaches things, and even about their knowledge of a specific programming language, by giving them even a vague problem like this.

---

The code:

When using polymorphism in C++, you'd want to:

• Use the virtual keyword when defining an interface, and the override keyword when writing derived class members.
• Ensure your classes have a virtual destructor.
• Show knowledge of why you're using polymorphism in the first place (storing multiple classes of different types in the same container (e.g. a vector) and using them via the same interface). (i.e. you really want to write a main() function for your program that shows how to use the classes).
• Use a std::unique_ptr to store those objects safely, instead of doing raw memory management.

I'd suggest that polymorphism would not necessarily be appropriate here at all (the "prefer composition to inheritance" design guideline of C++).

---

string getStatus() { string msg = to_string(percentage); return msg; } 

This function should be const (as should the various printStatus functions).

Although the instructions are sparse on detail, they are fairly precise about the actual message you should be returning, so it's best to be careful to return the exact reply.

It's important to write std::to_string, and include the relevant header at the top. (You should always avoid using namespace std;.)

---

I think the Battery should also handle charging, and there's no need for a separate Power class.

You also don't seem to use the Battery class anywhere.

---

The OutputType member isn't actually used anywhere, so it's not clear why this needs to exist.

---

You don't really need polymorphism for the outputs. The FireTV can keep the speaker and display(s) as separate member variables, just like the other devices.

We should use a std::vector, not a std::list here too. (A list is usually slower than a vector, unless we have many thousands of items to insert and remove, and we don't need iterating the container to be fast. Here we have very few items, and we need to iterate them.)

---

There's no need to use pointers for the various device member variables. It's much easier to use simple member variables on the stack. (Also, the code doesn't show how those pointers are allocated or cleaned-up - even if you did need pointers, why not use std::unique_ptr instead of raw pointers?).

---

Range-based for loops in C++ look like for (auto const& output : outputs) .... They don't use foreach. Of course you might not care if you're writing pseudo-code, but it's something basic that the interviewers might notice if they're expecting C++ specifically.

---

The code doesn't try to actually produce the desired messages; the instructions do say: Focus more on ..., and returning the correct responses. So there's a lot of missing detail here... e.g. how do you return the formatted JSON? how do you show "say" vs "display".

---

They give you links to each device (most of them, anyway). So if you had the time, it might have been worth looking at each one, and making sure you modelled them all as accurately as possible. (Being systematic and thorough is good. Showing knowledge of their products (being a bit of a suck-up :p ) might not be bad either).