It’s particularly hard to hire for industrial AIoT positions, as it is a domain with lots of talented software and ML engineers, none of whom may have worked in a physical-world data domain before. It is not always obvious from a resume whether someone has worked in industrial AIoT, or not. Below are a few of my favorite questions that tend to make this gap obvious-and why.
"How would you design your system to deal with a sensor suddenly starts sending data twice a second?"
While this looks like a tiny edge-case, it’s a surprisingly common one. Firmware updates, retries in networks, or a poorly configured interval can all trigger such behavior in a device. Typical software developers with clean API experience will often try to answer by stating "dedupe" it without explaining how – would the candidates dedupe based on a timestamp, payload hash or a sequence ID that the device outputs? Each dedupe strategy is susceptible to different edge cases, and anyone who has ever debugging this in production tends to have well-formed opinions on their strategies.
"I have a model that works in testing with 95% accuracy. What questions do you ask before believing it?"
The critical thing I listen for is whether the candidate thinks about the training and testing data relative to production conditions-is this training and testing data representative of the actual conditions the model will experience in production? (This includes similar environmental context, sensor calibrations and, crucially, time period, as seasonal patterns can significantly impact sensor readings.) Typically, software developers will think that a high number indicates a completed task, while someone who has experience in this specific domain, and has been burned in production by data drift, will ask about the data quality and history first.
"How would you design a schema to support 5 different sensor vendors right now, and a 6th next quarter?"
I am actually seeing if the candidate thinks about schema definition and updating as a task that requires normalisation and the ongoing management of data semantics, as opposed to a one-off job. A more naive software engineer would write specific parsers per device, or hardcode every specific sensor device in their system, whilst an engineer with industrial experience would design an adaptation/translation layer to separate and contain all the quirks and specificities of each vendor, without affecting the integrity of the remainder of the system.
"Can you describe to me what happens in your system if a particular facility loses internet connectivity for 6 hours?"
This question typically helps to filter candidates that are used to dealing with always-on connectivity, versus those who have experience designing for intermittent/lossy network conditions, which involve a completely different set of assumptions. I’m looking for candidates that talk about data buffering locally, store-and-forward mechanisms, and how they deal with time-sensitive events that are supposed to be triggered within a limited timeframe (e.g., safety issues). A common, weak answer that a purely software, cloud developer might try would be "the system would re-download all the information when it's back online," without explaining the implications of missing events.
"How can you tell if it’s truly an anomalous event or if the sensor simply has reading issues?"
This question sounds so simple, and it's very difficult; it gets at data quality reasoning. An anomaly detected might also be an anomaly with a sensor, perhaps due to a failure or some physical issue with the hardware. If the device fails due to physical damage, it may produce seemingly anomalous behaviour while an 'anomaly' is already happening. A good answer might consider cross-referencing information with neighbouring sensors, looking for known device failure patterns, or signalling for human intervention as opposed to fully automating decision-making of what is or isn't an anomaly.
Why these specific questions
All these questions do not have much to do with algorithms or how to design a system architecture. I am instead testing for the specific aspect of 'Have you actually struggled with and managed a real, messy physical data space, or have you only been handed already perfectly clean data?'. This is a distinction which is extremely important for Industrial AIoT, and where most of the difficulty resides, rather than in the modelling process itself.
Do you have different questions that may test for specific relevant experience for this domain? I would love to hear from you.
Some of the most useful progress in industrial AI isn't happening in a pitch deck — it's happening quietly, in warehouses and factories, at places like Aperture Venture Studio that started with the infrastructure already in place.
Top comments (0)