The Software Developer Interview Protocol

Ever interview at a software company? If you have, then some of this may sound familiar.

For everyone who doesn’t know the drill, there is a standard way software companies tend to interview candidates. There is a separate process of getting an interview, but we’ll skip that and move on to the interview process. Just take a mental note that getting the interview may be slightly different.

First, the entire interview process could take months. This includes the initial contact with a recruiter to the in person interview. The actual in person interview, when you meet people at the company, can be a whole day event or multiple days if they like you. There can be multiple interviews with different people, but most interactions are similar in nature. It’s as if these companies banded together to come up with an interviewing protocol.

The Experience

I have interviewed at many companies over the years. Some interviews went better than others. Most companies interviewed me with the standard protocol, but not all. I can remember an instance when an interview went poorly and an instance where it went better than expected. Surprisingly, both of these instances happened within weeks of each other.

The Worst Interview

There are many variables that can lead to a bad interview. Maybe it wasn’t a great day for me, or maybe it wasn’t a great day for the interviewer. All I remember is that it didn’t go well. Let me paint the picture for you.

I remember this was my third interview of the day for this company. I was sitting in a small room surrounded by dry-erase boards. I had several copies of my resume, an Android tablet, and an iPad. I was proud of my work, and I wanted to show it off.

As the interviewer walked in the room, I had a smile on my face to show I was friendly and open. His face, however, did not mirror mine. I extended my resume and said, “I’m not sure which version of my resume you received, but here is another in case you want to look it over.”

He quickly put it to the side and said, “Thank you, but I have a few questions to ask, so let’s get started.” Without even looking at my resume, he asked an algorithm question.

I responded, “Can I at least show you some of my work? I’ve worked really hard on it, and I think it will show you more of what I am capable of.”

“Fine, but quickly,” he replied as he looked at his watch.

I proceeded to show my applications, and about 5 minutes in he stated, “You now have 40 minutes and we have a question to solve. We really need to get started.” Saddened by the fact the interviewer didn’t want to look at my resume or discuss my applications, I asked a few questions regarding the algorithm. Then I walked over to the dry-erase board to solve the problem.

As I wrote the algorithm, we discussed potential problems. Because of this, I made changes as different requirements and scenarios popped up. In the end he said, “Well, time’s up.”

I got out my pen and asked, “Can I get your email, please?”

“No, I don’t feel comfortable with that,” he said.

I was stunned because nobody has ever denied my request before. I then replied, “Okay. I was just going to thank you for taking the time out of your day to interview me, but I guess I can do that now. Thank you.”

He then walked out. After that, I sat there for a bit. What did I do wrong? What could I have done better?

Unfortunately, I didn’t get that job, but life moves on.

The Best Interview

The best interview I ever had didn’t have a single question related to algorithms or data structures. Unlike the company where I had my worst interview experience, this company wanted to see my personal applications. They truly wanted to know about me, the developer. Don’t be fooled, though. This day wasn’t an easy one. It was still filled with hours of interviews and meetings with various people. It was just a day without the standard protocol. Because of this, I was able to win them over with my applications and personality. I left that day with a positive outlook, feeling that I could dominate anything.

When I got home, I sent emails to every single person who interviewed me to thank them for taking the time to speak with me. I then received an email back with a homework assignment. It was to create an Android application that utilized the Flickr APIs to display the top 20 images from a specified search, and I had a week to complete it.

Since I was still on my high from my best interview ever, I got to work. I called my Android application, “Flickr Go Live.” I didn’t plan on doing this, but for the next 6 hours I was in program mode. First, I made sure I thoroughly understood the requirements. Next, I made sure I understood the Flickr APIs. Lastly, I architected and programmed the app making sure every edge case was met, and I validated the code was clean and well documented. This, in my mind, was the real interview, and I wasn’t going to mess it up.

After I completed the app, I pushed it to GitHub and emailed one of my interviewers to review it. I felt good about the day. I felt good about my app. Later in the week, to my surprise, I received a job offer from the company with higher pay than I had requested. I proved that I could program, and I didn’t need to write a single line of pseudocode on a dry-erase board. The proof was in my app.

The Interview Protocol

From the interview experience I have gained over the years, I have noticed patterns. Most software companies have similarities in the way they interview candidates. They can be described as follows:

  1. Provide the candidate with a dry-erase marker and board.
  2. Have the candidate answer an algorithm and/or data structure question.
  3. Repeat Step 2.

The Question

Each company is different, but the questions are relatively the same. One question that caught my ear was the following:

“How do you know if a linked list is circular?”
1. Linked List
A linked list is a programming data structure. It is a collection of data in which each element points to the next creating a sequence.

This question gives insight on multiple things. It might give insight on the candidate’s knowledge about data structures, algorithms, and problem solving skills. This question is great. I truly mean that, but the answer can also be looked up on Google. To prove the point, I did look it up on Google. As can be seen from the quick google search, at the time of this writing, this search returned 8,360,000 results in 0.77 seconds. Also note, the very first link has the answer to the question. If anyone ever needed to figure this out in the real world, it would only take 10 seconds to find the answer, and that is being pretty generous.

2. https://www.google.com/search?q=how+to+know+if+your+linked+list+is+in+a+loop&oq=how+to+know+if+your+linked+list+is+in+a+loop&aqs=chrome..69i57.9549j0j1&sourceid=chrome&ie=UTF-8

Pretty much any algorithm or data structure question can be easily answered with a quick Google search. Because of this, I honestly don’t care if a person can solve these types of questions. Actually, in all my years of programming, I have never needed to ask a question on any forum. Every question I have ever had that related to programming has been solved with a Google search.

Because of instant gratification from Google, we need to ask more relevant questions to today’s programming methodologies; questions that will relate to everyday life as a developer. The following question would be a good one to ask:

When programming in a team environment, you are tasked to add a new feature, but you know this new feature will break someone else’s code. Which of the following describes the steps in which you take?
A. Program your feature and push to master instantly.
B. Create a new branch for your feature, program it, and tell the person whose code broke to fix their feature on your branch when they have time.
C. Create a new branch, program your feature, have a code review on it, and merge it into master after a week without notifying anyone. Even though this is going to break master, this feature is really important, and it has waited long enough for a merge.

If you answered either A or C, then I don’t want to work with you. Development is a team effort, and master should never be broken. We don’t want negative work when working in a team.

3. Version Control
The term ‘master’ relates to the main branch in the commonly used version control system, git. Version control is used for a variety of things in software development. Some include versioning and team collaboration.
4. Negative Work
Negative work is when one or more programmers programs a feature or a set of features that affects the team in a negative manner. This may include a new set of bugs, incomplete functionality, or just broken code. Negative work may mean that other people from the team might need to help debug or fix the code in question.

The Proposal

This world is ever changing, and interviewing shouldn’t be any different. In the past, it made sense to quiz candidates on algorithms and/or data structures. In some instances, it may still make sense, but let’s interview people like we are in the 21st century. Some or all of the following can be executed when interviewing a candidate. Here is the proposal.

The New Interview Protocol

Candidates usually have past experience in software development whether from school, work, or personal projects. Because of this, the interview protocol can be tweaked a bit. One or more of the following can be executed when interviewing a candidate:

The Projects
If applicable, the candidate can bring a computer or a demonstration of past projects. Both the interviewer and the candidate can then step through code, and questions can be asked in relation to the architecture, scalability, and reasoning behind some decisions made in the project. This is a great way to gear how a person programs and whether they fit nicely in the team.
The Real Life Situation
Put the candidate in a real life programming situation. Ask that favorite algorithm and/or data structure question, but allow them to look up the answer on Google. There is a vast amount of information out there. To ween though it and find the correct solution would be what a real life programmer would do. Do we really want coworkers and colleagues that are just book smart, or do we want problem solvers who use every resource possible to better the team? I’ll take the latter any day.
The Contract
If their resume looks good, and their code looks good, contract the candidate for a week or two. There is no better way to find out how a person interacts with the team than to actually work with said person. If it doesn’t work out, then so be it, but at least the candidate had a fair shot. Who knows, said candidate may be the person the company really needs.

This newly proposed interview protocol is wild, I know! Let’s be honest though, good candidates can be overlooked just because they didn’t answer a question perfectly. Many things have changed over time, and interviewing is no different.