How to Teach Yourself Software Engineering and Interview for a Job

Posted: …, Updated …

If you are reading this paragraph that means that this is still a work in progress. Instead of approaching this like a book, where you have to finish the entire thing before you can publish it, I am putting it out there as I write it. Primarily, because I have a friend of mine that wants to get back into Software Engineering and that is good impetus for me to aggregate all of this information and get him started as soon as possible.

Let me be absolutely clear, up-front; this is NOT a “how to pass a coding interview or technical phone screen trips and tricks”. If you just want to memorize enough to squeak by the technical part of your interview you probably don’t want a job at that company anyway as they are not digging deep enough into your knowledge and skills to determine how much you actually know.

This is a guide and methodology for teaching yourself how to become a Software Engineer, and how to interview for a Software Engineering position.

Teaching yourself means working on your own and actually learning. Learning can be defined as “the acquisition of knowledge or skills through experience, study, or by being taught”. This guide is about actually learning the software engineering principles, and skills. Once you do that, passing any technical interview or test, for a given skill level, is easy.

How to interview for a Software Engineer position is broken down into two parts. The first is the training and study regimen to refresh your existing knowledge and prepare for the interview. Much like an elite athlete who is already accomplished in their sport and is training for an upcoming competition. They want to be in tip-top shape and perform their best. The second part is how to interview; not only how to best present yourself, but also how to interview your prospective employer. I have made made the mistake of not properly interviewing a prospective employer, or ignoring warning signs, and found myself in dysfunctional organizations. Usually, technical dysfunction follows overall organizational dysfunction, but more on that later.