Reddit reviews An Embedded Software Primer

Here's a few books I highly recommend:

Making Embedded Systems by Elecia White

An Embedded Software Primer by David Simon

Programming Embedded Systems in C and C++ by Michael Barr - out of print, but still a decent book.

Also, embedded guru Jack Ganssle has a long list of embedded books he's reviewed here: http://www.ganssle.com/bkreviews.htm - lots of good stuff on there

I'm not in embedded anymore so take what I have to say with a grain of salt, but here's my opinion.

The resume looks pretty good to me. Between your GPA and the descriptions of your class projects and personal projects, a hiring manager should be able to see that you can handle technical depth, and that should be enough to bring you in for an interview.

At this point I'd put my focus on networking to get an interview rather than polishing the resume. Talk to your university career center. Talk to professors that may know about jobs. Talk to family friends that work in engineering. Set up some informational interviews (these aren't as common in engineering as in other fields but can actually be very helpful in choosing a career path).

And since you asked specifically about the resume:

1. Polish the formatting (font/spacing/layout). Use a nice Word template, LaTeX moderncv, etc. No one is going to throw out a resume that doesn't look beautiful (especially in engineering, and especially for an internship) but it does give the impression that you're more invested in the job search and pay more attention to details.
   
   
2. List your coursework. If you're a junior presumably you are taking a number of upper level courses. It looks like you could easily add this without needing more than one page, so this could be a good way to fill some of that space with information that could draw a hiring manager's eye.
   
   
3. Add something that shows you understand concurrency and can work with a real-time OS. These are requirements for many embedded positions, and while experience coding for an RTOS probably wouldn't be expected of an intern, some general understanding of the concepts could give you a leg up. See: <http://aosabook.org/en/freertos.html>, Jack Ganssle articles, Michael Barr articles, <http://www.amazon.com/Embedded-Software-Primer-David-Simon/dp/020161569X>.

You know what I hate? And this seems to be the thing that you're taking issue here: people not thinking of the consequences of their design decisions properly.

Any idiot could tell you it's probably more cost-effective and smarter to use one of the standard USB connectors--I don't know, maybe he decided to use the other one because he didn't want people plugging things into it. But it's entirely possible it was just a really dumb oversight that should've been caught. The fact that he's the same guy that has a problem understanding the very basics of networking leads me to believe he just didn't think things through--I'm laughing at the SVN thing too--I wonder if he was just really thick. SVN isn't that hard. I'm an EE (well, I guess I work in more of a CE environment though), and a psuedo-SVN (it's not Apache, but it follows the same basic principles, it's just proprietary to my company) is what we use for fetching, modifying, and checking back in literally all of the collateral that we work with.

And I can kind of understand why an EE wouldn't know much about networking--but he ought to be aware that he doesn't know much about networking. Hell, I know virtually nothing about networking (though I do know enough to know that you can't use one IP to communicate with two devices unless you're spamming the same message to both of them).

The PCI-E issue though, while it is a problem, I can virtually guarantee that it wasn't something that's easy to catch. Embedded systems design is more complicated than you'd think. If you want to read up a bit on it, I highly recommend An Embedded Software Primer. It was my college textbook for my first real foray into embedded systems design (with the help of this book, I wrote my first RTOS that ran on the Intel 8088). It's actually extremely readable, unlike a lot of other textbooks--I actually specifically kept this one when the class was over, because it's a good read.

Currently looking through http://www.ganssle.com/startinges.htm and http://www.ganssle.com/bkreviews.htm

Think I'm about to pick up this book: http://www.amazon.com/Embedded-Software-Primer-David-Simon/dp/020161569X

Sounds awesome. Think I'll pick up this book and maybe in a year I'll not be utterly unqualified for this.

https://www.amazon.com/Embedded-Software-Primer-David-Simon/dp/020161569X
is a good read. Though there's no substitute for working on a real system with people who can point you in the right direction.

I personally think embedded is kinda fun -- but then, I used to think optimizing DSP assembly was fun; I'm not a well man! (Now, not so much -- I can't out-pipeline the compilers, for the most part, and they offer hints to try to help you write optimizable functions).

I'm not my boss, but I guess mostly what I'd look for is evidence or problem-solving and debugging skills. An EE background is a plus. I don't actually have that, although I've picked up some rudiments. There are folks around me who can help me come up with coefficients to use in a filter or help me capture states on a logic analyzer. You've got to know the low-level stuff pretty cold: flipping bits, threads, using mutexes, avoiding race conditions, implementing state machines, debouncing inputs, and especially serializing data.

This book was helpful to me: http://www.amazon.com/Embedded-Software-Primer-David-Simon/dp/020161569X

It would be helpful to know what the C standard says about types, sizes, etc., and what guarantees it makes about initialization and things like that. I have worked with a lot of developers who think that since their compiler does something non-standard with initialization, that gcc or whatever is then wrong when it doesn't work the same way. Learn to write portable code where possible! Really the best way to do that is to port some code. It's actually a shame that Apple went to Intel CPUs, because now the ecosystem is a little less diverse. It was very valuable for me to learn to write code that was portable between 68000 family 16-bit ints, 68000 family 32-bit ints, PowerPC big-endian, and Intel little-endian.

If you are very familiar with the basics of C++ -- how constructors and destructors work, how inheritance works, etc. -- then you probably know enough of the high-level to do embedded work. A lot of embedded code bases don't use multiple inheritance, don't use exceptions, don't use STL, etc., although that is not always a hard rule; we're starting to use some more templates and some basic STL.

Experience in higher-level languages like Python would be valuable too -- we're starting to write more and more tools in Python. Sometimes I write internal tools for my own use in Haskell, but that's mostly for my own enjoyment.