https://www.thegeekstuff.com/2013/11/interview-mistakes/
TO-Read
How to Break Into the Tech Industry—a Guide to Job Hunting and Tech Interviews
https://haseebq.com/how-to-break-into-tech-job-hunting-and-interviews/
http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html
Long-term warming up means: study and practice for a week or two before the interview. You want your mind to be in the general "mode" of problem solving on whiteboards. If you can do it on a whiteboard, every other medium (laptop, shared network document, whatever) is a cakewalk. So plan for the whiteboard.
Short-term warming up means: get lots of rest the night before, and then do intense, fast-paced warm-ups the morning of the interview.
1) Study a data-structures and algorithms book.
For instance, if they ask you about coloring U.S. states in different colors, you get major bonus points if you recognize it as a graph-coloring problem, even if you don't actually remember exactly how graph-coloring works.
And if you do remember how it works, then you can probably whip through the answer pretty quickly. So your best bet, interview-prep wise, is to practice the art of recognizing that certain problem classes are best solved with certain algorithms and data structures.
My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual. More than any other book it helped me understand just how astonishingly commonplace (and important) graph problems are – they should be part of every working programmer's toolkit. The book also covers basic data structures and sorting algorithms, which is a nice bonus. But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail. Almost every 1-pager has a simple picture, making it easy to remember. This is a great way to learn how to identify hundreds of problem types.
2) Have a friend interview you. The friend should ask you a random interview question, and you should go write it on the board. You should keep going until it is complete, no matter how tired or lazy you feel. Do this as much as you can possibly tolerate.
As for short-term preparation, all you can really do is make sure you are as alert and warmed up as possible. Don't go in cold. Solve a few problems and read through your study books. Drink some coffee: it actually helps you think faster, believe it or not. Make sure you spend at least an hour practicing immediately before you walk into the interview. Treat it like a sports game or a music recital, or heck, an exam: if you go in warmed up you'll give your best performance.
Mental Prep
You should go in humble, open-minded, and focused.
If you come across as arrogant, then people will question whether they want to work with you. The best way to appear arrogant is to question the validity of the interviewer's question.
Feel free to ask for help or hints if you're stuck. Some interviewers take points off for that, but occasionally it will get you past some hurdle and give you a good performance on what would have otherwise been a horrible stony half-hour silence.
Don't say "choo choo choo" when you're "thinking".
Don't try to change the subject and answer a different question. Don't try to divert the interviewer from asking you a question by telling war stories. Don't try to bluff your interviewer. You should focus on each problem they're giving you and make your best effort to answer it fully.
Some interviewers will not ask you to write code, but they will expect you to start writing code on the whiteboard at some point during your answer. They will give you hints but won't necessarily come right out and say: "I want you to write some code on the board now." If in doubt, you should ask them if they would like to see code.
Interviewers have vastly different expectations about code. I personally don't care about syntax (unless you write something that could obviously never work in any programming language, at which point I will dive in and verify that you are not, in fact, a circus clown and that it was an honest mistake). But some interviewers are really picky about syntax, and some will even silently mark you down for missing a semicolon or a curly brace,without telling you. I think of these interviewers as – well, it's a technical term that rhymes with "bass soles", but they think of themselves as brilliant technical evaluators, and there's no way to tell them otherwise.
So ask. Ask if they care about syntax, and if they do, try to get it right. Look over your code carefully from different angles and distances. Pretend it's someone else's code and you're tasked with finding bugs in it. You'd be amazed at what you can miss when you're standing 2 feet from a whiteboard with an interviewer staring at your shoulder blades.
It's OK (and highly encouraged) to ask a few clarifying questions, and occasionally verify with the interviewer that you're on the track they want you to be on. Some interviewers will mark you down if you just jump up and start coding, even if you get the code right. They'll say you didn't think carefully first, and you're one of those "let's not do any design" type cowboys. So even if you think you know the answer to the problem, ask some questions and talk about the approach you'll take a little before diving in.
On the flip side, don't take too long before actually solving the problem, or some interviewers will give you a delay-of-game penalty. Try to move (and write) quickly, since often interviewers want to get through more than one question during the interview, and if you solve the first one too slowly then they'll be out of time. They'll mark you down because they couldn't get a full picture of your skills. The benefit of the doubt is rarely given in interviewing.
One last non-technical tip: bring your own whiteboard dry-erase markers. They sell pencil-thin ones at office supply stores, whereas most companies (including Google) tend to stock the fat kind. The thin ones turn your whiteboard from a 480i standard-definition tube into a 58-inch 1080p HD plasma screen. You need all the help you can get, and free whiteboard space is a real blessing.
You should also practice whiteboard space-management skills, such as not starting on the right and coding down into the lower-right corner in Teeny Unreadable Font. Your interviewer will not be impressed. Amusingly, although it always irks me when people do this, I did it during my interviews, too. Just be aware of it!
Oh, and don't let the marker dry out while you're standing there waving it. I'm tellin' ya: you want minimal distractions during the interview, and that one is surprisingly common.
Tech Prep Tips
Algorithm Complexity: you need to know Big-O. It's a must. If you struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired. It's, like, one chapter in the beginning of one theory of computation book, so just go read it. You can do it.
Sorting: know how to sort. Don't do bubble-sort. You should know the details of at least one n*log(n) sorting algorithm, preferably two (say, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical, so take a look at it.
For God's sake, don't try sorting a linked list during the interview.
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview.
Trees: you should know about trees. I'm tellin' ya: this is basic stuff, and it's embarrassing to bring it up, but some of you out there don't know basic tree construction, traversal and manipulation algorithms. You should be familiar with binary trees, n-ary trees, and trie-trees at the very very least. Trees are probably the best source of practice problems for your long-term warmup exercises.
You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree. You should actually know how it's implemented.
You should know about tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.
Graphs
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons.
You should know the basic graph traversal algorithms: breadth-first search and depth-first search. You should know their computational complexity, their tradeoffs, and how to implement them in real code.
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance. They're really great for just about anything, from game programming to distributed computing to you name it. You should know them.
Whenever someone gives you a problem, think graphs. They are the most fundamental and flexible way of representing any kind of a relationship, so it's about a 50-50 shot that any interesting design problem has a graph involved in it. Make absolutely sure you can't think of a way to solve it using graphs before moving on to other solution types. This tip is important!
Other data structures
You should study up on as many other data structures and algorithms as you can fit in that big noggin of yours. You should especially know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem, and be able to recognize them when an interviewer asks you them in disguise.
You should find out what NP-complete means.
Math
Some interviewers ask basic discrete math questions.
We're surrounded by counting problems, probability problems, and other Discrete Math 101 situations, and those innumerate among us blithely hack around them without knowing what we're doing.
Operating Systems
This is just a plug, from me, for you to know about processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about deadlock and livelock and how to avoid them. Know what resources a processes needs, and a thread needs, and how context switching works, and how it's initiated by the operating system and underlying hardware. Know a little about scheduling. The world is rapidly moving towards multi-core, and you'll be a dinosaur in a real hurry if you don't understand the fundamentals of "modern" (which is to say, "kinda broken") concurrency constructs.
Concurrent Programming in Java
https://www.nczonline.net/blog/2015/09/my-favorite-interview-question/
Suppose you could design your dream job that you'll be starting on Monday. It's at your ideal company with your ideal job title and salary. All you have to do is tell them what you want to do at your job and you can have it. What does your job entail?
Sometimes the scope of this question is too big for people to grasp and they get stuck. The enormity of defining any job they want can be overwhelming to certain people, and if that happens, I ask some followup questions to send them down the right path:
Let's start very simple: do you want to be writing code all day? If not, what else would you like to be doing?
Would you be working alone or on a team? If on a team, what role would you play on that team?
Is there a programming language you'd like to be spending most of your time in? What percentage of time would you need in that programming language to be happy?
Let's turn this around: what would you absolutely not want to do?
Is there something you'd like to spend time learning on your new job?
Leader vs. follower
The key phrases I look for in determining if someone is a leader are:
I like to help other people
I feel like I have a lot of experience to share
I don't mind/I love mentoring others
Time spent
At some point during the discussion I usually ask people to break down how much of their time they'd like to spend on any particular task. Do they want a 50/50 split between coding work and management work? Do they want to spend 70% of their time designing and architecting and only 30% doing actual coding? Are they a manager who wants to spend 10% of their time coding to "stay in the game?" These are all important to understand to get a full understanding of the person.
http://www.sitepoint.com/getting-hired-developer-tips-senior-recruiters/
http://blog.jobbole.com/94565/
怎么去简化和抽象问题，把问题拨出来分类或者分层讨论，同时他们还会试图把问题分解成不同的子问题逐个来讨论。
http://www.geeksforgeeks.org/top-5-common-mistakes-in-technical-on-site-interviews/
Mistake #2 – “Give me 5 minutes”
For instance, I won’t hire someone who has no idea about our company’s product even if he’s an expert in a specific technical area. On the contrary, I might hire someone who might not be very outstanding technically but is very passionate about our company’s mission and product. He might be a very active user and has a lot of critiques about how to improve the current product.
http://www.1point3acres.com/bbs/thread-170890-1-1.html
一道简单的二维字符表找字符串数量的问题，LZ一开始就知道用DFS，当时脑子秀逗了想直接最优，搞了个DP，结果没考虑到会路径循环重复的问题。。。写完后，三姐直接说了你的代码输出结果是错的。面完后心都碎了
这个面试题，我一看就知道用什么方法解最好，然后我直接跳进去写答案了。弄了一会，最后发现不对。然后面试被拒了。
基础知识要学得全面、至少有一定的理解；计算机基本知识不会光刷题没用。
2. 衡量下自己平时的水平，基本就可以评估自己面试时“做出来了”、“easy”、“秒了”到底是有多大把握。
说句有点打击人的话，如果某candidate平时的水平就是“遇见新题目无法自己解答”、“自己想了个解法和好方法差很远”、“自己以为对的跑出来经常是错的”，那面试时自己的良好感觉也没啥可信的吧。
一个简单一点的办法，就是在答任何一道题之前，就算是你闭着眼睛都能写出来的原题，都花1分钟把你的思路给面试官说一遍，等对方给出肯定的答复（或者至少是那种“那你写写看吧”的答复）以后再开始写code！然后全程写完一段以后都要回头和面试官交流一两句，说说你这两句是想实现什么，接下来要做什么。
面试官未必期待上来就bug free，最重要是把思路明白清楚地和他讲，脑子里平时默默想的都和他讲，他印象才会好 就算一紧张没做出来也要把脑子里的第一想法讲出来，反正也做不出来题，万一思路对呢
凡是用量衡量自己刷过多少题目的，基本都不是高手，最重要的是能讲明白理解到位，我也见到过刷80道题目，也照样找到工作的，主要是理解到位，能给面试官讲清楚，自己能在白板上写出来，基本是bug－free。初学者刷题一般上来就是想写code，而并非理性思考，为什么选择这个数据结构，他们经常讲数据结构和算法混起来。
我一般都会先跟面试官沟通，跑几个test case，看看自己题目理解是否到位。然后再说一个最straight forward的解法，然后优化。写code的时候关键变量会解释是拿来干嘛的，每个part之前都会说下是干嘛的。并非完全不沟通。再说了，我现在遇到新题，就算没见过，我一般都可以很快想出来(我平时刷题并非背题)
http://dongfei.baijia.baidu.com/article/52449
2. Don’t Just Memorize Code Snippets
3. Less Interaction with the Interviewer
4. No Practice for Phone Interviews
TO-Read
How to Break Into the Tech Industry—a Guide to Job Hunting and Tech Interviews
https://haseebq.com/how-to-break-into-tech-job-hunting-and-interviews/
http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html
Long-term warming up means: study and practice for a week or two before the interview. You want your mind to be in the general "mode" of problem solving on whiteboards. If you can do it on a whiteboard, every other medium (laptop, shared network document, whatever) is a cakewalk. So plan for the whiteboard.
Short-term warming up means: get lots of rest the night before, and then do intense, fast-paced warm-ups the morning of the interview.
1) Study a data-structures and algorithms book.
For instance, if they ask you about coloring U.S. states in different colors, you get major bonus points if you recognize it as a graph-coloring problem, even if you don't actually remember exactly how graph-coloring works.
And if you do remember how it works, then you can probably whip through the answer pretty quickly. So your best bet, interview-prep wise, is to practice the art of recognizing that certain problem classes are best solved with certain algorithms and data structures.
My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual. More than any other book it helped me understand just how astonishingly commonplace (and important) graph problems are – they should be part of every working programmer's toolkit. The book also covers basic data structures and sorting algorithms, which is a nice bonus. But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail. Almost every 1-pager has a simple picture, making it easy to remember. This is a great way to learn how to identify hundreds of problem types.
2) Have a friend interview you. The friend should ask you a random interview question, and you should go write it on the board. You should keep going until it is complete, no matter how tired or lazy you feel. Do this as much as you can possibly tolerate.
As for short-term preparation, all you can really do is make sure you are as alert and warmed up as possible. Don't go in cold. Solve a few problems and read through your study books. Drink some coffee: it actually helps you think faster, believe it or not. Make sure you spend at least an hour practicing immediately before you walk into the interview. Treat it like a sports game or a music recital, or heck, an exam: if you go in warmed up you'll give your best performance.
Mental Prep
You should go in humble, open-minded, and focused.
If you come across as arrogant, then people will question whether they want to work with you. The best way to appear arrogant is to question the validity of the interviewer's question.
Feel free to ask for help or hints if you're stuck. Some interviewers take points off for that, but occasionally it will get you past some hurdle and give you a good performance on what would have otherwise been a horrible stony half-hour silence.
Don't say "choo choo choo" when you're "thinking".
Don't try to change the subject and answer a different question. Don't try to divert the interviewer from asking you a question by telling war stories. Don't try to bluff your interviewer. You should focus on each problem they're giving you and make your best effort to answer it fully.
Some interviewers will not ask you to write code, but they will expect you to start writing code on the whiteboard at some point during your answer. They will give you hints but won't necessarily come right out and say: "I want you to write some code on the board now." If in doubt, you should ask them if they would like to see code.
Interviewers have vastly different expectations about code. I personally don't care about syntax (unless you write something that could obviously never work in any programming language, at which point I will dive in and verify that you are not, in fact, a circus clown and that it was an honest mistake). But some interviewers are really picky about syntax, and some will even silently mark you down for missing a semicolon or a curly brace,without telling you. I think of these interviewers as – well, it's a technical term that rhymes with "bass soles", but they think of themselves as brilliant technical evaluators, and there's no way to tell them otherwise.
So ask. Ask if they care about syntax, and if they do, try to get it right. Look over your code carefully from different angles and distances. Pretend it's someone else's code and you're tasked with finding bugs in it. You'd be amazed at what you can miss when you're standing 2 feet from a whiteboard with an interviewer staring at your shoulder blades.
It's OK (and highly encouraged) to ask a few clarifying questions, and occasionally verify with the interviewer that you're on the track they want you to be on. Some interviewers will mark you down if you just jump up and start coding, even if you get the code right. They'll say you didn't think carefully first, and you're one of those "let's not do any design" type cowboys. So even if you think you know the answer to the problem, ask some questions and talk about the approach you'll take a little before diving in.
On the flip side, don't take too long before actually solving the problem, or some interviewers will give you a delay-of-game penalty. Try to move (and write) quickly, since often interviewers want to get through more than one question during the interview, and if you solve the first one too slowly then they'll be out of time. They'll mark you down because they couldn't get a full picture of your skills. The benefit of the doubt is rarely given in interviewing.
One last non-technical tip: bring your own whiteboard dry-erase markers. They sell pencil-thin ones at office supply stores, whereas most companies (including Google) tend to stock the fat kind. The thin ones turn your whiteboard from a 480i standard-definition tube into a 58-inch 1080p HD plasma screen. You need all the help you can get, and free whiteboard space is a real blessing.
You should also practice whiteboard space-management skills, such as not starting on the right and coding down into the lower-right corner in Teeny Unreadable Font. Your interviewer will not be impressed. Amusingly, although it always irks me when people do this, I did it during my interviews, too. Just be aware of it!
Oh, and don't let the marker dry out while you're standing there waving it. I'm tellin' ya: you want minimal distractions during the interview, and that one is surprisingly common.
Tech Prep Tips
Algorithm Complexity: you need to know Big-O. It's a must. If you struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired. It's, like, one chapter in the beginning of one theory of computation book, so just go read it. You can do it.
Sorting: know how to sort. Don't do bubble-sort. You should know the details of at least one n*log(n) sorting algorithm, preferably two (say, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical, so take a look at it.
For God's sake, don't try sorting a linked list during the interview.
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview.
Trees: you should know about trees. I'm tellin' ya: this is basic stuff, and it's embarrassing to bring it up, but some of you out there don't know basic tree construction, traversal and manipulation algorithms. You should be familiar with binary trees, n-ary trees, and trie-trees at the very very least. Trees are probably the best source of practice problems for your long-term warmup exercises.
You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree. You should actually know how it's implemented.
You should know about tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.
Graphs
There are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons.
You should know the basic graph traversal algorithms: breadth-first search and depth-first search. You should know their computational complexity, their tradeoffs, and how to implement them in real code.
You should try to study up on fancier algorithms, such as Dijkstra and A*, if you get a chance. They're really great for just about anything, from game programming to distributed computing to you name it. You should know them.
Whenever someone gives you a problem, think graphs. They are the most fundamental and flexible way of representing any kind of a relationship, so it's about a 50-50 shot that any interesting design problem has a graph involved in it. Make absolutely sure you can't think of a way to solve it using graphs before moving on to other solution types. This tip is important!
Other data structures
You should study up on as many other data structures and algorithms as you can fit in that big noggin of yours. You should especially know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem, and be able to recognize them when an interviewer asks you them in disguise.
You should find out what NP-complete means.
Math
Some interviewers ask basic discrete math questions.
We're surrounded by counting problems, probability problems, and other Discrete Math 101 situations, and those innumerate among us blithely hack around them without knowing what we're doing.
Operating Systems
This is just a plug, from me, for you to know about processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about deadlock and livelock and how to avoid them. Know what resources a processes needs, and a thread needs, and how context switching works, and how it's initiated by the operating system and underlying hardware. Know a little about scheduling. The world is rapidly moving towards multi-core, and you'll be a dinosaur in a real hurry if you don't understand the fundamentals of "modern" (which is to say, "kinda broken") concurrency constructs.
Concurrent Programming in Java
https://www.nczonline.net/blog/2015/09/my-favorite-interview-question/
Suppose you could design your dream job that you'll be starting on Monday. It's at your ideal company with your ideal job title and salary. All you have to do is tell them what you want to do at your job and you can have it. What does your job entail?
Sometimes the scope of this question is too big for people to grasp and they get stuck. The enormity of defining any job they want can be overwhelming to certain people, and if that happens, I ask some followup questions to send them down the right path:
Let's start very simple: do you want to be writing code all day? If not, what else would you like to be doing?
Would you be working alone or on a team? If on a team, what role would you play on that team?
Is there a programming language you'd like to be spending most of your time in? What percentage of time would you need in that programming language to be happy?
Let's turn this around: what would you absolutely not want to do?
Is there something you'd like to spend time learning on your new job?
Leader vs. follower
The key phrases I look for in determining if someone is a leader are:
I like to help other people
I feel like I have a lot of experience to share
I don't mind/I love mentoring others
Time spent
At some point during the discussion I usually ask people to break down how much of their time they'd like to spend on any particular task. Do they want a 50/50 split between coding work and management work? Do they want to spend 70% of their time designing and architecting and only 30% doing actual coding? Are they a manager who wants to spend 10% of their time coding to "stay in the game?" These are all important to understand to get a full understanding of the person.
http://www.sitepoint.com/getting-hired-developer-tips-senior-recruiters/
http://blog.jobbole.com/94565/
怎么去简化和抽象问题，把问题拨出来分类或者分层讨论，同时他们还会试图把问题分解成不同的子问题逐个来讨论。
http://www.geeksforgeeks.org/top-5-common-mistakes-in-technical-on-site-interviews/
Mistake #2 – “Give me 5 minutes”
t’s highly recommended to talk while thinking instead of coming up with a “complete solution” after silence. There are various reasons for this.
First of all, this gives the interviewer a chance to help you. Believe it or not, most interviewers want to help candidates to pass interviews. By talking about your ideas, the interviewer is able to know your current progress and may give you some hints when you get stuck or are not on the right track.
Secondly, it’s safer to do so. In the worst case that after a while you may fail to provide a solution, you just waste a lot of time and the interviewer has no way to know what’s in your mind and how close you get to the answer. At the end of the interview, he could hardly write any feedback except that the candidate failed to come up with a solution.
Lastly, it’s a great chance to show your communication skills.
Mistake #3 – Crappy code on whiteboard
Some common mistakes includes:
- Pseudo code
- Incomplete code (no function/variable definition)
- No input validation
- Bad code style/naming
- Unclear handwriting
- Redundant code
Most tech companies won’t hire people without checking their code, so it’s for sure that you’re gonna be asked to write code in an on-site interview. The rule of thumb is that when preparing always write down your solution on a whiteboard or a piece of paper instead of in your mind.
Mistake #4 – Bad communication
For many companies, interviewers will evaluate candidates’ communication skill together with technical skill at the end of the interview.
However, many candidates didn’t pay enough attention to this point. They may be quite passive in the discussion, failed to articulate their solutions clearly and ignored basic etiquettes like eye contact. Part of the reason is that they were too nervous in an on-site interview and forgot almost everything.
One suggestion is to pay attention to communication in your preparation. You can keep talking about your idea when thinking even if no one else is there. Or have mock interviews with your friends or some experienced people to practice this, which is also highly recommended.
Mistake #5 – No enthusiasmFor instance, I won’t hire someone who has no idea about our company’s product even if he’s an expert in a specific technical area. On the contrary, I might hire someone who might not be very outstanding technically but is very passionate about our company’s mission and product. He might be a very active user and has a lot of critiques about how to improve the current product.
http://www.1point3acres.com/bbs/thread-170890-1-1.html
一道简单的二维字符表找字符串数量的问题，LZ一开始就知道用DFS，当时脑子秀逗了想直接最优，搞了个DP，结果没考虑到会路径循环重复的问题。。。写完后，三姐直接说了你的代码输出结果是错的。面完后心都碎了
这个面试题，我一看就知道用什么方法解最好，然后我直接跳进去写答案了。弄了一会，最后发现不对。然后面试被拒了。
根据他们的反馈，面试官没指望你技术上灭绝群雄，尤其是刚毕业的学生。面试官希望你跟他沟通，面试有来有往，上来二话不说闷头就写代码最糟糕。
很不幸，很多同学恰恰就是上来就闷头写答案，让面试官觉得很无语。如果你能做出来，还ok，如果做不出来，这就是最找死的一种方式了。有些时候，面试官甚至把题目做点小变化，或者是有意无意把题目说模糊点，让你想当然的以为是某种情况，一头跳进去，折腾一番发现跟想象的不一样，结果就是稳稳的拒掉你了。
. visit 1point3acres.com for more.
我们通常说中国人缺乏软技能（Soft Skills），这就是最典型的情况：不是你使用的方法好不好、对不对，而是你不跟别人交流。最可悲的是，你挂了都不知道到底挂在什么地方。这位同学在上下文里还说了印度人，根据他提供的信息来看，我觉得中国人面试官也会拒掉他。
最神奇的就是前几天bloomberg onsite。。。前两轮面试非常简单就是leetcode easy水平，LZ都轻松做出来了，但是面了两轮就被人领了出去。。。简直吐血。
公司叫你去面试的目的是什么？招人。每轮面试对公司来说，都耗费资源，都要烧钱，他们的目的不是溜你玩。两轮面试题你都做出来了，但是被轰走。为什么？我觉得不是公司变态，我头脑中浮现的是这样一种形象：愣头青一根筋的上来就写code，如此的不知道跟人交流，对面试官给予的提示也意识不到，以至于人家觉得没必要跟你继续浪费时间，直接踢你走。
. 涓€浜�-涓夊垎-鍦帮紝鐙鍙戝竷
我不认识这位同学，不知道详情，但是据很多面试官跟我反馈：经常遇到给了提示也没反应的中国学生，面试不到10分钟，就断定要拒掉此人了。
刷题到了一定程度，就没用了。基础知识要学得全面、至少有一定的理解；计算机基本知识不会光刷题没用。
2. 衡量下自己平时的水平，基本就可以评估自己面试时“做出来了”、“easy”、“秒了”到底是有多大把握。
说句有点打击人的话，如果某candidate平时的水平就是“遇见新题目无法自己解答”、“自己想了个解法和好方法差很远”、“自己以为对的跑出来经常是错的”，那面试时自己的良好感觉也没啥可信的吧。
一个简单一点的办法，就是在答任何一道题之前，就算是你闭着眼睛都能写出来的原题，都花1分钟把你的思路给面试官说一遍，等对方给出肯定的答复（或者至少是那种“那你写写看吧”的答复）以后再开始写code！然后全程写完一段以后都要回头和面试官交流一两句，说说你这两句是想实现什么，接下来要做什么。
面试官未必期待上来就bug free，最重要是把思路明白清楚地和他讲，脑子里平时默默想的都和他讲，他印象才会好 就算一紧张没做出来也要把脑子里的第一想法讲出来，反正也做不出来题，万一思路对呢
凡是用量衡量自己刷过多少题目的，基本都不是高手，最重要的是能讲明白理解到位，我也见到过刷80道题目，也照样找到工作的，主要是理解到位，能给面试官讲清楚，自己能在白板上写出来，基本是bug－free。初学者刷题一般上来就是想写code，而并非理性思考，为什么选择这个数据结构，他们经常讲数据结构和算法混起来。
我一般都会先跟面试官沟通，跑几个test case，看看自己题目理解是否到位。然后再说一个最straight forward的解法，然后优化。写code的时候关键变量会解释是拿来干嘛的，每个part之前都会说下是干嘛的。并非完全不沟通。再说了，我现在遇到新题，就算没见过，我一般都可以很快想出来(我平时刷题并非背题)
http://dongfei.baijia.baidu.com/article/52449
我总结成3C (Culture, Communication, Curiosity)，下面也展开一些重点。
技术：平常扎实的技术积累，包括系统知识点，不同编程语言，开源工具，团队合作工具，比如, Restful架构有哪些特点，动态语言的优劣。我在知乎上也给出了硅谷跳槽工具箱指南
基本功：代码简洁优美没有bug，常见算法的应用，优化技巧，比如如何把一个O(n^2)的算法优化成线性。好的编程习惯一定要坚持，格式：缩进可以良好排版，括号要对齐，变量名起的有意义。边界检查，参数检查，异常处理，单元测试。主动写出合理的Test case，一些常见的null检查。不管你之前做过多少年，只要申请工程师职位都要经历过编程的基本考核。
交流：实技术人员用到的英文都比较浅显，听和读应该问题不大，但最好在说和写方面下大功夫，这能突破一些天花板，更多融入团队交流。
系统设计：包括设计大型系统的架构选型，各种不同组件的tradeoff，数据库系统，网络系统，分布式系统。比如什么时候适合用NoSQL，如何做一个推送系统，缓存系统如何搭建。
问题：您在面试中会重点考察面试者除了技能之外的哪些点？面试者身上哪些特点往往会是各公司认为不能接受的？
首先，看背景是否符合职位的需求，比如做分布式计算的工程师，对系统底层，大数据架构就要有一些涉猎。
第二，聪明，如果我交流的时候发现他们能很快意识到我说的意思甚至补充我心里想的，这种人非常讨喜。如思路异与常人，很快给出最优解，能挑战一些难度大的问题。
第三，好奇和热情，如果面试者说不清为啥要申请，或者没啥主动提问的，我会觉得对公司兴趣不大，没有好好做功课，态度上不够积极，而就算最后技术很出色，在评价上也是要打折扣。另外如果他技术面很狭隘，技术兴趣不广泛，可能也要考虑是否能胜任创业公司不断变化的环境。
不能接受的
不愿意学习，对他说的或者写的很自大，但却不虚心接受其他人指出的问题和建议。
企业文化不合，对公司的使命和价值观有一些偏差，这个比技术功底更致命，主要是找志同道合的。
问题：面试中出了Bug怎么办？
BUG Free很重要，这个需要我们平时不断的练习，按照我们方法的准备，还是可以避免一些坑。但碰巧你可能不在状态，写出了BUG被面试官指出，是不是就挂了呢？
别担心，出BUG很正常，也许面试官来面你之前正在DEBUG:( 衡量一个程序员能力的标准，并不是他能想出多牛的算法（那为什么还要面算法题？）而是当遇到问题的时候，程序员去分析和解决问题的能力。而出BUG的时候，正是展现你是否是一个合格程序员的时候。
DEBUG流程：
1. 通过TEST CASE定位BUG所在位置
2. 不要立即修改代码，重新梳理逻辑。因为很有可能还有其他BUG。
3. 走完所有逻辑之后，心里有数怎么改了，再动手开始改
4. 用TEST CASE再走一次新的代码。
5. 在整个过程中，不停的告诉面试官你在干嘛（在不影响正常写程序的情况下）
这样，成功排解BUG，不但不会减分，还会因为你优秀的DEBUG能力和与此同时展现出来的沟通能力而加分。
http://www.1point3acres.com/bbs/thread-142380-1-1.html
我建议楼主永远不要说不enjoy work，这样非常negative，可以说what you enjoy about your work first, but you are looking for something more challenging/more collaborative environment/smarter people to work with etc。为什么跳槽也可以说当时想先积攒工作经验所以接了offer，但是一直的梦想都是大公司or uber。
http://instant.1point3acres.com/thread/144080
我建议楼主永远不要说不enjoy work，这样非常negative，可以说what you enjoy about your work first, but you are looking for something more challenging/more collaborative environment/smarter people to work with etc。为什么跳槽也可以说当时想先积攒工作经验所以接了offer，但是一直的梦想都是大公司or uber。
http://instant.1point3acres.com/thread/144080
