​是的，我今天就想批判一下那些披着「设计（系统/语言）」外衣的研发工程师。设计系统（Design system）这个概念应该是从国外最先有的。它的定义是：国内的组件库只有 Antd 在推出的时候声称自己是 一个 UI 设计语言，虽然当时我还不知道什么叫做设计语言，什么是设计系统。但是从工程师的角度我知道它就是 一套组件库。一直到近两年，越来越多的前端团队以设计系统为排面推出自己的组件库的时候，我就觉得有些不对劲儿了。哪里不对劲儿了？我在想我们实际上做的事情不就是设计了一套组件库吗，为什么要把设计放在前面。这似乎传达给我们一种信号：我想并不是这样的，或者说不应该是这样的。设计 永远是最上层的，它们关注的用户的外在、外观感受，它是感性的、多变的，没有唯一标准的。你很难想象用一套设计系统满足所有人的需求对吧？因为我喜欢蓝色，你喜欢红色这是不需要解释的。工程 永远是最底层的，它关注事物内在的东西、自身属性，它是理性的、不变的，有迹可循的。所以工程层面追求的是一致、复用和效率。没人喜欢一个相同的组件在不同的实现上有不一样的 API。在「前端工程师」这个职位名字中，「前端」是个形容词，「工程师」才是名词。我们得先是工程师再是前端对吧。当我们不由自主地和设计靠拢时，思维模式也受到了影响，似乎只有设计思维才会关注到那些形容词。当我们在设计一套组件库的时候会遇到很多不一致的情况，在我的经验里面：当我们设计的组件库需要考虑到跨端情况的时候，我们的组件库应该有一套一致的 API、一致的命名规则。但是从设计角度去决策的时候这件事情变得非常困难。比如说：日期选择 这个组件，移动端通常叫做 DatePicker，这个词强调的是用户的动作（pick），在 PC 端通常叫做 Calendar，这个词强调的是组件本身的特征。还有：按钮 组件的类型属性，有的是表形的：default/info/warning/error，有的是表义的：primary/secondary/danger再一次，我们在工程实现层面不需要这种差别。它就是一个简单的按钮而已。造组件库的人没有想清楚这件事情，用组件库的人却得承受这种不一致。那什么组件库的设计者们没想清楚这件事情？因为他们的思维也被设计系统带偏了。一味的追求设计上的形式化的一致，却忽略了工程上逻辑的一致。当这股邪风吹来，没人会在意组件库的工程化设计，没人在意它好不好用，每个人都想复制粘贴快速实现一套组件库，然后再披上设计系统的外衣，为自己的似锦前程添砖加瓦...​

二道算法题 中等难度JAVA有哪些集合？HashMap和LinkedHashMap的区别？实习为什么模糊查询会导致索引失效？MySQL为什么用B+树？B+树怎么做范围查询？Redis里面的String有哪些用法？缓存穿透？Redession实现分布式锁原理？项目相关由实习引出设计模式，然后手写单例模式RabbitM和kafka的区别？反问挂了，虽然都答出来了，但是没准备好，约面推迟了一周，hr说人招满了。

50分钟左右主要问了一下实习的经历然后两个算法题：算法题1：三个没有刻度的被子A、B、C，各自有对应的容量（容量是个整数），现在有无限的水。问是否可以可以经过一系列的操作将三个被子的水量之和等于t?如何可以的话，给出操作路径。参考leetcode:365. 水壶问题的bfs解法，讲了一下思路，面试官说思路没问题，感觉写代码比较麻烦，主动给我换了一个题。算法题2：单链表排序。      -- Java写了个归并排序上午面的，感觉面试管好像通宵一夜没睡，面试的时候要睡着的样子。#快手复活##快手Java面经#

八股都是从项目介绍里引申的1.自我介绍2.细问实习，实习遇到的难点，做了什么3. 简历里写的定时任务，缓存预热是怎么回事4.ThreadLocal有什么问题（面试官：线上项目一般不用这个）5.分布式锁6.项目里用了多线程吗7.代码题：实现懒汉式单例8.代码题：字符串表达式计算，如3*(2+1)/4 知道用栈但没写出来最后还给了建议，算法题还是要多刷刷，项目可以再找找亮点（面试官都找不到问题问我啦，哈哈）