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?

Eric <e...@hotmail.com> 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?

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;
<---- breakpoint here
...

At the breakpoint, z does not equal 3. Why?

A good candidate should be able to come up with many failure modes... 

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

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?

Cheers,

Al

"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?
>
>
> 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?

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. 

"Al Borowski" <a...@gmail.com> wrote in message 
news:1...@k70g2000cwa.googlegroups.com...
> 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?

Maybe I can get one right....
1) With certain optimisers then the value of z may not be assigned until 
it is used.
2) z may not get used elsewhere and get completely optimised out.
3) Cosmic radiation altering the register. (clutching at straws now) 

Al Borowski wrote:
> 
> [..]
> 
>> 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?

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.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>;

In article <1...@k70g2000cwa.googlegroups.com>, 
a...@gmail.com says...
> 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?
> 

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

Al  Borowski wrote:

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

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

Al  Borowski <a...@gmail.com> wrote:
> 
> 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?
> 

Did I say the system wasn't broken? 

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

CBFalconer wrote:
> Al Borowski wrote:
> >
> > [..]
> >
> >> 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?
>
> 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.

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