I have 7 days to prepare for an Embedded C++ Interview. Any tips and good links?

I've programmed in C/C++ and other languages before. I've passed two phone interviews for an Embedded Software Engineer position which mentions:
- Linux application and driver development for embedded microprocessor environments
- Previous experience in C++ programming and embedded development tools
- Knowledge of software engineering theory
- Strong debug, diagnostic and test skills
- Organized coding style
- Experience of integrating new and existing code

There's a lot to know about C++ and I can only remember the basics. I cant remember small details because I haven't been programming in C++ regularly in my current job (which is web development so its not really related). I have 7 days in which to prepare as much as I can and answer all the interview questions and show them I know my stuff. I have installed C++ development tools at home and work. I can create flash cards, write programs, do exercises - whatever it takes.

So what I need from people here is:

Any recommendations on good revisions tools/methods/resources, lists of exercises, interview questions etc so I can work on them and be prepared for this interview?
I can google and find some information but if I can get recommendations from experienced people here that would be great.

Not related to embedded development, but consider these books for programming interviews.

Elements of programming interviews
http://www.amazon.co.uk/gp/product/1...A3P5ROKL5A1OLE

Cracking the coding interview
http://www.amazon.co.uk/gp/product/0...A3P5ROKL5A1OLE

Programming interviews exposed
http://www.amazon.co.uk/Programming-...=I5ZEFKGC2VKUU

Wish I had the time to buy a book but it takes time for shipping. I basically have a week left. Will try start searching around.

Fact of the matter:
They're probably more concerned about getting to interview someone who's experience in the "embedded" part, rather than someone that has "C/C++" experience.

You probably have a shot if you know about embedded programming and know nothing at all about c/c++.
But if you're experienced in C/C++ and know nothing about embedded, chances are, you aren't what they need.

if you know nothing about embedded programming, and don't even know C/C++ fluently... I wouldn't put my hopes up too much :s


Long story short, trying to "cram" knowledge in a short timeframe is a bad idea, you're better off being honest, explaining what you do know and what not, show a willingness to learn the stuff they need (even on your own time).

Search the web for opinions about what parts of C++ to be aware of when programming in an embedded envioronment.
Opinions can differ quite a lot concerning C++ constructs, but RTTI, dynamic memory allocation and exceptions are among the most hotly debated subjects in embedded circles. Some even get very twitchy about using templates.

My own opinions are:

• RTTI
  You need this if you are using typeid or dynamic_cast. RTTI incures a space overhead and dynamic_cast a time overhead. I've not had a need to use these in practice as there are often better methods.
  
• Dynamic memory allocation
  The heap on an embedded project may be anywhere between 'practically non-existant' and 'huge'.
  The main concerns in using the heap is either running out of space (it's hard to determine statically how much you actually may need), and the time penalty involved in allocating and deallocating memory. If the heap is large enough I would tend to say that dynamically allocation at initialisation of the application is of no harm. This is actually a common technique in embedded programming; to allocate everything up-front.
  
• Exceptions
  Now this is probably the most contentious! It all depends on how exceptions on your platform are implemented. One method may incure extra code around the throw-try-catch, possibly affecting time performance, while another may incure a space penalty, but making the non-exception path quicker than the equivalent 'error code return' version. Some do not like the non-deterministic path that the code takes when unwinding the stack and calling destructors after a throw, while others are of the opinion that, if an exception has occured, then something nasty has happened and it's better to at least close things down in an orderly fashion.
  
• Templates
  I use them extensively. The common complaint is that they can cause 'code bloat' though inadvertent creation of many 'types' from one template. Personally, I find their usefulness far outweighs any arguments over (potentially) larger generated code size.

There's no one right answer, it all depends on the platform and application.

2kuad, I just got the first book you linked. I got one-day shipping and it should be useful in future interviews too.

OReubens, I got the Embedded part covered somewhat. I have prior experience in education settings that should help. I'm also getting extra training currently. Hope it works out.
I'm ok in C/C++, I just havent programmed in a long time in this language and I can Google things and get stuff working but they wont allow it in the interview. I wish they always tested people on how they generally solve problems rather than checking 'book' knowledge which is helpful for sure but if someone isnt strong in that, they should be forgiven if possible. However if someone has both aspects covered they'll be ahead.

Quote:

---

Long story short, trying to "cram" knowledge in a short timeframe is a bad idea, you're better off being honest, explaining what you do know and what not, show a willingness to learn the stuff they need (even on your own time).

---

I know what you mean. I've been applying and like all job applicants I've not gotten not a lot of positive replies (nature of mostly any job search). This certain job though is a great fit for me and with the extra training I'm doing, everything should be fine or atleast better. I just hope I get lucky enough and they give me a chance. There's still so much competition for every job so I'm scared. I'll give it my best try.


JohnW@Wessex, thanks for that info. I'll read up on all of those topics and make sure I know them.

Quote:

---

Originally Posted by alan-31

I'm ok in C/C++, I just havent programmed in a long time in this language and I can Google things and get stuff working but they wont allow it in the interview.

---

I think it may be okay if you're a little bit rusty on the details but know and understand C++ conceptually.

Realtime embedding often raises safety concerns. The full language cannot be used anymore but must be restricted to a safe subset. One example of this is the Joint Strike Fighter C++ coding standard. Interestingly Bjarne Stroustrup, the founder of C++, has been actively involved in this effort.

You should find a presentation of the JSF++ project as a dowloadable pdf file if you google for this,

"JSF++ AV Coding Standard"

This will give you an idea of what parts of C++ are problematic in an embedded situation, how they can be dealt with and what the work-arounds are.

A figher jetplane of course is an extreme case. On the other hand the requirements on C++ hardly cannot get any tougher so it's an interesting one. And it's not just anybody behind it but the most credible C++ guy on the planet. The entire JSF++ standard is available on the net.

Another tip for the interview is to show a keen interest in the company's products and also the people conducting the interview, especially the tech guy. It's the only way to somewhat control the situation. People like people who are interested in them. Afterwards they'll recall having heard from you what they said themselves. So do your homework so you can ask informed questions.

Dazzle, great information and advice. I will read again and make mental notes (showing strong interest in the products and the people, asking good questions etc). Will also search for that PDF and will look up more information on C++ issues with embedded. Thanks.

Quote:

---

Realtime embedding often raises safety concerns. The full language cannot be used anymore but must be restricted to a safe subset. One example of this is the Joint Strike Fighter C++ coding standard. Interestingly Bjarne Stroustrup, the founder of C++, has been actively involved in this effort.

---

in this particular case there were safety concerns (or rather 'reliability concerns').

This isn't really related at all to the JSF++ problem and the results used there may not even apply to you at all.

The thing to remember is that embedded systems tend to be restricted in some way to reduce cost, reduce physical size/weight (sending a few extra grams into space can be a big deal), reduce power consumption etc.

If you're on an embedded system with very few RAM, then any C++ feature that needs lots of RAM will be an issue. If you have little or no heap, then something as simple as vector<> could be problematic or even forbidden.
if you're limited in ROM, then features like RTTI may be forbidden because of the extra memory usage.

There's little point to try and cram stuff in your head about much of anything without knowing what actual hardware you'll be designing for. THe reasons that motivated/guided a certain project like JSF++ into a certain direction may be radically different than the ones you'll be facing.

JSF mainly needed a sturdy design that could withstand the G forces, that wasn't likely to crash, didn't consume a lot of power, operates in a wide variety of temperatures and humidity, and didn't weigh too much. That typically translates into lower CPU clockrates, less memory and lower amounts of ram. Such restrictions then guide certain software design decisions (and ultimately language features if the restrictions are strict enough).

Quote:

---

Originally Posted by OReubens

This isn't really related at all to the JSF++ problem and the results used there may not even apply to you at all.

---

There is plenty of information on embedded systems readily available on internet, like say here,

http://en.wikipedia.org/wiki/Embedded_system

What sets the JSF++ coding standard apart is that it demonstrates concretely how safety concerns, hard realtime restrictions and performance requirements imposed by embedding influence the use of the C++ language. It's precisely because it's an extreme case it works so well as example.

The link I suggested is not to the JSP++ standard itself but to an overview presentation. Having a look at it isn't about cramming details. It's about understanding and gaining perspective.

I know embedding may simply translate to we need a language with a small footprint. Then plain C is often a better answer than a restricted C++. But that's hardly a bomb to drop during a job interview with an employer who's already committed to C++, is it? :)

Quote:

---

Originally Posted by dazzle

But that's hardly a bomb to drop during a job interview with an employer who's already committed to C++, is it? :)

---

I tried talking up the suitability of C++ in an embedded environment to a group of hardware engineers (who'd never programmed in anything but C) at an interview once. It didn't go down too well.

One of the issues with coding for embedded systems is the amount (lack of!) memory available - both for the stack and for the heap. Depending upon how small is the available memory, this can have effect upon the program design - such as limiting the depth of function calls or the number of variables that can be used in a function. It can even mean that function parameters are always passed by reference rather than by value so as not to create a copy of the variable.

Depending upon the processor used in the embedded system, this can determine the size (and maximum value) of ints and whether float/double are available - or these functions if needed have to be provided by software emulation in a library which adds to the size of the produced code.

There is also the issue of new (malloc/calloc) and delete (free). Are the uses of these predictable or are they based upon external factors (interrupts, user action etc)? If unpredictable will they always work and if not how to handle failure? - the embedded program must keep running! Depending upon the heap size and the relative calls of new and delete they might be enough physical heap memory available in total but not enough consecutive available memory to satisfy the request.

Quote:

---

Originally Posted by JohnW@Wessex

I tried talking up the suitability of C++ in an embedded environment to a group of hardware engineers (who'd never programmed in anything but C) at an interview once. It didn't go down too well.

---

You can produce code that's just as optimal in C++ as it is in C. But you may have to restrict some language features to do so.
C++ has a lot of advantages over C.

I'll call those short-sighted engineers. Or engineers that are still stuck in the early days of C++ when indeed, there was a lot of language and library overhead and you could end up with very bulky exe's even for simple projects.

I got the usual FUD aurguments from them such as 'code bloat', 'slow' and 'inefficient'.
I tried to point out that, if they were experienced C coders, they were undoubtedly manually implementing many C++ features anyway. Just in a slightly inefficient and error prone fashion.

Watch some videos on the latest stuff on C++ here

http://channel9.msdn.com/Events/GoingNative/2013