embedded software boot camp

Knowledge versus Understanding

Wednesday, October 11th, 2006 by Nigel Jones

Every month or two a ‘Technical Recruiter’ from one of the larger placement companies calls me up to see if I’m available for work. Most of the time I’m not, and so the conversation terminates quite quickly. However, once in a while I am available, and so the inevitable request for an updated resume is made. After sending an updated resume, the ‘Technical Recruiter’ calls back to discuss what you have to offer.

Well, for the first time in several years I recently went through this rigmarole. The conversation with the recruiter was both illuminating and yet rather depressing. To paraphrase, the conversation went like this:

Recruiter: “What RTOS experience do you have?”

Me: “VxWorks, MicroC/OSII, Embedded Linux, various bespoke systems”

Recruiter: “No others? ”

Me: “Isn’t it more important that someone understands the benefits and limitations of an RTOS rather than knowing the particular API of a specific RTOS?”

Recruiter: After a long pause. “Our clients like someone that can hit the ground running.”

I see two possibilities here.
1. The ‘technical recruiter’ has no technical knowledge and is nothing more than a matcher of acronyms and buzz words.
2. His clients really are saying to him, we need someone with experience of XYZ RTOS.

If it’s the latter, then it appears that knowledge is a more highly prized commodity than understanding. Personally, given the choice between someone that knows an RTOS API and someone that really understands priority inversion, can discuss the pros and cons of RMA as a scheduling algorithm, and can explain the implications of making an RTOS call from within an ISR, then I’d take the latter any day. Of course, one might claim that an experienced user of XYZ RTOS should be aware of these sorts of issues. However, in my experience, large swathes of the folks out there using an RTOS really don’t have a clue about what it’s doing for them – and what it’s costing them.

Thus my point is this. Next time you are looking for help, think about what you’d like the person to understand – as well as what they should know. I suspect you’ll end up with better help.


5 Responses to “Knowledge versus Understanding”

  1. Víctor says:

    Hello,I'm a newcomer to the engineering world since I ended my electrical engineering studies just a couple years ago and most recently finished my thesis (on Reaktor, making a synth). I'm reading your blog because I found it taking a look around some embedded systems sites, because it's an interesting field and looks like a nice market, since I like home and industry automation (besides microwave applications which is by far my favorite). I agree with you on the side that most headhunters/recruiters look for professionals with a very specific knowledge of "A/B/C SYSTEM" no matter the capacity of the person to actually understand how things work. I want to move from my actual job but I find in frustration that most companies in my field require CCNA/CCNP certifications which in the end say nothing about a persons ability to solve problems. This gets worse when job interviews are taken by external consultants (mostly psichologists or tai-chi/relaxation therapists which are douche-it-alls regarding tech stuff). I still wonder why I take the time to write a resume when all they look for is "software a, certification b, course of d".

  2. Amit says:

    Hi Nigel, I am frequent visitor of your site, it’s informative and interesting.
    I mostly work on linux systems. As this topic is about RTOS, can you please explain what the difference between RTOS kernel and General purpose operating systems.
    I could find that RTOS kernel are predictive and execute the instructions in some max time limit but no where I could find who they do it.
    Is it possible to recompile our linux kernel with some setting to make it work as RTOS.

    • Nigel Jones says:

      As a regular reader you will probably have noticed that I don’t write much about RTOS. I don’t because it’s a topic that gets discussed to death in a myriad of locations. Anyway to answer your question – yes an RTOS must be deterministic and usually very fast. It does this in part by severely limiting what it does. For a good exposition on this I suggest you read Jean Labrosse’s book uC/OS-III As to whether it’s possible to recompile the Linux kernel. I would say in general no. There are a number of vendors out there that offer real time Linux kernels. Try searching under ‘real time linux kernel’ and you’ll find all you want to know on this topic.

  3. anamika says:

    Nigel Could you suggest a good book which discusses all the concepts of RTOS that wrote about ” priority inversion, can discuss the pros and cons of RMA as a scheduling algorithm, and can explain the implications of making an RTOS call from within an ISR” thanks

Leave a Reply