How do I get a software developer job?

What are some good ways to further educate myself in order to get a embedded software developer job?

• I am good at the basics of C. I had a formal course in college and I coded in C for personal projects and school courses. I was a developer in a leading company right after school. But I was in a team which mostly did bugfixing for a pretty stable software. So not much to learn as far as development is concerned. I have been looking for job outside as a developer and even though I am good at the basic, my lack of strong  experience comes in way. I am currently working in a non-development role. I would like to use my spare time to gain a lot of knowledge in C development, mostly in embedded domain. How should I go about it? Any projects in mind, practical books etc? Please be as detailed as possible. I would really appreciate if you don't write short answers.

• Answer:

  Embedded software development differs from "desktop" programming, particularly on Linux, mostly in the following ways: Someone has to bring up the device/board Someone has to write drivers for the hardware (if the company develops hardware and drivers are not otherwise available) Someone has to write applications (ok, this is also required for desktop, but how it is done can be different) Everyone has to become familiar with cross-development, how to copy binaries to the device, how to "flash" or upgrade the device. Knowing C is pretty much a requirement. So, getting *really* good with C programming is a pre-requisite in my opinion. Knowing Linux is important too. Command-line Linux, not just how to use GNOME or KDE or some other GUI environment. Board Support: If you are the person bringing up the board, you will need hardware experience, good idea of what the Linux boot process involves, how to work with a boot loader like uboot, and so on. In all my experience, someone had already done that work by the time I joined the company. Usually that work, in a bigger team/company, is dedicated to a few specialists who have the experience. As new boards come along, they probably take what they have, tweak it for the new boards to come up with a solution. One way to learn would be to get familiar with Linux boot process and a boot loader like uboot (I'd do this by reading a book on embedded Linux, then buying a Raspberry PI or a beagle board and studying the uboot implementation). If I were at a company that already has people who know this stuff, I would tell them you are interested, tell them what you have learned outside the job, and try to beg on to the project and help them the next time they bring up a board. Drivers: Learning about drivers is similar, you read a book, and you play. You can learn about drivers with a desktop Linux system, or once again, play with a beagle board. There are tons of drivers in source code form shipped with the Linux kernel sources. Use the source to learn about character and block devices. Applications: This is what I usually end up doing, and it may be the most common way to get into embedded. You just needed to be a kick-ass C/C++/Python/Whatever Unix developer to be useful. Most of the time, it requires the same skills as desktop development, except for the last issue, which is: Learning the toolchain and how to interact with the board: Here, some experience cross compiling apps for a beagle board or raspberry PI on a Linux desktop would be useful. If you can compile C/C++ for the ARM (or whatever) using cross development tools and can find a way to copy it to the board, run, and debug (learn about gdb-server, it's common in embedded Linux development), you probably know all you need to know. Some places will NFS mount your build system to the device, and that is how you access your builds, in other places you tftp or scp it to the device. Regardless, learn one method, and expect to be told exactly what to do when you join the team. It almost always varies in one way or another. Good luck. Embedded is fun, there are lots of resources outside of work to learn about it from. Learn the basics, and try to beg onto the team, especially if you already have your foot in the door of the company (that's usually the hardest part).