分享一篇关于站立会议的的文章，非常全面的分析了站立会议的形式、意义、最佳实践和常见问题。
楼主有兴趣可以研究学习一下，不过是英文版。
https://www.martinfowler.com/articles/itsNotJustStandingUp.html

如果发现站立会议流于形式，没发生正面作用，可能有两方面原因：
1. 团队荣誉感 /自治性不足，主观上不愿意作为团队的一部分去共同实现一个有意义的目标；
2. 团队成员职业能力有短板，客观上无法理解团队目标，达成团队协作，阐述团队及个人的工作内容和价值。

两者都是站立会议可以轻松暴露的问题，但需要在站立会议之外解决。

不管是给自己部门招人面试还是帮其它部门交叉面试，我都会先看过《应聘登记表》上的期望薪资再接触候选人。

因为期望薪资体现了候选人对自己工作能力的认知；
我也要根据这一价位选取合适的交流主题，判断其能力是否符合公司对该 level 员工的期望。

只有双方对能力及薪资的认知大体一致，后面才能有合作的可能。

> 1.收到您的简历后，如果符合要求，我们会通过邮件与您联系第一轮 coding test 。
> 2.您有两天时间完成 coding test 。通过之后 HR 会邀请您进行一次非技术面试，以了解您的更多信息，如薪资期待等 。

本来想要试试的，被这面试流程劝退了……
公司情况、团队情况、发展规划、工作要求都不先聊聊，候选人怎么知道和企业的匹配度如何，是否值得花几天时间去做 coding test ？

> 由于每日收到邮件较多，无法一一回复，希望大家见谅

据信标准模板都懒得抄一下，太过于傲慢了。
接触过的北美本土 startups 都会「礼貌婉拒」。如果再去信想要了解不匹配的地方，大多也会简单说几点。

1 、靠谱的产品策划 /行业布局
2 、兼容互补、互相欣赏、逐渐信赖的合作伙伴
3 、突破当前职业天花板的机会 + 合适的股权期权
4 、能让团队存活一年以上的现金
5 、能保持体面生活的月薪

「政务类项目+销售型老板」的通病……

在我看来这不应该是「工作优先级」的问题，而是「项目管理如何平衡“功能范围 & 时间 & 质量”」的问题。

如果老板逻辑还算清晰，能尊重技术的话，建议准备好充分的素材后与其做一次坦诚深入的沟通，从你的视角提供几个解决方案让老板选。举个例子：
技术团队上一个月同时维护 x 个项目，共发布 y 个版本，总计 z 个用户故事；
以同行业同地域平均水平而论，需要 xx 个团队成员 yy 人日完成；
但由于现在仅有 4 人，导致加班严重，交付质量严重下降，共出现 xxx 个缺陷，其中 yyy 个是生产环境严重级 bug ；
目前团队修 bug 和开发新功能的时间比大概在 x:y，参照前几个月工作产出估算，接下来四周最多能完成 z 个用户故事；
解决方案 1: 缩减功能范围，专注开发 a 、b 、c 几个核心功能，其余低优先级项目 /功能由商务挡住；
解决方案 2: 延长开发周期，下两周开发 a 、b 功能，再下两周开发 c 、d 功能，……总计开发周期预估为 x 个月；
解决方案 3: 降低产品质量，所有功能均做最小化开发与测试，商务验收后再长期救火不足部分与线上 bug ；
长期解决方案：补充团队成员至与项目规模匹配的数目，但要说明新人上手需要一个月，稳定输出需要两三个月，对近期项目没有帮助，甚至帮助新人融入还会降低老员工的工作效率（没有银弹！）。

如果老板不讲理的话，那就真的只能六字真言了。

> 我们公司同个部门的好几个同事

多个成员存在这样的问题，说明这是团队（负责人）的问题，而不是孤立的某几个人的问题。

如果要从团队层面系统地解决这个问题，推荐两个实践：
1 ）引入压力测试 /性能优化，对于数据量千万级以下的传统应用，要求单机支持 1k+ tps 、100- ms latency，可以在设计 /开发 /测试环境快速识别性能瓶颈，避免低质量的设计和开发；
2 ）引入 Application Performance Monitoring 工具，数字化直观展现应用在生产环境的性能瓶颈，将慢操作视为高优先级技术债务，对应的产品有 SkyWalking 、New Relic 等等。

通过建立体系化的开发流程，即使新的工程师加入时没有相关的经验和意识，处理几次相关问题后也能逐渐适应和融入。
当然，这对团队负责人的技术能力和管理能力要求就比较高了。
如果楼主部门领导不具备这种能力，楼主描述的问题必然会反复出现。

钉钉的锅，不要甩到 Spring Security 上。

@zxCoder #3

从文章里可以看到，Aurora Serverless 可以根据负载情况自动调整配置规格，最大规格可以支持到最多 6000 连接数。

如果把一个连接数看作一个并发访问，那相当于是能支撑一个「千万用户级」的系统服务。
虽然达不到 Lambda 的无限伸缩（理论上），但对于 90%（其实我想说 99%）以上的业务场景也基本够用了。

如果期望支持更大的并发，需要组合其它技术来支撑，比如说缓存、消息队列、拆分服务。

https://www.jeremydaly.com/aurora-serverless-the-good-the-bad-and-the-scalable/

Max Connections
A major limitation of relational databases in serverless architectures is the maximum number of concurrent connections allowed by the database engine. While FaaS services like Lambda may scale infinitely (in theory anyway), massive spikes in volume can quickly saturate the number of available connections to the underlying database. There are ways to manage connections in serverless environments (also see Managing MySQL at Serverless Scale), but even with Aurora Serverless, this still appears to be a possible limiting factor.

AWS uses the following formula for generating the max_connections value for Aurora instances:

log( ( <Instance Memory> * 1073741824) / 8187281408 ) * 1000 = <Default Max Connections>

A db.r4.xlarge instance with 30.5 GB of memory for example would have a default max_connections value of 2,000.

log( (30.5 * 1073741824) / 8187281408 ) * 1000 = 2000

@yidinghe #23

只是类图就错综复杂绕来绕去的……
就算代码写的再优雅，要是移交给别人（或者半年后自己再来看）会很难看懂吧……

针对这种计算规则多样，并且可能频繁修改的需求，一个比较推荐的办法是做个简单的「计算规则引擎」。

比如说：把「计算公式」和「参数」按照标准的格式记录在 Excel 文件里，「计算规则引擎」解读该 Excel 文件生成计算规则，然后应用程序读取数据并调用计算引擎作计算。
当需要更新计算规则时，业务人员只需修订 Excel，然后重新上传到系统。

除了 Excel，Python/Lua/Javascript 之类的脚本语言也能用来定义计算规则，我甚至用过 xml 。
之所以首选 Excel，是因为运营人员（产品经理、系统运维）和用户（学校老师）都熟悉 Excel 操作，而且能直接在 Excel 文件里输入一些样例数据对公式做人工验证。

@caroline1022 #22

> 我很好奇作为面试官真的有义务回答面试者反问的问题吗？

没有“义务”。但是如果追求成为负责任的面试者，很有必要。

我与候选人交流时，当对方回答问题不在点上时，即使对方不提问，也会提出一两个解决思路与他 /她作进一步的探讨。

如果候选人开始答不上来只是对问题的表述理解有偏差，这时候就可以理解问题的关注点，展现自己的技术实力；
如果候选人开始确实没有思考过这个问题，但是提示思路后能迅速理解关键点并举一反三，或者指出我思路里的不足，那也能说明他 /她的技术理解力和敏感度。

在我的招聘理念中，“面试”是一个平等交流双向选择的过程，可以认为是与未来同事提前模拟一下后面工作中的技术讨论。
我要在团队里努力营造一种“协作进取”的技术氛围，那从与团队成员的第一次接触 - 面试时就力争能给到他 /她这种印象。

@eric96

如果只评估传统的关系性数据库的话，那就尝试分区、分表、分库操作吧。

撑不住 20k tps 写入，可以考虑加一个消息队列做缓冲，批量处理批量写入。
在对读操作要求不高的场景下，问题应该不大。

> 目的：根据唯一主键从数据库中查询一行数据，要求 50TPS，延迟在 200ms

如果没有硬件资源限制的话，任何支持水平线性扩展的分布式数据库都能满足吧。
数据量再大，性能要求更高，加机器完事。

Cassandra 完美契合这一需求，参考 Discord 的经验：12 个节点，3 重复制，支撑日均过亿消息，写操作亚毫秒，读操作 5 毫秒。
https://blog.discord.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7

Discord 去年声称迁移到了性能更佳的 ScyllaDB，但是没有看到具体的性能指标。
https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/

@weiwenhao #17

> 问一下大专怎么写能去大厂面试，投了几十次了都没有面试

先要明确自己的经验能力和大厂岗位要求的匹配度有多高。
以我自己为例，如果目标岗位是 Amazon Senior Principal Engineer，岗位匹配度非常低，简历写的再漂亮也没有机会。

当然了，JD 和实际要求可能会有偏差，自我评估也可能会有偏差。
一个可能的办法：寻找各种途径联系到目标大厂的资深员工（ linkedin ？微博？邮件？），请求对方帮助评估匹配度和不足之处，针对性地补强后再投简历。

@luckyrayyy #18
@jin5354 #21

> 确实没做过这么多高大上的产品就很蛋疼
> 很多候选者那简历纯 CURD

简历想要打动人，总得先要把自己的亮点找出来吧。
没有高大上的产品项目经验，可以强调对技术的钻研和应用，再退一步也能说说工作细致负责，最次那就强调努力和加班吧。
要是连努力也谈不上，那还是建议他别想着换工作了，好好修炼一两年再说。

我文中举例的测试小伙子，他的工作表现其实也就中规中矩，业界平均水平吧。但只要努力挖掘，总能找到工作的闪光点。

@Yc1992 #14

> 都 CTO 了还需要简历吗，纯属好奇

以我现在接触的层级来看，不管是猎头牵线还是朋友内推，提供一份精心制作的简历都能让对方了解你的基本情况，判断岗位匹配度，为面谈准备好讨论话题。

顶尖大厂的 CTO/VP 级别我就不清楚了，听说有些大牛是要持之以恒好几年才能挖到手的？

@dcsite #6
@ingdawn #7

> “如果把微不足道的事情都要写在简历里，那简历要多厚”
强调细节 != 微不足道，列举的数据和事实是用来佐证你与其他人不一样的成绩和特点的。

> "都这样写的话五页纸都写不下”
我自己十四年的工作经历，在两页 A4 纸里写完了。
如果能强调的经历和特点很多，那就要仔细斟酌如何取舍，看强调哪一个项目情况更能打动阅读者。
马斯克也说的是“a few”嘛，只要有一两个亮点吸引到注意，就算成功了
事实上，没必要担心过犹不及，我看过的简历，90%以上一个突出的亮点都找不到。

@forbreak #2

“略显浮夸” - 是否真的浮夸，要看下一步的面试里能否把简历里体现的亮点都表述清楚，事实充分，细节详尽。
所以我自己简历里罗列的所有内容，都预先准备好几个面试者可能会提问题的答复。
只有能经过自己反复推敲的亮点，我才敢放心写到简历上。

只要进入了面试，那就说明我们在简历这一关已经胜利了，不是吗？
至于与面试者斗智斗勇，那就是另一个大话题了。

@imes #1

“修饰词太多了” - 是有这么点儿感觉。
我习惯把简历压缩在两页纸内，为了尽可能地体现过往经历和成绩，只能省略细节增加修饰，以提高信息密度。
你有什么好建议来改善行文方式吗？

“让人觉得浮躁” - 见仁见智吧。