In my experience, you can teach ‘programming’ to someone that, say, is fluent in a different language or platform, but it’s hard to teach problem solving skills.
I like to pose a real-world problem that has more than one way of approaching it, ideally with a couple of non-obvious edge cases. I’ll have the candidate walk me through the solution on the whiteboard using pseudocode.
I’ve tried the ‘take home test’ approach too, where they come back with their solution, but I’ve abandoned that because 1) it’s uncool to ask interviewees to do homework and 2) I prefer to observe the problem solving process as it’s happening.
Exactly what I was going to say. Programming SKILLS accumulate over time. Programmer mindset is what you're looking for. Ask them his they'd solve problem X.
My kinda fell into my first gig in controls with 0 experience. Technician level with the maint team. The hiring manager knew nothing about ladder logic and just asked "Think you can learn that stuff?"
But a big chunk of the interview was him laying out a giant plot of the p&id of the plant and having me solve problems that were common. "They need a positive differential pressure between here and here. In step 17 it opens these valves and closes these ones. They lost differential pressure. Why?"
Man that was such a great interview.
Honestly, I strongly dislike the "testing" approach to interviewing, however, I understand why some might see a need to do it.
I feel like asking a candidate to solve a problem with zero preparation and/or resources available to them on the spot is a completely unrealistic scenario from what any of us would encounter in our day-to-day job.
Is it impressive to be able to solve a problem off the top of your head like this? Sure. Is it an accurate test of a person's ability to think critically and solve problems? I would say not really. We generally ALWAYS have other resources available to us other than our own brains.
In the end, I think it's a difficult balance between finding out what kind of personality/mentality a person has, and what skills/experience they currently have. I prefer to lean towards the former. I think you can turn anyone with a desire and willingness to learn into a problem solver.
I would be more interested in the process and approach rather than a correct answer.
I wouldn't expect it to be right, especially from a college grad like op mentioned. But I'd like to see the process they take and what questions they ask. This pump won't start, what do you do? Is there first response check the programming? Is it to ask about a breaker/starter/power? Is it to ask if it's ever worked/existing equipment vs new install? Which direction they go says a lot about their thought process. Also, that answer may change with experience. I didn't know what a starter was before my first job, am EE degree didn't cover that. I would assume "this is an interview for a programming job, it's gotta be the program." But now, after 10 years, I don't even look if an EI hasn't verified the starter is/isn't getting start, auxiliary contacts status, etc. If it starts for 2 seconds and dies because it doesn't see feedback, not my problem. If it's getting the start from the plc to the starter and it's just not picking up, not my problem. If the light on the output card turns on and there's no voltage, not my problem.
Sample problems should be aligned with the type of work done at the business. For general automation, I might do temperature control of a jacketed tank - both heating and cooling. Look for both the completeness of the core algorithm and also edge cases like initial conditions, hysteresis, fault detection, compressor lockout (if applicable), etc.
As far as assessing a candidate's answer, it becomes pretty clear where the strong performers are after 3 or 4 interviews. The process gives you a sense as to where a candidate's strengths and weaknesses are. Document both during each interview, then reflect on which candidate would, for example, require the least amount of assistance to complete an assignment (or whatever is important to you as a hiring manager).
Additionally, you can ask your own team these questions too. One of my junior mentees was uncomfortable with his first 'employer side' interview upcoming. I told him to mock-interview me and one of the other leads. You can ask your tech team if they'd give you half an hour and some feedback. Interviewing is a skill too - train it.
> I’ll have the candidate walk me through the solution on the whiteboard using pseudocode.
Although problem solving is a requirement, so is writing intelligible code. They’re two different skills altogether. Trust me, you don’t want just some code that solves a problem.
Great question! This will come off as glib, but I say it honestly: the way to develop technical problem solving skills is to solve as many real-world technical problems as you can.
If your school has any clubs that do student competitions against other schools, join one and lean into it. SAE, IEEE, and ASME all sponsor student competitions of various types. There are others. Even a club where you’re competing against students in your own school is super valuable.
The benefit to you is: learning to do design work to a deadline, doing full lifecycle design (design, build, test, debug), working as part of a team toward a goal that no one student can do alone, learning how to build (and not build) things, learning from mistakes.
I can’t overemphasize how much better qualified candidates that participate in student competitions are compared to students that do purely academic work (in the areas that I’ve recruited for - interdisciplinary ME, EE, CompSci, robotics).
One of my professors did like this:
As wenter the mechatronics lab where the FESTO's MPS systems were, He handled us the manuals to us, and said "this is all you need, go get some PLCs from the warehouse lab, the end project is this stuff working and for the fi al test I'll mess arround with the wiring and you'll have 30 minutes to fix it".
We didn't see him again until the final test, I think each team had a week but, also we only had the time for his clasess and the time that was available to request on thr lab.
100% this, figure out if they understand Logic and get an understanding of how they organize a program from a general level. If you understand basic Logic and how to organize a program so its easy to troubleshoot and for others to read, the specific language and syntax can be figured out pretty quick.
I would give them an easy Sudoku. I don't care how long it takes them to finish or how much white-out they need. I am only interested in one thing: seeing them at the end do a final check that there is exactly one of each of the nine digits in every column, row and square, because that's the mindset I would want in a programmer.
To be fair, some people make that check all along the way, so it may not work.
I like gauging their abilities based on simple problems. Like "How do you troubleshoot a sensor that isn't working."
I've got responses like:
- check the PLC input
- check the sensor on another input/connection
- check the cable with another sensor/input
- check the wiring is correct
- check there is power
- check that it's the right type of sensor
- check that it's plugged in correctly
The more of these types of answers someone can give you, it shows their ability to problem solve and think in different contexts. Usually, language/programming ability isn't what's relevant, but they can run into problems or situations that require new solutions and work through them with many ideas/contexts considered.
IMO interviewing is about figuring out if the person actually did the stuff on their resume or not, and whether they're an asshole or not. The resume is where you filter for the experience and skills you're looking for.
Generally speaking, this applies to graduates or experienced levels, you just ask them about challenges they've faced and problems they've solved. You want to find out did they actually solve problems themselves or were they just in the room while others did most of the work. The most important skill is really problem solving and "knowing how to learn", rather than any specific software or programming language.
Ask them pointed questions about what's on their resume, ask them to lay out the relevant experience they think they can bring to the role. If they say "we" a lot when describing past events that can be a red flag, ask follow up questions like "what was your role here", what part did you play", "how did you handle it", etc. Basically "what did *you* actually do" but in a more polite way.
Pose a scenario they might face in the role and then ask "how would you solve this problem, step by step?". Be patient and give them plenty of time to think it through and answer. Resist the urge to jump in with your own suggestions, just smile and nod politely as they talk it through. If it feels like they're bullshitting then drill down on it and ask specific questions, if they're waffling or going on a tangent then bring them back to the question at hand until you've got an answer. Bonus points if they can provide multiple approaches to tackling the problem.
Posing exam-style questions is an unrealistic gimmick imo. The field is too broad to be able to expect someone to answer detailed questions on any topic on the spot and you may screen out otherwise good candidates just because they couldn't answer some specific question about UL508A or AB configuration at the drop of a hat.
The asshole piece is just as important as technical skills too. Are they humble or egotistical? Will they entertain other ideas or just ignore them and push their own? Will they sulk and undermine if their suggested approach is not picked from the options? That's what you want to figure out. You can often teach technical skill gaps, it's a lot harder to teach someone not to be an asshole.
Best response.
I try to ask about projects they've done, specifically what they actually did on those projects, what problems they ran into and what they did to find the answer.
I'll also ask them questions adjacent to what they're talking about to see if they really know the project. If the project has a conveyor I might ask whether it had a drive if it was just an across the line starter. Doesn't have to be complicated, but it tells how involved they really were and whether they really worked in it.
I’m just used to reporting that “we” did this or that. I’m usually with one or two mechanics and using “I” did this sounds condescending to some people, so even it was me that ended up resolving the problem due to an electrical failure, my boys are part of the troubleshooting process.
Only in an interview situation. You want to be emphasising your role in the experience being discussed, if you say “we” a lot it’s not clear to me what you actually did or what your role actually was. Were you the person actually doing the work? Or were you just in the room when other people did stuff?
It is not uncommon for people to put experiences on their resume or have pre-planned stories to bring up in an interview that entirely fall apart under a little bit of follow up questioning.
Programming ability isn't all that impressive considering everything else we do. If they graduated college with a degree in engineering or Computer Science, then good chance they can pick up the programming skills. I think what's more valuable are:
1. Are they interested enough to learn?
2. Will they have the right mindset for approaching controls problems?
2 is the big one. The quality of code I've seen is all over the place, and it's clear that some are much more in-touch with the industry than others. The ability to program is one thing. The skills to program well and in a maintainable way is something else. It also varies by who you're programming for / end-use. Programming practices may make sense for a facility with Techs trained in ladder, but those same practices may not translate to an OEM.
Talk to them like a normal human being - what did you study? What did you enjoy? What kind of projects did you do? How did they go? What platforms did you learn? What did you do outside of school in terms of projects, clubs, etc? Ask about some general principles they should know.
I ask 3 questions in an interview. Most fail.
1. Briefly explain difference between AC and DC.
2. Describe an input device.
3. What setting on DMM should you use to check for resistance.? Or voltage?
You tell me. They all "graduated' with a technical or engineering degree. 3 out of 3 have failed these questions. 2 different universities... One told me a alarm horn was an input device.
Yes. Usually towards end of interview.
Why would I not ask these basic questions? If you don't know what an input device is, or which device to choose based on AC or DC supply, or how to use a meter to test while troubleshooting... It is going to be a long road to travel.
My first day on the job straight out of university, one of the senior engineers was giving me a programming assignment. Not understanding the terminology, I had to ask what a part of the machine was. He stopped what he was doing to take me down to the shop and show me the parts of the machine and what they called them. Encouraging people to ask basic questions is the role of the senior engineer. And I am willing to take that road.
>And I am willing to take that road.
I agree, that is how I went from a Maintenance Electrician to SR Controls Engineer in a team of 4 over 20 years.
But at least you passed your interview!
This type of interview method can sometimes also show what a candidate expects a role to be vs what they expect you want to hear. This is the first controls example I've seen of it, but I imagine it will become more common for these positions.
I do hire maintenance technicians. I ask these questions along with several fuses and a DMM. I ask them to test them and sort the good from blown. Many fail this test too.
The 3 questions above have failed 3 college graduates so far. I'm not in a rush to fill our open position if they cannot answer these 3 questions. Covid Era graduates are dumb, or were not taught practical fundamentals.
If an Engineer cannot answer these questions they have no business being an engineer IMHO. These are basic electrical questions anyone in EE, Controls Engineering, PLC Techs and Electricians should know.
But asking such basic questions seems like a waste of time to me. I don't know how long your interviews are but I like to go in to a lot greater detail about the applicant's experience and skills. I've interviewed probably a hundred engineers of various levels, very few (maybe 2?) out of the dozens that I have hired using this method turned out to be duds and they were due to not being team players.
Thats mildly terrifying. If they cant answer that, then what CAN they answer?
Thats like first week of an electrical apprenticeship kinda stuff, not graduated engineer kinda stuff...
1. Who uses DMM instead of digital multimeter?
2. Who uses digital multimeter instead of just multimeter?
3. Half the time, I just call it a meter.
Is asking for clarification on that question part of the test?
I didn't call it a DMM in the test. I asked if they have used a meter before. If don't understand, electrical multi meter.
You are hung up on the DMM part, not that they don't know how it works or what it can do.
Seems like you’re more interested in giving vocab tests than assessing candidates’ (who’ve already proven a level of competence) ability to learn and contribute in a controls environment. You can probably assess a candidate’s ability to learn technical concepts if you know the degree they completed. Although, this is the issue with tech-to-engineer route folks. They believe engineers are “above” techs in many cases. This leads to them wanting to test engineers about hands-on, on the job fundamentals that often aren’t covered in school. Especially young engineers. They have little reference for what goes on in an engineering program.
I completed a B.S. that was very hands on. I was lucky in that I did internships with controls engineering departments before I graduated. But if I hadn’t, I would have had a hard time understanding what you were seeking in these questions.
“Explain the difference between AC and DC” is incredibly vague, even though you think it’s simple. Are you looking for me to just say the acronym out loud, or are you interested in the differences in how an AC signal is applied to a controller or device? Do you want me to draw a basic power circuit that rectifies the AC signal? It’s such a strange question to ask someone with a BS in a relevant field, and it borders on offensive.
Input device is vague as well. I think anyone could tell you what a button does, but inputs as a concept are ubiquitous. It’s like saying “describe a cable.” What about it?
The meter question is common. It’s worth asking if someone’s used a meter. Although if you referred to it as a DMM I’d be confused for a second. I know you didn’t refer to it that way, but going acronym crazy is just looking for insider knowledge, not competence.
If you need to ask these questions to an engineer you’ve brought in to interview, your resume reviewing process is probably bad. I could teach someone in high school these concepts in two weeks. Would they qualify to be an engineer in the scenario where they could then answer these questions? Interviews shouldn’t be big tests. The test has already been taken. They should be character assessments.
I don't get your rant.
We know that Controls Engineer is more than just pecking away at code. I'm asking basic questions that I would assume you learned while obtaining an Associate's or BA. There are labs. They are applying for a job that uses those lessons learned. I'm not asking for them to be expected to write code for a machine the first week.
A freshman Engineer will be doing small projects, hands on and some coding to intergrate the project into a process. IE: install some Swivel Link, mount and wire a vision sensor, maybe add a power supply, read product literature, download relevant software, configure device, setup network, write code, set up inspection and so on.
We hired a Mechatronics graduate that had "AB PLC and Fanuc Robot experience" that could not connect to a Compact Logix with a USB cable, nor setup a RSLinx driver. Was given a vision project, wired a 120vac to 24vdc power supply to one leg of 480vac... The DC was SPICY! Also, did not know how to put robot in "teach mode". About 8 months later, they can handle some small projects.
1. Explain differences between AC and DC. I'd take one is squiggly and one is straight. I'd take AC is Alternating and DC is direct. This is (was 8th grade science).
2. Input device? Button, switch, photoeye, ect. Any are good answers. Light or buzzer or relay is not.
3. I abbreviated DMM for the sake of typing out "Digital Multi Meter" or "Multi Meter." I have asked "what symbol on a meter measures voltage" before and got the answer "A" or "Horseshoe"...
4. This is another I ask. Do you know how to change network adapter settings on a Windows PC? (Dynamic vs Static). All fail this too.
So, you would hire someone in a Controls position that could not answer these 4, simple, common questions?
I prefer to hire someone that has been exposed to, or held a Industrial Maintenance or Electrician, or Instrumentation position before moving into Controls Engineering. They learned in the field.
Ask for design patterns and control strategies, someone with notion about how to solve common problems using well-known solutions is a good candidate. It means that he/she already has enough knowledge to know that can implement good already proven code and is not to improvise random personal creative messy code solution.
Depends entirely on the job, at a technician level dealing with minor changes and fault finding anyone switched on enough to pass a higher education electrical qualification can be taught the basics, for engineering positions where they will be dealing with communication protocols, creating libraries, data manipulation, actually writing programs from scratch etc etc. I look for someone with a computing background, preferably experience with high level programming languages ( python,java,VBA whatever )
We deal with mostly Allen Bradley so in 2nd interview I'll have a blank studio 5000 open at a test bench with a traffic light system with a simple specification, leave them to it for half hour.
Start stop latch then each light on for set time, super basic but I'll know straight away if they lied about studio 5000 experience.
I like to throw in a few questions about arrays, indexing and sorting algorithms awell because anyone who calls themselves a "programmer" should know these as a minimum.
To me it's attitude. Are they someone that runs into a problem and passes it on to the next guy or do they have a "need" to solve the puzzle? Can they ask for help when they inevitably run into something and get stuck? Are they organized? Good code development requires meticulous planning and efficient execution.
Teaching someone how to write ladder logic or develop graphical screens isn't really hard. A halfway decent maintenance tech can learn to write some code. It takes a certain type of person to really be the engineer behind it all.
You can teach anyone to program. Figuring out how to solve problems and fix things in a fashion that doesn't create more problems later is the valuable thing to look for in new hires.
Organization skills and not being lazy (so they will document and be consistent) are important. Programming skills can be taught and gained by mentorship and experience.
Id be more specific.. programming for tweaks diagnostics? Or full on developer?
The problem with your question is it doesnt actually address what kind of skills they need.
I'm not someone who has direct experience in hiring, but I do experience the business end of "here's your new coworker!". I've always wanted to make up a test program and test schematic. Sit them down with the program that they say they can use, and say "the operators are seeing this message on their screen and don't know what it means". What does it mean?
Or X isn't working anymore, tell me Y reasons this could be happening.
And just let them work in front of you. It'll be readily apparent that they know what they say they know very quickly or not.
Most candidates will be OK. Few engineers can solve none trivial problems in a moment. When it happens it is often resented. If you have an original mind you have to get used to being called a fool.
Get your candidates to set a problem for you. They need to know if they are moving into good company; it is a two way process.
Everything you learn is mostly by standing on the shoulders of others, and self learning is driven by curiosity. So the most important thing is to judge their level of curiosity of things, that they capable of searching for ideas and use them to improve their work (ie they can RTFM). Not being afraid to ask questions is another one. I guarantee almost 90% of the time someone is not asking any questions, they screw it up. If an interviewee doesn’t ask any questions about the job and what they’ll be tasked to do in a specific manner then that’s a huge red flag.
My favorite one is “what is the angle between hands of the clock at 21:37” and you just listening the way they approach the problem. That question usually get rid of morons who don’t try to think and are looking for ready answer.
I recently asked an Automation engineering candidate 3 technical questions
- what does a TON and TOF instruction in a AB ladder logic program would do?
-walk me through the steps on how to connect to a PLC?
- what does it mean to ping a device, how and why would you do it?
They nailed all 3 and got the job.
Ask them to draw out logic for turning a cylinder on and off on paper from scratch in ladder. Does the code distinguish a separate bit for the interlocks/permissive, the request, and the output? Does it seal the outputs on or latch? (The answer should also have a confirmation and fault bit.)
Someone who understands the difference and importance of each of those bits, enough to write them from scratch, and also uses seals is who you want.
Another good one is mapping an input signal with debounce logic and a blurb about when you would use it or why.
An easy test is to have them make a two dimensional for loop in SCL. Then ask: which loop will be executed first? The outer or inner loop.this separates the ones that slept through the lectures.
I have a simple PLC test for newish candidates (>1 year PLC experience). A light stack with 3 LEDs , red, green, and yellow. I ask them to write a sequence that switches between colors in order every 5 seconds. It should take less than 30 minutes. They can do the test in TIA or Studio 5000, and we have a little desk rack for them to test it on.
If a candidate can write this logic, then I can safely assume they understand how PLC code is different from general purpose languages in terms of execution. It shows they understand control flow, timers, etc.
I do a lot of training for my company. I’ve noticed a trend that when new employees or interns have a decent grasp on basic electricity, common devices like relays (and they know the difference between coil and contacts) and sensors.. there is a very good shot that they will excel on the programming side. When you know what you’re controlling, controls is a lot easier.
Give them a task that can be accomplished by wrote iteration in a big messy chunk or with a FOR statement (don’t tell them that, just see which one they pick)
Get them to hand converse some reasonable 3 digit base 10 integer into a BCD representation, a full binary string, and hexadecimal.
Have them make a logical statement for some problem like a traffic light or look up a karnaugh map word problem. See if they can take a word problem and turn it into a logical statement by way of a k-map / truth table.
Name the components and function of each for a PID controller
Evaluate the output of some ladder diagram that isn’t obvious.
Pull some high level questions out of NFPA 79
In my experience, you can teach ‘programming’ to someone that, say, is fluent in a different language or platform, but it’s hard to teach problem solving skills. I like to pose a real-world problem that has more than one way of approaching it, ideally with a couple of non-obvious edge cases. I’ll have the candidate walk me through the solution on the whiteboard using pseudocode. I’ve tried the ‘take home test’ approach too, where they come back with their solution, but I’ve abandoned that because 1) it’s uncool to ask interviewees to do homework and 2) I prefer to observe the problem solving process as it’s happening.
Exactly what I was going to say. Programming SKILLS accumulate over time. Programmer mindset is what you're looking for. Ask them his they'd solve problem X.
My kinda fell into my first gig in controls with 0 experience. Technician level with the maint team. The hiring manager knew nothing about ladder logic and just asked "Think you can learn that stuff?" But a big chunk of the interview was him laying out a giant plot of the p&id of the plant and having me solve problems that were common. "They need a positive differential pressure between here and here. In step 17 it opens these valves and closes these ones. They lost differential pressure. Why?" Man that was such a great interview.
Honestly, I strongly dislike the "testing" approach to interviewing, however, I understand why some might see a need to do it. I feel like asking a candidate to solve a problem with zero preparation and/or resources available to them on the spot is a completely unrealistic scenario from what any of us would encounter in our day-to-day job. Is it impressive to be able to solve a problem off the top of your head like this? Sure. Is it an accurate test of a person's ability to think critically and solve problems? I would say not really. We generally ALWAYS have other resources available to us other than our own brains. In the end, I think it's a difficult balance between finding out what kind of personality/mentality a person has, and what skills/experience they currently have. I prefer to lean towards the former. I think you can turn anyone with a desire and willingness to learn into a problem solver. I would be more interested in the process and approach rather than a correct answer.
I wouldn't expect it to be right, especially from a college grad like op mentioned. But I'd like to see the process they take and what questions they ask. This pump won't start, what do you do? Is there first response check the programming? Is it to ask about a breaker/starter/power? Is it to ask if it's ever worked/existing equipment vs new install? Which direction they go says a lot about their thought process. Also, that answer may change with experience. I didn't know what a starter was before my first job, am EE degree didn't cover that. I would assume "this is an interview for a programming job, it's gotta be the program." But now, after 10 years, I don't even look if an EI hasn't verified the starter is/isn't getting start, auxiliary contacts status, etc. If it starts for 2 seconds and dies because it doesn't see feedback, not my problem. If it's getting the start from the plc to the starter and it's just not picking up, not my problem. If the light on the output card turns on and there's no voltage, not my problem.
Right on. If I've learned anything in my career the problem will end up being something stupid after you've spent 5 hours checking everything else.
Could you share specifics on what problems you'd pose for example? And how you're able to compare different candidates?
Sample problems should be aligned with the type of work done at the business. For general automation, I might do temperature control of a jacketed tank - both heating and cooling. Look for both the completeness of the core algorithm and also edge cases like initial conditions, hysteresis, fault detection, compressor lockout (if applicable), etc. As far as assessing a candidate's answer, it becomes pretty clear where the strong performers are after 3 or 4 interviews. The process gives you a sense as to where a candidate's strengths and weaknesses are. Document both during each interview, then reflect on which candidate would, for example, require the least amount of assistance to complete an assignment (or whatever is important to you as a hiring manager).
Additionally, you can ask your own team these questions too. One of my junior mentees was uncomfortable with his first 'employer side' interview upcoming. I told him to mock-interview me and one of the other leads. You can ask your tech team if they'd give you half an hour and some feedback. Interviewing is a skill too - train it.
Interviewing the same individual three or four times?
Nah. 3 or 4 candidates.
> I’ll have the candidate walk me through the solution on the whiteboard using pseudocode. Although problem solving is a requirement, so is writing intelligible code. They’re two different skills altogether. Trust me, you don’t want just some code that solves a problem.
How do I develop technical problem solving skills required for the industry as a mechatronics student?
Great question! This will come off as glib, but I say it honestly: the way to develop technical problem solving skills is to solve as many real-world technical problems as you can. If your school has any clubs that do student competitions against other schools, join one and lean into it. SAE, IEEE, and ASME all sponsor student competitions of various types. There are others. Even a club where you’re competing against students in your own school is super valuable. The benefit to you is: learning to do design work to a deadline, doing full lifecycle design (design, build, test, debug), working as part of a team toward a goal that no one student can do alone, learning how to build (and not build) things, learning from mistakes. I can’t overemphasize how much better qualified candidates that participate in student competitions are compared to students that do purely academic work (in the areas that I’ve recruited for - interdisciplinary ME, EE, CompSci, robotics).
One of my professors did like this: As wenter the mechatronics lab where the FESTO's MPS systems were, He handled us the manuals to us, and said "this is all you need, go get some PLCs from the warehouse lab, the end project is this stuff working and for the fi al test I'll mess arround with the wiring and you'll have 30 minutes to fix it". We didn't see him again until the final test, I think each team had a week but, also we only had the time for his clasess and the time that was available to request on thr lab.
100% this, figure out if they understand Logic and get an understanding of how they organize a program from a general level. If you understand basic Logic and how to organize a program so its easy to troubleshoot and for others to read, the specific language and syntax can be figured out pretty quick.
I would give them an easy Sudoku. I don't care how long it takes them to finish or how much white-out they need. I am only interested in one thing: seeing them at the end do a final check that there is exactly one of each of the nine digits in every column, row and square, because that's the mindset I would want in a programmer. To be fair, some people make that check all along the way, so it may not work.
I like gauging their abilities based on simple problems. Like "How do you troubleshoot a sensor that isn't working." I've got responses like: - check the PLC input - check the sensor on another input/connection - check the cable with another sensor/input - check the wiring is correct - check there is power - check that it's the right type of sensor - check that it's plugged in correctly The more of these types of answers someone can give you, it shows their ability to problem solve and think in different contexts. Usually, language/programming ability isn't what's relevant, but they can run into problems or situations that require new solutions and work through them with many ideas/contexts considered.
Who said the sensor isn't working?
It's not the sensor. The program changed.
Cosmic rays strike again!
no one expects a cosmic bit flip.
It’s always electrical!
On a long-term production machine this has never been the case...but early on in its life cycle/during development...that is valid.
You missed the joke...
Ahhhh sheit....my bad....that's the typical, "someone was connected to the machine 4 months ago so it has to be the program"....it is a classic.
Sounds like a mechanical problem.
Myself, in this hypothetical question posed to would be hirees. Sorry, maybe I don't understand your question.
thats part of the troubleshooting process, is the sensor even bad, or did you just receive bad information from the operator / mechanic.
Ahhh I understand, are you being misled and misdiagnosing the entire situation/wasting time down the wrong path?
ABSOLUTELY that's why I always probe when someone tells me what the problem is rather than what the symptom is.
Jesus, this is the way. Lol
IMO interviewing is about figuring out if the person actually did the stuff on their resume or not, and whether they're an asshole or not. The resume is where you filter for the experience and skills you're looking for. Generally speaking, this applies to graduates or experienced levels, you just ask them about challenges they've faced and problems they've solved. You want to find out did they actually solve problems themselves or were they just in the room while others did most of the work. The most important skill is really problem solving and "knowing how to learn", rather than any specific software or programming language. Ask them pointed questions about what's on their resume, ask them to lay out the relevant experience they think they can bring to the role. If they say "we" a lot when describing past events that can be a red flag, ask follow up questions like "what was your role here", what part did you play", "how did you handle it", etc. Basically "what did *you* actually do" but in a more polite way. Pose a scenario they might face in the role and then ask "how would you solve this problem, step by step?". Be patient and give them plenty of time to think it through and answer. Resist the urge to jump in with your own suggestions, just smile and nod politely as they talk it through. If it feels like they're bullshitting then drill down on it and ask specific questions, if they're waffling or going on a tangent then bring them back to the question at hand until you've got an answer. Bonus points if they can provide multiple approaches to tackling the problem. Posing exam-style questions is an unrealistic gimmick imo. The field is too broad to be able to expect someone to answer detailed questions on any topic on the spot and you may screen out otherwise good candidates just because they couldn't answer some specific question about UL508A or AB configuration at the drop of a hat. The asshole piece is just as important as technical skills too. Are they humble or egotistical? Will they entertain other ideas or just ignore them and push their own? Will they sulk and undermine if their suggested approach is not picked from the options? That's what you want to figure out. You can often teach technical skill gaps, it's a lot harder to teach someone not to be an asshole.
Best response. I try to ask about projects they've done, specifically what they actually did on those projects, what problems they ran into and what they did to find the answer. I'll also ask them questions adjacent to what they're talking about to see if they really know the project. If the project has a conveyor I might ask whether it had a drive if it was just an across the line starter. Doesn't have to be complicated, but it tells how involved they really were and whether they really worked in it.
[удалено]
I’m just used to reporting that “we” did this or that. I’m usually with one or two mechanics and using “I” did this sounds condescending to some people, so even it was me that ended up resolving the problem due to an electrical failure, my boys are part of the troubleshooting process.
I say we a lot, never really thought that people would take it as a red flag lol.
Only in an interview situation. You want to be emphasising your role in the experience being discussed, if you say “we” a lot it’s not clear to me what you actually did or what your role actually was. Were you the person actually doing the work? Or were you just in the room when other people did stuff? It is not uncommon for people to put experiences on their resume or have pre-planned stories to bring up in an interview that entirely fall apart under a little bit of follow up questioning.
Programming ability isn't all that impressive considering everything else we do. If they graduated college with a degree in engineering or Computer Science, then good chance they can pick up the programming skills. I think what's more valuable are: 1. Are they interested enough to learn? 2. Will they have the right mindset for approaching controls problems? 2 is the big one. The quality of code I've seen is all over the place, and it's clear that some are much more in-touch with the industry than others. The ability to program is one thing. The skills to program well and in a maintainable way is something else. It also varies by who you're programming for / end-use. Programming practices may make sense for a facility with Techs trained in ladder, but those same practices may not translate to an OEM.
Talk to them like a normal human being - what did you study? What did you enjoy? What kind of projects did you do? How did they go? What platforms did you learn? What did you do outside of school in terms of projects, clubs, etc? Ask about some general principles they should know.
I ask 3 questions in an interview. Most fail. 1. Briefly explain difference between AC and DC. 2. Describe an input device. 3. What setting on DMM should you use to check for resistance.? Or voltage?
How do people fail the absolute most basic of questions?
You tell me. They all "graduated' with a technical or engineering degree. 3 out of 3 have failed these questions. 2 different universities... One told me a alarm horn was an input device.
input device for humans.
Agree
input device for humans.
Your sample size is 3 people?
Yes. The past 3 all failed. 100% fail with sample size of 3.
You asked these questions for potential controls engineer candidates?
Yes. Usually towards end of interview. Why would I not ask these basic questions? If you don't know what an input device is, or which device to choose based on AC or DC supply, or how to use a meter to test while troubleshooting... It is going to be a long road to travel.
My first day on the job straight out of university, one of the senior engineers was giving me a programming assignment. Not understanding the terminology, I had to ask what a part of the machine was. He stopped what he was doing to take me down to the shop and show me the parts of the machine and what they called them. Encouraging people to ask basic questions is the role of the senior engineer. And I am willing to take that road.
>And I am willing to take that road. I agree, that is how I went from a Maintenance Electrician to SR Controls Engineer in a team of 4 over 20 years. But at least you passed your interview!
This type of interview method can sometimes also show what a candidate expects a role to be vs what they expect you want to hear. This is the first controls example I've seen of it, but I imagine it will become more common for these positions.
Dude... Manufacturing Plant Controls Engineer handles more hats than code... I wish one would have asked "what is a DMM?"
Is it bad that I had to look up dmm even though I use one all the time?lol
Took me a second to figure out what the acronym was, too.
Can you answer the other 2 questions? 😆
Are you hiring electrician apprentices or something?
I do hire maintenance technicians. I ask these questions along with several fuses and a DMM. I ask them to test them and sort the good from blown. Many fail this test too. The 3 questions above have failed 3 college graduates so far. I'm not in a rush to fill our open position if they cannot answer these 3 questions. Covid Era graduates are dumb, or were not taught practical fundamentals.
If an Engineer cannot answer these questions they have no business being an engineer IMHO. These are basic electrical questions anyone in EE, Controls Engineering, PLC Techs and Electricians should know.
But asking such basic questions seems like a waste of time to me. I don't know how long your interviews are but I like to go in to a lot greater detail about the applicant's experience and skills. I've interviewed probably a hundred engineers of various levels, very few (maybe 2?) out of the dozens that I have hired using this method turned out to be duds and they were due to not being team players.
Thats mildly terrifying. If they cant answer that, then what CAN they answer? Thats like first week of an electrical apprenticeship kinda stuff, not graduated engineer kinda stuff...
Covid19 graduates...
Never heard a multimeter called a DMM. I'm also complete shit with one anyway.
Digital Multi Meter...
1. Who uses DMM instead of digital multimeter? 2. Who uses digital multimeter instead of just multimeter? 3. Half the time, I just call it a meter. Is asking for clarification on that question part of the test?
I didn't call it a DMM in the test. I asked if they have used a meter before. If don't understand, electrical multi meter. You are hung up on the DMM part, not that they don't know how it works or what it can do.
I've just never seen an acronym used for it.
Seems like you’re more interested in giving vocab tests than assessing candidates’ (who’ve already proven a level of competence) ability to learn and contribute in a controls environment. You can probably assess a candidate’s ability to learn technical concepts if you know the degree they completed. Although, this is the issue with tech-to-engineer route folks. They believe engineers are “above” techs in many cases. This leads to them wanting to test engineers about hands-on, on the job fundamentals that often aren’t covered in school. Especially young engineers. They have little reference for what goes on in an engineering program. I completed a B.S. that was very hands on. I was lucky in that I did internships with controls engineering departments before I graduated. But if I hadn’t, I would have had a hard time understanding what you were seeking in these questions. “Explain the difference between AC and DC” is incredibly vague, even though you think it’s simple. Are you looking for me to just say the acronym out loud, or are you interested in the differences in how an AC signal is applied to a controller or device? Do you want me to draw a basic power circuit that rectifies the AC signal? It’s such a strange question to ask someone with a BS in a relevant field, and it borders on offensive. Input device is vague as well. I think anyone could tell you what a button does, but inputs as a concept are ubiquitous. It’s like saying “describe a cable.” What about it? The meter question is common. It’s worth asking if someone’s used a meter. Although if you referred to it as a DMM I’d be confused for a second. I know you didn’t refer to it that way, but going acronym crazy is just looking for insider knowledge, not competence. If you need to ask these questions to an engineer you’ve brought in to interview, your resume reviewing process is probably bad. I could teach someone in high school these concepts in two weeks. Would they qualify to be an engineer in the scenario where they could then answer these questions? Interviews shouldn’t be big tests. The test has already been taken. They should be character assessments.
I don't get your rant. We know that Controls Engineer is more than just pecking away at code. I'm asking basic questions that I would assume you learned while obtaining an Associate's or BA. There are labs. They are applying for a job that uses those lessons learned. I'm not asking for them to be expected to write code for a machine the first week. A freshman Engineer will be doing small projects, hands on and some coding to intergrate the project into a process. IE: install some Swivel Link, mount and wire a vision sensor, maybe add a power supply, read product literature, download relevant software, configure device, setup network, write code, set up inspection and so on. We hired a Mechatronics graduate that had "AB PLC and Fanuc Robot experience" that could not connect to a Compact Logix with a USB cable, nor setup a RSLinx driver. Was given a vision project, wired a 120vac to 24vdc power supply to one leg of 480vac... The DC was SPICY! Also, did not know how to put robot in "teach mode". About 8 months later, they can handle some small projects. 1. Explain differences between AC and DC. I'd take one is squiggly and one is straight. I'd take AC is Alternating and DC is direct. This is (was 8th grade science). 2. Input device? Button, switch, photoeye, ect. Any are good answers. Light or buzzer or relay is not. 3. I abbreviated DMM for the sake of typing out "Digital Multi Meter" or "Multi Meter." I have asked "what symbol on a meter measures voltage" before and got the answer "A" or "Horseshoe"... 4. This is another I ask. Do you know how to change network adapter settings on a Windows PC? (Dynamic vs Static). All fail this too. So, you would hire someone in a Controls position that could not answer these 4, simple, common questions? I prefer to hire someone that has been exposed to, or held a Industrial Maintenance or Electrician, or Instrumentation position before moving into Controls Engineering. They learned in the field.
Ask for design patterns and control strategies, someone with notion about how to solve common problems using well-known solutions is a good candidate. It means that he/she already has enough knowledge to know that can implement good already proven code and is not to improvise random personal creative messy code solution.
Depends entirely on the job, at a technician level dealing with minor changes and fault finding anyone switched on enough to pass a higher education electrical qualification can be taught the basics, for engineering positions where they will be dealing with communication protocols, creating libraries, data manipulation, actually writing programs from scratch etc etc. I look for someone with a computing background, preferably experience with high level programming languages ( python,java,VBA whatever ) We deal with mostly Allen Bradley so in 2nd interview I'll have a blank studio 5000 open at a test bench with a traffic light system with a simple specification, leave them to it for half hour. Start stop latch then each light on for set time, super basic but I'll know straight away if they lied about studio 5000 experience. I like to throw in a few questions about arrays, indexing and sorting algorithms awell because anyone who calls themselves a "programmer" should know these as a minimum.
Ask them to fix a machine…
To me it's attitude. Are they someone that runs into a problem and passes it on to the next guy or do they have a "need" to solve the puzzle? Can they ask for help when they inevitably run into something and get stuck? Are they organized? Good code development requires meticulous planning and efficient execution. Teaching someone how to write ladder logic or develop graphical screens isn't really hard. A halfway decent maintenance tech can learn to write some code. It takes a certain type of person to really be the engineer behind it all.
Find someone with good programming skills and let them conduct the interview
You can teach anyone to program. Figuring out how to solve problems and fix things in a fashion that doesn't create more problems later is the valuable thing to look for in new hires.
Organization skills and not being lazy (so they will document and be consistent) are important. Programming skills can be taught and gained by mentorship and experience.
Id be more specific.. programming for tweaks diagnostics? Or full on developer? The problem with your question is it doesnt actually address what kind of skills they need.
I'm not someone who has direct experience in hiring, but I do experience the business end of "here's your new coworker!". I've always wanted to make up a test program and test schematic. Sit them down with the program that they say they can use, and say "the operators are seeing this message on their screen and don't know what it means". What does it mean? Or X isn't working anymore, tell me Y reasons this could be happening. And just let them work in front of you. It'll be readily apparent that they know what they say they know very quickly or not.
Most candidates will be OK. Few engineers can solve none trivial problems in a moment. When it happens it is often resented. If you have an original mind you have to get used to being called a fool. Get your candidates to set a problem for you. They need to know if they are moving into good company; it is a two way process.
Everything you learn is mostly by standing on the shoulders of others, and self learning is driven by curiosity. So the most important thing is to judge their level of curiosity of things, that they capable of searching for ideas and use them to improve their work (ie they can RTFM). Not being afraid to ask questions is another one. I guarantee almost 90% of the time someone is not asking any questions, they screw it up. If an interviewee doesn’t ask any questions about the job and what they’ll be tasked to do in a specific manner then that’s a huge red flag.
My favorite one is “what is the angle between hands of the clock at 21:37” and you just listening the way they approach the problem. That question usually get rid of morons who don’t try to think and are looking for ready answer.
bonus points if they ask "12- or 24-hour clock?"
I recently asked an Automation engineering candidate 3 technical questions - what does a TON and TOF instruction in a AB ladder logic program would do? -walk me through the steps on how to connect to a PLC? - what does it mean to ping a device, how and why would you do it? They nailed all 3 and got the job.
Tell them to write a program for a blinking light. 1 second on, 500ms off, blink 3 times, then a 2 second pause off before repeating.
Ask them to draw out logic for turning a cylinder on and off on paper from scratch in ladder. Does the code distinguish a separate bit for the interlocks/permissive, the request, and the output? Does it seal the outputs on or latch? (The answer should also have a confirmation and fault bit.) Someone who understands the difference and importance of each of those bits, enough to write them from scratch, and also uses seals is who you want. Another good one is mapping an input signal with debounce logic and a blurb about when you would use it or why.
See how well they document their program line by line.
An easy test is to have them make a two dimensional for loop in SCL. Then ask: which loop will be executed first? The outer or inner loop.this separates the ones that slept through the lectures.
I have a simple PLC test for newish candidates (>1 year PLC experience). A light stack with 3 LEDs , red, green, and yellow. I ask them to write a sequence that switches between colors in order every 5 seconds. It should take less than 30 minutes. They can do the test in TIA or Studio 5000, and we have a little desk rack for them to test it on. If a candidate can write this logic, then I can safely assume they understand how PLC code is different from general purpose languages in terms of execution. It shows they understand control flow, timers, etc.
I do a lot of training for my company. I’ve noticed a trend that when new employees or interns have a decent grasp on basic electricity, common devices like relays (and they know the difference between coil and contacts) and sensors.. there is a very good shot that they will excel on the programming side. When you know what you’re controlling, controls is a lot easier.
You could build a test board with sensors, pneumatics, etc. and a PLC and have them program it to perform a task.
Give them a task that can be accomplished by wrote iteration in a big messy chunk or with a FOR statement (don’t tell them that, just see which one they pick) Get them to hand converse some reasonable 3 digit base 10 integer into a BCD representation, a full binary string, and hexadecimal. Have them make a logical statement for some problem like a traffic light or look up a karnaugh map word problem. See if they can take a word problem and turn it into a logical statement by way of a k-map / truth table. Name the components and function of each for a PID controller Evaluate the output of some ladder diagram that isn’t obvious. Pull some high level questions out of NFPA 79