Favorite screening interview questions

[BowenM]

I saw this thread, but didn't feel like dragging it back up.

So, we've been trying to hire for 2 positions now for awhile and we always do a 30 minute phone screen.  I usually only get a single question to ask that will say "yes this person likely knows LabVIEW" or "nope, don't bring them in."  So, for those of you that have interviewed candidates, what are some of your favorite single screening questions?

Personally, I initially started with something simple - CLAD type questions.  "Tell me an example of when you would use a shift register", etc. but it wasn't very reliable.

I have since switched to:   "What is your favorite architecture and why?".  My thought is that if they know enough about LabVIEW to at least know the most common architectures it's likely worth bringing them onsite.

Anyone have any others?

[Hooovahh]

I like to ask them "What is reentrancy in reference to a VI and when would I use it?"  It isn't a subject a beginner will be too familiar with, and it is a somewhat LabVIEW only feature.  Asking something like what architecture do you like could be answered with a state machine or producer consumer, or publisher subscriber.  Which are fine answers but most CS students could answer that with no LabVIEW experience.  That being said you can know what reentrancy is and be a bad LabVIEW programmer so my follow up question is usually "Do you know who hooovahh is?"

Spoiler

Just kidding I'm not that pompous.

[Gregory]

I think the question about architectures is a good one, although a little open ended. A phone interview is especially challenging, if you cannot find a way to both be looking at the same block diagram for some questions. One place I applied to sent me to an online portal where I took a a CLAD style exam, I don't know if that is an option for you.

Related to architectures, I've found a large gap in skill between people who know how to pass data between loops and people who don't. If they only mention local/global variables and property nodes, they probably have a lot to learn. If they mention queues and notifiers and can explain that "enqueue element" puts an item on the queue and "dequeue element" takes it off then they are a bit more advanced. If they know about user events and how to generate an event and handle it with the event structure, then they probably know their stuff.

When I was interviewing people in person I would usually finish with a block diagram that looked like producer / consumer (events) where the consumer loop could communicate an error to the producer with a user event. I would ask "how is data sent from the bottom loop to the top loop?" Even a guy who showed off some impressive sequencing code and claimed everyone calls him "the LabVIEW guy" just stared blankly at the diagram... 😞

On the application you can ask if they are active in any LV forums or have certifications. I absolutely believe you can write great code without a LV certification, but it is nice to have a baseline to go off of when interviewing someone!

[Jacobson-ni]

Don't have a specific question, but I think you can tell how experienced someone is with LabVIEW by what and how they complain about LabVIEW. I talk to a lot of different users with varying amounts of experience and it's something I've noticed.

If someone doesn't have a lot of experience, they tend to complain about non-issues. Like, for complex projects, VI diagrams tend to get large and become difficult to navigate/manage. The competent developer might complain about something like LabVIEW locking classes which get loaded under multiple targets in a project or how exiting many parallel processes gracefully can be tricky. And, of course, you know that the very experienced LabVIEW programmer will launch into some impassioned tirade about some very specific detail.

[thoult]

• What architectures have you used, and why?
  • Silence at the other end of the phone is usually the beginning of the end of the call
  • Even if they're single loop programmers, awareness of other architectures is a good sign
• What hardware have you interfaced with, and how?
  • Any NI hardware? Have they used RT and FPGA?
  • Any third party hardware? Have they used .NET or ActiveX? Have they used VISA?
• What experience do you have in working with electronics or mechanics?
  
  • Do they think they can debug a simple circuit? Can they use an oscilloscope? Can they provide requirements to a PCB designer?
  • Can they understand the mechanical components of a test system? Can they liaise with mechanical engineers?
  • I like LabVIEW engineers, but I prefer system engineers who can interact with specialists
• Do you use any sort of source control? If so, how has it helped you? If not, can you see how it could help?
  • This is one of the steps to enlightenment in software development
  • You might have to explain the concept to some, but they should be able to join the dots and see that collaborative working, traceability and retracing your steps in the event of catastrophe are all benefits
• If you don't know how to solve a problem in LabVIEW, how do you figure it out?
  • The things I want to hear are Googling, using the NI forums, using examples, talking to a more experienced colleague, using AE support at NI...but I want to hear a few options
  • Problem solving is an important skill that is hard to judge in interviews...but at least get them showing that they can approach problems in different ways over the phone
• Do you work with any other developers, or see anyone else's code? How do you rate your experience and skillset?
  • I don't mind people who've been lone wolves, but an unswerving belief that your skills are excellent having not had anyone else to benchmark against is usually a warning sign
  • I like people who want to learn and expand their skills, so a bit of self realisation that there are areas to improve in is always welcome
• What do you like to do away from work?
  • Like a CAPTCHA, are you a robot?

Just a few thoughts off the top of my head. In general, try to ask open ended questions and let them talk about their work, skills and experience.

[BowenM]

---

@Jacobson-ni wrote:

Don't have a specific question, but I think you can tell how experienced someone is with LabVIEW by what and how they complain about LabVIEW. I talk to a lot of different users with varying amounts of experience and it's something I've noticed.

---

I like that idea a lot... tell how competent someone is at LabVIEW by asking them to complain about it.  A question something along the lines:  "Every programming language has its strengths and weaknesses - and LabVIEW is no exception.  What are some of the weaknesses you think LabVIEW has?"

[jcarmody]

---

@BowenM wrote:
[...]

Anyone have any others?

---

"What's your ni.com user name?"

"What's your LAVA user name?"

Spoiler

Do you use the CaseSelect QD plugin?

[Hooovahh]

---

@jcarmody wrote:
Do you use the CaseSelect QD plugin?

---

 I do (just not often).  When Jim and his gang were showing off the JKI State Machine Editor, I called it CaseSelect++ and got a few chuckles.

[JÞB]

My favorite is:  "Hey Jeff! are you available?"

[PeterFoerster]

If you have the possibility to show them something, a small code sample can help assess their skill level.

This is something I've used to test people fresh from college that claim to know LabVIEW.

Question one: What is result?

Question two: What is result the second time? (or better: Obviously, it's the same every time I execute this, isn't it?)

It's certainly not too hard, but it shows you if someone knows basic concepts, like auto-indexing and uninitialized shift registers. Really depends on what level you want to test.