请问EB2 11/19/2015的PD，现在要怎样？# EB23 - 劳工卡
l*i
1 楼
对于面试做题，很多同学关心的是我做了多少真题，leetcode刷了多少遍，还有用特定
的programming language刷。个人感觉面试做题其实不完全是你写的code能不能
compile，能不能过所有的testcase，面试是一个跟人交流的过程，对方是在考虑这个
candidate是不是能跟自己，还有自己的team合作。一个什么都不问，听完题目， 甚至
题目都没有听完就开始敲code，或者在白板上开写的candidate绝对不是一个好的
candidate。一个好的面试过程应该是能让对方知道你的thinking process，你写code
的习惯，还有你跟teammate沟通的能力。有人说只要我写出bugfree对方能不让我过么
，这个还真不一定。一个是很难背熟150题，另外一个是如果面试官认真准备过他的题
，总能找到一些办法让你做一些extension。
下面是我总结的做题流程，抛个砖。
1. draw a picture
2. understand the problem, ask any questions if the problem is not clear. In
a programming competition, all the constraints will be clearly stated, but
in an interview, you have access to the interviewer, so it is your
responsibility to ask questions to clarify. The worst thing can happen in an
interview is to solve the wrong problem.
3. Come up with one or two example, simple enough so that it does not take
too much time. This also serves a context to clarify problem. You may also
use them as your testcases after you finish coding.
4. Write down data structures and function prototypes.
5. Decide key variable names and meaning. Surprisingly enough, good variable
names are hard to come up with, and it is not uncommon to confuse yourself
with different variable names, especially when you want to change them in
the middle of coding. The meaning of variables is essential in dynamic
programming, when you write dp[i][j], what state does it capture, and which
range does i and j delimit.
6. Write invariants and assumptions, this helps you to argue why your code
is correct and why it covers all edge cases. You should attempt to cover all
cases with general code, most of time you do not have to write an if/then
to deal for a special case, e.g. do you really need a special case for 1-
element array.
7. Write code. It might be easier to do it top-down, that is, if you find
yourself stuck in implementing a subroutine, or you are repeating some block
of code, write a function prototype for it, and tell the interviewer what
this function is supposed to do and you will implement it later.
8. Read your code at least once, and talk to yourself what your code is
doing from beginning to end. You will catch more mistakes than you might
think.
9. Think about a few cases and see if your code deals with them all.
10. When you are done, check with interviewer for feedback. It really
depends on the interviewer, but most of them will show some sign whether he/
she is happy or already see a problem. Keep in mind that the interviewer
knows the problem better than you, and he/she has used this problem to test
a few candidates already so he/she knows where people make mistakes and are
looking for those.
Step 0 should be done before you start any interview.
-------------------------------------------------
0. You should know one language really well. If you use c++, you should be
able to write code using everything you need from STL without looking up
anywhere. If you use Java, you should know the collections without
consulting javadoc. You might think that it is impossible to remember so
many data structures and APIs, but if you have practiced leetcode at least
once, you should know those library functions well enough. If not, read the
C++ STL tutorial (book, ch 1 - 4) to get an idea about the design of STL and
the convention of the API. I do not know Java well enough to recommend
books.
的programming language刷。个人感觉面试做题其实不完全是你写的code能不能
compile，能不能过所有的testcase，面试是一个跟人交流的过程，对方是在考虑这个
candidate是不是能跟自己，还有自己的team合作。一个什么都不问，听完题目， 甚至
题目都没有听完就开始敲code，或者在白板上开写的candidate绝对不是一个好的
candidate。一个好的面试过程应该是能让对方知道你的thinking process，你写code
的习惯，还有你跟teammate沟通的能力。有人说只要我写出bugfree对方能不让我过么
，这个还真不一定。一个是很难背熟150题，另外一个是如果面试官认真准备过他的题
，总能找到一些办法让你做一些extension。
下面是我总结的做题流程，抛个砖。
1. draw a picture
2. understand the problem, ask any questions if the problem is not clear. In
a programming competition, all the constraints will be clearly stated, but
in an interview, you have access to the interviewer, so it is your
responsibility to ask questions to clarify. The worst thing can happen in an
interview is to solve the wrong problem.
3. Come up with one or two example, simple enough so that it does not take
too much time. This also serves a context to clarify problem. You may also
use them as your testcases after you finish coding.
4. Write down data structures and function prototypes.
5. Decide key variable names and meaning. Surprisingly enough, good variable
names are hard to come up with, and it is not uncommon to confuse yourself
with different variable names, especially when you want to change them in
the middle of coding. The meaning of variables is essential in dynamic
programming, when you write dp[i][j], what state does it capture, and which
range does i and j delimit.
6. Write invariants and assumptions, this helps you to argue why your code
is correct and why it covers all edge cases. You should attempt to cover all
cases with general code, most of time you do not have to write an if/then
to deal for a special case, e.g. do you really need a special case for 1-
element array.
7. Write code. It might be easier to do it top-down, that is, if you find
yourself stuck in implementing a subroutine, or you are repeating some block
of code, write a function prototype for it, and tell the interviewer what
this function is supposed to do and you will implement it later.
8. Read your code at least once, and talk to yourself what your code is
doing from beginning to end. You will catch more mistakes than you might
think.
9. Think about a few cases and see if your code deals with them all.
10. When you are done, check with interviewer for feedback. It really
depends on the interviewer, but most of them will show some sign whether he/
she is happy or already see a problem. Keep in mind that the interviewer
knows the problem better than you, and he/she has used this problem to test
a few candidates already so he/she knows where people make mistakes and are
looking for those.
Step 0 should be done before you start any interview.
-------------------------------------------------
0. You should know one language really well. If you use c++, you should be
able to write code using everything you need from STL without looking up
anywhere. If you use Java, you should know the collections without
consulting javadoc. You might think that it is impossible to remember so
many data structures and APIs, but if you have practiced leetcode at least
once, you should know those library functions well enough. If not, read the
C++ STL tutorial (book, ch 1 - 4) to get an idea about the design of STL and
the convention of the API. I do not know Java well enough to recommend
books.
