All I hear is the sound of breathing and the occasional clack of a keyboard. I stare into the screen, silently willing the pieces to fall into place and a sudden deluge of progress to come. But I have no idea what gears are turning in that small room halfway around the country which represents the other side of our virtual connection.
It's been like this for ten minutes. I ask a leading question about the approach but don't receive much back other than a brief explanation of the things I can already see in the code editor and then another lapse into into furious thought. I know exactly what the next ten minutes will look like while desperately wishing it was otherwise.
No one likes to get stuck in a technical interview. It's somewhere between getting a root canal at the dentist and public speaking on the list of life's unpleasant experiences.
While everyone can acknowledge how difficult it is to perform poorly as the person taking the interview, it's also worth thinking about how difficult it is to be on the other side of the process.
Now consider the opposite case:
She's talking through an edge case which wasn't handled properly by the current solution. I know exactly what she's getting at because she laid out her initial approach and has proceeded to systematically take it on. It's not a straight shot, but I can feel momentum building. Though she hit a few predictable dead ends at first, she was able to see the problem and shift tacks after a few probing questions.
I'm fully engaged, participating in each micro triumph and setback while knowing that the key insight is just around the corner. This is a familiar path. When it finally falls into place, I actually pump my fist and mouth "YES!", wondering briefly what the person passing in the hallway at that moment must have thought.
Why so emotional? It's just an interview, right? We're talking about the most hated of gatekeepers to any school, job, or partnership. How could it possibly be that painful or rewarding, especially to the person giving it?
The reason is that I want to see you succeed. With all my being, I want to see you come in, confidently say "hello", and then work with me to nail all the challenges I throw at you. There's nothing more rewarding in an interview than being able to help a candidate to navigate the deliberately obfuscated layers of a problem and see it all come together.
Firing up Skype and opening up our collaborative text editor is like getting into an unfamiliar car for a drive on familiarly challenging roads. You don't know whether you'll take off and find the responsive power of an Italian supercar, allowing you to become one with the road ahead, or if the shifter never quite makes it into 4th gear. It's a partnership where success is measured by the alignment of connection and performance.
I've written this post because I want to help you succeed in your technical interviews, whether for a school like Viking or a job later down the line. Make no mistake -- interviewing is an acquirable skill. In the end, you always need to know what you're talking about but there's no sense letting preventable mistakes cloud your interviewer's ability to see this.
The key insight here is to put yourself in the shoes of your interviewer and work backwards from there. I've experienced this first hand -- I was awful at interviews before I started giving them. There's something magical about understanding what's going on in the head of the person on the other side of the table which allows you to relax and focus on what matters.
In the next few sections, I'll lift the hood on this whole process and show you how to better prepare yourself to succeed. While it will naturally focus on factors most relevant to more junior candidates, you should find it useful regardless of your position.
Why we Interview
Everyone who interviews you does so because they want to make sure that you can add significant value to their team. Let me say that again -- as an interviewer, I don't care how "good" you are in absolute or on-paper terms, I want to make sure that you are good for us.
The manager of a software team, for instance, is hoping to hire you because they are overwhelmed with work and need someone to make their life easier. Especially as a less experienced developer, this means they need to be able to trust that you'll quickly grow into your role and begin adding significant value soon. This is less correlated with your grades in school or your ability to academically solve an algorithm and more with intangible factors that influence growth.
Here at Viking, we identify and train the potential software engineers who will soon need to excel in those production roles so we're looking for a similar set of criteria, just earlier in the timeline. As such, we need to know that you are highly competent, that you'll relentlessly grow your skills, and that we can work together well... essentially, whether you will become the exponential growth curve that leads to success in this industry.
That's a lot to figure out in a very short period of time, so all the things we do as part of our application process and particularly in the interview are designed to zero in on it. Though the exact characteristics defining your value to an organization will vary depending on that organization, we are looking specifically for Communication, Relentlessness, and Teachability.
How we Interview
There is an endless debate out there about how technical interviews should be run, whether that means giving trivia problems, focusing entirely on producing code, relying heavily on the whiteboarding logic problems, etc... (quite... literally... endless... thoughts... and continuous... debate...). Though we tend to focus on solving logical problems using code, I think success is most dependent on the quality of the interviewer and not the approach.
While some positions will require you to have a fixed level of pre-existing knowledge, a good interviewer knows you won't know everything and that you might not have had exposure to certain concepts. I've found it far more illuminating to understand how you react to things than how much you currently know. Your growth curve has a lot less to do with where you are now than how actively you expand and extend your knowledge in response to shortfalls.
That's why the interview isn't a fixed process. There isn't a script to read or a specific set of problems to give. If there was, we could do that with a purely automated process. Instead, my goal is to ensure that you are challenged enough that you eventually struggle.
I promise it's not done for sadistic reasons, but rather because that's the best way to understand the above-mentioned factors. You'll struggle almost daily when picking up challenging new concepts or tackling unrealistic deadlines, so I need to know that you use it to grow instead of making excuses and melting down.
What happens when you hit the wall? How do you respond to prompts? Do you communicate well or clam up and refuse to take input on your approach? Do you become discouraged or more determined? Are you passionate about learning something new? Are you comfortable with the underlying concepts or have you just been copy-pasting code until now?
Surviving the Interview
Now that you know where I'm coming from, how can you use this to your advantage? I'll cover each of the three major factors I'm testing for in the sections below and how you can reverse-engineer it to help yourself.
You might go into a technical interview thinking it's all about solving code. That's wrong. The ability to communicate well and express passion for the subject can actually be more important than pure technical proficiency.
When we're first getting set up and making small talk, do you speak with energy like you're excited to get started or do you sound sullen and unhappy to be there? No one likes interviewing and it can throw the best of us off our game, but attitude is innate. If you come out with a positive attitude and give me the impression that you're looking forward to take on the upcoming challenge, I can't help but feel confident in your abilities before we even begin.
Once we've started, talk your way through things. Clarify the assumptions of the problem and then approach it deliberately. Even if you're the type of person who needs some peace and quiet to form coherent thoughts, you will hit seams in your flow and these are good times to walk through your thought process out loud.
This helps both of us because if I see potential issues with your approach, I might ask questions to get you to focus on a particular problem point. This could easily save you 15 minutes of silent pain going down the wrong path. Remember -- I want you to succeed but you need to give me something to work with. Without good communication in the interview, it's difficult to imagine that you'll be a good fit for working directly with teammates in the future.
I can't tell you how many times I've had an interviewee hit the wall on a problem and stop, saying "I'm stuck". Here's the thing -- I'm going to try to give you something just past your current abilities precisely so I can see how you react to this situation. These aren't logic problems you need to know the "trick" to, just procedural situations with direct correlations to reality so the solution is within your reach.
Real world development is rife with errors and debugging. What separates the productive engineers from the rest is a lower "time to fix bug". Getting stuck on an interview question is just like hitting a bug.
If you just throw your hands up in the air and say "I'd just Google it", you're dangerously close to saying "I need to go find some code to copy". Productive debugging hinges on diagnosing the issue at hand before exploring the potential fixes. This requires demonstrating an understanding of the underlying system and tools, and the same is true of an interview challenge question.
When you're stuck in a problem, I want to see you relentlessly pushing ahead. If you're working on a software project with a deadline in three days, you can't get stuck! "Stuck" implies a total lack of meaningful progress and a will to give up. It would be fine to ask another engineer for help, but you first need to identify the right questions to ask. Framing and asking the right questions isn't "stuck", it's debugging the problem and that's good progress.
So when you get stuck, take a step back and revisit your assumptions. Think through the high level strategy of the problem and verify that it's a useful approach. Figure out WHY you're not making progress and what that implies. If it's a code problem, walk step-by-step through a sample input and see where it goes off the rails. Once you've done this, you can ask much better questions and I will gladly work with you instead of having to react to a request for a life preserver.
"Teachability" is particularly relevant for our school since we need to know that you will work with everyone here to learn an insane amount of knowledge in a very short period of time. You first year or two on the job will be much the same. This isn't an individual's game, it's a team sport. You'll be working with other students and learning from developers every day so we need to make sure that your learning interface is open enough that you'll accept feedback and use it to grow.
There are often two types of people in interviews:
- Those who put their heads down and push forward with their thought process regardless of outside input. This may be a personality thing or just an indication of a lack of familiarity with the material.
- Those who accept feedback, consider it, and use it to improve their approach. This shows humbleness, good communication, and comfort with the underlying code.
In the interview, how you respond to prompts, hints, and leading questions tells a lot about your comfort, experience and personality. Remember -- you're going to get stuck, I promise. But I'm also going to lead you out if you're willing to accept my help. Practically speaking, that means that you should consider my questions carefully and use them to test or reevaluate your approach.
Protip: If I'm asking you a question, think it through before brushing it aside. I'm not just talking to fill the silence -- you probably have something wrong with your approach.
Preparing For The Technical Interview
There are also plenty of resources with conventional tips for preparing for the interview, which you can peruse at your leisure:
- How to Prepare for and Ace the Technical Interview (CIO.com)
- How do I Prepare for a Software Engineering Job Interview? *(Quora) *
- Preparing for a Google Technical Interview (Grouplens.org)
- How to Prepare Yourself for Programming Interview Questions (Stack Exchange)
- How to Ace your Technical Interview (Forbes)
- How to Prepare for a Technical Interview (Dan Dreams of Coding)
- How to Interview (Niniane Wang, 2006)
For my part, I'd like to impart three less conventional preparation tips that are relevant to anyone who wants to showcase their abilities in a technical interview:
Tip 1: Use a Rubber Duck
When you take on practice challenge problems like the type which you might expect in the interview, solve them by talking out loud. Get used to that awkward feeling of explaining your thoughts, because you'll need to do so in the interview.
A frequently advocated tactic for debugging is to put a rubber duck on top of your computer screen and speak directly to it ("Rubber Ducking"). This actually makes the act of speaking slightly less awkward and helps you get used to clearly stating your logic.
Dogs, goldfish, infant children and 90's GI-Joe action figures work well too.
Tip 2: Be One with the Machine
A common way to differentiate those who have real familiarity with the technology from those who don't is to see them operate without the benefit of an interpreter or REPL to run their code for them.
I frequently see this with beginners who are used to guess-and-checking their code by running it immediately. When I ask them to step through it as if they were the computer, they often have trouble following the variables through the logic. This is directly correlated with getting stuck later in the problem and having difficulties debugging later in the learning process.
For more advanced developers, the equivalent might be understanding the flow of a request through the framework or the guts behind a particular abstraction.
In both cases, that level of understanding shows the difference between someone who has written code and someone who has understood code.
So practice thinking through real problems piece-by-piece and debugging them without using the computer. Challenge yourself to guess the answer before you turn to Google so you can build up the resilience of your mental models.
Tip 3: Stretch Yourself
The only way to practice struggling is to struggle. Keep pushing yourself to take on challenges that are just past your abilities. This doesn't mean memorizing any fancy algorithms but rather to give yourself practice debugging and solving challenging problems.
So don't be content taking on things you're comfortable with. Build things that are slightly more advanced than you know how. Embrace that "I have no idea" feeling and get used to deconstructing the problem's assumptions to look for solutions. It's the only way to rapidly grow.
I hope you now have a better idea of what your interviewer is thinking and how you can take advantage of that. The best interviews I've ever had felt more like conversations than interrogations. You can train yourself to get better at achieving this. It just takes a little practice and maybe some talking to inanimate objects along the way.
The key is to remember that I want you to succeed, so, as long as you're communicating well and keep pushing forward with the problem, we'll both be pumping our fists by the end, thrilled that we have a match and can begin an exciting new phase together.
Special thanks to Michael Alexander and Jonathan Barcus for helping to debug these thoughts.