All jobs / Embedded / hardware

Communication Protocols interview questions

Communication Protocols questions a Embedded / hardware can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. You see no UART data on the PC. Fastest split?

    The strongest answer: Loopback on the board, known baud, and a scope on TX — I do not rewrite the protocol first

    Why it works: Exactly. Does TX wiggle at the right rate? Loopback splits board vs PC.

    • Loopback + known baud + scope TX.
    • Do not start at 921600.
    • Do not invert all pins at once.
    • Split board vs host.

  2. A PC tool shows your uint32 as nonsense. First protocol question?

    The strongest answer: Endianness and packing — I write the on-wire order down, I do not cast a struct onto the UART and hope

    Why it works: Exactly. On-wire is a contract. Hope-casts and double-sends are how you debug for a week.

    • Document on-wire endian and packing.
    • Do not overlay a struct on the wire.
    • Do not send twice as a spec.
    • Pick a contract that fits the link.

  3. You accept UART frames with no check. What do you add before features?

    The strongest answer: A length and a CRC (or equivalent) and a reject path — I do not trust a noisy line because the demo was pretty

    Why it works: Exactly. Detect trash. Friendly ACKs on garbage teach the other side to send more trash.

    • Length + CRC + reject.
    • Demos do not bless a bare line.
    • Do not mask UART errors.
    • Do not ACK garbage.

  4. Three SPI devices share one bus. What does chip select do, and what else has to match per device?

    The strongest answer: Chip select picks which device listens and drives the shared data line; each device also has its own clock polarity, phase and maximum speed, so I reconfigure the controller between devices

    Why it works: Right — the classic bring-up bug is a shared bus left on the previous device’s clock polarity and phase.

    • Select one device; match its settings.
    • One chip select per device.
    • Mode and clock are per device.
    • Reconfigure the controller between transfers.

  5. On an embedded Ethernet board, name the pieces between your firmware and the cable.

    The strongest answer: The MAC in the MCU drives a PHY chip over MII or RMII, the PHY feeds the magnetics and the jack, and a management bus reports link state and speed; the IP stack sits above the MAC

    Why it works: Right — that split is why “link up but no address” and “no link at all” are two different investigations.

    • Link, addressing and stack are separate layers.
    • MAC inside the MCU, PHY outside it.
    • Magnetics and jack finish the path.
    • Read link and speed from the PHY.

  6. Your USB device plugs in and the PC shows nothing. Walk me through enumeration so we know where to look.

    The strongest answer: The device signals attach with a data-line pull-up, the host resets the port, reads the device descriptor, assigns an address, reads the configuration descriptors, then binds a driver by class or by the IDs

    Why it works: Exactly — enumeration is host-driven and ordered, so you can say whether you died at attach, at the descriptor, or at the driver.

    • Enumeration is host-driven and stepwise.
    • Attach is electrical: a data-line pull-up.
    • Host resets, reads descriptors, assigns an address.
    • The driver binds on class or IDs.

  7. I2C hangs after a NACK. What do you design for?

    The strongest answer: Timeouts, a bus-recover clocking of SCL, and not leaving SDA owned — I do not reset the MCU as step one every time

    Why it works: Exactly. Stuck buses are normal. MCU reset is a sledgehammer. Faster is not recover.

    • Timeout + SCL recover.
    • Do not MCU-reset as step one.
    • Do not ignore NACKs.
    • Bit-bang still needs a timeout.

  8. A device publishes telemetry and a status over MQTT. Which QoS do you choose, and what is the last will for?

    The strongest answer: Telemetry rides QoS 0 where losing a sample is fine; what must arrive goes QoS 1 with an idempotent consumer. The last will is the offline message the broker publishes when we drop without disconnecting

    Why it works: Right — QoS is a per-topic choice, and the will exists precisely because a dead device cannot announce itself.

    • Pick QoS per topic, not per product.
    • QoS 0 where a lost sample is fine.
    • QoS 1 plus an idempotent consumer.
    • The last will announces the drop you cannot.

  9. A BLE sensor has to answer a phone quickly and still live a long time on a small battery.

    What do you tune, and who decides?

    The strongest answer: Connection interval and peripheral latency trade responsiveness against radio time; the peripheral only requests them and the central decides, so I design for what phones actually grant

    Why it works: Right — and check the supervision timeout still covers the interval and latency you chose, or the link drops.

    • Interval and latency buy power or speed.
    • The peripheral requests; the central decides.
    • Measure the parameters you were granted.
    • Keep supervision timeout above the latency.

  10. A CAN node on a test rig goes quiet after a few seconds, and the controller reports bus-off.

    What does bus-off mean, and what do you check?

    The strongest answer: Its transmit error counter passed the limit, so the controller took itself off the bus. I check the bit rate on every node, termination at both ends, and whether anything is there to acknowledge frames

    Why it works: Exactly — bus-off is a symptom. A node alone on a bus never gets an acknowledge and will error its way off.

    • Bus-off is an error-counter verdict.
    • Check the bit rate on every node.
    • Check 120-ohm termination at both ends.
    • Confirm another node is acknowledging.

  11. A consumer device has to join the customer’s Wi-Fi, and the first prototype has the office network name and password compiled into the build.

    What do you require before this ships?

    The strongest answer: Credentials come from the customer during setup through a provisioning flow, are stored per device in protected flash, and can be changed or cleared without a firmware update — factory reset included

    Why it works: Exactly — per device, changeable, erasable on reset. Baked-in credentials are one teardown away from every unit.

    • Credentials belong to the customer, not the build.
    • Provision at setup, per device.
    • Store them protected, never in the image.
    • Make factory reset clear them completely.