How to Study for a Software Engineer’s Technical Screening 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.

Introduction

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 for teaching yourself and brushing up on existing Software Engineering skills, 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.

This guide is broken down into two main 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 a dysfunctional organization. Usually, technical dysfunction follows overall organizational dysfunction, but more on that later.

My Background

I have a BA in Art Studio with a concentration in East Asian Studies. Most of my painting was traditional oil on canvass or board. My drawings were in a variety of media; pencil and graphite, mixed media, and some lithography. My focus in East Asian Studies was on Japan.

I graduated college in 1994 and the 1990’s recession meant that there were few if any jobs available. Especially for an Artist. The i486 microprocessor came out in 1989 and by this time enough consumers had one that the computer gaming industry started adding real graphics and art to their games. There was a demand for digital 2D and 3D artists and I decided that was my best bet. I scraped together some money and with my parent’s help bought myself a Compaq desktop PC with an i486 DX2-66 processor and managed to “find” a copy of AutoDesk Animator and set about teaching myself how to use it and how to translate my traditional drawing skills to the digital arts.

After about a year of working in retail and restaurants and studying in my spare time I managed to land a job at Bethesda Softworks. I continued to grow my digital arts skills and learned 3D animation, however I found myself drawn to the coding side of the business. From computer gaming I moved on to web design and development; to back-end development and providing managed hosting services (including running ALL of my own infrastructure except an Internet connection); to working in the Big Data space.