Coding Interview Advice
How to improve your performance in technical interviews without practicing?
Chitchat like a Pro
Before delving into code, most interviewers like to have a casual conversation about your background. They’re looking for:
- Metacognition about coding. Do you think about how to write good code?
- Ownership/leadership. Do you see your work through to completion? Do you fix things that aren’t quite right, even if you don’t have to?
- Communication. Would chatting with you about a technical problem be productive or difficult?
You should be prepared to share at least one:
- Example of an interesting technical problem you solved
- Example of an interpersonal conflict you overcame
- Example of leadership or ownership
- Story about what you would have done differently in a past project
- Piece of trivia about your favorite programming language, and something you like and don’t like about it
- Question about the company’s product or business
- Question about the company’s engineering strategy (testing, Scrum, etc)
Nerd out about stuff. Show that you’re proud of your accomplishments, excited about what the company is doing, and have opinions about programming languages and workflows.
Communication
Effective communication is crucial during coding questions. A candidate who communicates well and asks for help when needed can be even better than a candidate who breezes through the question.
Understand the type of problem. There are two types of problems:
- Coding: The interviewer wants to see you write clean, efficient code for a problem.
- Chitchat: The interviewer just wants you to talk about something. These questions are often high-level system design (“How would you build a Twitter clone?”) or trivial (“What is hoisting in Javascript?”). Sometimes the trivial questions are a lead-in for a “real” question, e.g., “How quickly can we sort a list of integers? Good, now suppose instead of integers we had . . .”
If you start writing code and the interviewer just wanted a quick chitchat answer before moving on to the “real” question, they’ll get frustrated. Just ask, “Should we write code for this?”
Make it feel like you”re on a team. The interviewer wants to know what it feels like to work through a problem with you, so make the interview feel collaborative. Use “we” instead of “I”, as in, “If we did a breadth-first search we’dget an answer in O(n)O(n) time.” If you get to choose between coding on paper and coding on a whiteboard, always choose the whiteboard. That way you’ll be situated next to the interviewer, facing the problem (rather than across from her at a table).
Think out loud. Seriously. Say, “Let’s try doing it this way—not sure yet if it’ll work.” If you”re stuck, just say what you”re thinking. Say what might work. Say what you thought could work and why it doesn”t work. This also goes for trivial chitchat questions. When asked to explain Javascript closures, “It’s something to do with scope and putting stuff in a function” will probably get you 90% credit.
Admit what you don”t know. If you”re touching on a fact (e.g., language-specific trivia, a hairy bit of runtime analysis), don”t try to appear to know something you don”t. Instead, say “I”m not sure, but I’dguess $thing, because…”. The because can involve ruling out other options by showing they have nonsensical implications, or pulling examples from other languages or other problems.
Take your time. Don”t confidently blurt out an answer right away. If it’s right, you’ll still have to explain it, and if it’s wrong, you’ll seem reckless. You don”t win anything for speed, and you”re more likely to annoy your interviewer by cutting her off or appearing to jump to conclusions.
Get Unstuck
Sometimes you may get stuck during an interview. Don’t worry, this doesn’t mean you have failed. Remember, interviewers are more interested in your ability to approach problems from different angles than finding the exact solution. When you feel stuck, keep trying.
Draw pictures. Don’t waste time thinking in your head, think on the board. Draw different test inputs and how you would get the desired output with your own hands. Then, think about how to translate your approach into code.
Solve a simpler version of the problem. If you don’t know how to find the 4th largest item in a set, think about how to find the 1st largest item and see if you can adapt that approach.
Write a naive, inefficient solution and optimize it later. Use brute force if necessary. Do whatever it takes to get some kind of answer.
Think out loud more. Say what you know. Say what you thought might work and why it won’t work. You might realize it actually does work, or a modified version does. Or you might get a hint.
Wait for a hint. Don’t stare at your interviewer expectantly, but take a brief second to “think”. Your interviewer might have already decided to give you a hint and is waiting to avoid interrupting.
Think about the bounds on space and runtime. If you’re not sure if you can optimize your solution, think about it out loud. For example:
- “I have to look at all the items, so I can’t do better than O(n).”
- “The brute force approach is to test all possibilities, which is O(n^2).”
- “The answer will contain n^2 items, so I must at least spend that amount of time.”
Apply a common algorithmic pattern. There are a few patterns that come up again and again in the answers to these questions. Once you know the patterns, designing an algorithm is just a matter of trying a few of them and seeing which one sticks.
Write down your thoughts
When writing code, it’s easy to get bogged down by details. Instead, focus on getting your thoughts down first and worry about the details later.
Call a helper function and keep moving. If you can’t immediately think of how to implement some part of your algorithm, big or small, just skip over it. Write a call to a reasonably-named helper function, say “this will do X” and keep going. If the helper function is trivial, you might even get away with never implementing it.
Don’t worry about syntax. Just breeze through it. Revert to English if you have to. Just say you’ll get back to it.
Leave yourself plenty of room. You may need to add code or notes in between lines later. Start at the top of the board and leave a blank line between each line.
Save off-by-one checking for the end. Don’t worry about whether your for loop should have “<<” or “<=”. Write a checkmark to remind yourself to check it at the end. Just get the general algorithm down.
Use descriptive variable names. This will take time, but it will prevent you from losing track of what your code is doing. Use “names_to_phone_numbers” instead of “nums”. Imply the type in the name. Functions returning booleans should start with “is_*”. Variables that hold a list should end with “s”. Choose standards that make sense to you and stick with them.
Clean up when you’re done
- Walk through your solution out loud with an example input while writing down what values the variables hold as the program is running. This will help you find bugs and clear up any confusion your interviewer might have about what you’re doing.
- Look for off-by-one errors. Should your for loop use a “<=<=” instead of a “<<”?
- Test edge cases, such as empty sets, single-item sets, and negative numbers. It’s a good idea to mention unit tests as well.
- Don’t be boring. Some interviewers may not care about these cleanup steps. If you’re unsure, you can ask something like, “Should we check the code against some edge cases next?”
Practice
Practice makes perfect. The more you practice, the more comfortable you’ll be in an interview. You’ll also get better at recognizing the patterns in these problems and applying them to new problems.
Reference
https://www.interviewcake.com/coding-interview-tips