VxWorks interview question !
Jamilur Rahman
Event: Job interview for Embedded S/W Designer
Interviewer: (question...)
Candidate: (answer...)
.....
.....
Interviewer: What is the best thing in VxWorks you like most ?
Candidate: Semaphore.
Interviewer: Why ?
Candidate: Because, it is faster and flexible.
.....
.....
(note that, The candidate was not offered the job)
Any suggestion, comment or thought ?
Thanks.
Jamil,
Ottawa, Ontario.
Jamilur Rahman
Event: Job interview for Embedded S/W Designer
Interviewer: .....
Candidate: ......
..........
Interviewer: What is the best part in VxWorks ?
Candidate: Semaphore.
Interview: Why ?
Candidate: Because, it is faster and flexible.
..........
..........
(Note that, the candidate was not offered the job)
Does anybody have some other thought/comment/suggestion on this ?
RonnoBonno
I would have said Windview!
Ron
"Jamilur Rahman" <jamilur...@sympatico.ca> wrote in message
news:TDkP7.17301$iF3.1...@news20.bellglobal.com...
Yin, Yong
Jamilur Rahman <jamilur...@sympatico.ca> wrote in message
news:TDkP7.17300$iF3.1...@news20.bellglobal.com...
Umesh Satyanarayana
Nothing special about the semaphore in Vxworks (except PRIORITY
INVERSION SAFE argument). Candidate should have said "Real time kernel
with rich API's"
what does semaphore got to do with faster and flexibility?
Umesh
Don Dewar
the features that make developing on vxWorks its best features. Having a
shell that can run almost any function in the system, that can set
breakpoints, look at task traces, look at task registers, control task
states, and dynamically load .out files for quick development makes vxWorks
the best development enviroment of all the real time OS'es I have used.
VxWorks has many other great features. If I were to rank the best in order I
might say:
shell
dynamic load
network support (IP stack, ftp, tftp, telnet, rlogin etc.)
windview
I would not include the basic facilities any RTOS must have such as,
semaphores, memory management, and scheduling. Although the choice of
different scheduling models provided by vxWorks is nice.
-- Don
"Jamilur Rahman" <jamilur...@sympatico.ca> wrote in message
news:TDkP7.17300$iF3.1...@news20.bellglobal.com...
Thierry De Corte
"Jamilur Rahman" <jamilur...@sympatico.ca> wrote in message
news:TDkP7.17300$iF3.1...@news20.bellglobal.com...
B.Manivannan
beneficial to all of our friends to upgrade their knowledge...Here we
have discussed only one question...
ume...@myw.ltindia.com (Umesh Satyanarayana) wrote in message news:<b6df7130.0112...@posting.google.com>...
Gary M
straightforward problem (in five minutes or less, including pseudo-code),
such as an ISR and a task synchronizing access to shared memory, or a simple
producer-consumer relationship with acknowledgement. If that's too soft a
test, you can always discuss possible solutions to the "Dining Philosophers"
problem ("n" tasks competing for simultaneous access to a pair of "n"
resources) in real-time systems.
2. VxWorks driver writers should be able to convincingly describe driver
guidelines and discuss drivers they have worked on.
3. All candidates (VxWorks or not) should be able to describe in detail a
complex project (or two) they have worked on in the past three years,
including system architecture, design issues, the areas they worked on, etc.
Given the choice of two candidates, the first a VxWorks veteran who is
lacking in complex design experience or has poor communication skills,
versus a second candidate weak in VxWorks but has outstanding RTOS
experience and complex design backgrounds, I will always lean towards the
second.
"B.Manivannan" <mani...@covansys.com> wrote in message
news:23de5426.01121...@posting.google.com...
Johan Borkhuis
this:
http://www.embedded.com/2000/0005/0005feat2.htm
Groeten,
Johan
--
o o o o o o o . . . _____________________________
o _____ || Johan Borkhuis |
.][__n_n_|DD[ ====_____ | bork...@agere.com |
>(________|__|_[_________]_|__________________________|
_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
=== VxWorks FAQ: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ===
Jim
about any of these questions ...
vxWorks is first and formost a real time OS ... if people are asking about
semaphores etc ... then you are not being interviewed for a job that
requires RTOS experience ... anybody with windows programming or even java
experience should be able to solve concurency problems ...
I think OS and Concurency questions should be clearly separated from Real
Time questions which sit on top of the OS ...
My $0.02 ...
Jim
"Gary M" <com.vertical@garym> wrote in message
news:3c152217$0$2729$724e...@reader2.ash.ops.us.uu.net...
Gary M
> Maybe I am wrong ... but so far I have really seen anything "Real Time"
> about any of these questions ...
>
1. What is an Interrupt Service Routine? What are the typical
requirements for an ISR?
2. What are the advantages and disadvantages of cache memory in a
real-time system that uses DMA?
3. What are the different types of timing requirements that real-time
systems have?
4. What is priority inversion and how is it typically addressed?
5. You finished writing a real-time system but find that the system
performs much worse than expected. What should you do? (Answers should
include: hardware verification [cache, SDRAM and device timing], compiler
settings, task priority settings, profiling, bad coding, etc.)
6. Discuss issues with dynamic memory allocation in real-time systems.
(If they don't mention the words "memory leak" or "thread-safe", they should
probably be excused.)
> vxWorks is first and formost a real time OS ... if people are asking about
> semaphores etc ... then you are not being interviewed for a job that
> requires RTOS experience ... anybody with windows programming or even java
> experience should be able to solve concurency problems ...
Picking up a book and learning windows or Java programming does not teach
someone how to write a *correct* multi-threaded application. (How does the
saying go? Reading the Owners Manual does not teach someone how to drive a
car?)
>
> I think OS and Concurency questions should be clearly separated from Real
> Time questions which sit on top of the OS ...
>
Are you implying that the OS will take care of all concurrency issues? Most
certainly not!
Real Time questions "sit on top of the OS"? Not even close.
Jim
Thanks I will go write these down now ... even you last comment about what I
implied would be a good question ;-)
What do you think about the following question ...
"What is the difference between the three types of semaphores in vxWorks
'mutual-exclusion','binary', and 'counting'?"
This question would screw me nicely ... because of the first semaphore ...
but not now hopefully ...
> Are you implying that the OS will take care of all concurrency issues?
Most certainly not!
I did ... but I know better ... as an example I offer DMA and a thread using
a pointer that is not "volatile" ... I am sure there is more ...
> Real Time questions "sit on top of the OS"? Not even close.
Sorry ... me and my big mouth ;-)
For your question ... . What are the different types of timing requirements
that real-time systems have?
What type of answer are you looking for? My best guess here would be 1.)
signaling to devices (ie being able to look at a logic analyser and find the
problem with interdevice communication), 2.) issues with data throught put
(ie minimizing bus activity and processor useage to move data through a
system), 3.)service times for various threads/processes and activities ...
would these suffice or do you think typical employeers should look for "key
words" on these answers ...
What about asking canidates about osciloscopes, logic analysers, and
spectrun analysers ... is this fair ... I am a software guy ... but I have
found these tools invaluable ... is this fair to assume that knowledge of
these tools are essential to exhibit ones experience in the field ...
Thank you ... I look forward to your response ...
Jim
"Gary M" <com.vertical@garym> wrote in message
news:3c191f2c$0$20175$724e...@reader2.ash.ops.us.uu.net...
Michael R. Kesti
>What do you think about the following question ...
>
>"What is the difference between the three types of semaphores in vxWorks
>'mutual-exclusion','binary', and 'counting'?"
Such questions make me feel that my memory is being tested, rather than
my talent. The immediate response I would want to make, but might avoid
depending on how much I want the job, is that I am willing and able to
refer to the documentation when I need to know.
After all, the definition of a technology guru is "one who is both willing
and able to read a manual", isn't it?
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mke...@gv.net | - The Who, Bargain
Jim
In my opinion a good answer to this could cover alot ... I have no problems
handing someone a manual during an interview ;-)
Is an interview with specific questions necessarily bad?
Jim
"Michael R. Kesti" <mke...@gv.net> wrote in message
news:3C1CEB60...@gv.net...
David Laight
> and able to read a manual", isn't it?
Then:
1) try the code to see how it works
2) search for the source...
3) disassemble it
4) patch the object code
5) raise a bug
6) .....
Michael R. Kesti
>What questions would you like in place of this?
I think that questions concerning design and documentation philosphies and
methodologies are far more relevant to finding good programmers. The trouble
is that it is difficult to develop tests that rate candidates in these areas.
So, just as companies often account for costs that are easy to track while
ignoring those more difficult, they tend to quiz candidates on the topics
that are easy to test. Accurate representations of the situations are not
generated in either case.
>In my opinion a good answer to this could cover alot ... I have no problems
>handing someone a manual during an interview ;-)
That's cool, but I suspect that few engineering and HR managers would agree.
>Is an interview with specific questions necessarily bad?
I suppose that it depends on the candidates and what you want to learn about
them. It seems far more appropriate to quiz a recent graduate looking for
his first job about the subtlties of a programming language than to ask such
questions of a senior engineer with dozens of completed projects behind him.
jim...@sympatico.ca
1.) "I think that questions concerning design and documentation philosphies ..."
--> I have seen a lot of canidate employee's give some really gushy answers that
only HR people and managers love ... clear and simple 'all talk and no action'
... how do you avoid that? Yes design methodologies are becoming more and more
well definined such as "The Unified Process", "XP", etc ... but too many people
out there know "the right thing to say" but have no realization of there
application to "actual work" ... (Note: maybe I am just venting ;-))
2.) "That's cool, but I suspect that few engineering and HR managers would
agree."
--> Engineering and HR managers get this reasoning from studies right ... I wish
one of them would sit me down and explain it. ;-) Or am I dreaming ;-)
3.) "I suppose that it depends on the candidates and what you want to learn about
them."
--> What can I say ... I agree ... I suppose being "Specific yet general" is the
bottom line of what you want to achieve.
Jim
tom
use one sempore,i don't know if the sempores use too much resource.
Gary M
"Jim" <jg...@ureach.com> wrote in message news:d15T7.6052$8e.345131@news...
>
> For your question ... . What are the different types of timing
requirements
> that real-time systems have?
> What type of answer are you looking for? My best guess here would be 1.)
> signaling to devices (ie being able to look at a logic analyser and find
the
> problem with interdevice communication), 2.) issues with data throught put
> (ie minimizing bus activity and processor useage to move data through a
> system), 3.)service times for various threads/processes and activities ...
> would these suffice or do you think typical employeers should look for
"key
> words" on these answers ...
>
Hard requirement loosely defined as "as action which is initiated by stimuli
and required to be completed within a specified period of time, or the
system and/or mission is subject to failure." Systems such as missile
guidance systems and anti-lock braking systems have hard requirements. "Soft
requirements" usually specify a timing requirement, but the system is
designed to recover from failures to meet deadlines. One of the challenges
in a multi-tasking, single processor system is to guarantee that hard
requirements will always be met regardless of all other soft requirements in
the system.
> What about asking canidates about osciloscopes, logic analysers, and
> spectrun analysers ... is this fair ... I am a software guy ... but I have
> found these tools invaluable ... is this fair to assume that knowledge of
> these tools are essential to exhibit ones experience in the field ...
Always a plus, but ask them how and when they use it. In my earlier career
days, I would too quickly want to spend a couple of hours hooking up an
analyzer and running tests, when I could better solve the problem by writing
some tracing functions or mousetraps in a couple of minutes. Now I prefer to
drag the analyzer out only when the problem is buried in hardware that can't
be touched by software.
I'd like to stress the need to have candidates describe in detail a major
project worked on in the past three years. Interview them in a room with a
large whiteboard, if possible, and have them go at it. After they give a
broad explanation, drill down into their areas of responsibility, and
question them about design decisions, testing plans, how they interacted
with other members on their team, problems they encountered and the
solutions tried, how they would do things differently now, etc. From this,
you will learn more about the candidate's technical strengths and
preferences, as well as the candidate's skills in communication, teamwork,
design, innovation, quality, and discipline. And if they don't get excited
while talking about the project, find out why, because you want them to get
excited about your project, right?
Aaron Graham
that Jones doesn't seem to have a very high bar for his programmers.
A lot of the answers he gives seem awfully shortsighted...
1. "This [ternary] operator exists in C because it allows the compiler
to produce more optimal code than an if-then-else sequence." Baloney!
Although I personlly love the ternary operator, there's no reason why
even bad compilers can't optimize an if-then-else sequence just as
well.
2. Programmers prefer for(;;){E} to while(1){E} because the consensus
is that more compilers will optimize the for loop better (in other
words, they don't check the conditional every time). Of course, this
could go either way. It seems obvious to me why a programmer should
prefer one construct over the other, especially after taking into
consideration which compiler he's using.
3. Maybe a better question about #define directives would be, "Why is
it good to severely limit their use?" Understanding where and how a
compiler will optimize is a much better practice than throwing
#defines all over the place. In my practice, the bugs that I've had
the most trouble tracking down are the ones that are caused by overuse
of #define. As has been said time and again, "Learn the language,
don't redefine it!"
I could go on like this... I would assume most college sophomores in
CS could have answered at least 14 of these questions correctly.
Contrary to Jones's remarks (and considering the other valid
objections raised in this thread), I would NOT recommend giving this
test as part of an interview to would-be embedded programmers.
Aaron
Gary M
has a style guideline, show it to the candidate during a second interview
and inform him/her that all code styling is done to that standard. If the
company (or the group) doesn't have a style guideline, you get what you
deserve. Enough said.
Compiler optimization questions, likewise, are a waste of the interview
time. Far more CPU resources are wasted on bad design than on whether for
(;;;) or while (1) is used.
Again (broken record), it's far better to delve into a candidate's body of
work in great detail to find out if he/she has the right stuff. They may
have taken all the requisite classes in college, but if they don't know
what, when, or how to use the items in the programmer's toolbox, forget it.
(e.g. "I used a linear search because there were only 32,000 items in the
list and we were using a fast Pentium.")
"Aaron Graham" <agr...@openglobe.net> wrote in message
news:95ebbe31.01121...@posting.google.com...
> The sad quality of the questions (and answers given) tells me only
> that Jones doesn't seem to have a very high bar for his programmers.
> A lot of the answers he gives seem awfully shortsighted...
>
> 1. "This [ternary] operator exists in C because it allows the compiler
> to produce more optimal code than an if-then-else sequence." Baloney!
> Although I personlly love the ternary operator, there's no reason why
> even bad compilers can't optimize an if-then-else sequence just as
> well.
>
> 2. Programmers prefer for(;;){E} to while(1){E} because the consensus
> is that more compilers will optimize the for loop better (in other
> words, they don't check the conditional every time). Of course, this
> could go either way. It seems obvious to me why a programmer should
> prefer one construct over the other, especially after taking into
> consideration which compiler he's using.
>
>
> Aaron