How Important is solving Data Structures related problems to get a job as Embedded Software Developer?

General Electronics
1

Hello everyone, I am in a dilemma of, if spending time on learning to solve Data Structures related coding problems worth it?

About me for context - I have worked in Mechanical Engineering domain for 2 years(and have a Mechatronics Degree) where I was involved in designing and prototyping mechanical parts. I have worked on couple of hobby Arduino projects and and did an edx course on Embedded Systems by UT Austin in which I learned working with a TI board with arm cortex M4 uC.

I have taken break from my work for past 2 months to transition my career into Embedded Software Development and have been learning and practicing C. I am in touch with a Senior Embedded Software Engineer who is mentoring me. He recommended to get good with C and learn about Data Structures, RTOS and ARM architecture then he can arrange my interview, he has been very kind to help me solve doubts if I am stuck somewhere.

I just wanted a third opinion on if I am on the right path or not, an Right Now I am having hard time by trying to learn about Binary Trees so thought to ask this question.

Thanks !

2

Hi, my degree is in computer science and I have good bit of experience doing embedded stuff and reverse engineering and the like.

The short answer is yes, you need to know how to implement a binary tree (including the red black variety) and a handful of other common data structures (linked lists, buffers of various types, hash tables, etc) because just about every company will ask you to do this as one of their interview questions. :sweat_smile:

Binary trees are not as common as buffers or linked lists, but you definitely see it pop up.

So in that respect, it’s not a waste of time.

Will you ever need to hand implement a binary tree? In my experience, rarely to never. But it also depends on how interesting of a project you’re working on.

The long answer is, in my opinion, an even stronger yes.

The subtlety here is that the point of learning all these data structures in and out by implementing them yourself isn’t actually about learning those data structures. You aren’t learning to create a binary tree from scratch to know how to, well, create one from scratch.

What you are learning is how things like pointers and memory management can be used to do some pretty clever things. You are learning how to think in the right mindset to solve the sorts of problems one is often tasked with in the embedded space.

If you are having difficulty with binary trees, then that should be your single strongest indicator that you do need to learn how to create them. Not for the binary tree itself necessarily, but because programming is often a series of “aha!” light bulb going off moments where some abstract concept clicks into place. And learning about these data structures is a great way to force these moments of understanding to occur.

It also makes it a bit frustrating, because often it will feel like you just can’t figure it out and you aren’t making any progress. I think this is something most people experience when learning this stuff for the first time. I would implore you to not give up and keep banging your head against the wall. It isn’t fun and there is no sense of getting close. But one day, possibly in the shower or when eating lunch or even possibly while writing code, your brain will suddenly just “get it”.

And after that, you’ll have a very different perspective and see binary trees as easy and trivial even if they seemed very difficult as recent as yesterday.

THAT is the real reason to learn these data structures and it is difficult to see the value in this until after you’ve already come to understand them.

But I’ll put it this way: if you have difficulty with these various “benchmark” data structures, even if only one or two, then that means you still have some learning to do. Each one of these “aha!” moments is analogous to gaining a new tool, albeit in the form of insight into how to program and solve problems in this space. You need to have all of these tools available and once you do, none of those data structures will be challenging to you anymore - they’ll just be understood and useful tools.

5 Likes
3

@metacollin said it well - it’s not about the specific algorithms that you learn/implement that matters, but what you learn in the process of implementing them during the course will be essential if you plan to go into embedded systems development. Through the process, you will start to think about the performance/scaling implications of the software you are writing. Especially on embedded systems, you need to be very aware of the resource/performance limitations that you’re going to hit if your product handles data.

1 Like
4

Thanks for the detailed explanation , I got this same feeling while learning about pointers and LinkedList but now I am pretty comfortable using them, hopefully I will be able to get the binary trees too.

Thanks Again for taking out time and answering my question!

5

Another resource you might want to consider:

I don’t test everything I write, but Grenning presents some useful methods for integrating tests that will help you understand the C programming language better. Testing – both at the function and application level – encourages good design. Structure your entire app so that it can be called in a test function if possible for end-to-end testing.

One of the most useful techniques I’ve learned over the years is to build embedded apps such that they can be easily run on your development computer for most of the development. This greatly speeds up development – especially for more complex networked devices, or devices that have complex storage requirements. As embedded systems become more powerful, the line between embedded and any other type of programming is becoming blurred.

Being very comfortable with Git is another important skill.

3 Likes
6

I’d definitely second this. My skill improvement with Git absolutely paralleled my improvement as a programmer (both embedded and non). Many of the best practices of Git generally make you a better programmer.

Unfortunately though, I feel like learning Git is something that can really only come from using it. As in, reading articles about working in branches and working in teams is helpful, but you don’t really grasp it until you’ve had to use it in depth.

1 Like
7

@metacollin Is right on the money with almost every point. His comment was both accurate and very nicely written.

FWIW, I studied mechanical, but software has been my calling, I guess. I consider myself a switch-hitter, with many projects having hardware, software and mechanical components - and it’s nice to be a contributor in each of those areas.

This year, I’m entering my 4th decade of doing this work. In that time, I have been interviewed any number of times and have hired a fair number of people myself. In all of those interviews, data structures were rarely mentioned, and even then, it was in passing. Basically, interviewer: “Can you implement a hash table?” me: “yeah”, interviewer: “OK”.

Some of those positions were very high-end, definitely pushing the envelope. So, I don’t think this laissez-faire attitude toward data structures was the result of mediocrity at all. And, while I could not agree more that it is _very important to have experience creating those things by hand - to help develop the basic skills and knowledge to be successful - I would personally see it as at least a “yellow flag” during an interview if there were too many questions on that topic. To me, it would signal that the manager/department/whatnot may be focusing on the wrong things on a broader scale. I have walked away from otherwise compelling offers for this very reason - interviewers demonstrating myopia.

Embedded development demands mastery of basic skills - no question. However, coding is actually a relatively small part of the overall process of software development. In a healthy organization/project - even if it’s a consultancy of 1 - a numerical majority of your time will be dedicated to making sure that you’re solving the right problem, testing it, communicating with co-workers (including integration), customers, managers and so forth. That might sound like bureaucracy, but it’s really the opposite: solving _a problem is one thing, solving the _right problem, well, is another entirely.

Bottom line, you will need to “do your homework”, so to speak. But, once you’ve done so and grokked the underlying concepts, I wouldn’t be overly concerned about the job part. You’ll be prepared.

P.S. I’m mildly envious of your position at this point. You’re about to enter a whole whirlwind of great exploration and I think you’re going to have a lot of fun wrapping your head around “the classics”. I don’t know how many people do this, but I kept a little journal during the earlier parts of my engineering journey. It’s nothing short of amazing to look back at it now and see how much I learned during that period.

4 Likes