Confirming question

• Repeat the question back
• Run through example input/outputs
  • treat the function as a black box
• Check input values
• Check input size, and frequency of each bee called
  • Ask these early on during the interview
  • Also ask whether you are heading towards a correct direction
• Clarify the edge cases

Algorithms design

• Clearly explaining the algorithm you going to use
  • Iterative, recursive, data structure used...
  • Come up with the brute force solution first, then ask interview whether proceed or not
• Pseudocode and/or comment before coding

Complexity Analysis

• State and explain time complexity
• State and explain space complexity

Coding

• Write the mains steps first
  • BFS, write down the full structure first, then worry about the boundaries and details
• Each line explained verbally before writing
  • Keep it clean

Testing

• Run your example through the testing
• Boundaries and possibilities all tested
• Test both correctness of code and algorithm

Optimisation

• describe why your solution is not optimal
• keep talking to ensure interviewer know you understand the issue
• Tell your current time complexity
• Seek for improvement, whether reduce edges cases or use another algorithm or data structure

1.    面试官描述题目，onsite的题目描述基本不会像phone那样直接粘贴描述，而是：
    a.    说要解决的问题的back ground
    b.    给一个base的test case
    c.    然后说问题，并给出base test case的答案
    d.    一般不会主动告诉input和output的format
    e.    一般而言，onsite的问题描述都是比较抽象的(为了模拟实际的问题环境)，哪怕是lc的题，也不会像lc或者phone那样给很多的detailed的information，需要candidate自己去ask question来clarify.
2.    面试者(你)问clarification的问题
    a.    问清楚要解决的问题具体是什么，什么input，什么output等，并征求面试官的确认
    b.    问清楚了题目中的所有可见的或者隐藏的condition/constrain，并征求面试官的确认
    c.    如果自己有意识/无意识地makeassumption，像面试官确认这些assumptions
3.    面试者(你)问test case/corner case
    a.    一般面试官会和你一起讨论你提出的testcase，看正确答案应该是怎样
    b.    一般在这里如果test case没有想全，尤其是cornercase，那么之后在想idea并walk through的时候一般会出问题
    c.    一般而言，面试中，在开始想idea以及walkthrough idea之前，先跟面试官把test case/corner case讨论全，会对之后的idea思考大有帮助，很多时候idea不work就是有些case根本不能handle导致的.
    d.   小技巧: 对于某些面试题，或者面试官，部分困难的test case甚至可以不要求实现，或者算作follow up，但candidate要能够想到这些case，会是一个加分点
4.    面试者(你)告诉面试官，能否让自己想一会儿idea(1 min左右)，然后跟他一起讨论想到的idea:
    a.    因为时间紧迫，不能花好长时间站着不说话干想，建议先思考high level idea
    b.    如果high level idea跟正确的idea方向一致，可以进行下一步，讨论idea的细节并walkthrough->面试官快速+满意的笑了/点头
    c.    如果high level idea跟正确的不一致，或者是恰好错误/不够好的方法，可以先跟面试官一起分析一下题目，看看哪里是不够好，行不通->面试官快速地反馈给feedback
    d.    如果某个点被block了，向面试官askfor help，告诉他在哪个地方confused了，好的面试官都会带着你往正确的track上走
    e.    如果自己的idea面试官不确定行不行，先进行下一步->面试官慢速地思考/犹豫/疑惑/提出问题
    f.     一般而言，跟面试官讨论idea的过程中，可以通过对方的表情/神态判断出自己的idea是什么状态(恰好正确/完全错误/面试官没见过不确定对错)
    g.    小技巧: 先提出一个brute force的idea并分析复杂度，可能就是一个可以写代码的解，或者缓解想不出来的尴尬气氛，不至于什么idea都没有
5.    面试者(你)讨论idea的细节，用什么data structure，并用test case来walk through这个idea
    a.     如果自己的idea错误/不够好，面试官一般会给一个testcase来attack这个idea，但能自己想出来更好
    b.     如果自己的idea的细节有block，也可以向面试官askfor help一起讨论
    c.     Ask for help本身就是工作中重要的一种能力，也是面试中要评测的能力，寻求帮助一点错都没有，不丢脸.--
6.     讨论/讲解idea的每一步，都要确定面试官对自己的idea和行为完全ok，当然，更重要的是，自己也要对自己的idea完全清晰的理解，再开始写代码
   a.    白板写代码，要注意排版和字体间距，尽可能让面试官看得舒服，很多面试是要求面试官拍照回去自己敲一遍
   b.    每写一部分，可以回过头跟面试官说一下这个是干什么的，并确认面试官理解了
   c.     小技巧：把一个完整的算法代码拆分成几个函数，其中一定要把main logic这个部分独立出来，然后先把high level的structure和各个helper function的接口定义好，然后着重实现main logic的部分，当然，记得征求面试官同意，不然他不知道你在干什么
   d.    一般而言，在算法面试中，一定有一个面试官最希望看到的部分，就是算法的main logic，比如dp的状态转移方程，只要这个部分写好了，这道题的solution就成功了一大半，因此要把主要时间留在这里而不是其他的边角余料，比如data structure的初始化这种完全可以放在helper function里面，这些东西哪怕不写在很多情况下也是ok的，前提是征求面试官同意
7.     Walk through test case(如果前面已经做了，这一步可以省略)，test case的walkthrough一定要有，不管是在写代码前的idea讨论，还是写代码后的debug，根据面试官的要求来(要问)
8.    主动对代码的时间复杂度/空间复杂度的分析，可以在代码之后也可以在ideawalk through部分，一定要自己主动提出分析复杂度，体现自己算法analyais能力，面试官会期待candidate自己主动来分析算法
9.    小技巧：楼主之前onsite一直因为心态不好崩掉，后来把面试模版总结了一下写在了小纸条上，每次面试前都会看一下，心态就会好了很多，因为每一步要做什么都很清楚了，就不会紧张

• don't over communicating and ramble
• write the bone structure first, write done comment as notes

1. Clarify the problem‘s inputs/output, ask about edge cases (even stupid questions like “is the tree balanced?” “does the linked list have any cycles?” “Can the input array have negative numbers?”) and come up with your own set of test cases. You should assume that interviewers won’t even give you any test cases like leetcode does.

2. Come up with a few approaches for the problem. Always briefly discuss the brute force solution, then brainstorm different potential approaches (maybe 1 or 2 in addition to the brute force solution) and highlight each one’s tradeoffs (space/time/simplicity)

3. Write out the pseudocode for whichever approach you’re going for (if you have time, never skip this because ideas you think are easy to implement might not be so straightforward)

4. Implement your solution, still verbalizing what you’re doing for each line of code you’re writing.

5. Review the solution - do a dry run with one of the test cases you came up with to spot any potential bugs

6. Optional if you did this in step 2: Reiterate the time/space complexity again and briefly explain the rationale to double check with the interviewer