Nothing's more terrifying for a software developer than an interview, especially if it is a coding interview on a whiteboard — though, with the right preparation and mindset, an interview can actually be something you look forward to as a chance to show your stuff and exhibit your best skills.
I know that the above statement may seem difficult to believe, especially if you’ve had not-so-great interview experiences in the past. I’ve also had some pretty horrible interviews in my career as a software developer, and I’ve learned from those experiences.
Without a doubt, the right preparation makes all the difference.
I remember my first interview with Microsoft as a young developer who thought he knew everything. Microsoft flew me out to their Redmond campus for a full day of interviewing. Things got off to a very bad start. As soon as I arrived at my hotel and began to unpack, I realized that I forgot my pants. I found a department store where I could buy some pants for the next day, but little did I know my trouble was just starting.
I had no idea what a Microsoft interview was like, and I was absolutely not prepared. The next morning, a driver picked me up and took me to the Microsoft campus where my liaison explained to me how the interview process would work. I’d be spending all day going to six or seven interviews. The day would either be a half-day or a full day.
After the first four interviews of the day, including a lunch interview, if it didn’t look like I was going to be a good hire, they’d send me back to my hotel early to pack; otherwise, I’d have three or four more interviews. Stressful enough for you?
My very first interviewer asked me to code a Win32 function on the whiteboard. I was not prepared. I stuttered. I sweated. I scrawled something illegible on the board. It was pretty clear I didn’t know what I was doing. The interviewer tried to help me out to no avail. I made excuses. I stalled for time. I produced nothing close to the desired output. I lied to cover up my inadequacies.
The next interview was no better. More whiteboard coding, more complete, embarrassing failure. If you are going to be cocky, you better at least know what you are doing. My ego was quickly deflated.
The lunch interview was a mercy killing. We just chatted about Microsoft and life. I felt like I was a lame horse being taken out to the pasture and given a few sugar cubes before…
Before I knew it, I was back on the little bus, heading back to my hotel. I did not get a job offer. I did, however, learn quite a few lessons and I became much better at interviewing later in my career.
This chapter is all about not making the same mistakes I did. Let’s carry on, shall we?
Kinds of Interviews
I thought that by starting up this chapter sharing an embarrassing story about myself, you would have loosened up a bit. Now, I’ll be sharing one of the most important things about interviewing you should know: all the different kinds of interviews you can expect to have as a software developer.
I’ve tried to catalog here what I think are the most common variants and types of interviews you are likely to see with the hopes that understanding what you might be getting into beforehand might help you avoid the kind of embarrassing episode I had to endure at Bill Gates’ torture chamber.
In this next section, I’m going to talk about the different kinds of interviews, but we aren’t going to go much into the preparation for them since you probably won’t know what kind of interview you are up against until you are either at the interview or scheduled for it.
Have no fear, for after we talk about the kinds of interviews, we’ll cover how to prepare for them—I promise.
It’s pretty common to have a phone screen before you’ll be seriously considered for a job. Most major companies that hire developers will make sure to screen any potential candidate they want to bring in for an interview before incurring the cost of doing so.
A phone screen is usually technical in nature, but it can also have some non-technical questions. You may also end up with both a technical and non-technical phone screen. Back when I interviewed for Microsoft, they gave me both types of phone interviews. Like I said, the purpose of the phone screen is not to decide whether to offer you a job, but rather to weed you out.
You want to pass a phone screen by showing that you are technically competent and that you aren’t some kind of psychopathic freak. Usually, a phone screen interview will be composed of some basic technical, qualifier questions and a few personality questions.
As long as you are properly qualified for the job, these interviews should not be that difficult. In fact, often a non-technical person asks you a standard set of questions and records your answers. So just answer the questions, don’t read too much into the responses, and try to give as many details as possible so that it is more difficult to screen you out.
Online Technical Interview
This is a new kind of interview that has only really started to appear in earnest in the last few years, but I believe we’ll see more and more interviews conducted in this fashion.
This kind of interview is much like a phone pre-screen, but instead of taking place over the phone, it will take place over a Skype call or another video chat equivalent. You will be asked to solve some programming problems or even do pair programming with an interviewer so that they can quickly assess your talent remotely.
Many remote teams are employing this kind of interview because it closely resembles the conditions of working as a remote developer.
This is also a very difficult interview to bullsh*t. If you are screen-sharing with an interviewer while you are working on a programming problem, it’s going to be pretty clear whether or not you really know how to code.
Another variation of this interview entails being given a coding assignment or a link to a programming assessment test where you will have a controlled environment and time limit to complete some number of programming problems.
Preparing for either of these types of interviews is going to be very similar to preparing for an in-person coding interview, which we’ll discuss in-depth a little bit later.
You will want to make sure you have a good mastery of solving algorithm-type problems in your programming language of choice and that you have a good understanding of data structures.
Standard Technical Interview
By far, this is the most common type of interview.
In my programming career, most of my interviews were one-hour, in-person, technical interviews where the interviewer asked me a series of technical questions about the technology I would be primarily using at the job and didn’t really go much deeper.
I would suspect that the reason why these kinds of pretty shallow interviews are so prevalent is because most software developers who are asked to conduct interviews don’t really know how to interview someone. They just Google a list of common interview questions related to the primary technology or programming language they are interviewing the candidate on and then simply ask them.
Obviously, you can be pretty prepared for this kind of interview by doing much the same. Google common programming questions for your technology and know the answers to them.
Culture Fit Interview
This kind of interview is usually conducted by a manager or, in a small company, the CEO or startup founder.
The goal of this kind of interview is to see if you will fit in with the team personality-wise.
For this kind of interview, you might be taken out to lunch and asked some basic questions about yourself and your past experience. The interviewer is usually looking for some indication here that you have some kind of personality flaw that would be detrimental to the team.
For example, if you seem to always get in conflicts in your past jobs because you assert that you are so much more knowledgeable in the right way to do things and everyone at your previous jobs were so ignorant, that’s a pretty good indicator that you are going to be trouble.
Also, at a lunch interview, if you are very nervous and can’t have a good time and relate to the interviewer(s) by having a decent conversation, it also might be an indicator that you are not going to be a good fit. It’s pretty difficult to know what an interviewer is looking for here, so you want to be yourself as much as possible and avoid any antisocial behavior.
Honestly, this is probably one of the worst kinds of interviews for most people—especially if it is combined with a coding interview. With a panel interview, you are interviewed by several people, lined up in a panel, at the same time. The panel might take turns asking you questions or asking you to clarify on someone else’s previous question.
You should expect a mix of technical and personality types of questions and everyone scribbling copious amounts of notes about each of your answers. Most often, a panel interview is conducted at the end of a half-day or after a full-day interview as the final test, so be prepared.
This is also another kind of the worst, dreaded interviews—perhaps the most dreaded of all.
In a coding interview, you’ll be asked to solve some algorithm problem by writing some code. Often, you’ll be asked to write that code on a whiteboard without the use of an IDE. Most software developers who haven’t specifically prepared for this type of interview do not do well at this request.
Writing code on a whiteboard while someone is watching can be extremely unnerving, especially if you are not confident about how to solve the problem you are being asked to solve. Big companies like Microsoft, Google, and Apple often employ these kinds of interviews, so if you want to get a job at one of these companies, you had better be prepared. The best way to get good at these kinds of interviews is to study specifically for them and practice, practice, practice.
All-Day or Half-Day Interview
This kind of interview usually consists of several technical interviews, a culture fit interview, and possibly even a panel interview at the end. Usually, bigger companies are going to conduct all-day or half-day interviews, but I’ve also been interviewed in this manner by smaller startups that had heavy funding.
The reason why is because it’s expensive to have multiple staff members spend an hour each interviewing every candidate for a job and to coordinate all of that as well. These interviews are pretty grueling.
I already told you about my experience at Microsoft, but I’ve also had two all-day interviews ending in a panel interview at HP, both of which went much better than the Microsoft one.
I really dislike these interviews. All it takes is for one interviewer to dislike you, and the entire day could be ruined since one bad vote can usually vote you off the island. With these kinds of interviews, expect to go from interviewer to interviewer during the day, to have a lunch interview, and then to have some kind of interview with management or a panel at the end.
It’s tempting to think that if a company if going to fly you across the country, put you up in a hotel, and spend all day interviewing you, that it’s just a formality and you already got the job. But I assure you that is not the case—trust me, I know.
What You Need to Know
OK, so now that we’ve talked about the different kinds of interviews, let’s talk about what exactly it is that you need to know for an interview–technical or not.
I am going to speak in general terms here because, obviously, the specific job and technology will dictate what a large amount of the knowledge you need to have will be and the types of questions you’ll be asked.
However, I think you’ll find it useful to get a general idea of what you need to know and then once you know that, you can work on the specifics yourself.
How to Solve Coding Problems
Even though not all interviews will require you to solve algorithm-type coding problems, the most difficult—and probably the most important—ones will.
You should take the time to master the skills required to solve coding-style interviews by becoming good at solving coding problems and gaining a good, working knowledge of data structures. For that, again, I’ll recommend Gayle Laakmann McDowell’s book, Cracking the Coding Interview, and you can also see the section on the chapter on “The Technical Skill You Need to Know” for more resources.
(At this point, you might think I’m best buds with Gayle. I’ve actually never met her. She has yet to return one of my emails. Her book just happens to be one of the few books dedicated to teaching you all the types of coding problems that you are likely to face in a coding interview.)
I also wrote a blog post about how to crack the coding interview, which you may also find useful. If you prefer to learn by video, I did a course on Pluralsight about Preparing for a Job Interview, which shows you step-by-step how I solve algorithm-type problems and break them down. I actually find them fun.
Yes, it’s a bit difficult to master this skill, but it will pay off immensely. Most programmers can’t handle coding interviews and don’t know how to solve common coding problems.
Once I got good at these types of interviews, I became extremely confident in any interview I would go into because I knew I could tackle the most difficult challenge they could throw at me.
Oh, also do a search for FizzBuzz. Don’t get blindsided by this one—you’ll thank me later.
Common Technical Questions About Your Technology and Expertise
This one should go without saying, but I’ve sat on the other end of the interview table interviewing a supposed .NET developer who couldn’t answer what the CLR was as well as a C++ developer who thought polymorphism was a kind of religion enough times to know that I have to make it pretty clear: you need to know your sh*t.
Seriously. Know the stuff about your programming language or technology that any idiot Googling “Java interview questions” can find. You should know the answer to every single question in the three results from Google on your technology choice and interview questions. If you don’t, it’s completely your fault, because this one is so easy.
Yes, an interviewer may still stump you from time to time, but you should at least know the most commonly asked questions. If you are interviewing for any object-oriented programming language, you better know what encapsulation, inheritance, polymorphism, data abstraction, interfaces, and abstract base classes are at the very least.
I’m pretty sure that I asked about each one of those topics in every single technical interview I ever conducted, and I was also asked about them at least 50 percent of the time.
You can usually find plenty of books, blog posts, and other resources that contain lists of interview questions for whatever programming language or technology you are going to be interviewing for, so I won’t try to list them here. I did do a Preparing for a Job Interview course on Pluralsight which goes over some of the most common ones for common technologies.
Personality and Psychological Questions
Be ready to answer all of the common personality and psychological questions most interviews default to asking.
You should be prepared to answer questions like:
- What is your greatest strength?
- What is your worst weakness?
- Where do you see yourself in five years?
- What was a challenge or conflict you got into at work and how did you handle it?
- Why do you want to work here? Why do you want this job?
- Can you tell me a little about yourself?
- Why are you leaving your current job?
I’m not going to go over how to answer these questions here. You can find plenty of advice on how to answer these types of questions online. If you really want my advice, you can find some on how to answer these questions on my Pluralsight course, Preparing For a Job Interview.
The short of it is that you want to be as genuine as possible without revealing too many negative details, and you want to keep everything as positive as possible. Accept responsibility, show growth. Never blame anyone else for anything.
Make sure you have at least practiced and thought about answers for all of these questions and any other similar ones you are likely to be asked, especially for questions like, “why are you leaving your current job?”
All right, now let’s get into some actual tips to help you do the best you can in an actual interview.
Before we get into these tips, I want to talk about one of the most important tips, which you can find a whole chapter on in my book, Soft Skills: The Software Developer’s Life Manual.
This tip is that you shouldn’t be relying on the interview as the time to impress the interviewer. The best possible thing you can do to help you “pass” an interview is to have the interviewer already like you before you get into the interview. Even though technical skills are important, most interviewers end up hiring people they like.
How could you possibly get the interviewer to like you before the interview? What sorcery is this, you ask?
Simple. Think outside of the box.
In the chapter on “Finding a Job,” I talked about the traditional way to get a job by blasting out resumes and some of the more out-of-the-box techniques. If you’ve used one of the out-of-the-box techniques, there is a good chance you came in via a referral instead of a cold job application and resume.
In that case, the interviewer may already know who you are or have a good impression of you. If you have a blog or YouTube channel, the interviewer may also know who you are ahead of time.
And, finally, I’ve talked to many software developers who—when they knew who was going to interview them—actually reached out ahead of time for a pre-interview and to introduce themselves. (This works surprisingly well.)
The point is, if you can build rapport ahead of the interview and think of ways to make it so that the interviewer already likes you before you even step foot in the door, you are going to have a much better chance of landing that job.
I’ve had situations in my career where I was able to do this so well that the interview was just a formality, and I literally just chatted with the interviewer for an hour. (The best interviews feel like that, anyway.) Regardless, if you can’t gain that advantage, here are some tips that will apply in just about any interview situation.
I’ve got a bit of an against-the-grain opinion on this one, but I believe you should always dress up as best you can for an interview. I know that many software development shops allow everyone to wear flip-flops and shorts, and they may even say you can at an interview, but don’t do it.
For an interview, you should dress two levels above the standard office dress code.
If you are a guy, I’d almost always recommend coming into any interview with a nice suit, and if you are a lady, I’d recommend the equivalent dress or power suit.
If you are a power ranger, you definitely want to wear your power suit (couldn’t resist).
Although, I wouldn’t wear a tuxedo. That might be overkill (unless, of course, you are interviewing for a secret agent position). Yes, it’s true the interviewer might say that you didn’t need to wear a suit and that you are “overdressed,” but don’t trust what people say.
Even if the interviewer feels that you are overdressed, looking sharp and professional causes a first impression that is difficult to shake. I can’t see any disadvantage to having an interviewer think you are extremely professional.
Let the other job candidates dress in T-shirts and jeans, but you dress up as best you can and create a strong, unconscious bias that you are the more professional, better candidate. You don’t have to take my advice here, but whatever you do, at least dress one level higher than what the standard office wear is.
Please do not wear shorts to an interview, no matter how bad*ss you think you are.
Be on Time
On time is 10 minutes early. Not 15, not 20. Not 10 minutes late. Not right at the time you are supposed to be there. If you are driving to the interview, plan to be there 30 minutes early, but wait in your car for 20 minutes if you get there on time.
This is called a buffer.
If you have trouble being on time for events, always plan to arrive 30 minutes early and spend 20 minutes answering email, reading a book, or something else. Then, if something comes up—and it always does—you are still on time.
It’s tempting to lie or fudge the truth, but don’t do it. You don’t have to volunteer every negative piece of information about yourself, but if something comes up, address it. Don’t sweep it under the rug.
This especially goes for answering technical questions. If you don’t know the answer, just state that you don’t know, but you are interested in learning the answer or that you will find out the answer when you get back home.
Don’t try and bullsh*t answers to questions you don’t know. It’s obvious and if the interviewer knows his or her subject well, you’ll just sound unconfident, arrogant, and dumb. I’ve interviewed enough software developers to know that bullsh*tting an answer never leaves a good impression.
It’s OK not to know the answer to every single question the interviewer asks. You will create a much better impression by honestly and humbly admitting your lack of knowledge in an area and your eagerness to correct that fault than any kind of deception or bullshit you can come up with.
It may even work in your favor to have at least one question that you admit you don’t know the answer to.
Don’t Defend Yourself
Interviews can be high-stress situations where you can easily feel like you are being judged—you are. In these kinds of situations, it can feel like you are being personally attacked—you aren’t.
It’s easy to slip into a defensive response when asked certain questions about your work experience or skills. It’s easy to slip into a defensive response when you don’t know the answer to a question the interviewer asks, and you might feel embarrassed or like they are trying to make you look like an idiot.
Resist this temptation at all costs.
Nothing shows more of a lack of confidence than a backpedaling, defensive person who can’t handle anything negative about themselves or being perceived as not knowing the answer to something.
If you feel like you are being “attacked” during an interview, go with it. Have a stoic resolve which shows that your confidence in your abilities is so high that you can admit your weaknesses and you aren’t afraid to look dumb or incompetent.
An interview is like an audition. You want to get as much stage time as possible. So don’t blow it by giving one-word answers to questions the interviewer asks—or even one-sentence answers. Always elaborate. What do I mean?
Instead of just answering the question—especially a technical one—add more details. Talk about how you used a particular technology or concept. Give your thoughts about it, especially your controversial ones.
You’ll be seen as having an understanding and a depth of knowledge rather than as someone who memorized a bunch of definitions that you don’t really understand. You also have a chance to show your personality and show how you explain and share your ideas.
Don’t go overboard and tell your entire life story to the interviewer, but always elaborate on any non-trivial questions. One huge advantage of this approach is that even if you are technically wrong, you will get credit for analytically thinking about the problem or question, especially if you think out loud.
Be Confident (Not Act)
You can fake everything but confidence, so don’t even try it. Instead, actually be confident going into an interview. Faked confidence comes off as either insecurity or arrogance.
Real confidence comes off as being comfortable with who you are, where you are, and just having a good ‘ol time. How can you actually be confident? Well, by preparing, of course.
The more prepared you are for an interview, the more confident you’ll be going into one, so do the difficult work up front. As the Greek lyrical poet Archilochus once said, “We don’t rise to the level of our expectations, we fall to the level of our training.”
Demonstrate This One, All-Important Message
I am self-motivated. I figure out what needs to be done and I do it.
Everything you say to the interviewer should indicate this. As an employer myself at Simple Programmer, I can tell you that this trait is what I am looking for more than anything else. I want to hire people who I can count on to get things done and require minimal guidance from me. I want people who figure out what needs to be done and do it.
Those are the most effective people. Those are the kinds of people you don’t have to manage because they manage themselves.
Demonstrate—in as many ways you can—this all-important trait. Specifically say it if you have to.
Practice, Practice, Practice
Unless you’ve got a hardline into the Matrix, if you want to get good at anything you’ll need to practice. So do it. Practice mock interviews. In the mirror. With your pets. Have your friends and family interview you. Go out and get real interviews—just for practice. Record yourself on video and play it back, so you can watch and cringe. Practice coding problems on whiteboards.
Do whatever it takes to get the practice you need. Practice, practice, practice. I can’t say it enough. Practice.
This post is a chapter from my book, The Complete Software Developer's Career Guide. I'm writing the book live on this site week-by-week. If you enter your favorite email address here, I'll send you the prior chapters and get you caught up - then send every new chapter as it comes out!