我在杭州的node全栈面试过程记录

今天在杭州的现场面试通过了发表一下面试总结吧
介绍一下公司的技术背景是nodejs+react的全栈开发形式，主要是在线编辑业务的。
首先我来公司之前研究了一下之前hr让看的在线编辑需要用到的crdt技术其核心就是要满足数学上的交换律，在我进入到公司的现场面试环节后
公司有两位面试官，技术面的面试官首先说了一下公司的工作考核要求：
1.文档设计:这意味每位员工都要对产品要有自己的设计产出，而不是只有代码业务的实现
2.github的仓库贡献:公司是全面使用github作为公司的代码平台的，并且在github项目上的任何文字描述都要是英文的（为的是以后吸引国外投资者进行估值),具体的考核有commit，issue，code review，pull request
以上就是公司日常工作的考核标准，这也解释他们为什么在挑选面试者的时候很看重面试者的github活跃度
问题一:
接下来就是场景面试题，hr先是在白板上画了一些常用的页面布局组件，接着又开始构造用户的操作方式(A、B用户都新增了一个组件)，然后问我这个他所构造的用户操作方式如何通过数据的形式进行保存
问题一解答:
在来之前学的crdt中提出任何协同操作都要转换为满足数学上交换律的形式才能合并，但这里的关键不是合并，而是设计出一个能够保存这个新增组件的数据结构，我这里采用的了对象的形式保存，需求的字段信息为组件的位置、组件的类型、组件内容
问题二:
hr继续问我在A、B两个用户对同一个组件的进行不同的操作后应该怎么合并
问题二解答：
这里就要用交换律来实现，例如A更改了组件的name、B更改了组件的位置，那我们只需将两次属性更改合并就能得到这个最终的结果
问题三:
hr继续问我，如果A将组件删除了，而B对组件的一些其他属性进行了修改，要如何合并
问题三解答:
这里我一开始陷入了，要是否判断组件是否还存在的误区，实际上我们应该将这里的删除看作是软删除，即不是真的删除了，而是通过一个一个属性控制其是否被删除，这样我们就将问题转为问题二
问题四:
这里应该最难了的问题，难到连另外一个面试都觉得比较难，这题的场景是如果用户A更改了组件的所属结构该如何通过数据结构进行描述，这里首先要分析组件的数据结构是什么样的，其实应该就是树状的数据结构，但是问题树状的数据结果没办法通过合并的形式保证交互律的成立，我提出可以构建一个新的树代替原来的树，但这个想法被hr提出太浪费资源应该转换方向考虑。
问题四解答:
在这里我真的僵持了很久后，hr提示我应该考虑将树打平，我又进行了一下思考后发现要打平树应该采用链表的形式去记录这个组件的嵌套关系，于是我将其转为链表形式的数据结构，但是这里还没完，我还需要去发现如何用链表满足交换律，终于我发现了组件所属层级结构的改变，其实就是链表元素指向的改变，很快我就将所有元素通过链表的形式排列好，并通过指向的改变的满足交换律的操作
以上就是全部的面试过程了，在结束面试后，hr让我到外面去等他们两人的讨论结果，最终有惊无险的通过了面试，被告知周四去上班
总结这次面试是对于我系统设计的考察，面试并没有考我代码实现层面的内容。我很庆幸自己的实现方案和思路实现刚好能够回答出这些问题，当然这也建立在对于crdt这个技术有一定了解的基础上才行。通过这次面试让我对我入职后要做的东西也有了一个初步的了解，这也许就是压力就是动力吧
最后说一下公司是个小公司就5个人，但氛围还行年轻人偏多，全员mac吧，工资不算多一天200，一个月算22天