The Start
Setting the stage for when I was a wee-little first year starting out at Waterloo Engineering - I had just found out that the type of code I liked writing wasn't front-end, or back-end, ML, AI, Data Science, or any of the tons of other categories. It was something else, embedded software - where code meets the real world.
Then began the co-op search (for those unfamiliar, Waterloo Engineering has a mandatory co-op program that interleaves internship with schools) for my first firmware position. I applied like crazy, and just as the winter holidays begun, there it showed up in my inbox: we'd like to schedule an interview with you for our embedded software intern position. I was estatic! My first engineering internship interview, and that too for embedded software. Then, the nerves hit; interviews I had done before, sure, but few technical interviews, and never any embedded ones. Google revealed a lot of good questions, but the truth is, I didn't know where to start. I did a bit of leetcode and prepped to talk about my projects and to spare the details, it didn't go well.
Looking back, I wish I had a guide on what to expect in an embedded interview, rather than a spam of questions which felt half-relevant. This blog is a letter to first-year me on how to prep for those first few interviews and comfort those getting started with embedded internships.
So... what's different about it from a software interview?
This comes down to the definition of embedded software itself. While debatable, it generally includes (in some way) 'software to control purpose-built hardware.' In my opinion, embedded software requires a lot of care about the system, which calls for a much more unique variety of questions. As a result, it's quite uncommon to be pulled with a leetcode question (as in a regurgitate-an-O(N)-solution) or be asked about abstract graph theory. Embedded interviews, in my experience, focus much more on applying software to embedded systems rather than simply writing software.
Embedded Coding Challenges
Embedded Software, is after all, still software. However, unlike leetcode, the embedded coding challenges that I've encountered are much more about C and C++ proficiency and writing software or pseudocode in response to an actual problem, compared to trying to return a sorted list while optimizing for time and space complexity. Examples of problems you may be expected to code solutions to include:
Write code to initialize a driver peripheral given a register map
Write code to turn a timer with a 32 bit timer into a 64 bit timer
Write a debouncing algorithm for a button
Write code to manipulate raw memory locations and bits
Write code to print out code using printf within an ISR. Assume that an RTOS is available
As a warm-up, I'd recommend doing a few math-based leetcode easy's in C and C++ to get comfortable with the language and pointer manipulation. However, a lot of online leetcode problems will focus on algorithms and sorting, which is typically not asked in an embedded interview.
The DS & A (data structures and algorithms) I have found to be the most relevant so far in embedded is: stacks, queues, binary trees (heap and regular), and linked lists. Certainly not an exhaustive list, and a touch biased to the type of embedded I do, but I'd be surprised if another type of data structure was relevant in the context of an embedded intern interview.
The theory you need to know
As an embedded intern, you will be roughly expected to know the following broad categories of theory. Depending on the role, you're probably going to find an emphasis on a few of these areas compared to the others (I would be surprised to hear an interviewee for an embedded Linux position be grilled about RTOS's and electrical intimacies).
General Software Engineering
An embedded software engineer must know how to code well and apply generalist software skills. Mostly, you can expect C (and C++) trivia (ex: what does the keyword volatile mean?) and softball questions designed to gauge the extent to which you understand the code you write (an excellent basic question is what the purpose of header guards are). If applicable, Linux kernel development will also fall into here as well.
General Electrical Engineering
Another key trait of an embedded engineer is to write code that runs on physical hardware, which, at the bare minimum, requires basic EE knowledge. However, it's possible to get quizzed intensely on EE if the role requires a decent knowledge of electrical systems. At minimum, you should be able to describe key lab equipment you've used to debug and how they work from a high level. A popular question is asking a candidate how they would debug 'X' and probe you (pun intended) on your tooling knowledge, such as how to use an oscilloscope and setting up a trigger appropriately.
Communication within an Embedded System
Many embedded producs and distributed systems feature communication between separate IC's and microcontrollers - for this reason, it's common for candidates to be quizzed on their knowledge of common protocols. I2C, SPI, and UART are the bread and butter of protocols that most embedded engineers use fairly frequently, and it's almost cliche to be asked about one of these 3 in an interview. Candidates can expect protocol design questions in addition to comparing and contrasting protocols they are familiar with.
Real-Time Operating Systems (RTOS)
An RTOS is a common piece of software that is commonly used in embedded systems where concurrent execution and/or strict timing deadlines are required. If the role requires you to know about RTOS's (usually identified in the job description), be ready to answer questions on synchronization and inter-thread communication (semaphores, mutexes, event flags, queues) and how software design within an RTOS works.
Design it all
The last type of common question is an open-ended "how would you design X" question. This is an interviewer's chance to see how you think and implement a design as well as drill down on your technical skills. In my opinion, the best way to prep for this kind of interview is to look around and ask yourself "how would I implement this?". The approach I follow for these questions is as follows:
Pull up onenote and screen share (or MS paint)
Clarify the requirements
Architect a solution that solely meets the requirements (Keep it simple, stupid!)
How to architect a solution is beyond the scope of this blog, but the exercise above of simply asking yourself how embedded systems are implemented in real life is an excellent way to think and learn about system design as a whole.
Conclusion
An embedded software intern interview is not rocket science, but it's unique from generic software interviews because the theory spans a lot wider range across multiple disciplines. The best way to get better at interviewing is to interview and see common trends in questions, as well as gain more experience that helps you answer these questions implicitly and from first principles rather than having it rotely memorized.
Comments