LabVIEW for Recruiters
Recently I have had many meetings/discussion with recruiters, hiring managers and procurement staff regarding LabVIEW and what iNU Solutions can offer to them as a company.
During these conversations it became very clear that there is limited knowledge, understanding and/or experience of LabVIEW within these groups of people, take for example this conversation I had with a purchasing “engineer”:
Me: Can you tell me why we weren’t selected for the final round of bidding?
Purchaser: You do not have any LabVIEW experience
Me: Sorry? I am a CLA
Purchaser: A what?
I told this to a LabVIEW friend of mine and she said “I know someone who was asked when they were going to get the “D” to go on the end of their CLA”. Now this could be considered a kind of “inside joke”, however in reality it can be a very serious issue if it prevents qualified candidates from being accepted for interviews/job opportunities.
So for all those recruiters, hiring managers, purchasers, team leaders etc. here is a quick guide to LabVIEW and what you should be looking out for…
General LabVIEW Trivia
LabVIEW – Laboratory Virtual Instrument Engineering Workbench – is a graphical programming language, sometimes referred to simply as “G”. Note that this is different from G-Code. It is developed and sold by National Instruments (NI), currently there are 2 versions LabVIEW and LabVIEW NXG.
Due to the introduction of LabVIEW NXG (Next Generation) it is common to hear LabVIEW to be referred to as “LabVIEW Current Gen”.
The IDE (Integrated Developer Environment) is based around the “drag and drop” concept and uses data flow to control the program execution. The data is passed along wires, creating a very easy to follow visual representation of your program. Anyone who has ever seen a flow chart will be able to understand the basic concept.
In addition to LabVIEW, National Instrument also sells various other software platforms and add-ons, as well as a whole host of hardware. The most common of these are:
TestStand – A test sequence environment
LabVIEW RealTime – Allows programs to be developed for the RealTime environment
LabVIEW FPGA – Allows programs to be compiled so that they run on an FPGA
Vision Toolkit – Built in modules to allow for advanced vision techniques such as edge detection, depth measurements, etc.
What can LabVIEW be used for?
Almost anything that requires measurements, capture of data, manipulation of data, displaying of results, controlling of hardware etc. This can be anything from a simple power sweep measurement on a lab desk through to production lines for rocket ships.
If you really are an engineer (i.e. it’s more than just in your job description) then this part will make some kind of sense to you.
Simple programming architectures such as state machines and producer/consumer loops are possible, as well as more advanced architectures, such as Object Oriented Programming (LVOOP) and Actor Framework.
The implementation of parallel programming is exceptionally simple, as is the creation of Hardware Abstraction Layers and interactive User Interfaces.
You can also use techniques such as user events, notifiers, assertions, and data queues. All of these are build in to the IDE.
For testing and releasing you can use most mainstream processes such as Continuous Integration, Unit Testing, Regression Testing and so on. Stand alone executables are very simple to create and can be distributed with the free Run-Time Engine. Source Code Control services such as Git and Subversion can be integrated directly into the environment.
It has built in API for using additional plug-ins such as JSON, Python, Cloud storage, SQLite and many others.
If you don’t know much about software engineering, computer science, programming environments then that’s ok, this section is just for you.
Firstly, Yes LabVIEW is spelled like that. It is a brand name so that is just how it is spelled, it’s not Labview, LabView or labview, it is LabVIEW.
Second, Yes it is a “real” programming language. Take a look at the above description and try Googling some of the terms, you will see that they show up for most of the “real” languages you have heard of, such as Java, C++, Python etc.
Thirdly, Yes it can be very easy to program in LabVIEW. However this is all relative, as flying a Boeing 747 is easy to a pilot with 20 years experience. Yes, you can create very simple programs in LabVIEW in a few minutes that will capture and display data on a lab bench. But you know CERN (that big circle in the ground under Switzerland)? The high energy beam is controlled by LabVIEW. Also, you know that SpaceX launch that was abandoned with a few seconds to spare due to a technical issue? You know what detected that issue? Yep, LabVIEW!
Now that some of the more common “questions” have been covered, lets give you a few tips on how you can correctly interview for a LabVIEW based role.
National Instruments has a certification program that consists of 3 levels:
Certified LabVIEW Associate Developer (CLAD) – A 1 hour multiple choice exam
Certified LabVIEW Developer (CLD) – A 4 hour practical exam
Certified LabVIEW Architect (CLA) – A 4 hour practical exam
All of these certification are given based on a practical exam, they are marked against set criteria and are not just given out to anyone who has been on a 2 day course.
The CLAD is the lowest level and this really just says that the person is familiar with the environment and knows some basic ideas behind LabVIEW development.
If you are interviewing for a role where LabVIEW is a “nice to have” then this level would be suitable and you can assume that they would be competent enough to create simple programs or contribute small parts to larger programs.
The CLD is the middle level of certification and shows that the person can create a useable, runnable program based on a given specification in a relatively short time frame.
This level would be required for roles where LabVIEW is required in order to do the job, but is not the job itself. So for example, many “Test Engineer” roles require the tests to be written in LabVIEW, but writing tests is not the whole job.
Achieving the CLA level is something that not many LabVIEW users achieve, this can be for many reasons but the most common is that the exam is quite difficult. Holders of this certification level have shown that they can create a workable architecture for medium to large applications that can be expandable, is readable and above all allows others to contribute. One way to look at it, is that the CLA creates the template that the CLD then fills in.
If the role you are interviewing for is 100% LabVIEW, building large scale applications, working in teams, delivering cutting edge solutions, then you should be aiming for the CLA holders.
As well as the above 3 there are other ways of identifying candidates/companies, however these are slightly more subjective.
– NI Alliance Partner
These are companies that have been chosen by NI for some particular specialisation, this could be automated testing, vibration measurements, whatever.
It is important to note that there is no “test” as such to be in this partner program, it is purely based on the opinion of NI so this could be for business reasons as well as engineering/technical ones. Just because a company is part of the Alliance Program it does not mean that they are LabVIEW experts, note that it is the National Instruments Alliance Partner Program, not the LabVIEW Alliance Partner Program.
– LabVIEW Champion
This is an award given to a few people in the LabVIEW community who have gone “above and beyond” the normal level expected of the standard LabVIEW user. There is no exam for this, it is given by peers to individuals based on each individual’s skills, contribution and overall standing in the LabVIEW world.
Note however that to be a LabVIEW Champion, you do not need to have any of the “official” certifications, in fact you do not need to know how to program in LabVIEW at all.
Job Descriptions and Interviews
It is my view that if a candidate has one of the 3 “official” certifications then their level of knowledge should be assumed, to an extent.
So for example, someone interviewing for a role at CLAD level shouldn’t be asked questions regarding Actor Framework and its benefits to large scale applications
Likewise, someone interviewing for a CLA level position should not be asked questions such as “what is a VI?” Or “Are you familiar with HALs?”
Let me put it a different way, when you board a plane do you ask the pilot to give examples of routes he has flown, how many flights he has taken in the past 6 months and if he knows what a wing is?
Likewise, would you ask the person giving you your food what the total power delivered by the engines was at 20,000ft compared to 40,000ft?
NOTE that I said “CLAD level”, “CLA level” and not CLAD or CLA holders. There is a chance that someone who has the CLAD certification (or indeed no certification) does in fact know about AF, but for a CLAD level position this should not be a relevant question.
The certification system is a step by step process, so to get the CLA you need to hold a current CLD level certification. This is important as in some cases it has been assumed that a CLA cannot actually “do the work” and is all about the higher level architecture and support activities. This is not true, it is absolutely not possible to pass the CLA exam without having a high level of understanding of how to program in LabVIEW. The CLA exam is 100% practical, meaning that the person sitting the exam has to program in LabVIEW in order to pass. The biggest difference is that with the CLA exam you need to take into account that other developers will be contributing to the same program, so therefore you need to ensure best practices, common APIs etc.
The certifications are only valid for a certain time, after this the holder would need to re-certify. This is why it is important to ask for a current certificate, or you can check the list here
If you are going to be interviewing someone for a 100% LabVIEW role then I do not think that there is any need to insist on a CV. If they can prove they have a current CLD/CLA certification then that should be enough.
This especially applies if you are meeting with a representative from a company who you hope to do business with, there is absolutely no justification to ask for a CV from this person. By all means request some kind of portfolio of work, or maybe you could just check the website of the company.
On a similar topic, if you are a recruiter it is not appropriate for you to ask for the names and contact numbers of references. I have had the situation several times that this information has been abused and the recruiter has contacted them offering their recruitment services, not asking for references. This is totally unprofessional and the main reason why I do not give references to recruiters. If the end customer asks for a reference then this should be sent direct to them, not via the recruiter.
Most people who market themselves as a LabVIEW specialist will have some kind of website or portfolio of work. If it is not possible for them to send this to you then as a last resort you could call the local NI office. All “significant” LabVIEW developers in the region will be known to NI, if your candidate isn’t then this should ring some alarm bells.
So if you are going to be interviewing someone for a LabVIEW based role and you do not know much about it yourself, here are a few links to further explain the above points…
There are also many events that you can sign up to attend, if you want to get a more “hands on” approach…
There are many people in the LabVIEW community who write blog posts, some do it just as a way of sharing experiences and others do it to tackle specific issues they are having. To help get an insight into the minds of LabVIEW developers, read some of these posts…
There are also many presentations available to watch, these are mostly from the big NI events, such as CLA Summit, NI Week etc.
A quick note about presentations and blogs posts:
Most of these are written/presented by the leaders in the LabVIEW community, where their knowledge of LabVIEW itself is just a given. They present on topics that they have an interest in, side projects and areas where NI could do better. These presentation DO NOT represent the presenters only knowledge, experience and skills, they are a way of giving back to the LabVIEW community at large.
(I will add more as I find them. If you know of a good resource, comment below…)