Software Developer

So how do you actually prepare for A Software Developer Job Interview? We are going to explore a few basic interview situations and how to best prepare for them.

Nothing can be 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 the above statement may seem difficult to believe, especially if you’ve had not-so-great interview experiences in the past, but I’ve also had some pretty horrible interviews in my career too, and within recruitment, you hear some pretty disturbing stories overall. I’ve learned from those experiences and that’s why I always try to find out as much information before sending anyone into an interview situation especially within Software Development.

 

Kinds of Interviews

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.

 

Phone Screen

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. 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.

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. 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 it is more difficult to screen you out.

 

Technical Interview or Task

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, so they can asses your talent remotely. 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 a little bit later.

 

You will want to make sure you have a good mastery of solving algorithm-type problems in your programing 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 recruiting career, most of the interviews I have set up were one-hour, in-person, technical interviews where the hiring managers would ask a series of technical questions about the technology you be primarily using. This seems to me the most favourable among hiring managers.

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. Basic questions about yourself and your past experience will come into play along with your goals for the future.

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.

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.

 

Panel 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.

 

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.

Common Technical Questions About Your Technology / 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 stuff!

Seriously. Know the stuff about your programming language or technology that any person 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 + 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.

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 / want this job?
• Can you tell me a little about yourself?
• Why are you leaving your current job?

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?”

 

Dress Right

I know that many software development businesses 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. Smart Casual or suit if required depending on the environment and company culture.

 

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 professional.

 

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.

 

Don’t Lie

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 make up 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 lying 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 lies 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.

 

Elaborate

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 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.

 

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 a recruiter and employer, 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.

If you need any more support on preparing for an interview we can arrange a mock interview with you so you are always ready and feeling prepared.

 

Do whatever it takes to get the practice you need.

Practice coding problems on whiteboards.

Practice, practice, practice.

I can’t say it enough.

Practice.

   

 

John Sonmez – Simple Programmer