How to Ace Code Interview

https://blog.usejournal.com/how-i-got-into-google-161c97913b8b

• The recruiter is your friend too! Before any interview, feel free to ask the recruiter for the format of the interview, expectations, preparation material, general tips, etc. This will really help you focus your attention to specific things because otherwise CS is a vast area to tackle.

https://medium.com/@samson_hu/how-to-pass-technical-interviews-4653ea9220e5

https://www.startupinstitute.com/blog/startup-interview-questions-its-a-trap-technical

1. Understand the problem - ASK QUESTIONS!!! Check your understanding by repeating back what you think you’re hearing: “If I understand correctly, you’re asking…” or “Is that like…?” Interviewers can give you more information or clarify something you may not understand.
2. Define the algorithm with a block diagram or a list of steps and check it with the interviewer.
3. Define use cases for the function to understand the code that must be written. Think of the corner conditions.
4. Slowly, methodically start explaining and writing code. Start off by defining the function with a return type (void, bool, int, string, etc) and inputs needed.
   1. Remember it’s “pseudocode” so don’t get caught up on syntax.  The more you talk, the easier it will be for the interviewer to understand your thoughts behind the code you’re writing and re-steer you/guide you if you’re slightly off
   2. Once code is written, run an example (test cases)
   3. Any bugs, find them before your interviewer does

http://www.gayle.com/blog/2016/3/coding-interviews-and-the-importance-of-perfection

Your whiteboard code is merely a code sample from which your interviewer will derive information. The information that I derive here is that you probably don’t use the built-in linked list class much. Do I care? Not even a little bit.

What about code like this?

int getMax(int[] array) {
 int max = array[0];
 for (int i = 0; i <= array.length; i++) {
if (array[i] < max) {
 max = array[i];
}
 }
 return max;
}

We have a few issues here.

1. This code will crash at line 2 if the array is null or empty.
2. The for loop starts at 0 when there’s no need for it to. It should start at 1.
3. The for loop goes through array.length. This will cause an exception every time.
4. The comparison on line 4 is backwards.

int getMax(int[] array) {
 int max = array[0];
 for (int i = 0; i < array.length — 1; i++) {
if (array[i] > array[i + 1]) {
 max = array[i];
}
 }
 return max;
}

This isn’t just carelessness. The code doesn’t even make sense algorithmically. I’m very concerned about that.

How You Identify and Fix Your Bugs

Many candidates panic when they find a bug. A particular test case reveals a bug, and then they make a quick fix. The “fix” resolves it for that test case, but perhaps doesn’t fix the true issue.

For example, consider this code to locate all instances of a string s within a string b:

int countSubstrings(String s, String b) {
 int count = 0;
 for (int i = 0; i < b.length() — s.length(); i++) {
String bSubstring = b.substring(i, i + s.length());
if (bSubstring.equals(s)) {
 count++;
}
 }
 return count;
}

At first glance, the code basically looks correct, but it’s not. (Did you notice the bug yet?)

Many candidates spot the bug when they throw in a test case like a = “xyz” and b = “xyz”. That’s when they notice that the for loop never gets executed at all.

http://blog.gainlo.co/index.php/2016/02/27/warning-are-you-a-slow-programmer-in-interviews/
When I say slow programmer, I’m not saying someone is slow in typing. More generally, I mean people who are slow in coming up the perfect code.

In a 45min interview session, you will have few minutes for introduction in the beginning and few minutes for questions at the end. As a result, you only get ~35min for coding questions!

Generally, interviewers will expect you to solve 2 questions per interview. Depending on the difficulty, you may need to write solid code for at least one questions.

Therefore, honestly ask yourself whether you can complete 2 coding questions within 35min. If the answer is no, you should definitely need to speed up.

It’s worth to note that some interviewer will only ask one coding question but with a bunch of follow-ups. If you are trying to evaluate whether you are too slow in an interview, don’t forget to take the difficulty of questions into consideration.

Also, remember that interviewers won’t let you know if you are slow. If you used up all the time for his first question, usually he would just say he finished all his questions although the second one never got a chance to ask.

#1 Write code before having a clear mind
This is the most common mistakes I’ve seen. A lot of people like to start coding immediately after they have a vague idea, which is extremely terrible.

I can easily predict what’s gonna happen next. The candidate will start coding and get stuck very soon as he needs to figure out a bunch of details. He may keep fixing his code for a while. At one point, he notices that the whole approach doesn’t work and he has to erase everything from the whiteboard.

This wastes tons of time although it looks like he moves fast! Spending few minutes to discuss your solution with interviewers is definitely worth the time.

#2 Over optimization
In other words, some people tend to complicate the problem. They will consider a bunch of production issues that is not necessary for simplified coding questions. For example, they may consider things like security issue, dead lock, integer overflow etc..

I’m not saying that you shouldn’t consider these issues. But it’s better to postpone this discussion after you’ve finished the simple solution.

#3 Reinvent the wheel

Sometimes you don’t actually need to implement everything. For instance, some common sorting algorithms or binary search are not required to code from scratch.

Do ask interviewers whether you really need to implement them. If the question is not focused on these algorithms, most likely you can just use them for granted.

Identify your bottleneck

Usually there are two parts of a coding interview – coming up with the right approach and writing solid code, it’s always better to figure out which is your bottleneck before the optimization.

If you are slow to provide a solution, it’s very likely that you don’t have enough practice. Once you have worked on tons of coding questions, you’ll come up with the right approach within minutes. In this case, I don’t have any better suggestion than practicing as much as you can.

If you find yourself slow to finish coding, you should really write solid code for every question you practice with. I’ve seen so many candidates who came up with an approach quickly but failed to finish the code within the whole session. Do write solid code (NO PSUEDO CODE!) while practicing. It’s totally different from “solving in your mind”.

Practice with a timer

if you are slow when practicing, there’s no chance you’ll be faster in a real interview.

Therefore, it’s highly recommended to put a timer aside when you practice with coding questions. You’ll realize how different it is for sure.

You may feel nervous or maybe excited. Either case is likely to slow you down. The point is that if you can mimic the same environment as a real interview when practicing, you should get a better chance

Naive solution first

Never hold back your solution when you think it’s too naive.

What is highly recommended is to tell your solution even if it’s not concrete yet. For many interview questions, it won’t be hard to come up with a basic solution like brute force. If you are concerned about whether it’s too naive, you can say something like “I know this is definitely not the optimal solution, but I’d like to mention that…”.

The biggest advantage is that you successfully proved that you can solve the problem at least with some approached. Also, the naive solution acts as a starting point, which helps you to keep optimizing it.

In addition, communication plays an important role in coding interviews. Even if the idea is vague, thinking loudly can be helpful to form more concrete ideas and interviewers are also likely to discuss more about it.

If you are familiar with Python, do consider use it in coding interviews.

The simple syntax sometimes can save you a lot of time, especially compared to Java.

Again, this is optional so that you definitely don’t need to learn Python from beginning just for coding interviews. Using a language you are not familiar with does more harm than good.

Typing/writing fast won’t save you much time. What’s more, bad handwriting may confuse both interviewers and yourself.

Also. never sacrifice your time of thinking and discussion as we said before. Moving slowly but steady is the best way to speed up.

http://blog.gainlo.co/index.php/2015/12/30/7-things-most-people-ignored-in-a-coding-interview/

#1 Big-O analysis

#2 Input validation

It’s a great habit to validate all your input, which is true for both production code and interviews. However, many people assume inputs are all validated without even asking.

As the robustness principle said “Code that sends commands or data to other machines should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear.”

So a practical suggestion is whenever you’ve written down the function definition, put input validation right after that immediately.

Another suggestion is to ask interviewers for clarification, which can save you from unnecessary checkings. For instance, you may ask if you can assume all inputs are integers. If the answer is yes, then you can skip the integer checking in your code.

#3 Check corner cases

In an interview, most people are a little bit nervous and want to finish the code as soon as possible. So it’s very natural that those solutions don’t take all situations into consideration.

A general tip is that you should always consider corner inputs when writing your solution, which is a great habit for experienced engineers.

Secondly, after you finish your code, it’s highly recommended to use few example inputs to test your solution and you can include several corner inputs.

Writing robust code is a skill that is developed through experience and real life projects. That’s why good engineers can write well-rounded solutions without even thinking about it.

#4 Clean code

First, you should have good handwriting on a whiteboard. Many people tend to write very fast in hopes of saving time, however they may waste more time to explain what they have written.

Not only does clear writing make it easier to communicate with interviewers, but it also makes the reader comfortable and happy.

Second, you should care about your coding style. I suggest everyone pay attention to this point as it’s both a low hanging fruit for interview preparation and a great habit for your work.

#5 Prepare questions at the end of the interview

At the end of each interview, you will get a chance to ask any question to the interviewer. In fact, it’s a great opportunity to further impress the interviewer.

It’s unlikely to happen that someone who failed to solve a single problem but got hired due to good questions. However, good questions can still make you stand out to some extent and give you some advantages, let alone that it doesn’t require a lot of time to prepare.

Questions to Ask At The End of an Interview has a detailed discussion about this. In a nutshell, you can ask questions about product, company culture or technical questions if you don’t have any idea now and you should prepare well before the interview.

#6 Be confident in communication

A lot of people are so nervous in an interview that they are even afraid of making a single mistake. As a result, they tend to be very unconfident in communication.

For example, even if they are quite sure about the time complexity, they could still say “I guess the time complexity might be O(n), I may be wrong though”. From the interviewer’s perspective, it seems that the candidate is not very clear about big-O analysis although he gave the correct answer.

However, I’m not encouraging you to be confident when you are not. The correct interpretation of this point is to be certain about things you know. Of course everyone can make a mistake and you don’t need to be afraid of that.

Also you will keep discussing with the interviewer so that you may still figure out the correct answer later.

#7 Smile

Don’t take an interview as a painful exam. Instead you should think of it as a chance to discuss interesting problems with someone else.

A lot of people look pretty “unhappy” from the beginning of the interview. They might be too nervous or they have struggled a lot to solve the problem.

However, as is known to all that your mode not only can affect your performance, but your interviewer’s feedback as well.