07-19-2024 07:57 AM
I'm not sure if I can articulate well why this is difficult for me. But in interview questions where the STAR method applies (situation, task, action, result), the examples that are easy for me to talk about are not software problems.
I think it's because I have spent so much of my LabVIEW career working as the only software person around, and my customers/bosses don't know if my code is good or my solution is elegant. They just know that it works and from their perspective the "problem" is solved. It makes it not very interesting to talk about in interviews.
The software problems that have been interesting to me are generally things that nobody else around has even been aware of. So I don't have a "my boss was so happy I solved this problem" story to go with it.
Does that make sense? Does anyone else relate? How do you talk about LabVIEW skills in interviews?
07-19-2024 08:14 AM
@raffas wrote:
I'm not sure if I can articulate well why this is difficult for me. But in interview questions where the STAR method applies (situation, task, action, result), the examples that are easy for me to talk about are not software problems.
I think it's because I have spent so much of my LabVIEW career working as the only software person around, and my customers/bosses don't know if my code is good or my solution is elegant. They just know that it works and from their perspective the "problem" is solved. It makes it not very interesting to talk about in interviews.
The software problems that have been interesting to me are generally things that nobody else around has even been aware of. So I don't have a "my boss was so happy I solved this problem" story to go with it.
Does that make sense? Does anyone else relate? How do you talk about LabVIEW skills in interviews?
I would think that if the position you are going for uses labview, they will ask labview specific questions and then you can talk about labview. If the position does not use labview I would not even bring it up unless asked directly about what programing languages you use. The general programing concepts you use in labview translate to other programing languages, best to keep code theory general unless asked language specifics. If the company is looking for a developer that they can train to work with their T&M Ruby code base or whatever is not going to pick you if you keep going on only about labview ... but I guess it is up to you if you only want a labview position or are looking to branch out.
07-19-2024 10:38 AM
I can relate a 100% but do not know the answer. Thus, curious to know what people will respond with. 😄
07-21-2024 08:10 AM
I'm not familiar with "job interviews" or the "STAR" system, but have been "discovered" on numerous occasions when someone learns I have "familiarity with LabVIEW" and have designed fairly complex Data Acquisition and Analysis routines/systems for my colleagues (often "teaching" them about LabVIEW, LabVIEW Real-Time, data acquisition, etc.).
You might consider a couple of Projects that you designed. What was the "need"? What broad techniques did you use (Analog/Digital/Video acquisition/processing, etc.)? How were the Projects received (including did they ask you back for "expansions")? How did you ensure that they'd be able to run the system once you finished (Documentation, training, etc.)?
Bob Schor
07-21-2024 09:03 PM
Programming software is just a tool to solve business problems, the interviewer wants to know more about the industry, the problems you have solved, or the experience you have in the industry. the level of programming in LabVIEW is not their primary consideration, because the industry that uses LabVIEW software to program is basically related to hardware testing.
In China at least, most people in the industry don't consider labview as a programming language, which is sad and distressing to me.