Al Borowski wrote:
> Hi,
> 
> [..]
> 
>> A good open-ended question we used to ask was
>>
>> ...
>> int x=1;
>> int y=2;
>> int z;
>>
>> z = x+y;
>> <---- breakpoint here
>> ...
>>
>> At the breakpoint, z does not equal 3. Why?
>>
>> A good candidate should be able to come up with many failure modes...
> 
> 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?

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.

Eric wrote:
> The company I work for is in the process of interviewing several
> embedded software candidates.
>
> What types of questions could we ask to make sure the interviewee is an
> embedded software candidate and not just a high level CS major?
>
>

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

Robert Adsett <s...@aeolusdevelopment.com> wrote:
> 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.
> 

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.

> 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.
> 

pete
-- 
p...@fenelon.com "he just stuck to buying beer and pointing at other stuff"

Pete Fenelon <p...@fenelon.com> writes:
> z = x+y;
> <---- breakpoint here
> ...
> 
> At the breakpoint, z does not equal 3. Why?

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.

David Kelly wrote:

> Al Borowski wrote:
> > Hi,
> >
> > [..]
> >
> >> A good open-ended question we used to ask was
> >>
> >> ...
> >> int x=1;
> >> int y=2;
> >> int z;
> >>
> >> z = x+y;
> >> <---- breakpoint here
> >> ...
> >>
> >> At the breakpoint, z does not equal 3. Why?
> >>
> >> A good candidate should be able to come up with many failure modes...
> >
> > 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?
>
> 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.

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..

Pete Fenelon wrote:
> Robert Adsett <s...@aeolusdevelopment.com> wrote:
> > 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.
> >
>
> 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.

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

"Eric" <e...@hotmail.com> wrote in message 
news:1...@m73g2000cwd.googlegroups.com...
> The company I work for is in the process of interviewing several
> embedded software candidates.
>
> What types of questions could we ask to make sure the interviewee is 
> an
> embedded software candidate and not just a high level CS major?

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:
> David Kelly wrote:
>
> > Al Borowski wrote:
> > > Hi,
> > >
> > > [..]
> > >
> > >> A good open-ended question we used to ask was
> > >>
> > >> ...
> > >> int x=1;
> > >> int y=2;
> > >> int z;
> > >>
> > >> z = x+y;
> > >> <---- breakpoint here
> > >> ...
> > >>
> > >> At the breakpoint, z does not equal 3. Why?
> > >>
> > >> A good candidate should be able to come up with many failure modes...
> > >
> > > 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?
> >
> > 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.
>
> 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..

Eric a écrit :
> The company I work for is in the process of interviewing several
> embedded software candidates.
> 
> What types of questions could we ask to make sure the interviewee is an
> embedded software candidate and not just a high level CS major?
> 
> 
> We've asked questions about whether they would feel more comfortable
> doing low level drivers or application level stuff? The usual answer we
> get is "I can do all of that"..... No, most people are better suited
> for one or the other... many can do both, but that person usually has
> strengths in one or the other.
> 
> Another sample questions is "What steps would you have to go through to
> set up an interrupt on a mirco?"
> 
> Any other ideas for interview questions?
> 
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.

"Al  Borowski" <a...@gmail.com> writes:
> [..]
> 
> > A good open-ended question we used to ask was
> >
> > ...
> > int x=1;
> > int y=2;
> > int z;
> >
> > z = x+y;
> > <---- breakpoint here
> > ...
> >
> > At the breakpoint, z does not equal 3. Why?
> >
> > A good candidate should be able to come up with many failure modes...
> 
> 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?

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.