Interview questions for embedded engineers

This is an article about technical questions that can be asked in an interview for an embedded systems engineer that I have "standardized on" after doing multiple interviews. It does not cover other topics like how to do the initial screening, task assignments, soft skills, or "fantastic beasts, where to find them and how to retain them".

Interviews are difficult for a multitude of reasons:

• Stress - you are obviously stressed if you are looking for a new job (for whatever reason).
• Accent - everybody's accent is different. Personally, I need some time to get used to a new person's accent no matter how "standard" it is.
• Audio quality - you would think that it should be a solved problem in this century but it still happens that you can barely understand a thing, the audio drops or chops, there is feedback, echos, low volume, roadworks etc.
• Limited time - It is a sad joke that we think you can judge in less than an hour how a person will possibly perform in the months/years to come, and in projects that are not even known yet (and you may be hiring people to do work that you do not know how to do yourself).

When interviewing I am also concerned with two potential "errors":

• False positives - someone that pretends to know something but will not be able to deliver
• False negatives - someone that can deliver but is bad at self-marketing

Embedded systems engineering is a somewhat strange name in itself as it can cover everything from making electric toothbrushes to making missiles, from software development to high-voltage safety, from designing algorithms to getting dirty on the production floor. No engineer can cover every possible aspect so (at least for my work) I try to look for people that can adapt, can learn things they don't know, know how to find information, and can troubleshoot.

Question ideas

Generic

I think that the questions should be generic in some way. Imagine someone with 5 years of motor control experience using C2000 while you are looking for someone to work with signal procession and Bluetooth on Cortex-M. Or the other way around.

First, is that experience entirely worthless? I would say that it is still somewhat relevant. Unless you are looking for a drop-in replacement to add to your already late project (to make it even later) you have to find common ground with somebody that may have worked on totally different kind of projects than you. I can speak from my own experience that there always a learning curve in every new application or technology no matter how much experience you have. On the other hand once you have used five different MCUs learning the sixth one is pretty easy.

Second, everybody in our business has to maintain confidentiality so I would not expect talking about why choice FOO was a total disaster for project BAZ made by company XYZ, or how did your company spend $100k on your education (without planning for it).

Open-ended

A lot of embedded design problems that we deal with do not have a single obviously correct solution (but have plenty of obviously incorrect ones) so it is great when a candidate can come up with more than one and discuss the various tradeoffs.

Still relevant in the future

Progress and obsolescence in electronics is part of the profession so I try to keep the questions still relevant in the future. I do not know what will be the dominant ISA or the smallest transistor in year 2050 but I am absolutely sure that UARTs & multimeters will still be around.

Easy to answer...

...if you know what you have been doing during all the years you claim on the resume. This prevents the false negatives mentioned at the beginning and allows an immediate answer without too much stressful thinking. I am totally not interested in things that can be easily found in documentation.

This in turn makes the questions somewhat...

Google-proof and ChatGPT-proof

It will become harder and harder to screen candidates in the era of instant access to all possible knowledge. I wonder if interviews of the future will become some kind of Turing tests in response to faster and better quality AI. Just imagine: "keep your hands in the air and visible at all times" interview. Only to be countered by voice-recognition AI that will give you instant answers or auto-deep-fakes. What a time to be alive...

That is also why I avoid providing ready answers here so they are not scraped from this article.

Self-censorship against the AI. Sounds like a good title for a philosophical dissertation, does it?

The questions

How to debug a UART?

The candidate should probably ask for more details so the full question could be: "You have a board with an MCU and an FTDI chip. You can't see any data in the terminal. What do you do?".

This is a nice question because solving a seemingly easy issue needs a multi-step approach and every embedded developer must have used a UART at least once.

A lot of things can go wrong so I would expect an answer with a list of things to check like the clocking, pin muxing, probing with a scope, trying a different board etc. Of course the amount of steps and things to check will depend on candidate's experience. An experienced candidate will come up with many things to check. The more, the better.

You can also substitute UART with any "simple" peripheral like SPI, I2C, GPIO etc.

How to check an ADC (and the signal chain)?

Another generic and intentionally vague question. ADCs and signal chains come in different shapes and sizes so it could be narrowed down to "You have a voltage divider connected to the ADC of an MCU to measure the input supply voltage. How do you check that it works?". You can ask about the MCU that the candidate is already familiar with. If the candidate is more experienced you can extend the question with an analog front end or ask how to get a transfer function of the whole chain.

A standard response can feature measuring the voltage with another instrument, checking that the ADC reading is stable etc. Bonus points if the candidate ever mentions "offset", "gain", "linearity". Further question could be "The ADC reading is not what you expect" or "The readings jump around. What do you do?".

Another variant: do the same but for some AC signal.

How would you look for help?

Everyone got deeply stuck at least once (ah... Atmel USB RAMs 🥰) where no amount of shotgun debugging helps. An obvious answer could include asking a colleague for help, checking the datasheet, asking on forums (ask which) etc.

Which chips have you used?

Another question that everyone can relate to. I do not expect to get the exact 16-character part numbers (with package and temperature variant) but something along the lines of: SPI flash, I2C expanders, ESP32, level shifters etc. This can be followed up by a question what the particular chip was doing in the application the candidate worked on.

How to select an MCU?

If I were asked this question I would immediately try to narrow down what the intended application. The candidate should present more ways to clarify the requirements beyond the CPU clock + flash size + RAM size trio. It makes sense to ask for further details of whichever category the candidate comes up with.

Compare something to something

This question may be vulnerable to AI especially when asking the "classic" SPI-vs-I2C but it may work for less popular combinations. For example: "How different is working with MCU GPIO compared to a GPIO expander?".

This question works for totally everything the candidate is familiar with, Ethernet-vs-Zigbee, AVR-vs-MSP430, AC-vs-DC power, Matlab-vs-Python, automotive-vs-medical etc. It should be pretty easy to answer when the resume matches candidate's actual experience.

How to prevent a brick loop (or other damage)

There is code that can potentially brick (if it is ever flashed and automatically started) or even damage the device. I mean things like: changing the clocks, pin muxing, PMIC settings. Off-the-shelf MCUs usually can be recovered "under reset" but ASICs often come with less failsafes so you have to be careful when all your team has are only 5 engineering samples...

Design a peripheral driver for X

This question is basically about making a minimal API that allows to use a certain peripheral. It can be a UART, Ethernet controller, or an I2C GPIO expander. The answers do not have to be as specific as an exact list of C function prototypes. This is a particularly good question because it requires the candidate to design an abstraction.

Not all features and flags in a UART matter in every application so the driver can deliver an abstract simple UART. This also works the other way. Some driver may have to use more peripherals if the hardware is missing features (for example timeouts). You can add further questions about buffering, performance and various tradeoffs into the mix.

How to make sure that your code or device is not resetting itself?

This question is applicable to devices that are expected to run continuously (compared to, let's say, a remote control with a button that starts up from scratch every time and retains no state). Hints.

Alternatives:

• "What can make the code reset or the device reset, and how to distinguish these two?"
• "How can you detect a firmware crash?"

Design a manufacturing test for X

It can be something along the lines of "You have a board with 8 digital IO. How to test that soldering is okay?". Modify it with whatever feature you and the candidate are familiar with. There are many ways how something can be tested so you can also ask for the cheapest option, the quickest to develop, the fastest in the field, the least risky, the standards compliant etc.

How to test a peripheral?

Variant of the previous question but inside the chip. This question is relevant for people tasked with working on untested silicon. For example "How do you know that the ADC/DMA/SPI/whatever in this brand new chip actually works?".

Design something

You can pick something small that is an embedded system and is reasonably easy to grasp. Some examples: USB-C charger, "GPS tracker", Bluetooth remote control, home router. Of course if you have an exact project in mind then it is best to ask about the thing you need.

How do you protect against ESD?

A very generic question that can cover everything from device design (to withstand ESD) to safety in the lab, during installation or servicing, on engineer's own desk (to avoid ESD) etc.

Which lab equipment have you used? Which brands?

A trivial question for anybody that has spent any significant time debugging random boards. Bonus points for answering "Which brand is your favorite and why?" or an example of a situation where a particular instrument brand or feature became especially helpful.

A good craftsman knows his tools.

How would you debug a networked device or system?

You can pick any communication standard the candidate is familiar with (eg. RS-485, CAN, Zigbee) and ask how to debug a network of N devices, for example missed communication or wrong action executed by one of the nodes. Multiple J-Links and debugger windows quickly become unmanageable and it is next to impossible to debug things by haphazardly starting and stopping nodes (especially when network timeouts are involved).

This gets us nicely to the next question...

How to debug a system that can not be halted?

Some devices just can't be halted without breaking something or upsetting the larger system. For example: motor control, real-time DSP, USB, or many other communication protocols.

How can you debug an MCU without a debugger?

Sometimes the debugger connection itself upsets things and makes the original problem go away or hide. The debugger may also be simply unavailable and all the developer gets is a message from the customer saying that XYZ is sometimes wrong. After 20 days. Only when connected to a unique piece of machinery that won't even fit in the office. XYZ can be anything like a measured value, wrong reaction, unreliable communication, sluggish menu etc. This questions gives lots of freedom to come up with various schemes.

Give 5 examples of compiler warnings

This is the only question I would grade based on speed of reply. I think that any experienced developer should easily name at least 5 warnings in 15 seconds. If you can't it probably means that despite hitting "compile" tens of times per day you have been totally ignoring them (or have not enabled them to start with).

Bonus points for explaining what they mean and how to fix them.

Low power design techniques

There are many ways to get things done using as little energy as possible on the system/application level so I would focus on everything beyond just MCU sleep modes. Extra points for thinking about profiling.

How would you process a signal?

This question can be applicable if you are dealing with signal chains and a candidate with signal processing experience. Things to ask can be: how to select a sensor, how to connect to the sensor, what are the signal challenges, where the noise comes from, what part of the processing is best done in digital/analog, which DSP algorithms can be used etc.

Bonus question for amateur radio operators

The classic conversation starter: "Tell me about your station". 🙂