你看到的都是 N 年经验的社招面经

你见过应届写的面经吗？
应届是不是都不需要写代码？


你品一品

（诶？！那应届生都问啥？）

因果关系是这样的

人们并不知道光速不变是不是对的
但是如果假设有绝对时空，相对光做运动使用伽利略变换时，发现了矛盾
并且，如果假设有绝对时空，那么光在绝对静止的介质中运动时，应该能测量出某些性质

然而并没有测出来这个性质
所以绝对时空很可能是错的，光速能用伽利略变换可能也是错的


那好了，只能假设另一种情况了，假设光在任何参考系中速度都不变，以光速运动时观察光它还能相对你自己以光速运动

这个假设看起来匪夷所思，但也能推导出一系列结论，然后人们假设这些结论是对的，去做了一些实验观测，发现居然完美符合


那没办法，不信也不行，实验已经证明了

补充一下
copy 的语境，被 copy 的东西就是原来的，完全没变，而且 copy 的时候并不一定产生了结果（ copy - paste ）
duplicate 后，你一定得到了两份东西，是有结果的，而且这两份东西中是否一定有一份是原来的东西，并不一定，只是长得一样

比如 file copied，此时你并不预期 copy 成了哪个实体，也许会写到后面想起来再说的什么路径里去
但 file dupplicated 此时已经有两个一样的文件同时存在

把某个数据 duplicate 一下发往两个地方，很可能两个副本都 不是之前那份数据的引用
把某个数据 copy 到新地方，那肯定有一个是旧的引用本身




call invoke apply 区分得还是比较清楚的，直接调用叫 call，委托调用叫 invoke，把固定好的变换作用在不同对象上叫 apply

-or/-er 和 -ee 是主被动关系，这个不应该搞混才对

cache 有一个建议译名叫“快取”，很好地体现了这个词的原本定义

safety 和 security 并不好直接解释词义，开车这个语境比较容易分辨区别

copy 创造一个跟以前一样的实体
clone copy to new and likely for modifying
dupplicate 把原来的实体变成两个

call 执行任意形式的子过程并期待返回
invoke 代理给某个东西执行动作然后期待代理给我返回
apply 给一个对象应用一个变换器，尤其是函数。因此 apply 的语境相当函数式

iterator 用来访问集合的东西
-ee 被遍历的东西


buffer 存任意中间数据的地方
cache 用于加快访问而特意放置中间数据的地方


safety 开车撞车死不了
security 开车不会被劫持方向盘

还有一种方式是直接把 ip 地址算成线性空间，每个区间有左右界，合并的时候先按左界排序，然后判断
下一个区间的左界有没有落在前一个区间中，如果在，那么区间右界设成下一个区间右界，如果否，那么第一个区间已处理完毕，可以处理 23 区间

首先不考虑域名和 url

我当时的实现大概这样

一个 - 指定的范围可以解析成若干个 cidr 或 ip

那现在只需要考虑 cidr 一种情况（ ip 可以看做 /32 ）
用二叉 trie 来存这些 cidr，在深度为 N 的节点有一个 cidr 对象表示这个 cidr 是 /N

如果某个节点左右子树都存在则递归向上合并节点

插入过程中途遇到某个节点说明这节点已经包含了待插入地址，跳过

然后就没有去重这一说了，匹配就是走这个 trie 跟插入流程几乎一样的

当时没有去重合并完还要导出合并结果的需求

退休的没见过，财务自由早就可以退休了的见过不少

hhhh 之前有个同事比你这个聪明一点：

Button **btn = new ...
for(...)btn[...]= new ...

btn[0]->setText();
btn[0]->move(x,y)
...


btn[1]->...


问他为啥写屎他说这才是灵活的好代码，这样界面布局改了改坐标数字就行了，而且能随时加按钮

“这代码你看得出哪个是哪个吗”
“看 text 啊，你没用 ide 吗，看一下引用就知道是哪个了啊”

卧槽好像很有道理！

我昨天刚在笑话有人把监听当真，今天就又看到一个讨论监听的帖子
现在我信了，lz 监听我

random.shuffle

连 C++标准库都有类似的函数

从官方回复和其它网游经验来推测

你是不是买到了工作室出的钱或者装备什么的

我也面对过类似的重复工作。。 几十万行源码，几千个字符串，要从静态的改成可动态返回的


然后我
写了一个扫描特定格式字符串的脚本，把所有要替换的静态文本都收集了起来

写了一个扫描翻译文件（预先翻译好的文本对照）的脚本，把上一个脚本扫出来的东西转化成结构化的对{原文:翻译}格式，然后有些漏掉的手动修复

写了一段自动机描述程序（将被自动机生成器编译成 c 代码），这段程序能确保以 On 的效率搜索到原文对应的翻译结构

写了一堆宏和 wrapper 确保上面这个函数的调用能正确嵌入到原来字符串在的位置

还有一段脚本把原文件里的字符串换成上面的宏





最后这一大坨代码全部合在了一起变成了一个 translate.py 确保没有第二个人能看得懂怎么做到的 XD

虽然还是修了半天原文件里的字符串以让它变成能被脚本识别的特殊格式

但并不很枯燥无聊不是吗

emmmm 本来想 star 的，看了眼代码又关掉了

暴力匹配关键字 lexer
强行手写并不知道会不会符合语法定义的 parser

这个程度的 project 私以为随便做点现成语言的子集或者玩具语言就够了，意义不是很大
我觉得搞懂 bison 怎么写都比这个有成就感。。



就像 yin 神说的，写出来一个 parser 并不能完成什么里程碑

撸一撸自动机生成器或者接一下 llvm 实现一个编译型语言挑战大得多

jira.

不要忘了项目管理工具是为项目服务的

如果你们项目并不符合敏捷迭代的软件生命周期模型，那显然用不起来。我指的就那种做外包的、做传统软件的、一个项目大包解决方案先写几百页的瀑布流开发，那咋敏捷？连迭代都不需要，所有任务一个大表一块一块往小切，切不动花钱买，计划到头项目结束，完结了。这谁跟你看看板开站会哦

敏捷模型的典型场景是：
1. 你们小组经常需要交叉帮忙，没有固定 component 以及对应负责人
2. 需求池永远在增加，从不减少
3. 定期滚动发布，甚至每修一个 bug 就会发布一次

盲水印不都得在频域上做文章？。。但媒体分发用的视频编码都是有损的，都会破坏原有频域特征，盲水印咋搞的……这就跟要在 jpg 上打盲水印还要求重新压缩后信息不丢失一样难。。


再而且视频编码帧间压缩占绝大比例，跟图片很不一样，用图片逐帧合成估很可能没用

#3 说的很对，他们只想要一颗螺丝钉

“他们” 指的是国外的公司。


国内特别是小型团队招人，一定是想找个人解决某个方向上的问题。比如缺前端，公司前端用的 vue，那面试肯定最好能找到写过 vue 写得很熟练的人。这个时候考算法题有啥用？你给我讲讲你当初的项目都做了哪些东西我不就能判断你编码能力如何了吗，如果你吹得太虚那再做几道题不迟

框架的实现原理真真真就不是经验问题。因为是个人都知道写业务代码永远不需要搞清楚框架原理。只有特意去研究才能搞得清楚，而你去研究了，第一说明你读大型复杂代码的能力很强，第二你很可能遇到过框架不合理的地方，你在某些方面能力可以超过框架作者。

其实我感觉国内大多数大厂里的码农知识储备都是完全超出胜任他自己岗位的程度的。所以他要招人自然也会期望一个能超出仅仅够用标准的人，导致大家都面试造火箭入职拧螺丝。招你进去的那个人虽然也在拧螺丝但他也会造火箭，你猜他想不想让你帮他造火箭？

革这玩秋秋空间的害是你们这一群

“长大了的标志，你对了几条？太准了”