The Definitive Technical Interview Guide
I just returned from six hours of interviewing at the beautiful, yet intimidating Microsoft Redmond master hive. Only four of those hours were spent in actual interviews; the rest is allocated for essential things like lunch and tours. The position I applied for was a summer internship as a Software Development Engineer in Test, or SDET, which I would summarize as a coding position where your primary objective is to break other people’s code with your code. Is Code Wars copyrighted? Never mind, it’s already being used.
Preparing for these interviews can be daunting. A seemingly endless amount of programming knowledge is at your disposal, so how do you prioritize what to learn and practice? To be perfectly honest, I haven’t really gotten the hang of this yet. To prepare, I wrote some implementations of quicksort and mergesort, cracked open my ADTs textbook, and fucked around with template classes to make array-based and node-based stacks.
I had four interviews, each with a single interviewer in a private room with a whiteboard. After formalities, they’ll ask you to work on some kind of problem, then you’ll have some kind dialogue as you work toward a solution. I’d say three out of the four interviews went very well. I had very nice discussions about interesting problems. The interview prep material provided before your interview highlights that the problem-solving process is what’s being observed, not whether your solutions are correct, never mind optimized. To an extent, I believe that’s true. Regardless, I really wanted to straight up kill anything they threw at me. It didn't quite work out that way.
One of my problems was on finding all paths in a graph between a start node and an end node. I wanted to say “Look man, I do graphics, not graphs,” but it’s generally a bad idea to make snide remarks at the interviewers. Graph problems can be notoriously challenging; what seems like a simple approach can be difficult to formalize, especially on the fly in an interview setting. I spent some of my interview preparation time looking at stacks, so I worked on a depth-first search solution that used stacks to solve the problem.
Long story short, parts of my shit worked and seemed to be on the right track, but I ran short on time and didn't have a working solution by the end of the interview. I was afraid of that, so during the process I asked plenty of questions and spoke out loud about the issues I was having and what I might do to approach them. My interviewer was helpful and pointed out useful things, but ultimately I still felt like I let him down. I’m hoping that the whole emphasis on process, not product is true.
The other three interviews felt like they went extraordinarily well. I’m not sure that my first interviewer even had a question for me. I mentioned that I worked in graphics and animation and he asked me to go on. So I did. I spent about 40 minutes talking about rendering, handling and skinning meshes, performing character animation, the model-view-projection matrix paradigm, you name it. I made sure not to go totally hog-wild and asked him a few times if he’d like me to keep going, and he said yes. I didn't really solve any problems, but I apparently gave an entertaining overview on some of the shit that I handle on a daily basis.
After the interview, he mentioned how his background was in physics, so some of the challenges I discussed for realistic rendering were easy to understand and interesting to him. It was a good way to start off my interviews, and it was a nice reminder that I really do find all of the shit I work on interesting since I had so much fun talking about it. I’m not sure that this was how he planned the interview to go, but he seemed pretty happy with it.
The other two interviews were far more oriented on testing. For one, I was told that my résumé wouldn't print on a network printer from the interviewer’s laptop, and I had to develop a way to find the problem using testing methods. With enough questions and clarification, I narrowed it down to an issue with the printing driver in his version of Windows.
The scenario he described was a real bug in Windows ME that they encountered during development, and it made for an interesting discussion on how testers try to pinpoint the precise area of failure. Another question from the same interviewer involved how I might test that two web browsers rendered a collection of websites identically, which was surprisingly fun to discuss and design.
The final interview was the easiest and most relaxed. I wrote and tested a function that evaluated whether two strings were anagrams, then we talked about some issues with testing cloud services between multiple devices. I felt extremely thankful for such a nice end to a long day.
With that in mind, here are some helpful hints for any technical interview!
Don’t study. You almost certainly won’t be tested on the very little that you attempt to cram in during the few days before your interview, so why bother?
Make as much small talk as possible. If you spend more time talking about the latest episode of "Once Upon a Time" or “those fuckin’ Mac users,” you have less time to answer their technical questions and screw up!
Don’t ask questions. It’s a sign of weakness and shows that you don’t have any confidence in your problem-solving skills.
Don’t talk. Figure out the problem entirely in your head or with illegible, microscopic handwriting on the whiteboard before simply stating, “I’m finished,” then sit down and stare at them until the interview finishes.
Eat and drink as much sugar as you can. You've got a long day! Sugarless foods and water only take up space in your body. It’s all about acquiring as much sugar as you can fit inside your skin for the longest amount of time.
Alternately, do the opposite of those things and have fun!
-Nick spent $1.23 on breakfast today because all he could manage to get past his nerves was a banana and some water.