If I can use Google to answer your questions, do I still get the job?
“I see you have SQL on your resume. What is a foreign key?”
“What does CSS stand for?”
“What is the difference between an interface and an abstract class?”
“Great, this concludes the technical interview. You’ll be hearing back from us with our decision sometime between tomorrow and never.”
If you’re a software developer, it’s likely that at least once during your career you interviewed for a position in which the technical interview was similar to the one above. You are asked a barrage of questions and are expected to produce the answers on the spot. Maybe you answer a couple questions correctly, then are thrown one or more you get wrong. You didn’t know something, and now you are penalized for it. If you weren’t very nervous before, you are now. You are given little to no feedback on how you were doing, and you leave the interview worrying and analyzing every detail. You wait for the call.
Here’s the problem: This type of technical interview is incredibly detached from reality. It’s as if this interview is lost 30 years in the past when access to such knowledge was more difficult. In this interview setting, you are basically alone and cannot leverage any resources or people to get the answer you need. But then you get the job and you typically have access to a team of other developers to help answer your questions. Also, technology has changed enough that anyone with a brain stem, 30 seconds and a Google search can tell me what CSS stands for, or what a foreign key is. It’s time to move on from this archaic way of conducting technical interviews, and take a different approach. I will walk you through a way of conducting technical interviews that places a greater emphasis on learning, creative thinking and potential, rather than merely relying on whatever knowledge the developer has when he or she walks through the door. Let’s begin the interview.
I want you to be comfortable. Interviews are notorious for being nerve-wracking and stressful. A few days before the interview even starts you will be notified that you will be paired with me for two hours. At this time you will be told to arrive prepared with a laptop to work on, a development environment set up of your choosing (Visual Studio, IntelliJ, Eclipse, whatever) and with a testing framework such as Google Test ready to go so we can write tests. The ball is in your court at this point. Do you love Visual Studio and have years of experience using it? Let’s use that. Is your favorite language C#? Let’s use that too. I want you to put your best foot forward and avoid getting hung up on small things such as trying to learn how to navigate around some development environment you’ve never seen or try to write code in a language you used once 5 years ago.
When you arrive for the interview, I treat you like a guest in my home. I’ll greet you at the door, introduce myself, offer you a beverage and ask if you’re ready to begin. When we find a place to work, I sit down next to you facing the same screen. This is important because even though it’s technically your interview, we’re working on the problem together. You’re the interview candidate, but that doesn’t mean I’m a brick wall and you get marked down for not knowing something. In this moment, I am your coworker and your peer. As I conduct the interview, I let you know that it’s perfectly fine to bounce ideas off of me. Have an idea but don’t know how to implement it? Awesome. Maybe I know the answer, or we can figure it out together. Can’t remember the syntax for writing to a file in Java? Google it. This is real life, not a school exam. I’m more interested in how you get the answer, not necessarily that you know it already.
I want you to succeed. I start the interview by describing a very simple problem, regardless of whatever you or I believe your skill level to be. More often than not, this happens to be Fizz-Buzz. This elementary program will tell me a great deal about your level of ability. I don’t necessarily care where your skill level is, it’s just a good gauge for the rest of the interview. Fizz-Buzz works as follows:
Write a program that prints the numbers from 1 to 100.
If the number is a multiple of 3, print Fizz.
If the number is a multiple of 5, print Buzz.
If the number is a multiple of both 3 and 5, print FizzBuzz.
I prefer this one because it only takes about 20 seconds to explain, its requirements are very easy to understand, and we can just get right into coding something. I have done the best I can so far to set you up for success. I will ask you to test drive this program, then let you take it away.
I want you to learn. If you are experienced in test driven development (TDD) you may burn through Fizz-Buzz rather quickly without much trouble, which is fine. More power to you. However, this tends to be the time where it falls apart somewhat and you will require a teaching moment. Sometimes people have little or no experience with TDD. I don’t really care about that. I’ll teach it to you!
Wait, what? I know, at first glance teaching something required of the job to an interview candidate during the interview seems odd. If he or she is applying for this position, we should expect them to have already mastered everything they need to know, right? If we look less at the skills someone claims to have, and more into how smart, motivated and creative someone is, learning a new language or a new way of writing software usually isn’t a problem.
Before we started writing Fizz-Buzz, I told you to test drive this program. I expect a test to be written first. The test should fail telling me that this particular piece of functionality is missing. Then we write the smallest amount of production code to get that test to pass. Finally, we refactor if necessary and repeat the process until Fizz-Buzz is complete. Let’s say you start writing production code first because your experience with TDD is nonexistent. I will stop you and explain how TDD works, and walk you through the process. I will do this not just with TDD, but with other aspects of this process that you appear to be having difficulty with. It’s fine to struggle, but it’s how we learn from the struggle that tells me the most about whether or not you’ll be a valuable member of the team.
I want you to adapt. We’ve just finished Fizz-Buzz and I’ve taught you a bunch of cool stuff. You were able to put those things into practice for the rest of the program. At this point, the two-hour interview is probably halfway over. I’ll ask if you have any questions or if anything is confusing, we can chat about the little program you just wrote and I will provide constructive feedback. I will let you know what you did well, and where I believe you need improvement.
At this point, we start another program. I’ll use the result of Fizz-Buzz to determine the difficulty of the second one. I’ll also let you know that we will most likely not finish the second program before the time runs out, and that’s fine. I want to make sure that the problem I give you has a clearly defined set of requirements that are easy to understand, regardless of how difficult the problem is because we have a limited amount of time. Fizz-Buzz has no real world application that I’m aware of, so I like to make the second program a little more relatable, which could include problems such as:
Score a bowling game.
Determine the cost of a babysitter for a night with varying costs depending on time worked.
Determine the change provided from a vending machine.
When we begin the second program, what I’m looking for is if you can put into action all the things I taught you during Fizz-Buzz. It is your time to show me that you’ve listened to all the feedback I’ve given you and put it into practice. I don’t expect it to be perfect or anything, especially if the first time you’ve seen something was less than an hour ago. If you are able to go from having no experience with TDD to showing that you can learn and pick it up with some confidence within a two hour interview, that’s a huge win in my book. Imagine what myself or anyone else on the team could teach you in a day or even a week!
I want you to know where you stand. A lot of times when you have an interview, the person conducting the interview merely tells you the company will call you at some future date with the results. I’ve known people who have gone to an interview, thought it went amazingly well, but were called only to be told they didn’t get the job, if they were even called at all.
There are more factors at play than just the result of your technical interview. However, I will at all times during this interview give you honest and direct feedback so that you know where you stand with the technical aspect. This part may get uncomfortable for some people because it involves some varying degree of confrontation. I will take about 10 minutes at the end of the interview to give you any remaining feedback. It is definitely easier for me to just say that the interview is over and send you on your way, but I wouldn’t be doing you any favors.
Ultimately, I will tell you upfront if I will recommend you for hire or not. I let you know that all the feedback I gave you I will pass on to the recruiter. I will not tell you one thing and the recruiter another. If I don’t believe you’re ready, then that’s the way it is, but I hope you at least learned something from the interview. You can use the feedback I gave you to brush up on your skills, and I will always encourage you to try again later. Finding the motivation in your free time to learn new skills is something to be admired as well. I will also happily answer any questions you have, thank you coming in and let you be on your way.
I am looking for the person that can take constructive criticism well, is motivated and willing to try new things, and can show an ability to learn quickly. If we had a good time during the interview, I will very likely enjoy working with you for 8 hours every day. If I found that you are a very teachable person, that will go a long way with me wanting to work with you. I certainly don’t want myself or any of my teammates to be frustrated on a daily basis trying to reteach the same thing over and over to someone who never seems to get it.
Just because you can produce the answers to a dozen random questions I ask about a particular technology, doesn’t tell me anything about how you work or learn. We need to take this type of technical interview and leave it in the past where it belongs, to be forgotten. Let’s move on and start seeing people for the qualities that make them great, not as a storage device that can remember a few Google-able facts.