200 Embedded and IoT Software Engineering Interview Questions – Part 7 Debugging Skills

So far in part-1 of this interview questions series, we saw about

  • Questions about yourself
  • Questions about the projects you have done and
  • Questions from C programming language

Then in part-2, we saw some questions about the Basics of electronics. In part-3 we same some questions about Microcontrollers and peripherals. Then in Part 4, we saw about operating systems and in the last part (part 5) we saw questions on Networking followed by Part 6 on Software Engineering and Design patterns.

You can find parts 1, 2, 3, 4, 5 and 6 in the links below.

200 Embedded and IoT Software Engineering Interview Questions – Part 1

200 Embedded and IoT Software Engineering Interview Questions – Part 2 Basics of Electronics

200 Embedded and IoT Software Engineering Interview Questions – Part 3 Microcontrollers

200 Embedded and IoT Software Engineering Interview Questions – Part 4 Operating Systems

200 Embedded and IoT Software Engineering Interview Questions – Part 5 Networking

200 Embedded and IoT Software Engineering Interview Questions – Part 6 Software Engineering & Design Patterns.

Now lets head onto the next part and in this part, we will look at some questions about Debugging which is a major part of embedded software development. More than half of our working time will be usually spent on debugging problems so it is essential to be efficient in this process. Hence a good knowledge and experience of debugging skills are absolutely essential for embedded system design.

As usual, I have divided the questions into 3 categories of easy medium and hard. So let’s begin!

Difficulty level: Easy

Question#1: List 3 most used tools in debugging process

Answer #1: They include

  • programmer/ debuggers, either JTAG or SWD
  • Oscilloscopes and
  • Logic analyzers

Other less commonly used ones are simulators, spectrum analyzers, sniffers, etc.

Question#2: What is the GNU tool used for debugging?

Answer #2: gdb a.k.a the GNU Debugger can be used for debugging programs written in C, C++ and several other languages for programs that either run natively or on a remote machine.

Question#3: Explain the terms intrusive and non-intrusive debugging

Answer#3: Intrusive debugging involves making changes to the source code in order to find the bugs. This can be simple LED states or printf statement or just running the code through a debugger which lets us set breakpoints and see the memory contents at runtime.

Non-intrusive debugging involves just monitoring the system at runtime without changing any code so that we can get the true behavior of the system. This is usually the case in real-time systems where adding debug objects will affect the timing of the system.

Question#4: What is the difference between step-in step-out and step-over buttons that you normally see in an IDE’s debugging environment?


  • step-in: Steps into the function of the highlighted line
  • step-out: Steps out of the present function and goes back to the calling function
  • step-over: just jumps to the next line

Question#5: What are breakpoints?

Answer#5: Breakpoints are used for stopping the execution of the code at certain points in our code. This can be useful while debugging to determine where the code actually breaks.

Question#6: Explain the general process of debugging

Answer#6: The following steps can be used to debug any issues

  • Identify the problem by reproducing the bug
  • Gather logs, recent changes, and other relevant information
  • Come up with some hypothesis of why the bug is happening
  • Test the hypothesis to confirm it
  • Once confirmed implement a bug fix
  • Test the solution
  • Do a regression test on the entire system
  • Deploy the bug fix to the end-users

Difficulty level: Medium

Question#1: Give an example scenario where an oscilloscope is more useful than a logic analyser

Answer#1: Logic analyzers sense the logic and hence it can only see either a zero or a one. If say you think the problem is in power circuits and you need to see the voltage signals along with their magnitude then oscilloscopes are more useful here.

Also if your application involves anything other and digital signal like a square wave, say, for example, sine wave audio-sensor signals then you need to use logic analyzers.

Question#2: Give an example scenario where logic analysers are more useful than oscilloscopes

Answer#2: Logic analyzers usually have more than 2 channels and hence can monitor multiple pins at a time. They are especially useful are debugging serial communications like UART, SPI, and I2C as they will not only show the waveform but also parse and show the outputs in numbers so that we can see what data is actually being sent through the pins.

Question#3: What are watchpoints?

Answer#3: Watchpoints are very similar to breakpoints, except instead of stopping the processor at the said points, we let it run but just refresh the variables that we have added to our watch list in our IDEs

Question#4: Explain the difference between debug and release builds that we normally see in IDEs.

Answer#4: Debug builds usually have some extra information needed by the debugger such as symbol tables so that it knows how to connect our source code to our executable.

Release builds, on the other hand, does not include this information as it will reduce the space needed and usually some optimizations are also added on release builds by the compiler since it is free to rearrange the code as there is no debugging needed.

Question#5: Explain Tracing

Answer#5: Tracing is a process using which we can get the footprint of our code as it walks through its journey. As the code runs, the tracing tool records information such as

  • in what order the functions are called in
  • how many processor cycles each function consume

This information is especially useful while debugging and the code crashes in random places.

Question#6: Explain the process of Profiling

Answer#6: Profiling is usually done as a precursor to speed optimizations. It is a process where a software looks at our code as it runs in the microcontroller to see what time duration each function takes to execute and how many times each function is called. Using this information, we can concentrate on the slower and more frequently called functions to see what can be done to optimize those functions.

Difficulty level: Hard

Question #1: Explain why printf statement are not a good idea for printing debug information. Give a better option to do it.

Answer #1: The printf statements can consume a lot of CPU times and hence can create some unnecessary overheads on the processing. Especially on the real-time systems, this type of debugging can lead to inaccurate timing, which can make the system to behave abnormally.

A better idea is to use simple GPIO pins which can be connected to some LEDs and they can be used to get some information about events happening in the system. Since setting and resetting an LED can take less than 1/100th the time as compared the time it would need for the processor to print a statement. Thus making the debugger less intrusive to the actual running code.

Question#2: Explain SWD

Answer#2: SWD stands for Serial Wire Debug. It’s a debugging protocol developed by ARM. Unlike JTAG, SWD is specifically used for debugging and it uses just 2 wires SWDCLK and SWDIO, thus reducing the board space needed to implement this. The support for this interface is usually limited to ARM microcontrollers.

Question#3: List some software tools that can be used to sniff network traffic

Answer#3: The below list has 3 such tools

  • Wireshark is a multiplatform GUI tool that can be used to sniff the traffic on a network.
  • tcpdump does a very similar job on the command line in Linux systems
  • port mirroring in routers can also be used to sniff network traffic and log them.

Question#4: Expand and explain ETBs

Answer#4: ETB stands for Embedded Trace Buffers. These are the data buffers on the microcontroller where this information is temporarily stored and can be retrieved from using the debuggers as the code runs.

Question#5: Explain the difference between a hardware and a software breakpoint

Answer#5: Hardware breakpoints are physical breakpoints that a debugger and microcontroller can handle. Here the code is regularly checked and if the Program Counter Register a.k.a the PC register reads the same value as the breakpoint instructions address, then the execution stops there for us to debug it further. Typically the debuggers can only support very few limited number of such breakpoints.

Software breakpoints are another type where instead of continuously seeing the PC register, a PAUSE instruction is placed at the points in code where the breakpoint is needed. Once the program hits one of these points, the program pauses till the continue button on the IDE is pressed.

Question#6: What are spectrum analyzers?

Answer#6: Spectrum analyzers are similar to oscilloscopes except for the fact that it used to get the frequency domain data (amplitude vs frequency), of the signals we are analyzing whereas oscilloscopes are used to see time domain information (amplitude vs time)

They are particularly useful in applications that involve radio where frequency domain data is valuable

Beyond these simple questions, you will probably be given a code and ask you to find a bug in it. As long as you have the required knowledge base needed, all you need to do is to follow the step by step debugging process that we saw in one of the questions above, I am sure you will find the bug and get a bug-fix for it.

Alright, that ends our journey of looking at 200 interview questions. A big congratulations for those of you who made it this far to the end of the 7th part..!! You are obviously motivated and hard-working and I am sure you are going to do great on your interview..!

I hope this preparation material is of some value to you guys.

All the very best for you!


We’re passionate about inventing embedded devices and we hope you are too! This blog deals with a wide variety of topics from C programming to IOT to networking certifications and more. Hope you enjoy your time spent here and hope you get some value out of our blog!

You may also like...