How to Ace Interview

http://blog.gainlo.co/index.php/2015/10/23/7-red-flags-in-code-interview/

#1: No passion about the company/product

#2: Stop thinking

#3: Have trouble with big-O analysis

#4: Lack of confidence

#5: Crappy code

Someone may use variables that have never been defined previously, or put pseudo code in between.

Although you don’t need to remember all the syntax of C++ or Java, some common syntax like vector and list are better to be correct in your code.

#6: Late for the interview/bad signal

#7: Bad answers to why you want to join us

Some candidates may say that they want to join here because they didn’t have much chance to learn in their old companies or there’s no room to grow. This seems even worse if they came from some large corporations. If you are working at a company with 100+ employees, how could you say that you have few chance to learn any more?

“I’m getting bored with my old job” or “I just hate what I was doing previously” are also not good answers obviously. What the interviewer really want to hear is why you really want to join us instead of why you want to leave your previous company.

http://www.10tiao.com/html/142/201803/2650859606/1.html

六、积极主动

这个我自己理解是在回答问题时，可以将自己擅长的展示出来。比如简历里有写到「项目使用过 RPC」，那在回答项目中如何使用RPC的时候，可以描述一些 RPC框架的设计实现思路，例如「我大致了解过 Dubbo 是这样设计的」，和 「Thrift 有这些区别」,当然，这个时候面试官可能会问，有了解过 grpc么？ 你会怎么办？

此外，在讲述项目使用技术时，可以顺便将自己为什么这样做，为了什么选择使用这个技术，这样简历之外的丰富信息，才会让面试官更立体的了解，从而为「交流」打开局面。

https://www.interviewcake.com/article/python/coding-interview-tips
http://news.cnblogs.com/n/535496

Chitchat like a pro.

Before diving into code, most interviewers like to chitchat about your background. They're looking for:

• Metacognition about coding. Do you think about how to code well?
• 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 useful or painful?

You should have 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 should have done differently in a past project
• piece of trivia about your favorite language, and something you do and don't like about said language
• question about the company's product/business
• question about the company's engineering strategy (testing, Scrum, etc)

Nerd out about stuff. Show you're proud of what you've done, you're amped about what they're doing, and you have opinions about languages and workflows.

Communicate

Understand what kind of problem it is. There are two types of problems:

1. Coding. The interviewer wants to see you write clean, efficient code for a problem.
2. Chitchat. The interviewer just wants you to talk about something. These questions are often either (1) high-level system design ("How would you build a Twitter clone?") or (2) trivia ("What is hoisting in Javascript?"). Sometimes the trivia is 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, she'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'd get an answer in $O(n)$ time." 

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.

Say 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'd guess $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.

Slow the eff down. 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'll get stuck. Relax. It doesn't mean you've failed. Keep in mind that the interviewer usually cares more about your ability to cleverly poke the problem from a few different angles than your ability to stumble into the correct answer. 

When hope seems lost, keep poking.

Draw pictures. Don't waste time trying to think in your head—think on the board. Draw a couple different test inputs. Draw how you would get the desired output by hand. Then think about translating your approach into code.

Solve a simpler version of the problem. Not sure how to find the 4th largest item in the set? Think about how to find the 1st largest item and see if you can adapt that approach.

Write a naïve, inefficient solution and optimize it later. Use brute force. 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 do take a brief second to "think"—your interviewer might have already decided to give you a hint and is just 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 at least look at all of the items, so I can't do better than O(n)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."

Get your thoughts down.

It's easy to trip over yourself. Focus on getting your thoughts down first and worry about the details at the end.

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.

Clean up when you're done.
Walk through your solution by hand, out loud, with an example input. Actually write downwhat values the variables hold as the program is running—you don't win any brownie points for doing it in your head. This'll help you find bugs and clear up 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. These might include empty sets, single-item sets, or negative numbers. Bonus: mention unit tests!

Don't be boring. Some interviewers won't care about these cleanup steps. If you're unsure, say something like, "Then I'd usually check the code against some edge cases—should we do that next?"

https://www.quora.com/Are-you-expected-to-write-perfect-code-on-your-first-attempt-in-tech-interviews
When I ask you to write code on the whiteboard, what I am most curious about is your thought process. Therefore I vastly prefer people trying to 1) understand the problem well, and 2) develop an algorithm using drawings and examples, paying particular attention to edge cases. Only when we talked through all that, and both agree on the algorithm, should a candidate start to actually write code

 If you launch into writing your code, as opposed to developing the algorithm using examples, you are likely to make mistakes. You are skipping an important step -- the algorithm development. Writing code while at the same time thinking through the algorithm in your head is unnecessarily difficult in a high-pressure interview process.

For example write code to check if the array is a set of consecutive integers.
// for loop

1 2 3 4 5

for (int i =0;i<array.length; i++) {    if (array[i] !=array[i+1] - 1)        return false; } return true;

You are definitely have to write correct code in terms of handling corner cases and obviously it would be better to find bugs by yourself prior interviewer points out that. 

You are not obliged to write 100% correct code instantly, what I'd recommend is once you done with a draft, give a note to interviewer that you are not yet done and need to verify that code works as expected. Do not be in a hurry make sure you handle corner cases well, even better when you go through code mentioning that here you avoid NPE or index out of range exception or overflow. Come up with sample input data to your code and make sure that code produces result which is expected.
Once you go through examples and verify that all is good to your mind you can say interviewer that you are done.
In this case you show that you are very careful and tend to reduce number of bugs in a code and also while you are going through the code you can mention some details like you used this data structure or algorithm because of this and that.

I am going to refactor it, test it, and take suggestions from colleagues during code review.


Using the “Do You Have Any Questions?” Question

Redirect to a highlight – If an interviewer failed to address a particular strength or highlight of the candidate’s career, that can be corrected. “Do you feel my experience in PROJECT/SKILL would be valuable to me when working for COMPANY?” may bring the interviewer’s attention to an accomplishment or skill that the interviewer overlooked.

Demonstrate interest and insight

http://www.hiredintech.com/interview-strategies/5-do-s/
Tip 1: Diligently follow a process
Tip 2: Ask clarifying questions
Tip 3: Explain your thought process

Tip 4: Follow the hints from the interviewer
Tip 5: Keep an eye on the clock
Keep calm and stay positive

http://www.thegeekstuff.com/2013/11/interview-mistakes/
3. Less Interaction with the Interviewer
If you ever feel that there is something wrong with the question or if you have any other doubt then it is always advisable to talk to interviewer about it.

4. No Practice for Phone Interviews
5. Writing Messy Code

6. Hiding Your Approach
Interviewers are always interested in your approach to solve a programming problem. It is not expected that you would be able to solve each programming problem thrown to you. But, you are definitely expected to have correct approach towards the solution.
So, it is always advised to talk out your approach while solving a problem. This is a good way to keep the interviewer engaged.

7. Bad Naming Convention for Functions and Variables
8. Resume Filled with Technical Stuff You Don’t Know
9. Being Under-confident
10. Stressed-out and Deprived of Sleep
http://blog.hackerrank.com/3-ways-crush-technical-interview/
Readable, Maintainable, and Extensible Code: Can you write code cleanly and correctly? If not, then it’ll be hard to get you up to speed with the rest of the team.
Cultural Fit: Are you someone we see positively contributing to not just product, but also to culture?

Participate in Coding Contests
Justify Your Choices
Read Blogs for Company-Specific Advice

http://wdxtub.com/interview/14520850399925.html

• 面试的时候，人家给你两个选择，一定要选一个，分析清楚各种优劣即可
• 设计题的时候，一定要考虑 scale 的问题，并且要着重在这上面表现，多说一点，考虑各种情况。

https://mp.weixin.qq.com/s/YWS_vryCSr08UnlHOlJ4zA

过于谦卑

切勿“拍马”面试官，“过谦”自己。

我观察过很多的初入职场者，大多数人有这样一种心态：刻意放低自己，夸大对方。

初入职场者，往往会因为对方是自己的面试官，技术牛，经验多，而故意谦虚自己，并借此夸奖对方。你或许想谦虚一下，顺便说几句面试官的好话，以博取面试官的好感。甚至有时为了表示对面试官的尊重而“毕恭毕敬”。但事与愿违，这反而营造了一种不自然、拘谨的交流情绪。情绪是相互的，你的不自然拘谨，也会阻碍面试官和你自然的交流。你的过谦会让面试官认为是你的能力不行，你的拘谨，会被面试官认为是不善沟通，难以融入团队。所以，只有在放开、自然的状态下，面试官才能更好的去了解你。

面试最重要的是营造一个平等自然地对话状态。

自信不足

不知你是否见过这种现象：某些人技术不比你好，但却更容易拿到offer。

这种现象往往是因为一个人面试中表现的是否自信导致的。

自信很重要，你的自信表达，会让面试官也对你充满信心；你的唯唯诺诺，也会让面试官怀疑你的能力。

我知道很多面试者不愿意听面试官说这种话，但是面试官也是没办法。面试官更希望，即使这一系列的框架你都没接触过，只要你把相关的基础掌握扎实了有深度了，都是可以的。

学技术必须先有深度，再寻广度。

我为什么这么说呢？技术是最容易触类旁通的东西，一个技术掌握的有深度了，在学习其他技术，门槛极低。反过来，则不然。

简历上，只要把自己掌握牢靠有深度的技术写上就可以了。不要贪多，会一点就往简历上写。否则被问住，会大大折损你给面试官的印象。

面试官也没啥了不起，不卑不亢，平等自然交流最好。

问题回答不上来也不必灰心，保持自信，毕竟任何人都有没接触过的知识、不会的问题。

技术要掌握扎实，有些深度。你会的技术，就尽量不要让面试官把你问住。容易被问住的，就没必要写到简历上。