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.

Brag Your Way to Job Interview Success

https://biginterview.com/blog/2015/02/how-to-sell-yourself-in-an-interview.html

A job interview is unlike any other form of interaction. The interviewer wants you to communicate what makes you stand out from other candidates. His job is to pick the best candidate.

it’s about understanding what your key strengths are and being able to communicate them in a concise and compelling way.

the interview is also an exercise in positioning yourself for the position. You want to convey what sets you apart from the competition and how you could benefit the organization if hired.

Analysis

Understand what they are looking for and emphasize how you specifically fit those needs.

Sit down and list your top selling points. What do you want your interviewer to remember about you? Aim for at least five main points —these can be areas of expertise, key accomplishments, education or training, soft skills, personality qualities, and/or other strengths.

Step 3: Practice Until It Feels Natural

Here are some questions that provide useful openings for pitching your selling points:

1) Tell me about yourself — Most interviews open with this question or a variation (Walk me through your resume/background, etc.). This is an opportunity for you to start strong and steer the interview discussion to your strengths. Our article on answering the dreaded “Tell me about yourself” interview question will help you craft a great answer that incorporates your selling points.

2) Your strengths — Any question about your strengths is an invitation to share your selling points. Variations on “the strengths question” include:

• Why would you be a good fit?
• Why should we hire you?

3) Your role descriptions — Any decent interviewer will ask you about your most recent positions. Instead of just rattling off your duties, weave in examples that show off your key qualifications.

4) Your behavioral stories — Most interviews will include some behavioral questions (any questions that start with “Tell me about a time…” or otherwise prompt you for specific examples from your past). I work with all of my clients to prepare at least 3-5 strong stories that showcase their strengths and achievements

1) Stick with the facts. Instead of stating an opinion about yourself (awkward sometimes), present some nice objective facts that demonstrate your point.

Instead of: I’m a very strong writer.

Try: I’ve been published by Publication X and Z and was very excited to be selected for Writing Prize ABC during my senior year.

2) Quote somebody else. Sometimes it can feel less “braggy” to quote somebody else’s positive opinion of you. Truthfully, this approach can lend additional credibility even if you’re perfectly okay with tooting your own horn.

Instead of: I’m a very effective project manager.

Try: My manager told me that I am the best project manager at the company and the CEO specifically requested me to lead our highest-profile client engagement this quarter.

3) Push yourself out of your comfort zone. Give yourself permission to brag. Try writing your selling point bullets as if you were a brazen self-promoter. You can always dial it back later if the results feel obnoxious. However, I have seen many clients benefit from pushing themselves a little.

4) Get feedback from a trusted (and objective) advisor. Try it out loud with a friend or coach and get some honest feedback. You’ll likely find that you’re too close to the topic to evaluate without some outside perspective.

http://www.businessinsider.com/10-ways-to-talk-about-yourself-without-sounding-like-a-jerk-2014-3

• Being too humble can cost you. Not talking about your accomplishments can hit you in the pocketbook. “It’s those who visibly take credit for accomplishments who are rewarded with promotions and gem assignments,” writes Klaus. As our economy has resulted in less job stability, self-promotion has become more important. Even if you aren’t an entrepreneur, says Klaus, you need to think like one and start talking up your most valuable product: you.

http://www.careercast.com/career-news/brag-your-way-job-interview-success
"So, tell me about yourself."
"What are your greatest strengths?"
"Why should I hire you?"

One of the most important things NOT to say in a job interview is a form of the verb "to be" followed by some high-flown adjectives: "I am creative, bottom-line oriented, innovative, practical, kind, trustworthy, brave, clean, reverent and wholesome." This is unsupported self-praise – it's not true just because you say it is, and the interviewer knows it. Equally important, most of us feel squeamish uttering generalized self-praise, even if it's true. We're afraid it sounds arrogant, or lacks self-awareness.

Cut to the Chase

Remember that employers aren't interested in who you are, but what you can do. They're not buying abstract virtues; they crave stories about you in action, action that addresses their company's needs and wants.

The next principle is that you need to learn how to brag in the past tense. To put a finer point on it, employers want to know what you have already done. The fact that you've already accomplished something is evidence that you can do it again – for the next employer. Therefore, potential employers tend to be most impressed when you list your skills in past-tense action verbs. Consider these two sentences:

• "I am a very good project manager."
• "I have always performed best in situations that required strong project management abilities."

See the difference? Use those past-tense verbs! Wrote this. Directed that. Recruited and trained them. Conceived, planned, Implemented and trouble-shot that innovative initiative.

It further helps to use verbs that create a visual picture of you in action, as well as simply conveying meaning: "struck a balance among competing interests" instead of "mediated controversy," or "forged a powerful management team" rather than "hired skilled managers." If your personal vocabulary is short on action verbs, find a list online. And remember to have variety – don't fall into "Planned A, Planned B, Planned C," but instead find alternate forms of expression to keep things interesting.

In addition to all these "Do's," here is one very important "Don't": Don't use overly-fancy words.

Practical Tactics

Once you've learned how to brag in the past tense, try a few specific techniques on for size. One comfortable way to sing your own praises is to let other people do it for you. This could be called the "other people tell me" approach, and it sounds like this:

Well, my staff tells me they like working for me more than any of their prior supervisors because, they say, I'm fair, listen to their point of view, and provide clear performance values and feedback.

The source of such praise can be informal, such as "My mommy tells me I'm adorable," or it can be official: "I was named Salesman of the Year in 2005, 2007 and 2008." The awkwardness of self-serving praise is avoided by this technique because you're not the author of the favorable judgment about you. You're simply passing on what other people have said – or would say if asked.

Preferential Treatment

Another low-stress approach to talking about your strengths is to state them in terms of preferences. Consider these two statements:

• "I am an excellent trainer."
• "Of all the different things that are part of my job, I enjoy training the most."

Same content, utterly different impact. The first is a boast and will be discounted as such, while the second implies that you're motivated and enthusiastic – and people usually don't like things they do badly. Let your enthusiasm do the bragging for you.

Practice a few variations on this theme:

• "The kind of challenge I like best is..."
• "I really go for situations that require me to..."
• "There's nothing that gives me more satisfaction than..."

This technique has been battle-tested in interviews, and is unquestionably the easiest and most effective way to brag. Another version of this "I love to do it" approach is the "I'm really proud of it" approach. Statements of pride in past accomplishments can be powerful, because they suggest a strong drive to repeat the satisfaction:

When the crisis hit, I was able to assemble a new project team and revise the whole design in six weeks with no down time. I was proud of my people, and I'm proud of the outcome.

My strengths? Well, my performance evaluations have always rated me highly on strategic planning ability, and my boss has told me he trusts my ability to turn goals into practical objectives and action plans. I really like situations where get to translate theory into tangible outcomes. When it comes to implementing marketing campaigns, I'm comfortable collaborating with both the product development people and the sales force. In fact, I'm proudest of my track record in this area.

The Proper Sequence

When asked about their strengths, people often dump all their diverse features in the same bucket, listing them in random order. However, in an interview you're selling three distinctly kinds of value: your skills, your abilities, and your personal attributes. These are not the same, and should be discussed using separate terms. I suggest using the phrase "skills" to denote areas of subject-matter knowledge and technical expertise. You brag about them by saying, "I know..." (as in I know the new TARP regulations) or "I'm an expert at..." Note that young people can know technical skills just as well as older job-seekers: "I was just certified as..."

Abilities are different. They reflect things you've already done, and therefore presumably can do again. You talk about them not in terms of expertise, but in terms of experience (or the equivalent terms "judgment," "maturity" or "savvy"). While expertise usually refers to something specific ("I can write javascript"), the point of experience is that it translates from setting to setting, situation to situation. That's why career consultants often refer to experience as "transferable abilities." When bragging, it's important to distinguish skills from abilities. This will make you sound focused and articulate.

When talking about the third component that you're selling – personal attributes – it's usually best to separate these into two categories:

• Motivational drivers – interests, specialties, favorite tasks, etc.
• Comfort zones – the types of companies, settings, colleagues and tasks that inspire your best work

It's often hard to talk about your personal traits directly. However, discussing your past accomplishments and qualities required for each of them can be a great solution.

In general, sell yourself in this order: first skills, then abilities, then personal qualities. Your technical skills show that you're qualified for the job; you then talk about the broader, transferable abilities you've mastered through experience: leadership, planning, trouble-shooting, business judgment, etc. This category is particularly important to articulate clearly if you you're changing careers. Here's where you say, in effect, "if the employment settings are similar, then what I achieved in my previous career will apply to this one, too."

Last, but not least, bring out the personal traits and qualities that do the following:

• Distinguish you from other similarly-qualified job seekers
• Reinforce the "can do" impression created by your previous description of your skills and abilities

While this information is no less important, if you talk about soft, personal stuff first, you risk losing the interviewer's attention before you can wheel out your heavy artillery.

http://www.job-interview-site.com/how-to-sell-yourself-in-an-interview.html

Effective Whiteboarding during Programming Interviews

http://www.coderust.com/blog/2014/04/10/effective-whiteboarding-during-programming-interviews/

Notes and figures on the side

Use one corner of the whiteboard to note down the requirements you have heard or an example figure that your interviewer has drawn. As you are thinking and asking clarifying questions to your interviewer take notes there. These can just be one-word bullets to make you remember all the scenarios

Write Clearly

Try to write as clearly as possible while not slowing down a lot. Yes they are not interested in seeing your calligraphy skills BUT you are still writing this for someone else to read. It has to be legible. The cleaner you write the easier it is for your interviewer to understand. Design diagrams should also be easily understandable

Use the Space Efficiently

Several times, candidates start writing XL size code and then have to inevitably write in super small font cramming in many lines in a small area. Then they turn to use arrows to point to other parts of the board where they will write the remaining code.Avoid that. It’s hard to follow code written on different parts of the board.

When you start writing code for problems, remember that most interview problem solutions span at least 15 – 20 lines of code. You need to make enough room for this much content.

Adapt to the size of whiteboard on which you are going to solve the problem. Sizes of the whiteboard vary a lot even within different rooms of the same company. Always leave some room for potential edits e.g. extra parameters, null checks, trivial if conditions etc.

One pro tip to use space efficiently is to structure your code in small functions.

Edits are part of the game

Don’t be afraid to change code. Several times, interviewers would modify requirements to see how you handle a slightly different or challenging variation of the same problem.

You will also have to edit your code if you find a bug during testing. In such cases, instead of overwriting or crossing out code, it’s better to erase and re-write that part of the code