6 ms·

In a few months I'm going to be sniffing around for embedded software engineering positions (c on microcontrollers, DSP, maybe even some PCB or FPGA design). I

In a few months I'm going to be sniffing around for embedded software engineering positions (c on microcontrollers, DSP, maybe even some PCB or FPGA design). I'm still buying a copy of cracking the coding interview and doing leetcode in the weeks leading up to applying for precisely this reason. It's dumb but I'm not going to give up an otherwise promising opportunity in protest, although in the interview I might politely ask (after solving the problem) what relevance it has to the job, just to make the point. ("I thought I was a applying to do X, and this doesn't seem to fit the job description. Does the job involve a lot of work like this?")

zrobotics 7y ago
Although embedded is possibly one of the few software positions where these questions might be somewhat relevant- aside from embedded who is writing a sort by hand anymore; although even in embedded it isn't that common of a problem. I just find the questions especially egregious for an average software dev working on something like a web app, since in that case hand-coding something like a sorting algorithm or BST is almost always the wrong thing to do.
- scottLobster 7y ago
  Oh I completely agree, but like it or not such questions have become the unofficial Software Engineering SAT. Part of being an engineer is working with/around other peoples' bullshit. If the furthest that extends is a dumb interview question or two, that's a dream job. :)
- emilecantin 7y ago
  I'm a Web developer, and I did hand-code the Dijkstra path-finding algorithm recently. Granted, it's not common, and I didn't do it from memory, but at least I knew what to Google. I needed to represent the shortest path between nodes on a map, so I needed the internal data from the algorithm, thus the need to whip out my own version.
woodrowbarlow 7y ago
actually, i would think leetcode interview problems would be more relevant for embdedded development jobs. in embedded, you're less likely to have access to libraries that implement advanced data structures, sorting and searching, string manipulations, etc. so you'll need to do more of it by hand.
- scottLobster 7y ago
  To a point, but like most things in software my experience is you look up someone who's already figured it out and copy them :) Granted you have to understand the code a little more and be able to apply it to whatever system/hardware constraints you're working with. But just as higher level Software Engineers rarely have a need to implement recursion/graph traversal/etc, in embedded its even rarer due to the relative expense of such operations. I'd say knowledge of signal processing and how to power/performance/memory-optimize code would in general be much more valuable.
- maxxxxx 7y ago
  That’s my impression too. I would expect more handcrafted code on embedded systems and you need more awareness of computational complexity and memory needs.
  - devanl 7y ago
    It's not as important as you would expect for a couple of reasons: 1. The size of the data is often much smaller - the savings from using an nlogn time algorithm vs a n^2 algorithm are much smaller when n=10 versus n=10000. There's a good chance that the constant time setup will dominate for those smaller datasets. 2. To a certain extent, embedded systems don't need to be as fast as possible - they just need to be "good enough" to meet their deadlines so that the rest of the system functions as expected. It'd be nice to be able to compute 1000 CRCs per millisecond instead of only 10, but if it already takes 1 millisecond to transmit the CRC over the serial bus, it's not going to make the system substantially better at its job. So yes, there is a lot of handcrafted code, but quite often it's just implementing your standard naive brute-force algorithm with minimal code size, minimal memory overhead (preferably without dynamic allocation), and well-understood worst-case latency.
Isamu 7y ago
For embedded programming you are more likely to be asked questions that require bit manipulation, shifting, masking, etc. Maybe low-level C, mapping structs to memory locations, etc. Maybe how you might go about implementing hardware interrupt handlers, or how you could put a microcontroller into low-power sleep and then wake up, etc. It is common for embedded software engineers to come from electrical engineering, and they are maybe less likely to ask CS-type questions.
- scottLobster 7y ago
  Hopefully. But I've heard from people who got asked leetcode style stuff in addition to those kinds of questions because it was company policy for anyone interviewing to be a "software engineer". Best to be prepared.
- scarface74 7y ago
  I interviewed for a position (and got the job) about four years ago for a C#/Angular senior developer and I was suppose to be “speaking my architectural experience into the team”. At the time, the only way I could document 10+ years of development experience was by putting a job I had worked at for a decade doing cross platform C and C++ with a little bit of assembly. Out of nowhere, after I thought the interview was over, one guy kept drilling me on that type of low level stuff that had nothing to do with the job just to prove how smart he was. I remembered all of it thanks to a decade of dealing with it and too much time on comp.lang.c but it was still off putting. I’ve since cut all of that stuff off my resume.
  - umanwizard 7y ago
    I wasn't there, so I can't know how the interview went, but are you sure the motivation was "just to prove how smart he was" ? If I'm already 100% sure I'll recommend a hire, it's not rare for me to go off-script and dig into random stuff in the candidate's experience, first of all because I find it interesting or fun to talk about, and second because having deep knowledge about anything is positive signal, regardless of whether it's useful for the job. I have definitely been in this scenario and asked people who had relevant background to work out low-level performance details of their code. I hope they didn't think I was "drilling" them.
libria 7y ago
> although in the interview I might politely ask (after solving the problem) what relevance it has to the job, just to make the point. I highly advise you don't do this, because I don't consider it polite. Everyone tries to be objective in final review, so don't jab them with something snarky they'll remember about you while discussing your performance. It's an exercise, it's artificial. Can you convert an abstract idea into code. Yes there are bad questions and bad interviewers, that doesn't mean wanting to see you write code is bad. You don't want Microsoft's new "real world, from the job" style questions [1] because I've had a few of those and they're misguided. Way too much internal domain knowledge is missing and I spend too long trying to get it out of them. That said, DP in a phone screen for devops is a little tough. [1] https://www.businessinsider.com/microsoft-new-developer-interview-process-2018-12?IR=T https://www.businessinsider.com/microsoft-new-developer-inte...
- scottLobster 7y ago
  I wouldn't ask it snarkily. I've been hired for jobs before and then asked to work on stuff that, while related, was nowhere in the job description. Got hired to do Java/C++ development, was pushed into being part-time sysadmin for our primary test environment because my team had spare capacity and our dev-ops team didn't. There were times I went 6 months without touching a line of Java or C++. Another guy I worked with said he got hired for real-time c development and then got pushed into Java development shortly after arriving. Some managers embrace the notion that all software engineers are basically the same and you can shuffle them around outside their area of expertise and then complain when efficiency goes down. Now granted there are probably more strategic ways to ask about that then the direct method I originally posted, but if I'm interviewing with one of such managers, I want to know.
  - libria 7y ago
    Fair enough; phrase it "What would my day-to-day work look like?" "What percentage of time coding/designing/testing/meetings?" The current interview process could be better but right now these coding questions are just a proxy for ability/aptitude. I just want you to have the best shot at this job. Be as critical about the process as you want after you get it.
Kurtz79 7y ago
As much the current interview process is broken, I honestly believe this is the best attitude. In a way, it's nothing more than studying for some goal you think it will improve your current situation, and the good news that it is pretty much a solved problem, with plenty of information online that can be used to practice. Just take into account that for an embedded position you might actually be asked more domain-specific questions. I wish you the best in your seearch!
gwbas1c 7y ago
I interview A LOT of candidates. Don't bother with books about how to get a job. You're wasting your time. Instead, spend more time with books about hiring. How to run an interview, what to look for, ect. The reality is that companies mostly want to hire someone who can do the job and behave in a team. (There are some exceptions, but you probably don't want to work there.) At the end of the day, doing lots of leetcode exercises doesn't prepare you on how to convince someone in an interview that you can do the job. A few leetcode questions might help build your confidence, but that's about it. Really, all you need to do is play along and evaluate the people who are interviewing you. BTW, what I usually tell candidates goes something like this: "Look, we only have an hour, so these questions are contrived. We don't write code like this on the job. The best way to succeed is to play along and answer the question." And then, as I get into the questions, I sometimes add things like, "This isn't a JSON versus XML question" and "If you can use async-await, we wouldn't have a question. I'm trying to evaluate..."
- ubercow13 7y ago
  You are still asking the leetcode question, and no matter how fairly you explain it the candidate who practised those questions will probably do better.
  - gwbas1c 7y ago
    I doubt it. Leetcode questions tend to be deliberately technically challenging, and focused on algorithms. I don't ask technically challenging questions. I'm more focused on comprehension in a technical discussion, and a basic comprehension of concepts that are critical for the product that I work on.

zrobotics 7y ago

Although embedded is possibly one of the few software positions where these questions might be somewhat relevant- aside from embedded who is writing a sort by hand anymore; although even in embedded it isn't that common of a problem. I just find the questions especially egregious for an average software dev working on something like a web app, since in that case hand-coding something like a sorting algorithm or BST is almost always the wrong thing to do.

scottLobster 7y ago
Oh I completely agree, but like it or not such questions have become the unofficial Software Engineering SAT. Part of being an engineer is working with/around other peoples' bullshit. If the furthest that extends is a dumb interview question or two, that's a dream job. :)
emilecantin 7y ago
I'm a Web developer, and I did hand-code the Dijkstra path-finding algorithm recently. Granted, it's not common, and I didn't do it from memory, but at least I knew what to Google. I needed to represent the shortest path between nodes on a map, so I needed the internal data from the algorithm, thus the need to whip out my own version.

woodrowbarlow 7y ago

actually, i would think leetcode interview problems would be more relevant for embdedded development jobs. in embedded, you're less likely to have access to libraries that implement advanced data structures, sorting and searching, string manipulations, etc. so you'll need to do more of it by hand.

scottLobster 7y ago
To a point, but like most things in software my experience is you look up someone who's already figured it out and copy them :) Granted you have to understand the code a little more and be able to apply it to whatever system/hardware constraints you're working with. But just as higher level Software Engineers rarely have a need to implement recursion/graph traversal/etc, in embedded its even rarer due to the relative expense of such operations. I'd say knowledge of signal processing and how to power/performance/memory-optimize code would in general be much more valuable.
maxxxxx 7y ago
That’s my impression too. I would expect more handcrafted code on embedded systems and you need more awareness of computational complexity and memory needs.
- devanl 7y ago
  It's not as important as you would expect for a couple of reasons: 1. The size of the data is often much smaller - the savings from using an nlogn time algorithm vs a n^2 algorithm are much smaller when n=10 versus n=10000. There's a good chance that the constant time setup will dominate for those smaller datasets. 2. To a certain extent, embedded systems don't need to be as fast as possible - they just need to be "good enough" to meet their deadlines so that the rest of the system functions as expected. It'd be nice to be able to compute 1000 CRCs per millisecond instead of only 10, but if it already takes 1 millisecond to transmit the CRC over the serial bus, it's not going to make the system substantially better at its job. So yes, there is a lot of handcrafted code, but quite often it's just implementing your standard naive brute-force algorithm with minimal code size, minimal memory overhead (preferably without dynamic allocation), and well-understood worst-case latency.

Isamu 7y ago

For embedded programming you are more likely to be asked questions that require bit manipulation, shifting, masking, etc. Maybe low-level C, mapping structs to memory locations, etc. Maybe how you might go about implementing hardware interrupt handlers, or how you could put a microcontroller into low-power sleep and then wake up, etc. It is common for embedded software engineers to come from electrical engineering, and they are maybe less likely to ask CS-type questions.

scottLobster 7y ago
Hopefully. But I've heard from people who got asked leetcode style stuff in addition to those kinds of questions because it was company policy for anyone interviewing to be a "software engineer". Best to be prepared.
scarface74 7y ago
I interviewed for a position (and got the job) about four years ago for a C#/Angular senior developer and I was suppose to be “speaking my architectural experience into the team”. At the time, the only way I could document 10+ years of development experience was by putting a job I had worked at for a decade doing cross platform C and C++ with a little bit of assembly. Out of nowhere, after I thought the interview was over, one guy kept drilling me on that type of low level stuff that had nothing to do with the job just to prove how smart he was. I remembered all of it thanks to a decade of dealing with it and too much time on comp.lang.c but it was still off putting. I’ve since cut all of that stuff off my resume.
- umanwizard 7y ago
  I wasn't there, so I can't know how the interview went, but are you sure the motivation was "just to prove how smart he was" ? If I'm already 100% sure I'll recommend a hire, it's not rare for me to go off-script and dig into random stuff in the candidate's experience, first of all because I find it interesting or fun to talk about, and second because having deep knowledge about anything is positive signal, regardless of whether it's useful for the job. I have definitely been in this scenario and asked people who had relevant background to work out low-level performance details of their code. I hope they didn't think I was "drilling" them.

libria 7y ago

> although in the interview I might politely ask (after solving the problem) what relevance it has to the job, just to make the point. I highly advise you don't do this, because I don't consider it polite. Everyone tries to be objective in final review, so don't jab them with something snarky they'll remember about you while discussing your performance. It's an exercise, it's artificial. Can you convert an abstract idea into code. Yes there are bad questions and bad interviewers, that doesn't mean wanting to see you write code is bad. You don't want Microsoft's new "real world, from the job" style questions [1] because I've had a few of those and they're misguided. Way too much internal domain knowledge is missing and I spend too long trying to get it out of them. That said, DP in a phone screen for devops is a little tough. [1] https://www.businessinsider.com/microsoft-new-developer-interview-process-2018-12?IR=T https://www.businessinsider.com/microsoft-new-developer-inte...

scottLobster 7y ago
I wouldn't ask it snarkily. I've been hired for jobs before and then asked to work on stuff that, while related, was nowhere in the job description. Got hired to do Java/C++ development, was pushed into being part-time sysadmin for our primary test environment because my team had spare capacity and our dev-ops team didn't. There were times I went 6 months without touching a line of Java or C++. Another guy I worked with said he got hired for real-time c development and then got pushed into Java development shortly after arriving. Some managers embrace the notion that all software engineers are basically the same and you can shuffle them around outside their area of expertise and then complain when efficiency goes down. Now granted there are probably more strategic ways to ask about that then the direct method I originally posted, but if I'm interviewing with one of such managers, I want to know.
- libria 7y ago
  Fair enough; phrase it "What would my day-to-day work look like?" "What percentage of time coding/designing/testing/meetings?" The current interview process could be better but right now these coding questions are just a proxy for ability/aptitude. I just want you to have the best shot at this job. Be as critical about the process as you want after you get it.

Kurtz79 7y ago

As much the current interview process is broken, I honestly believe this is the best attitude. In a way, it's nothing more than studying for some goal you think it will improve your current situation, and the good news that it is pretty much a solved problem, with plenty of information online that can be used to practice. Just take into account that for an embedded position you might actually be asked more domain-specific questions. I wish you the best in your seearch!

gwbas1c 7y ago

I interview A LOT of candidates. Don't bother with books about how to get a job. You're wasting your time. Instead, spend more time with books about hiring. How to run an interview, what to look for, ect. The reality is that companies mostly want to hire someone who can do the job and behave in a team. (There are some exceptions, but you probably don't want to work there.) At the end of the day, doing lots of leetcode exercises doesn't prepare you on how to convince someone in an interview that you can do the job. A few leetcode questions might help build your confidence, but that's about it. Really, all you need to do is play along and evaluate the people who are interviewing you. BTW, what I usually tell candidates goes something like this: "Look, we only have an hour, so these questions are contrived. We don't write code like this on the job. The best way to succeed is to play along and answer the question." And then, as I get into the questions, I sometimes add things like, "This isn't a JSON versus XML question" and "If you can use async-await, we wouldn't have a question. I'm trying to evaluate..."

ubercow13 7y ago
You are still asking the leetcode question, and no matter how fairly you explain it the candidate who practised those questions will probably do better.
- gwbas1c 7y ago
  I doubt it. Leetcode questions tend to be deliberately technically challenging, and focused on algorithms. I don't ask technically challenging questions. I'm more focused on comprehension in a technical discussion, and a basic comprehension of concepts that are critical for the product that I work on.