How should I prepare for a coding phone interview?

Question

I'm going to write code during a phone interview in the next few weeks. The interviewer and I will use a collaborative text editor to both view the code. I have a few questions since this is my first time writing code during a phone interview:

1. What are common questions asked during this type of interview?

2. What are common gotchas in this situation? (for both interviewer and candidate)

3. Does the interviewer commonly write code too? (perhaps a function w/ an empty body)

Any other tips and advice is greatly appreciated!

Answer 1

1. FizzBuzz would be an example of a question though there are likely a number of other simple questions that could be given like reversing a string, implementing a priority queue, or finding an element quickly in a binary tree. You could be asked to refactor or debug some code for another possibility here.

2. Communication of requirements and what assumptions are you making in writing up your answer. Did you ask what is the most important quality of the solution,e.g. space complexity, time complexity, maintainability, ease of re-use, scalable, or size of code footprint? How well are you explaining why this is a good solution and are you showing that this does work as expected and handles all cases properly?

3. Perhaps as there may be some initial code that you are fixing for another idea of what could be asked here. If the interview is being done by a fellow developer, then I could see a pairing exercise here and thus there may be some coding done by the interviewer.

Answer 2

The biggest gotcha is that many people simply don't follow instructions. Listen CAREFULLY to the requirements, verify your understanding, then confirm each requirement in your final code.

If you really want to impress them, write a simple unit test before starting the code.

Answer 3

A few things to consider on what the interviewer might be looking for:

• What's your general approach to the problem? In other words did you understand the problem and have the right idea on how to solve it? Is your approach reasonable? - I.e. use not using an O(n²) algorithm where you can do O(n)
• Are you asking clarifying questions on things that are important but were not mentioned by the interviewer? (Don't just make assumptions).
• Can you refactor the code accordingly when new constraints are brought in by the interviewer?
• Did you think about boundary cases (i.e. null checks etc.) in your implementation and are you testing for them?
• Are you clearly communicating your approach and thinking as you go along?

Answer 4

I would suggest making sure that you are comfortable with whatever collaborative text editor it is that you are going to use. It sounds a bit silly, but if you are accustomed to auto-indenting by an IDE, and the text editor doesn't do that, it can rattle your brain a little at an inopportune moment. (Or, if you tend to subconsciously hit CTRL-S to save your work as you go, and that makes something funny happen, etc, etc.)

Personally, I find it difficult to write code without being able to run the code as I go. I'm jealous of people who can look at nested loop on a whiteboard and see the "off by 1" error, but personally I tend to find those the first time I actually run the code.

If you are like me and write better code when a) the environment behaves like an IDE and b) you can run the code you are writing, you might want to suggest that your interviewer check out theReq.com . It's a site designed especially to facilitate online coding interviews. Write code in an IDE-like environment, and compile your code as you go.

Answer 5

@BrokenGlass and @JB King did a good job, a gotcha that I recall was a C pointer question, the code given declared local variables in a function and returned pointers to the variables to the main body.

(Common mistake made by inexperienced coders I think)

Answer 6

As the previous answers stated in a couple of different ways, most interviewers are more interested in your approach to the problem, your thought processes as you formulate your solution to the problem, and how you are expressing your solution in code.

You might get a question that you might think is unfair in the context of a 30-minute phone interview, but if you manage to keep articulating your understanding of the problem, it can help prevent brain freeze. (The interviewer is not going to find the sight of a blank screen with a blinking cursor very helpful, nor the sound of muttered curses and tearing hair coming over the phone.)

One such question I got was, "Write a function that takes a number, an arbitrary base between 2 and 32, and prints out the number in that base." As I started to explain how I would implement the function using stringstream, the interviewer said, "Oh, and implement it using the modulus operator."

I'm afraid I froze and drew a blank. (I managed to avoid the muttered curses.) I didn't think the question was fair after the fact, because implementing the solution on my own after the interview was not trivial; but because I said nothing and typed nothing during the interview, the interviewer had nothing to go on.