How to pass a Google interview as a C programmer

So you’re a C programmer. Maybe you hacked on the linux kernel or you worked on some embedded devices for the last N years. That’s great! But now you want to pass an interview at Google and you’re rusty in other languages. The good news: it is totally possible to rock a Google interview writing C code. Unfortunately, some of you have not rocked my interviews. So I’m writing this to help you!

[Before I continue, a disclaimer: I am, of course, speaking strictly for myself here, not for Google. I imagine this post applies to interviews at any big tech company, it’s just that I’ve been on both sides of the white board at Google. I’m not spilling any secrets here, not that there are any to spill — this is about letting you do your best, make your mistakes on the substance of the question rather than on the mechanics. Yeah, and an epistemic disclaimer, too: I have (obviously?) not actually tested the theory I’m providing here. It’s just a theme that really jumps out after you’ve been on this side of the whiteboard for a few interviews.]

At some point, if you’re interviewing for a technical role at Google, you’re going to write some code on a whiteboard. There are a few basic things that C programmers struggle with at this point. These are things that probably don’t bother you during your day-to-day programming life, but you’ve got limited time in an interview and you really want to come up with a technique that will let you spend the time solving the interview question and not struggling with the language.

Have a strategy for memory management

C programmers tend to be really stingy with memory. malloc stays in the toolbox until it’s absolutely necessary. I think this is partly because the language makes it hard, and partly because C programmers tend to work on things like kernels and embedded software where memory is scarce. Either way, this tendency works against you during an interview: often the problem you’re asked to solve involves some variation of making a tree or a hash table or a graph, etc. These things require memory! Maybe even more than fits on a single machine!

So, before you go to that interview, have a plan for how you’re going to allocate your memory. Hint: you can hide boilerplate in short functions and just describe to your interviewer what they do! (“I want to spend time on the problem and not boilerplate — I can write the body of this later if you like. ‘struct *frobber new_frobber()’ just calls malloc and does a cast…”)

Have a strategy for data structures

This is just like the above point, but for data structures. If your solution needs a data structure, invent an api for that data structure! Better yet, invent one for every data structure before you even go to the interview. You don’t want to spend your time figuring out what the API for a tree or a hash map should look like!

This is not cheating. C++ has the STL, and C has basically nothing standard — it’s up to you to produce something in a short amount of time. So figure out your APIs in advance, and maybe even practice writing them out by hand.

A related problem doing this review will solve for you: you really need to be familiar with the basic data structures. It’s not fun to watch someone shoehorn a problem into a linked list just because that’s what they’re familiar with.

If you like the C std lib, you can use it

I personally don’t care about bugs that you’d find instantly with the help of a compiler (other interviewers might, so maybe ask). But the C standard library has some functions that have surprising behavior, that the compiler may not catch (using void* as a type in many places doesn’t help). If you use these things, I may look for evidence that you’re aware of the surprising behavior. So, for example, if I ask for test cases, make sure you give ones that exercise the corner cases… The other approach you can take, if you’re not sure about the corner cases, is to say something like, “I know this library function does approximately what I want, but I’d probably go read the docs on it before actually using it.”

(I’d still be ready with those test cases, though!)

Wrapping up…

Think big when it comes to RAM. Use functions and invent APIs to abstract boilerplate, both for data structures, and memory management — if you find the latter helpful. Test the corner cases! Practice!

Note that this is a C-language addendum — not a replacement — for the standard advice. I found Steve Yegge’s Get That Job At Google helpful when I was preparing to interview. Now that I’ve been at Google for 3.5 years and have done a number of interviews of my own, I think it holds up quite well.

Good luck!

P.S. One last bonus idea: write the hardest part of the algorithm first.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.