Skip to content
Tech Interview Prep home
Technical interview guide

Control Systems & PID

The feedback loop that keeps a robot at a target state — proportional, integral, and derivative control, and why all three matter.

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

Scope: Current MathWorks, NI, Rockwell Automation, Arduino PID, python-control, SciPy, NIST SP 800-82 Rev. 3, IEC functional-safety, and OSHA guidance reviewed 2026-09-04.

Overview

Curated: · Written: · Reviewed:

Tune the complete feedback loop, not three gains in isolation

Interviewers who ask control-systems questions at senior level are usually probing one thing: do you know that PID is a loop, not three constants? Candidates who can recite the three actions but cannot say what happens at actuator saturation, or why a setpoint step produces a derivative spike, read as juniors with better vocabulary. This guide is built around the decisions the questions actually test.

The three terms are three separate judgements

A control system drives a process toward desired behavior. In open loop, the command does not depend on measured output; in closed loop, feedback compares a setpoint with measurement and adjusts the actuator. Feedback rejects disturbances and model error — poorly designed, it oscillates, amplifies noise, saturates actuators, or creates unsafe motion. PID is common because proportional, integral, and derivative actions cover many practical plants, not because three gains automatically solve every process.

Each term earns its place against a specific failure, and each has its own signature when pushed too far:

  • Proportional acts on current error. It gives the loop responsiveness, but P alone leaves a steady-state offset whenever a sustained effort is needed to hold the plant at setpoint — a level against gravity, a position against friction, a temperature against ambient loss. Raising P shrinks the offset but never fully removes it, and past the stability margin the loop starts oscillating. If a candidate says "P removes error," that is the weak answer; it reduces it, monotonically in gain, until it doesn't.
  • Integral accumulates error and drives persistent offset to zero — that is its entire job. The cost: added phase lag (slower, more oscillatory response) and windup when the actuator saturates, because the integrator keeps accumulating error it cannot act on. Overshoot after a large setpoint step that then takes forever to settle is the classic "too much I" signature.
  • Derivative acts on error rate and adds damping — it lets you run higher P without the overshoot. Its cost is noise: differentiation amplifies high-frequency measurement variation, so an unfiltered D on a noisy sensor turns the actuator output into hash, and sample jitter directly contaminates the term.

A common weak answer pattern is treating the three gains as a single knob that trades speed against stability. Interviewers probe this by asking "which term would you change if the loop overshoots?" The defensible answer names the measurement that decides it: overshoot after a big step with slow settling points at I, oscillation at moderate setpoint points at too much P or too little D, actuator buzzing on a noisy sensor points at D.

Windup, kick, and the other classic failure modes

Integral windup and anti-windup

Windup appears exactly when the actuator saturates: the plant cannot follow, error persists, the integrator accumulates a huge correction, and when the setpoint becomes reachable the output stays pinned past saturation until the accumulated error unwinds through the opposite sign. The result is massive overshoot long after the saturation event itself is over.

The fixes interviewers expect you to name:

  • Clamping / conditional integration: stop integrating (or integrate only in the unwinding direction) while the output is saturated.
  • Back-calculation: feed the difference between the unlimited and limited output back to the integrator, which unwinds it at a rate proportional to how badly it was saturating.

Clamping is simpler; back-calculation recovers faster and handles rate-limited actuators better, where the effective saturation depends on output history. Whichever you pick, saying "we clamp the integral" without saying when and in which direction is the incomplete version of this answer.

Derivative kick and its fixes

A step change in setpoint is a near-infinite error rate, so derivative-on-error produces a spike in output — the derivative kick — that can slam the actuator. Two standard fixes, best used together:

  • Apply D to the measurement rather than the error. Measurement rarely steps, so the term stays smooth; the loop loses derivative action on setpoint changes, which is usually fine since you wanted a soft setpoint response anyway.
  • Low-pass filter the derivative (typically a first-order filter with the filter time related to the derivative time). The filter coefficient belongs in the tuning record: a filtered derivative at N times the derivative time bounds noise gain at roughly N, and leaving N unstated makes two "identical" tunings behave differently on the same plant.

The rest of the loop is part of the tuning

Feedback sign is fundamental and interviewers love it as a follow-up: verify that a positive deviation produces an actuator change that drives the process back toward setpoint. A reversed sensor, actuator, or configuration creates positive feedback and rapid runaway — test sign and actuator direction at low energy before automatic mode, and keep independent limits and protective functions active during commissioning.

Sampling and computation are in the loop. Choose a fixed or measured interval fast enough relative to closed-loop bandwidth and plant dynamics, with anti-alias filtering and bounded jitter. Scale integral and derivative by elapsed time correctly — a controller tuned at one period changes behavior if the code runs twice as fast. Detect missed deadlines and stale measurements; do not repeatedly integrate the same sample as if it were new.

Actuator constraints are unavoidable. Limit output and rate from physical, thermal, and safety requirements, and coordinate software limits with actual driver limits — a software range wider than the actuator hides saturation. Test prolonged saturation, reversal, recovery, and unreachable setpoints.

Mode transitions need bumpless transfer. Manual, automatic, cascade, override, and fallback modes should initialize controller state so the output does not jump: track the actual manual or downstream output and align integral state before taking control. Make setpoint ownership explicit and reject stale remote commands.

Setpoint response and disturbance rejection are different goals

This is the trade-off interviewers probe with "how do you reduce overshoot without slowing down the loop's response to load changes?" The one-loop PID couples both responses to the same gains; the standard answers:

  • Setpoint ramping or prefilters soften the command so the loop never sees a step — overshoot drops without touching the feedback gains, so load-disturbance rejection is unchanged.
  • Two-degree-of-freedom weighting applies the proportional and derivative actions to a weighted blend of setpoint and measurement.
  • Feedforward uses a measured disturbance or a command model to act before error develops; feedback remains necessary for model mismatch.
  • Cascade control rejects inner-loop disturbances faster, when the inner loop is substantially quicker and well tuned — tune inner loops first.

The weak answer is "reduce the gain": that also slows disturbance recovery. Naming the decoupling is what passes.

Tuning as a procedure, not a guess

An interviewer who asks "walk me through how you'd actually tune this" is testing whether you have a procedure. The defensible one:

  1. Characterize the plant first. Identify step or frequency response within safe operating limits; account for dead time and nonlinear regions. A tune optimized for a clean simulation may fail with dead time, saturation, friction, or wrong sensor polarity. Before any of it: closed-loop sign check at low gain.
  2. Start with P alone. Increase until you get a fast response with acceptable (non-oscillatory) decay, and note the residual offset. This tells you how much integral you actually need.
  3. Add I to remove the offset, sized from the observed settling behavior. Add anti-windup at the same time — you need it whenever the actuator can saturate.
  4. Add D for damping if overshoot or oscillation persists, with the derivative filter chosen against sensor noise. On a very noisy sensor, skip D and accept lower P instead.
  5. Validate across operating points — load, setpoint, disturbance, noise, delay, and parameter uncertainty. What you measured, in the terms interviewers will ask about: rise time (setpoint to first crossing), overshoot (peak past setpoint), settling time (into and staying within a stated band), steady-state error (residual after settling).

Ziegler-Nichols (find the ultimate gain at which the loop sustains oscillation, then apply the classic gain table) or relay autotune (force a limit cycle with a relay and measure it) give starting points, not final tunings — the Ziegler-Nichols result is deliberately aggressive, typically overshooting more than most applications tolerate, so expect to back off P and I. If you mention autotuning, say that it is an experiment that can move equipment: gate it by state, limits, supervision, and rollback. A candidate who presents a tuning table as the end of the process has answered a different question than the one asked.

Implementation form, units, and the factor-of-sixty bug

The implementation decides what a gain change costs at runtime. The positional form computes output from the accumulated integral each cycle, so retuning the integral gain rescales history accumulated under the old gain and steps the output. The velocity (incremental) form computes a change in output from differences and holds the previous output as state, so a gain change affects only new error and transfers bumplessly — at the price of explicit limit handling, since the absolute output is no longer recomputed from scratch.

Write the units down. An integral term expressed as gain-per-second behaves differently from one expressed as reset time in minutes, and mixing the two conventions between a tuning table and the firmware is a common source of a loop that is a factor of sixty off. This is the kind of war story that lands well when you can say where you caught it.

When PID is the wrong structure

Dead time decides this. Compare apparent dead time to the dominant time constant: below roughly a fifth, a well-tuned PID handles the loop comfortably; approaching one, achievable bandwidth collapses because every correction arrives after the plant has already moved, and pushing gain to compensate buys oscillation rather than speed. At that point the honest answers are a Smith predictor or model-predictive control with an explicit delay model, or reducing the delay itself — moving the sensor, raising the sample rate, removing transport lag. Measure the delay rather than inferring it from the tune: a network hop, a filter, and a slow analog front end all present as dead time, and only one of them is cheap to remove.

Beyond dead time: multiple interacting inputs and hard constraints push toward multivariable or model-predictive control; large nonlinear changes need gain scheduling (defined regions, bumpless interpolation — not abrupt untested gain swaps); discrete sequencing needs a state machine, not a controller.

Control and safety are separate layers

Normal software limits are not automatically safety functions. Where consequence requires independence, hazard analysis determines interlocks, trips, guards, emergency stops, redundancy, diagnostics, and safe state; the protective layer must not depend on the controller that can fail. Cyber commands must be authenticated, authorized, fresh, bounded, and subordinate to local protection.

Record setpoint, measurement, error, P/I/D components, output before and after limits, mode, gains/version, timing, saturation, quality, interlocks, and faults. Measure tracking and disturbance error, overshoot, settling, saturation and rate-limit time, missed deadlines, mode bumps, nuisance trips, and safe transition time. "What would you log?" is a frequent follow-up, and this list is the answer.

What interviewers probe, and what weak answers sound like

Rounded into one place, the probes you should expect, each covered above:

  • "Why does the loop overshoot after a big setpoint change?" — windup, or too much I. Weak answer: "too much gain" without separating the terms.
  • "The actuator chatters at steady state." — derivative amplifying sensor noise. Weak answer: lowering gains instead of filtering D or applying it to measurement.
  • "Setpoint changes slam the valve." — derivative kick. The fix is structural, not a smaller gain.
  • "How do you reduce overshoot without slowing load response?" — 2-DOF, prefilter, feedforward. Weak answer: reduce the gain.
  • "What happens when the actuator saturates?" — windup mechanism plus a named anti-windup scheme. Weak answer: "we limit the output" with nothing about the integrator.
  • "When is PID not enough?" — dead time ratio, interactions, constraints, nonlinearity, with the successor structure named.

If you can answer each of those with the mechanism, the measurement that identifies it, and the standard fix, you have the loop — not just the gains.