Skip to content
Tech Interview Prep home
Technical interview guide

Sensors & Actuators

How a robot perceives its environment and acts on it — the hardware interface between software and the physical world.

Read
45 min
Practice MCQs
25
Interview QA
25
Edition
v4
Editorial status
Reviewed
Relevant for
Robotics Engineer

Scope: Current NIST SP 800-82 Rev. 3, Arduino, Texas Instruments, Analog Devices, NXP I2C, OSHA, and IEC functional-safety guidance reviewed 2026-09-04.

Overview

Curated: · Written: · Reviewed:

Engineer the complete path from physical reality to controlled action

A sensor converts a physical quantity into a signal; an actuator converts commanded energy into physical action. A reliable design covers the entire chain: measurand, transducer, excitation, signal conditioning, sampling, conversion, calibration, digital processing, decision, driver, power stage, mechanism, feedback, fault detection, and safe state. Reading a register or writing a PWM duty cycle is only one step.

Interviewers use this topic to separate people who have shipped hardware from people who have only called libraries. The classic probe is a system-design prompt — "design a distance sensor for a robot that must not hit a wall" — and the weak answer picks one sensor, states its datasheet range, and stops. A strong answer names the operating conditions, defends the sensor choice against two alternatives, walks the signal chain, and says what happens when the sensor lies. Expect follow-ups at every layer: "what's your accuracy budget?", "what happens if this wire breaks?", "why did you sample at that rate?" If you cannot answer the follow-up, the first answer doesn't count.

Requirements and vocabulary

Start with requirements in physical units and operating conditions. Define range and span, resolution, accuracy, precision, repeatability, sensitivity, linearity, hysteresis, drift, response time and bandwidth, cross-sensitivity, environment, lifetime, calibration, and failure consequences. Resolution is the smallest representable change; accuracy is closeness to truth; precision is repeatability. More ADC bits do not guarantee more accurate measurements when reference, noise, linearity, and sensor error dominate.

Interviewers probe the accuracy/precision/resolution triple deliberately, because conflating them is the most common weak answer in this topic. "12-bit ADC, so 0.1% accurate" is the answer they are fishing for; the strong answer separates the converter's resolution from the system's error budget — sensor error, reference tolerance, conditioning noise, calibration residual — and says which term dominates. A follow-up like "your repeatability is great but every unit reads 3°C high — what is that called?" tests whether you can name offset error and, more importantly, say you'd calibrate it out.

Sensor selection is a defended trade-off

Selection is where interviewers start when they want to see judgement rather than recall. Take distance sensing as the standard prompt: ultrasonic is cheap, works on glass-independent surfaces, but is slow (tens of milliseconds per ping), suffers specular reflection off angled surfaces, and crosstalks between units; IR time-of-flight is fast and small but range-limited and confused by ambient IR and target reflectivity; LiDAR gives range and accuracy but costs, power, and eye-safety limits scale with it; a camera plus processing extracts the most information but adds compute, latency, lighting dependence, and validation burden. The strong answer states the requirement first — range, accuracy, update rate, target material, ambient light, cost ceiling — and then eliminates candidates against it. The weak answer names a sensor and invents reasons afterward.

The same pattern applies to encoders: incremental versus absolute is a question about what happens at power-up and after a glitch, not about resolution.

Encoders

A quadrature encoder puts two pulse trains 90° out of phase on channels A and B; direction comes from which channel leads, and count rate gives speed. Counts-per-revolution at the encoder is not the resolution of the mechanism — a 1024-CPR encoder on a shaft geared 10:1 to the load gives 10,240 counts per load revolution, but the gearing also adds backlash that no encoder count sees. The index (Z) channel pulses once per revolution and gives a repeatable reference for homing and for correcting accumulated count error.

Incremental encoders lose position at power-off and can lose counts on electrical noise or vibration at standstill; the system must home, and the interview question is always "what does the machine do before it homes?" An absolute encoder — single-turn or multi-turn, the multi-turn turns counted mechanically or by battery-backed electronics — reports true position immediately, at a price. Expect the follow-up: "your incremental encoder counted 3 extra pulses during a power glitch — when do you find out?" The honest answer is at the next index pass or homing cycle, and a design that never re-homes never finds out.

IMUs

An accelerometer measures specific force (gravity plus linear acceleration), a rate gyro measures angular velocity, and a magnetometer measures field direction — none of them measures orientation directly, so orientation is always an estimate. Gyro drift is the central fact: integrating a constant bias of, say, 0.05°/s with no correction gives 3° of heading error in a minute. Bias and bias instability (how the bias wanders over time and temperature), vibration sensitivity (a gyro mounted on a vibrating chassis reads the vibration as rotation unless mechanically filtered), and axis/frame alignment (sensor axes versus body axes versus world frames) are the failure modes interviewers probe.

Filtering exists because the two sources have complementary error characters: the gyro is good short-term but drifts long-term; the accelerometer's gravity reference is good long-term but noisy short-term and useless during sustained acceleration. A complementary filter blends them with a fixed crossover — cheap, tunable by hand, adequate for many robots. A Kalman filter does the same blending with an explicit noise model and produces a covariance along with the estimate — worth it when the noise model is known and the covariance is consumed downstream. The weak answer treats a Kalman filter as "a better filter"; the strong answer says what it models and what it costs.

Analog acquisition chain

Analog acquisition needs a signal and error budget. Match sensor output to ADC input range, source impedance, reference, common-mode and protection limits. Use amplification, level shift, filtering, shielding, grounding, and isolation where needed. Sample fast enough for the signal bandwidth and apply an analog anti-alias filter before conversion; digital filtering cannot remove an out-of-band tone after it has aliased into the band of interest. This is a favorite follow-up — "can you fix aliasing in software?" — and the only correct answer is no, with the reason stated in terms of folded frequencies.

Filtering trades latency against smoothing, and interviewers like the trade-off stated with numbers: a heavier low-pass filter costs group delay on every step change, which in a control loop costs phase margin. Grounding and shielding questions — where does the shield terminate, why does the analog ground meet the digital ground at one point — separate people who have debugged real boards from people who have read about them.

Quantization maps a continuous input to discrete codes. Estimate ideal LSB size, quantization noise, effective number of bits, offset, gain, integral and differential nonlinearity, reference tolerance, thermal and flicker noise, and clock jitter when relevant. Oversampling can improve noise-limited resolution only under appropriate noise and bandwidth assumptions; it cannot repair clipping, systematic calibration error, or aliasing.

Calibration

Calibration connects codes to physical truth. Use traceable references appropriate to risk, record device, method, coefficients, date, conditions, uncertainty, and validity, and apply offset, gain, linearization, and temperature compensation in a controlled version. Validate at independent points and across the operating envelope. Detect drift and stuck or implausible values in operation. A successful factory calibration does not guarantee field accuracy forever.

The probe here is usually a scenario: "units drift 5% over a year in the field — walk me through what you do." The weak answer is "recalibrate more often"; the strong answer asks what the reference is in the field, whether the drift is temperature-driven, and whether the product can self-check against a known condition.

Digital interfaces

Digital interfaces have electrical and protocol contracts. I2C uses open-drain lines with pull-ups; bus capacitance and pull-up choice affect rise time, while addressing, clock stretching, arbitration, and stuck-low recovery affect software. SPI uses separate clock and data with chip select, requiring agreement on mode, bit order, timing, voltage, and ownership. UART is asynchronous and depends on baud, framing, levels, and clock tolerance. CRC or sequence checks may be needed beyond what a bus provides.

A classic follow-up: "the I2C bus hangs after a slave is reset mid-transaction — why, and how do you recover?" The answer is a slave holding SDA low waiting for the rest of its byte, recovered by clocking out pulses until the line releases or by toggling the bus. If you have never heard of this, say so and reason from the open-drain electrical layer — that reasoning is what is being scored.

Discrete inputs

Discrete inputs can float, bounce, or pick up transients. Use pull resistors, threshold and hysteresis, hardware protection, and time-based debounce appropriate to the physical switch. Debounce should not hide a real fast safety signal. Treat wiring open, short, stuck, and disconnected conditions as explicit states when consequence matters.

Actuation and power

Microcontroller pins cannot usually power actuators directly. Choose a transistor, MOSFET, H-bridge, relay, or dedicated driver for voltage, current, inrush, switching loss, thermal load, isolation, and failure behavior. Inductive loads require flyback or controlled energy paths. Motors need stall-current and mechanical-load analysis. PWM controls average delivered energy but is not a true analog voltage without filtering and load assumptions.

The follow-up that catches people: "your MOSFET fails — what does the load do?" A design where a shorted driver means the heater is permanently on is a different product from one where it means permanently off, and the answer must come from the hazard analysis, not from the component.

Closed-loop control and fusion

Closed-loop control measures output and adjusts actuation; open-loop control assumes the commanded input produces the intended result. Feedback improves disturbance rejection but adds stability, latency, saturation, sensor-failure, and tuning concerns. Define actuator limits, rate limits, deadband, anti-windup, watchdogs, and what happens when feedback becomes invalid. Never use a diagnostic software value as the sole independent safety interlock.

Sensor fusion and timestamping decide whether several correct sensors add up to a correct picture. Each device has its own sample instant, its own conversion delay, and its own transport delay to the processor, and none of those is the moment the reading arrives in the application. Stamp at the earliest point that is honest — a capture interrupt or a device-side timestamp — rather than at the read call, and carry the uncertainty of that stamp alongside it. The consequences scale with motion: a platform travelling at two metres per second turns ten milliseconds of unaccounted latency into two centimetres of position error, which no amount of downstream filtering recovers because the error is systematic rather than noise. When rates differ, resample deliberately to a common time base instead of pairing whatever samples happen to be newest; the newest reading from each of two sensors can easily describe two different instants, and the fused result then describes a moment that never occurred.

Failure detection and safe state

Failure detection has to be designed into the measurement rather than inferred from it, because the most dangerous sensor faults produce perfectly plausible numbers. A thermocouple that has come loose reads ambient, a pressure transducer that has lost excitation reads a clean mid-scale code, and a stuck ADC channel repeats its last value indefinitely — all three look like healthy data to a range check. Useful diagnostics come from placing the operating band inside the sensing band so that open circuit and short circuit fall outside it and are distinguishable from any real value; from checking rate of change against what the physics permits; from watching for a signal that is implausibly quiet, since real measurements carry noise and a variance that collapses to zero is usually a dead channel rather than a good one; and from cross-checking against an independent measurement where the consequence justifies the second device. Decide in advance what the control layer does when a channel is declared bad — hold, fall back to a model, or transition to the safe state — and make that decision explicit rather than letting a stale value continue to circulate.

Fail-safe behavior follows hazard analysis. Identify the safe state, but recognize that de-energized is not always safe — brakes and cooling may require energy to be safe. Separate normal control from independent protective functions where risk demands it. Use guarding, interlocks, emergency stop, redundancy, diagnostics, and proof tests according to applicable safety practice. Security changes must not disable safety, while safety fallback must not create unrestricted remote control.

This is the layer where senior candidates are separated from mid-level ones. The weak answer to "how do you know your sensor is telling the truth?" is a range check; the strong answer names the faults a range check misses and the structural defenses that catch them.

Testing

Test across normal, boundary, transient, degraded, and fault conditions. Inject sensor open/short/stuck/noise/drift, bus timeout and corruption, reference and supply variation, reset and brownout, actuator stall/open/short, thermal stress, mechanical obstruction, feedback reversal, timing jitter, and communications loss. Record physical input, raw code, calibrated value, command, driver state, feedback, faults, firmware/configuration, and timestamps. Measure end-to-end accuracy, latency, availability, nuisance trip, missed fault, energy, thermal margin, calibration drift, and safe-state transition time.