Interview Embedded Software Questions

You ask them questions that involve writing code, on a whiteboard, to do realistic but simple embedded systems tasks. Another good question to asks is getting them to explain their understanding of how an embedded system starts up - which leads on to their understanding of code and data sections, interrupt vectors, linkers and loaders etc.

A good open-ended question we used to ask was

... int x=1; int y=2; int z;

z = x+y;

Hi,

You've got me. If I was asked this in an interview I'd be stumped. What kind of non-seriously broken system could have z not being equal to three?

Cheers,

Al

Ask them to explain where you would use a volatile variable. That's always a good test to see if they've been paying attention.

Maybe I can get one right....

Me too. All I can think of is that the debugger is flawed, and actually setting the breakpoint before the completion of the statement. Alternatively the code has been optimized so that the bp location no longer makes sense, indicating that the compilation should be with optimization disabled.

My first guess would be a system where z was never used in any further operation and the compiler optimized out the addition.

If you actually look at the assembly code when debugging, that kind of problem should be obvious.

Mark Borgerson

This response illustrates nicely that cute interview questions do not select good employees, merely employees who know the answers to trick questions.

Did I say the system wasn't broken?

pete

Interrupt run amok or bad prologue/epilogue. In a tasking system, too small a stack and the local storage has wandered into an actively used area of memory.

If the variables are global rather than function local (as seemes to be implied) then bad startup initialization also comes to mind.

My first step would be to figure out what x and y were.

Robert

The compiler hasn't seen a reason to evaluate z yet. Z may not even have storage allocated, optimized out. If used later z may be simply replaced with the constant 3, but the debugger doesn't know this.

Declare z to be volatile and the compiler will be obliged to do what you said, not what it thinks you intended.

As always, Google is your friend. Google for _volatile embedded_ in google groups. It gives you a pointer to a thread called "Embedded software interview question collection" which may be useful.

Regards

Josep Duran

Some good answers. It's far from being a 'trick' question, it's aimed at seeing the sort of questions candidates ask and the assumptions they make.

pete

With a good optimizer, z might not even exist at the breakpoint ;-)

I'm thinking compiler bugs, optimizer quirks, ground bounce, rogue interrupts, ESD, bad MCU, bad SRAM (if the stack is in SRAM), debugger bugs, bad debug cable.

Good tools should say z = 3 regardless of what follows. My guess is z at that moment in time is located in a register or flow evaluated so it is stored to RAM and the source level debugging information should reflect where z actually is. I am not so sure that I wouldn't be stumped on this one.

w..

That's certainly what I would hope. If it's not meant to be the start of a discussion on how you would approach the problem then it does become a trick question. A list of possibilities should just be the starting point for determining how to eliminate or confirm them.

Robert

Is the UK currently experiencing a surplus of jobs for engineers? I'm currently recruiting a contractor/permanent hardware engineer and I've had several not even bother to turn up for the interview. This would imply that there are so many jobs available that they are not having to put any effort into finding them. Or perhaps they just take one look at the rough estate our premises are on and turn around :-)

One thing is for certain, z should be 3 or the compiler is broken period. Although this is NOT 100% true if we talk about the debugger!

In C:

... int x=1; int y=2; int z;

are "local" defined variables ( even for main() ), they live in the stack "assigned" to the function. Since x and y are initialized statically we can assume that they do live in the stack (or scratch registers depending on the compiler of course), z on the other hand could be located in a register for optimization purposes, that is why a Debugger wouldnt be able to catch Z as a variable...

The real answer would be based on how the debugger behaves given the code generated by the compiler, optimization flags set and the rest of the code for that particular function.

Rene

Walter Banks wrote:

Eric a écrit :

My company decided a long time ago we needed to be taught how to write software. They hired a consultant who arrived in a nice red sports car. We told him we were making software for devices that had no keyboard and no screen. It was hard to convince him that such things could be useful.

That was my reaction as well. If z != 3, how did the code execute well enough to even get to this point? Seems akin to the computer hardware diagnostic program contradiction -- if the hardware's working well enough to run the diagnostic program, you don't need to run it.