What knowledge other than LV should you know if you are a LV programmer

[GSR]

After I fail in my LV job interview, I really want to know what knowledge should a LV programmer should know? I understand that the answer may depend on the company, but any general knowledge that I should know?

Maybe I should give an example, I would expect a webpage developer knows about Photoshop, Dreamwaver, php, frontpage, etc

[shoneill]

QUOTE (zmarcoz @ Mar 16 2009, 04:42 AM)

After I fail in my LV job interview, I really want to know what knowledge should a LV programmer should know? I understand that the answer may depend on the company, but any general knowledge that I should know?

Maybe I should give an example, I would expect a webpage developer knows about Photoshop, Dreamwaver, php, frontpage, etc

Some basic algorithm knowledge is always a plus, as is some knowledge of software engineering principles.

Other than that, a solid knowledge of what makes a good UI and what makes a bad UI is pretty useful....

Shane.

[JohnRH]

QUOTE (zmarcoz @ Mar 15 2009, 10:42 PM)

After I fail in my LV job interview, I really want to know what knowledge should a LV programmer should know? I understand that the answer may depend on the company, but any general knowledge that I should know?

Maybe I should give an example, I would expect a webpage developer knows about Photoshop, Dreamwaver, php, frontpage, etc

Like you say - it really depends. I suspect that very few LabVIEW programmers do nothing but write software. Off the top off my head here is a short list of non-LabVIEW stuff that I like to see in our programmers:

1) solid understanding of computers and networking

2) basic understanding of serial communication protocols (RS232/485)

3) electronics! (at LEAST enough to design basic DAQ setups)

4) comfortable using an oscilloscope

5) basic math (calculus and statistics)

[jgcode]

QUOTE (JohnRH @ Mar 16 2009, 08:29 PM)

Like you say - it really depends. I suspect that very few LabVIEW programmers do nothing but write software. Off the top off my head here is a short list of non-LabVIEW stuff that I like to see in our programmers:

1) solid understanding of computers and networking

2) basic understanding of serial communication protocols (RS232/485)

3) electronics! (at LEAST enough to design basic DAQ setups)

4) comfortable using an oscilloscope

5) basic math (calculus and statistics)

I agree but would like that

4) Should be Oscilloscope + Function Generator, PSU's DMM etc..

and would like to add:

6) Ability to generate Documentation (Specs, Requirement Docs, Tests etc..)

7) Code in Web Technologies e.g. HTML/XHTML/Javascript/Ajax/PHP/MySQL

8) Proficient with Source Code Control

9) Personality (for programmer-client interaction)

10) Knowledge of system integration

If everyone who posted gave 5 responses we could get a very good list going!

[Francois Normandin]

QUOTE (jgcode @ Mar 16 2009, 09:13 AM)

I agree but would like that

4) Should be Oscilloscope + Function Generator, PSU's DMM etc..

and would like to add:

6) Ability to generate Documentation (Specs, Requirement Docs, Tests etc..)

7) Code in Web Technologies e.g. HTML/XHTML/Javascript/Ajax/PHP/MySQL

8) Proficient with Source Code Control

9) Personality (for programmer-client interaction)

10) Knowledge of system integration

If everyone who posted gave 5 responses we could get a very good list going!

Careful what you wish for! If the list goes too long, you get to be me...

[Grampa_of_Oliva_n_Eden]

Noise reduction techniques

Ability to look customer in the eye and hold their gaze

Database fundementals

Network protocols

Serial GPIB

Ben

[TobyD]

QUOTE (neBulus @ Mar 16 2009, 07:27 AM)

Ability to look customer in the eye and hold their gaze

I like this one...it seems to be a skill that many programmers lack.

[Aristos Queue]

QUOTE (JohnRH @ Mar 16 2009, 05:29 AM)

I suspect that very few LabVIEW programmers do nothing but write software.

A true pity. Of the items on your list, I would only hit #5, and you might consider me "overqualified" as far as basic math is concerned, and maybe #1. QUOTE

1)

solid

understanding of computers and networking

2) basic understanding of serial communication protocols (RS232/485)

3) electronics! (at LEAST enough to design basic DAQ setups)

4) comfortable using an oscilloscope

5) basic math (calculus and statistics)

But I have worked with various hardware teams over the years, and I've discovered that the further you get from signal processing and the closer you get to industrial control, the less you need to understand the hardware. Once you have an API that provides control over a motor and another API that acquires a picture from a camera, then its all math and software to figure out how to spin the motor such that the robot arm moves to a specific spot in the image and picks up the target object. You still need to understand the limitations that the hardware places on the software -- memory limits, data type restrictions, processor speed, available paralellism -- but those are restrictions within which you can design the software without understanding analog electricity itself.

In my analysis, the skills you need as a LV programmer are no different than those you need as a programmer in any language:

1. Know the terminology of the field you are serving. Making a pacemaker test harness? Know ventricle and aorta. Writing a word processor for news organizations? Know masthead and byline. This sort of subsumes the entire list about knowing electronics, etc, that was given earlier. When interviewing for a job that will involve X, be conversant with X.
   
2. Know the people who will actually be using your software. A daily headache for them may be solved with a one node tweak in your VI. A low priority side feature to you may be acritical core use case to them. When interviewing, demonstrate that you can talk to people, and ask good questions of your interviewer. That shows you can dig for project requirements.
   
3. Know the basic libraries and standard patterns of your chosen language. Don't rewrite something that already exists, and when you write new things, use the idioms that are typical for others who write that same language. When interviewing, if you're asked to demonstrate any code, make sure it is as clean as you can make it. If you're actually writing during the interview, you might not actually handle every error, but at least note out loud that it ought to be handled so you show you're aware of the situation.
   
4. Know what is expensive and what is cheap in terms of the project you'll be working on. Be conversant in relative value of buying tools vs building custom. For LV, this means the classic "use your own test harness or buy someone else's". Explore what your employer's needs will be, and show that you know options.
   
5. Know your own skills. If you're a hot shot LV signal processing guru who understands the fine art of minimizing error through complex calculations, don't assume that you qualify for the LV user interface job that calls for detailed XControls and 3D picture rendering. Although you want to highlight your strengths in an interview, do note your weaknesses, particularly if the employer is hiring a whole software team. You may very well still get the job, and you'll be happier because they'll hire someone whose strengths match your weaknesses, instead of someone who duplicates your skills, thus leaving a hole in the project.
   

[Neville D]

QUOTE (Aristos Queue @ Mar 16 2009, 09:45 AM)

But I have worked with various hardware teams over the years, and I've discovered that the further you get from signal processing and the closer you get to industrial control, the less you need to understand the hardware. Once you have an API that provides control over a motor and another API that acquires a picture from a camera, then its all math and software to figure out how to spin the motor such that the robot arm moves to a specific spot in the image and picks up the target object. You still need to understand the limitations that the hardware places on the software -- memory limits, data type restrictions, processor speed, available paralellism -- but those are restrictions within which you can design the software without understanding analog electricity itself.

I tend to disagree. It is equally (or if not more) important to really understand hardware limitations. Look at the number of questions on LAVA where people ask about capabilities of NI DAQ hardware. It is straightforward to crank out code once one understands the DAQmx API, but far harder to figure out which card to use or whether the card one has can do what you require it to.

Selecting inappropriate hardware (or using hardware incorrectly like not accounting for ground loops or common mode voltages) because of a lack of application-specific knowledge can be an expensive mistake.

All your other points are very valid though.

N.

[bsvingen]

QUOTE (zmarcoz @ Mar 16 2009, 04:42 AM)

After I fail in my LV job interview, I really want to know what knowledge should a LV programmer should know? I understand that the answer may depend on the company, but any general knowledge that I should know?

Maybe I should give an example, I would expect a webpage developer knows about Photoshop, Dreamwaver, php, frontpage, etc

This could include all and everything I think. Take signal processing. It is all mathematics and algorithms, so you need to know C/C++, FORTRAN, Matlab (in an "algorithmic" and "performance" kind of way) + being able to learn new mathematics quickly. In process control you would need basic knowledge of the process and knowledge of how to communicate with all kinds of hardware and software, new and old.

It is my impression that Consultants in LV tend to focus on UI and general software engineering, while "users of LV" focus more directly on applications and function (signal processing, process control, hardware control and of course DAQ and analysis in all shapes and forms).

[Aristos Queue]

QUOTE (Neville D @ Mar 16 2009, 12:12 PM)

Selecting inappropriate hardware (or using hardware incorrectly like not accounting for ground loops or common mode voltages) because of a lack of application-specific knowledge can be an expensive mistake.

Contrast: If the project is "our company maintains public fountains; we need a device that we can trigger remotely to drain the fountain and then drive around picking up coins that people have thrown in", I may decide that I need an iPhone app that controls a Roomba platform. That's a very different type of hardware decision -- and one that may have been made before you were even hired. I know of a few projects where the hardware stack was in place and then they brought in the software engineer to make it all work out.

If the job includes solder and screws, you need to know hardware details. But if you're a software engineer, the need to know hardware decreases as you move from where your software drives the hardware to where your software controls the hardware, yet both are still within the typical domain of LabVIEW. If you aren't hardware savvy, that's where to be looking for job opportunities.

[Yair]

QUOTE (Neville D @ Mar 16 2009, 08:12 PM)

It is straightforward to crank out code once one understands the DAQmx API, but far harder to figure out which card to use or whether the card one has can do what you require it to.

That's what NI has sales people for, although admittedly there would be a need to understand the implications of the environment and of choosing the equipment you choose.

Luckily, I don't have to do that, as we have other people who do understand electronics and who can sort these things out with NI or the other hardware vendors.

In my specific case, the skills required to do my job well are the ability to understand a variety of systems, the ability to understand the client's needs and offer an appropriate (or better, preferably) solution and the ability to implement the solution. The projects we do are often very different from each other, but LabVIEW's ease of use and various modules allow us to implement solutions we wouldn't dream of doing otherwise (e.g. image analysis, parallel execution systems).

I think that this shows the difference, although I probably am the minority, as John suspects. While the stuff we do is not "pure" software in the sense that we almost always have some hardware interaction, we don't usually have to really deal with the electronics ourselves.

[PaulG.]

QUOTE (Aristos Queue @ Mar 16 2009, 12:45 PM)

1. Know the terminology of the field you are serving. Making a pacemaker test harness? Know ventricle and aorta. ...

:laugh: For a recent project I spent an hour learning the language of "negative pressure wound therapy" ... while trying to eat my lunch. What has been read cannot be unread.

[Francois Normandin]

QUOTE (Aristos Queue @ Mar 16 2009, 12:45 PM)

• Know your own skills. If you're a hot shot LV signal processing guru who understands the fine art of minimizing error through complex calculations, don't assume that you qualify for the LV user interface job that calls for detailed XControls and 3D picture rendering. Although you want to highlight your strengths in an interview, do note your weaknesses, particularly if the employer is hiring a whole software team. You may very well still get the job, and you'll be happier because they'll hire someone whose strengths match your weaknesses, instead of someone who duplicates your skills, thus leaving a hole in the project.
  

I strongly agree with this statement. In an interview, unless you're trying to pass for a software engineer when you clearly have never done it before, I'm looking for people who know their current limitation very well because those people are likely, in my opinion, to try to exceed them when confronted with the need to.

In a project management situation, it can be scary when the manager doesn't know what are the risks that can come along and wreck your project. The same thing is true from a programmer that doesn't know what lies slightly beyond his immediate experience horizon.

[jcarmody]

In my factory job I've found that my managers expect me to be equal to an Electrical Engineer (I'm not), in my previous job I was expected to know everything about LabVIEW, SCC & a bunch of the other stuff already mentioned.

I'd add that you need to be able to research & learn new things on your own. Become proficient finding answers (including nuggets like prepending "site:forums.lavag.org" or "site:forums.ni.com" to a Google search).

The last thing I have to offer is that you should make sure that you understand what tasks they're going to throw at you and that they are very clear of your limitations. Getting a new job is exciting, but it stinks to be jammed into something you're unable to perform.

[PaulG.]

The next time you are scheduled for an interview, spend a couple of hours on the Internet and research the company you will be interviewing with. Find out what they are doing. Put yourself in that company and imagine what you could offer them. Think about that for a day or two. Then put yourself in the position of the manager you will be talking to. He/she will be asking: "why would I want to hire you?"

[GSR]

First, Thanks for everyone to answer me the question

As my first non-academic interview, I did a very poor preparation.

I was asked to prepare a presentation 2 days before the interview; and I know the exact date for interview as the same time. Too many things need to be done before a few hours of driving to the interview.

I had prepared the interview for a week, but I went to a wrong direction!

• Spend a few days for preparing the 200 standard questions: e.g. what is your weakness??
  

• Spend a day to understand the company. However, I really misunderstood the position until I asked the manager a question during the interview: How would you describe a typical day in this position? I thought it was a R&D position in a team, but it is a one-man-team position including customer service.
  

• I was so stupid that I did not read the undergrad. book, refresh my old knowledge.
  
• I was so stupid that I did not ask about this question "What knowledge other than LV should you know if you are a LV programmer" in this forum
  

Anyway, good experience! I know much more about the industrial interview

BTW, could anyone please tell me more about What is UI? and anything about Noise reduction techniques? thanks :worship:

[Mark Yedinak]

First, good luck on your job hunt. I don't envy you having to look for a job during this economy. Secondly, and please do not take this in the wrong way, but based on several of your posts, your questions here regarding LabVIEW and your description here of how things went on this interview I would recommend that you not try to present yourself as an experienced LabVIEW programmer. This may sound harsh but one of the worst mistakes you can make going into an interview is presenting yourself or your skills as more than what they really are. Naturally you want to put your best foot forward but you also want to be honest. Having interviewed tons of prospective employees over the years I can say that I leave an interview with an extremely negative impression of someone if they try to oversell themselves. Be honest with yourself and your interviewer. I would rather have someone say to me that they don't know the answer to something that I asked than for them to try and BS an answer. This is even more important if you are interviewing with a technically knowledgeable person and not simply someone from HR who probably doesn't have a clue about the technical requirements of the job.

Some general things you can do to make a good impression is to show a genuine interest and knowledge of the company you are inteviewing with. Come prepared with questions for the people interviewing. things you can ask are what would your responsibilities be, what is the group dynamic of the team you would be working with, or what is a typical work day like. Don't start to ask about money or benefits during initial interviews. Save those questions for when they make an offer, not before.

[shoneill]

QUOTE (zmarcoz @ Mar 17 2009, 04:49 AM)

BTW, could anyone please tell me more about What is UI? and anything about Noise reduction techniques? thanks :worship:

I can't believe somebody can be used to programming LabVIEW and not know what a UI is. But perhaps English isn't your first language and it's called differently where you are so....

to find out what UI is, search for "UI" on wikipedia.

To know more about noise reduction techniques, you kind of have to first know about the signals upon which the techniques should be used. Noise reduction in optical systems is different to digital systems is different to analog systems.....

Shane.

[Grampa_of_Oliva_n_Eden]

QUOTE (shoneill @ Mar 17 2009, 04:06 AM)

...

To know more about noise reduction techniques, you kind of have to first know about the signals upon which the techniques should be used. Noise reduction in optical systems is different to digital systems is different to analog systems.....

Shane.

"Noise Reduction Technique in Electronic Systems" by Ott.

He starts with each noise condition, applies Maxwell's laws, and reduces each case to rules of thumbs.

Many touched on not over selling, knowing your own capabilities, etc. These all boil down to "looking someone in the eye..."

If you can't look them in the eye and tell them you are an expert then don't.

If you can look them in the eye and tell them you have solved problems in LV and look forward tod doing so again, then stick with that.

"Let your yes mean yes and your no mean no."

Another note:

If you get to the point in an interview where you get the feel that this is not going well, make the best of it! Star asking the interviewer question like "WHat skill would you like to have seen?", "what would you recomened...." etc.

Ben

[Cat]

QUOTE (zmarcoz @ Mar 15 2009, 11:42 PM)

After I fail in my LV job interview, I really want to know what knowledge should a LV programmer should know? I understand that the answer may depend on the company, but any general knowledge that I should know?

Maybe I should give an example, I would expect a webpage developer knows about Photoshop, Dreamwaver, php, frontpage, etc

Substitute "C++ programmer" for "LV programmer" and ask the question again. Your analogy implies that LabVIEW is a specialized language. Or maybe isn't really a language at all, but a tool for some specialized purpose. That may have been the case back in the Bad Ole Days, but some of us use it for a general purpose programming language. Yes, I can control instruments with it. Yes, I can automate tests with it. But over the years I've used it for a lot more than that.

So as some other folks have said, if you're hunting for a job, it's important to know exactly what you're applying for, and just like with any other language it's important to know your particular strengths and weaknesses.

Good luck with the job hunt!

Cat

[shoneill]

QUOTE (Cat @ Mar 17 2009, 02:05 PM)

Substitute "C++ programmer" for "LV programmer" and ask the question again. Your analogy implies that LabVIEW is a specialized language. Or maybe isn't really a language at all, but a tool for some specialized purpose. That may have been the case back in the Bad Ole Days, but some of us use it for a general purpose programming language. Yes, I can control instruments with it. Yes, I can automate tests with it. But over the years I've used it for a lot more than that.

So as some other folks have said, if you're hunting for a job, it's important to know exactly what you're applying for, and just like with any other language it's important to know your particular strengths and weaknesses.

Good luck with the job hunt!

Cat

^^^^^

¦ ¦ ¦ ¦ ¦

I agree with this!

Shane.

Ps Except maybe for the topic of "pointers".....

[GSR]

QUOTE (Cat @ Mar 17 2009, 01:05 PM)

Substitute "C++ programmer" for "LV programmer" and ask the question again. Your analogy implies that LabVIEW is a specialized language. Or maybe isn't really a language at all, but a tool for some specialized purpose. That may have been the case back in the Bad Ole Days, but some of us use it for a general purpose programming language. Yes, I can control instruments with it. Yes, I can automate tests with it. But over the years I've used it for a lot more than that.

So as some other folks have said, if you're hunting for a job, it's important to know exactly what you're applying for, and just like with any other language it's important to know your particular strengths and weaknesses.

Good luck with the job hunt!

Cat

Thanks for your suggestion

I just start with a bad luck day. I received an email about a software engineer position an hour ago, they send me an exercise and need me to finish it. The exercise include a short Matlab, a short C programming problems and a long C++ problem. I spend 2 mins to solve the Matlab and C problems. However, I have never programming C++ in my life. I just feel myself a piece of shit. Why did I learn java not C++. I still try to solve it, but they are asking "automated unit tests" which I never never heard. OHHHHH, lost another chance to have a job.

QUOTE (shoneill @ Mar 17 2009, 08:06 AM)

I can't believe somebody can be used to programming LabVIEW and not know what a UI is. But perhaps English isn't your first language and it's called differently where you are so....

to find out what UI is, search for "UI" on wikipedia.

To know more about noise reduction techniques, you kind of have to first know about the signals upon which the techniques should be used. Noise reduction in optical systems is different to digital systems is different to analog systems.....

Shane.

Thanks for reminding me. I thought GUI is the standard term . When I was living in foreign country, I wrote American addresses, I used "U.S.A." as the country. However, I found out that American wrote their country as "U.S." after I have been here for years. I used to use the Matlab version "UI" which is GUI, so I am sorry that I asked the stupid question. :laugh:

Btw, how will you pronounce UI?? Do you just call it U-I or call the long form user interface?

[shoneill]

QUOTE (zmarcoz @ Mar 17 2009, 04:48 PM)

Thanks for your suggestion

I just start with a bad luck day. I received an email about a software engineer position an hour ago, they send me an exercise and need me to finish it. The exercise include a short Matlab, a short C programming problems and a long C++ problem. I spend 2 mins to solve the Matlab and C problems. However, I have never programming C++ in my life. I just feel myself a piece of shit. Why did I learn java not C++. I still try to solve it, but they are asking "automated unit tests" which I never never heard. OHHHHH, lost another chance to have a job.

Thanks for reminding me. I thought GUI is the standard term . When I was living in foreign country, I wrote American addresses, I used "U.S.A." as the country. However, I found out that American wrote their country as "U.S." after I have been here for years. I used to use the Matlab version "UI" which is GUI, so I am sorry that I asked the stupid question. :laugh:

Btw, how will you pronounce UI?? Do you just call it U-I or call the long form user interface?

Just remember, like UI vs GUI, a lot of the things you might think you don't know might just be down to semantics.

If a job you're applying for requires something you've never heard of, then you're most likely not the right person for the job. In the worst case, ask them what exactly they mean by term X or Y.

I've done that before and have found out I uderstood the principle behind something even though the name they were calling it was unknown to me. That's what I get for being self-taught.

Shane.

[Cat]

QUOTE (zmarcoz @ Mar 17 2009, 11:48 AM)

Btw, how will you pronounce UI?? Do you just call it U-I or call the long form user interface?

Now this is an interesting question. I find that if I'm going to abbreviate it, I say GUI (gooey), but if I'm going to say it all out, I say "User Interface". So I personally would not say UI (you-eye) or "graphical user interface".

Most of the folks I program with are C programmers and wouldn't know a GUI if one smacked them upside the head, no matter how I pronounce it. :-)

Cat (42/1000! Well on my way!)