Virtually Interviewed
or “How to deal with Virtual Interviews in the era of WFH”
Who am I? Why am I telling you these things?
I’m a Software Engineer at Google, and I’ve conducted a lot of interviews, including a lot of phone screens in The Before Time. I’ve seen a lot of things that go well and go poorly in these interviews, and I’ve mentored and coached a lot of potential candidates on things to do to prepare themselves for the weirdness that is a technical phone interview. These are some of the things I want candidates to know, and they’re all just my personal opinions and not those of my employer.
When I applied to Google, I had been out in industry for ~5 years, and so had to study for the interviews. If you’re serious about getting a job at Google, unfortunately that likely means getting serious about studying for the interview. I boned up on graph algorithms, but I’ll be the first to admit that I haven’t used any of them in my every day work at Google. Study it anyway.
Prepare for the technical parts of your interview
I’m no Steve Yegge, so my first bit of advice is to read this whole blog post he did about getting a job at Google. Nearly all that advice holds in the virtual interview scenario (except stuff specific to whiteboards and markers).
The biggest thing I can encourage you to do is just to practice writing code in the format you’ll be using in your real interview.
Get Cracking the Coding Interview, and try out some problems. I did one problem from each section in that book, then lots more in the sections where I struggled (yeah — I did NOT remember graph algorithms). I also used homework problems from my old Data Structures and Algorithms text books. Those questions are pretty well-written, and can help reinforce specific concepts. However you do it, find questions that would take you about 20–60 minutes to solve. If they’re a little shorter or longer than a real interview question, that doesn’t matter too much.
Get a friend to be your interviewer. Ideally, they’ll be someone with coding experience, and they can know enough about the problem to offer you useful hints and feedback. This is a tricky thing, so maybe settle for someone to have a solution sitting in front of them.
Now that you’ve got questions and a prompter, really try to solve the problems in front of another human. Write out your solution in the same format you’ll use in a real interview, in this case, Google Docs. Now try to debug your code by hand. Step through each line and see what each variable’s value is going to be. This is tedious AF, but you’ll probably catch a lot of bugs this way, and it’s the only debugger you’re going to have available to you in your interview.
Prepare for the awkward parts of your interview
Google Docs
Google Docs were not designed for writing code, yet here we are, asking people to write code in Google Docs so we can decide if they’re capable of writing code in real coding environments. That’s a thing we actually do.
So get comfortable with it. You’ll have 45 minutes to show your interviewer that you know your stuff when it comes to Data Structures and Algorithms (and maybe Systems Design too), so you don’t want your discomfort with the interview environment to overshadow your performance, or to become a distraction for you.
When you practice (and you’re going to practice, right?), use the same environment you’ll be using for your interview, in this case, Google Docs. You’ll probably be tempted to use your favorite text editor or IDE, since it’s right there, but don’t use it just yet.
And while you’re at it, do these things:
1 — Use a fixed width font
Which looks more like code to you?
public void bubbleSort(int arr[], int n) {
// do a bubble sort
}
public void bubbleSort(int arr[], int n) {
// do a bubble sort
}You’re probably most accustomed to using an editor that uses a fixed width font. I don’t have any research to back me up here, but when what you’re typing looks more like code, you’ll probably be better at thinking of it as code.
Figure out what font you prefer (or go digging into the additional fonts to find your fit). There are two that are quickly available from the docs font menu: Consolas and Courier New.
2 — Know how to indent and use spacing
I’m a two-space indent kind of gal. You might like to hit tab. You might even like CTRL+]. I’m not here to judge. Just know that Google docs isn’t going to handle indentation for you, but indentation will help you and your interviewer understand what your code is doing.
Your interviewer isn’t likely to ding you for having sloppy indentations, but if you can’t figure out what nesting level some line of code is, you’re going to have one hell of a time debugging it. You’re better off spending two minutes in your interview finding and fixing your off-by-one error than struggling to make your spacing look pretty.
And that’s not just for code. If you’re talking about traversing a grid, or using a 2-d array, drawing it with ascii art and spacing is waaaay trickier than being able to quickly create a table. Which XOR table looks like it took more time to draw?
0 1
0 | 0 1
1 | 1 0
The first one. The first one took way longer, and I’m still very unhappy with how it looks, and might be thinking about fixing it for the next half hour (see how that might hurt you in an interview?). The second one was made with the Insert > Table > 3x3.
Knowing how to make these kinds of diagrams quickly can save you time when you’re discussing your algorithm, and let you stop thinking about it once you start writing code.
3 — Turn off auto-capitalization
Otherwise, you’ll spend half the interview backspacing to fix errant auto-caps.
Again, which looks more like C++?
public void bubbleSort(int arr[], int n) {
bool swapped = true;
int j = 0;
}Or this:
Public void bubbleSort(int arr[], int n) {
Bool swapped = true;
Int j = 0;
}If you don’t know about C++ that’s ok, but keywords don’t generally start with capital letters. You can turn this off via Tools > Preferences… > Automatically capitalize words.
4 — Don’t use Print Layout
I’ve had candidates suddenly get disoriented after typing a particular line of code, and afterward I realize it’s because that new line is appearing on a different page from the rest of their code sample. Print Layout can be really useful if you’re writing a term paper and want that feeling of satisfaction when you’ve hit page 5, but not so much in the middle of a while-loop.
Go to View and make sure that Print Layout is unchecked. If it’s checked, click it to toggle. Now, when you go to a new page, you’ll just see a dotted line instead of losing 3 inches of screen real estate.
Ok. You don’t have to do this part, but it might give you some more confidence. When you’re practicing these problems, and you think you have a pretty good solution, copy your work into a real dev environment and try to build it. You’re checking to see if it really compiles and runs. Chances are, it doesn’t. See what kinds of syntax and logic mistakes you’re making a lot of so you can try to get ahead of them. Always mess up the order on your for-clause things? Do you often forget to declare and initialize your temp variables? Know that you’re not alone, but you can learn this about yourself, and then try to practice practice practice those mistakes away.
Google Draw
Sometimes, you just need to draw a diagram to convey how a system works. Back when a friend was getting his Master’s in CS, he called it “Advanced Box and Arrow Drawing”. It’s just a part of what we do.
You can use Google Draw to make a system diagram, or even a quick sketch of something. If you want to go this route, you should start practicing now. This takes a lot of practice to be able to get an understandable drawing quickly and efficiently.
For example, the below diagram took a full 60 seconds for me to draw, and there’s not a lot happening. Drawing it with pen-and-paper was about 8 seconds. Those 52 seconds aren’t a huge deal, but just imagine if you had something actually complex to describe.
Know which strategy is easier for you.
One thing I’ve started doing in my own meetings lately is to just always have a pen and post-it nearby. I can just draw what I’m talking about, then hold that post-it up to the camera, give it a second to adjust focus/contrast and start talking about it.
If you have a whiteboard, you might be tempted to use it for this purpose. Don’t. The contrast is just too hard to pick up, unless you have a high quality webcam, a high quality internet connection, and are sure that your interviewer also has a high quality internet connection (this isn’t always a guarantee, even with well-compensated Google engineers!).
Google Meet
This is how you’re going to be interacting with the interviewer, so make sure you’ve used it before. Know how to mute/unmute yourself quickly (maybe you get nervous farts or whatever, it happens). Hint: it’s CTRL+D.
This might sound silly, but make sure your webcam and mic work. Pick a spot that doesn’t have a lot of noise and has good lighting for a video chat. You’ve been quarantined for a few months now — you should know exactly which spots in your home have these characteristics.
Day of the interview
Some unordered quick tips:
- Be honest if the time doesn’t work for you anymore. I’ve had an interviewee whispering because they were at work and they couldn’t leave. Is there construction happening right outside your apartment and you can’t be heard on the mic? You’re going to have a hard time, and rescheduling might be easier for everyone. Know when your interview is, and be realistic about your ability to devote your full attention to the interview.
- Double-check that your webcam and mic are working.
- Remember to talk throughout the interview. Don’t be afraid to to throw out weird ideas. You won’t be dinged for something being wrong — you’ll be rewarded if you can figure out why you’re wrong and propose alternatives that are better.
- Don’t worry about being super-formal, and I’m not just talking about your attire. You don’t need to call us Sir or Ma’am unless you really want to. We’re just humans, and pretty casual ones at that.
- Stay hydrated, and don’t hesitate to ask for a bio-break if you need one.
The most important resource (and probably most underutilized) in the interview environment is the interviewer themselves. They’ve walked through this question dozens (maybe even a hundred) times. They know this question inside and out. That means that if you have no idea what you’re doing, they know just the right hint to give you to get you started or back on track. They know a lot of the ways that you can go down an unproductive rabbit-hole.
They also know a lot of ways that you can introduce bugs or bad assumptions. They’ve got lots of counterexamples and they’re probably itching to give them to you. If they’re asking you a pointed question, chances are that they’re really giving you a gentle hint. You hear “how does your solution handle input like XYZ?”. They might be saying “you have a bug in your code with input like XYZ — please find it”. This isn’t always true, but I’ve seen it with some interviewers (yeah — we sometimes interview each other for fun, and I can get an idea of how other people are conducting their interviews).
After the interview
Breathe.
Really ask your recruiter if you have any questions. A big part of their job is to help you through the process, and they can’t do that if you don’t ask them questions and tell them any concerns you have.
If you had a positive or negative interview experience, PLEASE tell your recruiter. We can only get better at giving interviews if we know what’s wrong.
Final Words
None of this is intended to make you better at coding. I can’t do that. This might just make you more comfortable and save you some time and mental energy in your virtual interview. The point of the interview is showcase what you know about data structures, algorithms, system, whatever. It’s not to see how well you do writing code in an environment that was never meant to have code written in it.