Need help hiring a competent LabVIEW programmer!

[Cat]

Subtitle:  Cat's continuing attempt to finally retire

I retired from the gov't (US Navy) around August of 2019.  Since the gov't is the gov't they didn't think about replacing me until after I retired.  So being a good little civil servant I came back part time as a contractor to fill the gap.  The basic requirements for my replacement were: 5+ years LV work, engineering degree, experience working with large data sets, experience working with large (2500+ vi) code sets, able to work independently (I have always been a team of 1).

The gov't finally hired my replacement and they started work in January of 2021.  It still being pandemic time, I didn't have a lot of face-to-face (or mask-to-mask) interaction with them, but I got more and more worried when I did.  While they had a lot of fundamentals down, there were glaring gaps in their technical knowledge.  They were more of a okay beginner programmer than the solid intermediate to expert level that we needed.  And they had obviously only ever worked in a team where everything was spoon-fed to them and then someone cleaned up after them.  They were let go.

This person had 6 years of programming LabVIEW on their resume.  But it was obviously 6 years of programming LV badly.

Going forward, how do I not repeat this mistake?  Should NI certification be required, and if so, is CLD good enough or should it be CLA?  Any other suggestions?  I really want to retire!!

 

Cat

[Bryan]

I would start with having a CLD (recent or in the past) as being helpful, but not necessarily a requirement. 

Ask them if they've taken any LabVIEW courses and what they were.  This should give a baseline of their expected knowledge/experience.  Quiz them on what they SHOULD know having taken them.  

Quiz them on the commonly used LabVIEW frameworks (or commonly used in YOUR job) to get a feel for their grasp on the concepts (e.g. QDMH, DVRs, OOP, etc. LIB MR DUCKS).

A courses, a degree, or CLD doesn't necessarily equal competence (but I agree, it gives more of a 'warm-n-fuzzy' feeling) - I've seen it several times in my career.  Some of the most competent people I've worked with have no official degree, but lots of experience.  Some people can have loads of LabVIEW experience, but never went for a CLD/CLA because the certification wasn't required for their job or field. 

If they can (and it's not always able to be done because of intellectual property constraints), ask them to provide sample code for you to review.  

I'm sure others will have more (and much better) insights than I do, since I haven't taken part in many candidate interviews for LabVIEW positions. (Although I will be here in the near future). 

[Cat]

Thanks for the response.  I hadn't thought of asking about LabVIEW courses.

This position is actually more than "just" LabVIEW programming.  It's the software part of a team that designs/develops/tests/fields data acquisition systems.  So an engineering degree is helpful to being able to see the big picture.  Or so the guy who does the hiring believes...

I personally fit in the "lots of experience but no certification" slot.  That's why I didn't think it would be necessary to require it.  Plus it will make it harder to fill the position.  If I go that route, having never taken the exam myself, I'm wondering if the group mind here thinks CLD would be good enough, or should it be CLA?  Especially considering the person will have to be the "A"rchitect as well as the "D"eveloper.

[ShaunR]

 

4 hours ago, Cat said:

Or so the guy who does the hiring believes

 

7 hours ago, Cat said:

Going forward, how do I not repeat this mistake?

You didn't and can't. Unless you are interviewing, there's not a lot you can do.

When I interview I get them to do a 30 minute test. It's a test that they cannot complete in 30 mins. I tell them that they are not expected to finish, it's not expected to work, there is no right answer and I just want to see their thought process when tackling a task - just make sure it's tidy enough so I can read it. This is all true.

After, we discuss the task. What they thought, what they were and weren't happy with, what issues they think their code has and why they did certain things. Additionally I ask things like how would they improve *my* test. Did it make them too uncomfortable, would they have preferred a specific result/correct answer etc.

A good engineer will be able to articulate problems with  interpretation of the instructions, the assumptions and decisions they had to make and what they would change now they know the task and we have discussed it with my input. What code they actually write is almost irrelevant and only serves as a common talking point but you'll spot the fakers straight away.

You very quickly find out who is an engineer and who is a code monkey.

 

Edited June 29, 2021 by ShaunR

[Bryan]

  

15 hours ago, Cat said:

I'm wondering if the group mind here thinks CLD would be good enough, or should it be CLA?  Especially considering the person will have to be the "A"rchitect as well as the "D"eveloper.

Well - Finding a CLA may be more difficult than finding a CLD.  Some people may (like myself) have gone the path up to feeling qualified to take the CLA Exam, but never pulled the trigger for one reason or another (mostly $$ reasons).  I never did it because - working for a company - a CLx never benefited me in any way nor did it benefit my company.  They were willing to foot the bill for the exams, some of the time, but I never went through the process and let my certification expire long ago after only one renewal.

You could specify CLA-Level of experience without necessarily making them have an active or expired credential. However, you'd still have to determine somehow by evaluation or by faith that they have the level of experience they claim to have.

10 hours ago, ShaunR said:

You very quickly find out who is an engineer and who is a code monkey.

Hey!  I (likely) resemble that remark!

[ShaunR]

1 hour ago, Bryan said:

Hey!  I (likely) resemble that remark!

I doubt it. Code monkeys have extreme problems with this kind of test because there are few parameters for them to follow. They are forced to think of a solution instead of being told how to implement one. The interesting thing is, though. Even if they are a code monkey, they may show skills or a propensity to think of solutions in the discussion afterwards that they previously haven't been called upon to utilise. While I don't think that is useful in Cat's case, it very useful if you are looking for a team member that you can cultivate.

[hooovahh]

This thread on interview questions might be helpful.  I suggested asking about describing reentrancy in your own words, but I think that might not work.  Matt in that thread suggested asking what your favorite, and least favorite features of LabVIEW are which might give incite into their experience level.

Still finding good engineers who don't need much hand holding often takes years.  And I don't mean like 6 years of experience, where you repeated the first year 6 times.  Those types of people are either very expensive, or are very under appreciated.

[Lipko]

Hmm. I would have answers for (almost) all questions I see in these interview question threads (many "dunno but I'd approach the question like this and that" answers), I even know hooovahh is not really Homer Simpson, but I don't feel any competent for a real Labview job. I can solve problems, made many mid-sized applications (control+daq, data analizers, report generators) that are team uses on a daily basis, I struggled with many architectures, fixed errors in 3rd party APIs, I know error handling is not simply connecting serially every crap with an error terminal to make a huge yellow snake (a thing that I see even in APIs of serious equipment from respected companies). Sounds promising. Yet my code and especially the architectures get so f... spagetti after a while, you'd get brain aneurysm just by looking at.

These questions are only good for first stage screening. If I were hiring, I would definitely go for a test Labview project in some way.

[ThomasGutzler]

Down here, you can't really hire a good LabVIEW programmer; all 10 of them have jobs they don't want to leave, so you'll just have to make your own. That's often easiest if that person has no LV experience. In that case you know they haven't been poisoned by "that uni course" they did where most certainly single-vi spaghetti with lots of local variables for "storing data" was the result. Candidate must have good understanding of generic concepts and not make a face when quizzed about graphical programming

[infinitenothing]

Find your local integrator and poach anyone that's been there for a few years. Basically, the integrators like to "train on the job" so the customers are effectively paying for the training. You can usually out pay the integrator for talent because they have to maintain margins on their contract hourly rates.

Edited August 2, 2021 by infinitenothing

[joerghampel]

On 8/2/2021 at 9:36 PM, infinitenothing said:

Find your local integrator and poach anyone that's been there for a few years. Basically, the integrators like to "train on the job" so the customers are effectively paying for the training. You can usually out pay the integrator for talent because they have to maintain margins on their contract hourly rates.

So you're saying that because a customer pays for a solution they get, they buy the rights to the people who worked on it? I don't agree with that notion.

Also, while people can't be kept from switching jobs, and companies can't be kept from advertising their vacancies, "poaching" your local integrator's employees doesn't sound like the right thing to do to me. Good thing my employees are in Germany and thus not local to you.

Edited August 4, 2021 by joerghampel

[joerghampel]

For the last few candidates I interviewed, I had prepared the following process:

1. a ~1-hour conversation to get a feeling of the person (in person until the pandemic hit, then via MS Teams), chatting about their past experience, current work, personal interests, involvement in the community etc.
2. a sample project to work on, which they had to clone from GitLab (via git), get the problem statement (requirements) from the readme, and describe in words how to solve the problem
3. another short conversation about their reply and suggested solution
4. implement part of the requirements in the sample project and submit the solution via GitLab (git)
5. another conversation about how they solved it, why, etc.

Regarding certifications, I recently posted to LinkedIn about my opinion on them.

Edit: The project mentioned above is an actual project of ours, where we had to implement some small changes to a very badly written piece of legacy code with no encapsulation, documentation, etc.

Edited August 4, 2021 by joerghampel

[ShaunR]

27 minutes ago, joerghampel said:

they had to clone from GitLab (via git)

I wouldn't have passed your interview. 

35 minutes ago, joerghampel said:

So you're saying that because a customer pays for a solution they get, they buy the rights to the people who worked on it? I don't agree with that notion.

I don't think he is saying that.

He is saying that since the employees' training wasn't a cost borne by the company but by the customers, therefore they are fair game for poaching. I still disagree, of course. It's just a rationalisation of a despicable behaviour to alleviate guilt.

[joerghampel]

2 minutes ago, ShaunR said:

I wouldn't have passed your interview. 

I'd have happily helped you along those steps  😍  so you can get to the actual work!

But seeing as git is integral to our way of working, that's an important piece of information for me.

[infinitenothing]

I was actually just pointing out that the employees of the integrators have had a reasonable amount of training and experience and are possibly an undervalued source of talent worth reaching out to. I'm not sure why you guys are all up in arms about ethics. There's nothing wrong with offering someone a job at better pay. That's just natural market efficiency.

It didn't occur to me that you might have the opportunity to hire someone from an integrator you are already working with (I was assuming you didn't have an integrator already) but if that was the case, any ethical issues should codified in the contract you signed with the integrator.

Edited August 4, 2021 by infinitenothing

[jcarmody]

I worked for an NI Alliance Member company and signed a (legally non-binding) non-compete agreement, which meant I wasn't supposed to be poachable.  I found a job opening at a company that turned out to be working with my employer on an unrelated-to-me project which I wasn't hired to take over, so I wasn't competing and jumped ship.  

[hooovahh]

Yeah I have some drafted documents about my work and integrator issues.  Still waiting a bit for the statues of limitations. 

But the gist of it is that I worked at an integrator who sent me to a customer to do work.  I was working with them full time for a few months and they offered me a job.  There was a non-compete clause stating they couldn't hire me unless they paid my one year salary to my current employer.  Turns out I wasn't getting paid all that much and they were willing to pay the fee.  Instead I was given a raise to stay (and thereby increased the fee).  After the year was up they came back and offered me more pay since they now didn't need to pay the breach of contract fee. 

I'd been given offers from other customers plenty of times, but this was the first place I was sent to that I could see working at.  It was sorta poaching, but totally my decision to make.  And one I didn't take without considering what I would be leaving behind.  It also wasn't a spur of the moment thing, since I had a while to think about it.