前言在过去的几年里，Terraform和 Kubernetes 的陆续发布，全球大部分云服务提供商提供了无数的 TerraformProviders,使得声明式 API 进行 IaC 操作成了业界惯例。Terraform 毫无疑问是一个很好的基础设施治理方案，采用声明式配置来描述基础设施，并进行标准化，比如使用版本控制管理配置、对变更进行评审，进行变更，回滚等操作，使得基础设施的管理过程和业界软件工程的最佳实践靠的越来越近。之前在 TapTap 以及 心动都大规模使用 Terraform，我并不是这些仓库的维护者，但是因为 ops 团队经常无法满足实际的进度需求，有时候我自己也会去提 MR 来管理一些基础设施。同时在过去的一年多里，我一直都用 Terraform 来管理所需的基础设施。在这里并不想写某个命令或者怎么安装某个资源,也不想分享它的好处，因为如果没有一定的收益，也就不会引入它了，因此更多的是分享自己的一些乱七八糟的想法，特别是从应用开发者的角度。我们、他们是怎么用的自动化在 TapTap 使用Atlantis做 Pull Request Automation，基于 Atlantis 可以在 Pull Request 内按照机器人提示，在评论区输入对应指令，重新 plan。review plan 结果，确认出现的结果是你需要的。ops 同事 approve 之后，仓库会自动 ...继续阅读 (11)

前言对独立开发者和创业者来说，找到前 1000 个早期用户太关键了。这是 Github 上1000UserGuide内的介绍，深以为然。但换个说法，我觉得或许会更贴切：对独立开发者和创业者来说，找到前 100 个付费用户真的太难了。看到大佬 laike9m 写的一篇博客《推广独立开发产品，我做了哪些尝试 》，我也来回顾一些自己尝试过的推广路子。借鉴1000UserGuide的内容，以下是我尝试过的一些渠道和方式。我尝试过的✅ Reddit我一般会选择 r/buildinpublic 板块，主要是可以蹭 buildinpublic 的流量。Reddit 的用户真的非常积极，而且大部分会抱着善意给予建议，有人愿意付费，也有人愿意给出建议或者改进意见。

之前开发了命令行工具,这里总结一下如何发布一个命令行工具。技术栈这次命令行工具开发使用的 Python 技术栈，回头来看或许使用 go 是个更好的选择，但人生苦短，我用 Python。我使用Typer来提高开发命令行工具的效率，引入pytest做单元测试。另外如果你的团队在考虑引入集成测试， pytest 将会是一个不错的选择，之前我在 XDSDK 团队的服务端大量引入了 pytest，使得登录、内购支付系统的稳定性有了不小的提升。支持多种安装方式PyPI为了让用户可以通过pip install xxx轻松的安装，可以把工具发布到 PyPI。具体的操作流程参考官方的文档Python Packaging User Guide。大致流程是：注册 PyPI 账号（分别有测试环境和正式环境的）完善 setup.pypython setup.py sdist bdist_wheel本地打包安装 twine 以及 twine upload 包到测试环境或者正式环境这种方式是不需要使用 PyInstaller 打包的。多平台支持使用PyInstaller来打二进制包，使得用户可以不安装 Python 即可安装使用该命令行工具。大体流程是：pip install pyinstaller完善 xxx.spec 文件pyinstaller xxx.spec本地执行会在 dist 目录生成命令行工具，可 ...继续阅读 (11)

不管是独立开发者还是数人小团队，打造高效试错的环境至关重要。获取更多的用户、把产品做好永远是第一要务。因此，我写这些并不是鼓励你在这些工具、平台上尝试，只是记录自己所使用到的一些平台和工具。VCS代码直接托管在gitlab，免费薅的羊毛包括：基于 Git 的版本控制。基本的 CI/CD。限量的存储和 CI/CD 分钟：免费存储空间和每月 400 分钟的 CI/CD 运行时间。基本够用。协作工具：我们一般都用 issue 来驱动小的需求。Container Registry：托管 Docker 容器镜像。Project 和 members 不限制数量如果你们是一个几人团队完全不需要自建，当然也可以用 Github。VercelVercel把与Next.js云函数的融合做得非常好，10 个 endpoint 内是免费的，但是超过了则需要 $20/month，我一般都是不同的账号注册来薅羊毛，写一个非常小的项目时非常方便。也有 redis、postgress 这样的存储可以用在小项目上。但有一点需要注意，Vercel 的 endpoint 如果超时超过了阈值是需要额外收费的，如果做 StableDifffusion 这样的 API 对接接口是非常耗时的，不建议放在 Vercel 上。否则可能早上刚起床房子就不是你的了！我一般使用netlify在放静态类型的资源，比如官方教程或者文档这些， ...继续阅读 (10)

前言在前司，出于前端工程师的紧缺，为了加快需求的推进，往往我自己也会承担一小部分在管理后台的前端开发工作。阿里“毕业”的后端工程师，应该都多多少少接触过类似ice这样的框架，并在无数个被前端拒绝的后台类需求里挣扎在前端代码里面。而平常的 side project 一般也都是自己来动手写前端。这里总结一下最近一年来写前端的一些乱七八糟的东西。工具TypeScriptTypeScript可以说是让前端开发更能让人接受了，或者说是重新创造了一遍 JavaScript。 Structural type system，支持泛型、类型检查等无疑给工程实践和维护上带来了巨大的益处。而且 TypeScript 的入门成本可以说非低，即使你只有一点点 JavaScript 基础也很容易上手。ReactLibrary 方面则使用选择了React。React 的学习成本真的非常低，除了 JSX，其它都是原生的 ES 的概念。而 VUE 谈不上难，却也是引入一些有别于 ES 的新概念。比如渲染列表，React 中只需要纯粹的 ES 方法 map，而 VUE 则需要理解 v-for 的新概念。当你使用 map 的时候它非常符合直觉，比如很多其他的编程语言都支持类似的操作，而当你看到 v-for 的时候并不符合直觉, 甚至你会想为什么不是 a-for/vfor 偏偏是 v-for 呢？并且 React 对于我 ...继续阅读 (9)

有做这个 Demo 的想法源于元旦回家，和我妈谈到要不要给她每一个可以上传血压记录的血压计，她问是不是很贵。虽然最后买了一个可以蓝牙连接并上传数据的血压计，但是脑子就在想是不是可以做一个玩具来拍下每次量血压的照片，然后自动识别记录血压、脉搏，这样就不用纸本子手写记录了。于是元旦期间就把这个 Demo 撸了出来,算是非常有意思的一次编码。需求整理对血压计拍照后能够自动识别出血压、脉搏用户可以修改识别后的血压、脉搏提供日、周维度的血压、脉搏变化曲线可以本地导出血压、脉搏的历史数据(CSV 格式)如何识别照片中的血压分别尝试了 OCR、ChatGPT 、 OCR + ChatGPT 以及一众国内的大模型之后，我特意在 V2EX 上发了个主题,得到了一些非常友善的回复。猜猜为什么我要这样做，哈哈！OCR：用的百度 OCR 服务免费的开发者额度。ChatGPT API: OpenAI 官方的价格比较贵，我用的是一个中转服务。比较便宜！编码Android多年之前撸过《第一行代码：Android》，但已经忘的差不多了，基本属于未入门的水平。但是借助强大的 ChatGPT 和 Google 还是能够做做 Demo 的。除了 Android 自带的常用组件外，以下是一些额外用到的工具：OkHttp:网络请求工具Room: 本地数据持久化SQLiteORM, Google 出的mpandroidcha ...继续阅读 (41)

这是一篇从 2023 年年初就开始写的博客，大部分内容在读书的当时就已经在 obsidian 上写好了。这里做了一些简单的归类的整理。年初读的书到了年末可能就只剩下一点点记忆了……今年读了比较多关于软件工程、技术管理方面的书，更多是出于工作上的需要。因为很多书都是在骑车去上班和锻炼减肥时用微信听书完成的，所以今年微信读书上的读书时长超过 100 + 小时。产品思维很多时候工程师会想着通过技术去解决业务问题，但【不要用技术去解决业务问题】往往是正确的。重读《俞军产品方法论》推荐指数: 4简评：大概 2020 年的时候简单翻过这本书，这次仔细看了一遍。关于什么是产品经理；企业、用户、产品；交易；决策；产品经理的选拔与成长。引用了许多经济学、心理学和行为学的知识来阐述产品。从工程师的角度看还不错，方法论和观点比较多，细节和逻辑则相对较少，对发展或者培养全局思维的工程师可以读一读。《微信背后的产品观》推荐指数: 4简评：内容来自于 2012 年张小龙的内部分享和演讲，我看的是其他人听演讲的整理版。很多观点和工程师的思维是不一样的，非常值得一读。重视“屌丝”用户群想起来 2015 年暑假在腾讯光子工作室实习的时候，各种巧合之下我和同在实习的游戏策划-维佳成了朋友。记得有一次他拿几张图片来问我游戏用户会更喜欢那一张，给出排序。从我这里得到分析之后，他决定和我的选择反过来。当时我很好奇，问他为什 ...继续阅读 (51)

《2022 年总结》中对 2023 年的计划中有一项是“完成至少 6 篇博客”,这一目标完成的还算不错。 7 月份更换了新的博客主题后顺便把数据 Google Analytics 加上了。9 月份把 Github Pages 的域名 CNAME 到了之前一直使用的linnana.me,又对博客的访问速度和性能做了简单的测试。10 月份简单学习了如何使用 Google Looker Studio，于是在年底有了如下图的数据报告。你可以访问这个链接（需科学上网）体验上面这份报告。 ...继续阅读 (49)

前言在 V2EX 上看到了一个讨论“大家认为好的交接文档和形式是什么样的？”，我在二楼写了一点看法。之后有人提到了”交接文档残缺坑的是别人，维护文档麻烦的是自己“，我想这是很多软件工程师的真实想法。鉴于过去两年时间里，推进团队的工程实践中在研发技术文档有一些收获思维转变很重要这些文档尽量不要等到交接的时候再去写，而是应该在日常工作中去完成。同时也应该把这些文档当成项目或者仓库的一部分，放在 仓库 wiki 里随着项目更新而修改。这样不管是对新人还是工作交接都更有利于。包含哪些内容以下是我们团队的一些实践： 1.新手教程。 2.架构说明。各个组件的作用，核心依赖以及非核心依赖。国内、海外，主、备等。 3.组件介绍。每个组件的核心逻辑、核心目录等介绍，可以根据重要程度详细或者简略介绍。 4.编码实践。如何搭建本地环境、分支管理策略、issue/PR 规范、代码审核规范、单元测试规范。 5.运维实践-开发篇。如何预发布、灰度、发布、重启、回滚等，以及 CI/CD 。 6.运维实践-运维篇。云服务商依赖、基础设施依赖简介。监控：业务监控、基础设施监控，报警：业务报警、其他报警。 7.测试。 如何单元测试、本地集成测试、预发布环境测试。 8.日志。日志规范、如何使用日志。 9.故障与问题。历史故障复盘、常见问题如何处理。 10.非预期。限流、降级、预案等，最小集功能。 11.账号与 lice ...继续阅读 (41)

前言在 V2EX 上看到了一个讨论“大家认为好的交接文档和形式是什么样的？”，我在二楼写了一点看法。之后有人提到了”交接文档残缺坑的是别人，维护文档麻烦的是自己“，我想这是很多软件工程师的真实想法。鉴于过去两年时间里，推进团队的工程实践中在研发技术文档有一些收获思维转变很重要这些文档尽量不要等到交接的时候再去写，而是应该在日常工作中去完成。同时也应该把这些文档当成项目或者仓库的一部分，放在 仓库 wiki 里随着项目更新而修改。这样不管是对新人还是工作交接都更有利于。包含哪些内容以下是我们团队的一些实践： 1.新手教程。 2.架构说明。各个组件的作用，核心依赖以及非核心依赖。国内、海外，主、备等。 3.组件介绍。每个组件的核心逻辑、核心目录等介绍，可以根据重要程度详细或者简略介绍。 4.编码实践。如何搭建本地环境、分支管理策略、issue/PR 规范、代码审核规范、单元测试规范。 5.运维实践-开发篇。如何预发布、灰度、发布、重启、回滚等，以及 CI/CD 。 6.运维实践-运维篇。云服务商依赖、基础设施依赖简介。监控：业务监控、基础设施监控，报警：业务报警、其他报警。 7.测试。 如何单元测试、本地集成测试、预发布环境测试。 8.日志。日志规范、如何使用日志。 9.故障与问题。历史故障复盘、常见问题如何处理。 10.非预期。限流、降级、预案等，最小集功能。 11.账号与 lice ...继续阅读 (44)

时任台湾财政部长的王建煊，则在 1982 年的《中国人应该如何想，如何做》一文中，如此回忆 1964 ：对岸搞战备，搞三线，搞核武，是不是劳民伤财?你可以说是，但是，它却是必要的，是至少遗惠 100 年的。对岸是大国，是无论如何不会符合强权们心意的大国，是无论如何要被骂被恨被仇视的大国，是无论如何要挑战旧秩序的大国，也是无论如何要与两超硬碰硬的大国。大国要就要搞战备，就要搞三线，就要搞核武。一时不搞，苟安一时;一世不搞，遗祸万代。对岸的民生差，我们要批判，都是中国人，我们感同身受;对岸建军工、实国防，我们要支持，都是中国人，我们同享普惠。有朝一日，我们光复故土，再造青天白日大中国，对岸的建设，我们也是要用的嘛! ...继续阅读 (44)

角色XDSDK 技术负责人，后端工程师。整个团队的实际负责人，研发实线汇报，产品等虚线汇报，大致 12 人左右（ HR 核算的人力成本）。 团队包括：客户端、后端、前端、QA、产品，产品同事向自己的产品专业线汇报。业务范围心动 100 多款自研或者代理游戏玩家的登录、用户、支付功能。开发者文档聚合支付：年支付流水 20 亿元+;登录：支撑多个百万 DAU 的游戏，峰值 QPS 1 W+。工作内容新交接过的团队和业务管理做管理动作之前，首先要了解现状，对团队存在的目的了解清楚，否则很容易做无用功。然后考虑请求哪些是要优先做的，哪些是可以往后长期建设的。团队存在的目的为了玩家提供好的、稳定的登录、用户、内购支付体验为内部游戏提供便于接入且稳定的登录、用户、内购支付中台影响游戏和公司营收：登录-影响用户进来，游戏会买量，登录稳定性、转化影响游戏支出；支付-支付稳定性、转化公司营收。现状故障频发需求、版本管理混乱外部抱怨、投诉较多上层管理者不满意原有负责人的管理质量优先级最高的降低故障率缓解外部压力次优先级让需求管理有序项目管理有节奏研发质量改善形成制度提升人员质量对外沟通游戏研发、策略、运营：统一对外沟通对接人员：我和产品经理固定的会议沟通，重点游戏每个月一次，非重点游戏两个月一次共享团队 OKR偶尔参加重点游戏的周会客服、财务、翻译等横向人员统一对外沟通对接人员：产品经理固定的会议沟通 ...继续阅读 (31)

前言文档即产品门户。在一个商业化的项目中，如何用工程化的思维和实践更好的持续迭代文档是一件非常值得思考的问题。平常工作中我们接触到的文档主要包括两类：类似 API 设计、架构设计、技术改动设计、逻辑设计等等面向用户比如开发者，更专注于教程和概念的文档。在《我们是如何做 code review》中提到如果是新增功能以及稍大的改动请提前达成设计上的共识。这类前后端、客户端、后端之间达成设计一致的文档属于第一类。这类文档结构化程度没有那么明显，我们主要放在 Confluence 和 Gitlab Wiki 里。平时工作中，工程师接触可能更多的是第一类。但这里主要谈第二类，这一类文档内容复杂，工程化的 ROI 更高，同时又因为其用户是开发者或者用户。内容往往会涉及到研发工程师、技术支持工程师、产品经理等等角色，工程化带来的业务价值也更明显。内容是首要的文档通常是为了产品用户的利益而创建的。它的主要目的通常是帮助用户完成产品的某些任务，因此在制作不同类型的技术文档时，应始终考虑到最终用户。而文档的内容是评判文档好坏的最好的标准。信息传达：文档的首要目标是传达信息。无论是教程、指南、手册还是说明书，文档需要提供详尽、明确和准确的信息，以满足读者的需求。良好的内容能够帮助读者理解和掌握所描述对象的知识和操作。解决问题：开发者查阅文档的常见原因是为了解决问题。好的文档内容能够回答读者可能提出的问题 ...继续阅读 (41)

You know the thing always make me cry, but I will not cry here. It’s not fair.It’s not fair. It’s not fair that I had to go through this disease while the other five didn’t. They got everything that I got, but I had to fight this thing - and still have to fight this thing.It doesn’t go away. It never go away. ...继续阅读 (47)

前言我是线下办公的支持者。在人与人的互动中获取信息的方式是多维的，包括视觉、触觉、听觉等等，而不是冰冷的文字而已。当一个人坐在你面前，Ta 是生动的，那种即时感是远程办公所无法给予的。两次远程远程办公 WFH（work from home)越来越被人们谈及，这两天看到V2ex上有不少求职远程工作的，也有不少发远程岗位招聘的。在 2020 年的春节过后 , 远程工作，一个之前都没怎么考虑的事情，在那之后中国的很多企业或多或少都对此进行了一次大规模实验。想到截止目前为止，我有「两小段」远程的经历，感觉有必要记录一下感受。2019~2020 年尝试创业期间。持续远程 5 个月。2022 年 COVID-19 疫情期间，上海 Lock Down。持续远程 4 个月。虽然两次远程都在疫情期间，但是情况却不太一样。2020 年的远程是出于尝试创业期间，我们都觉得没必要先成立公司，而是快速尝试，就更谈不上在某个地方租一个办公室了。因此 2020 年的远程更多是大家各自的选择。我在老家，其他几位伙伴分别在上海、深圳、杭州。这次远程持续了 5 个月左右。而 2022 年的远程某种程度上是被迫的。上海 Lock Down 之后 4 月开始我在上海的出租屋里，6 月份之后我回到了老家，远程到了 8 月多才去的上海办公室。远程的好与环对大部分互联网公司来说，工程师在家办公并不是什么困难的事情，本来许多工作 ...继续阅读 (51)

裸身高 169 ~ 172 cm 左右，巅峰时期完全没有小肚子的体重在 120 斤以内。减肥前体重 160 斤，100 天内减了 30 斤左右，腰围瘦了 10 cm 左右。空腹状态下肚子上依然有一把可以捏起来的肉。先放结论七分吃，三分练减脂是全身性的，不存在单纯瘦肚子的方式减肥的核心是要找到一种适合自己并且可坚持的饮食和运动方式饮食饮食最为关键七分吃，三分练。我坚信减肥靠饮食调整，运动只是辅助而已。坚持把零食、饮料、宵夜、聚餐等等都拒绝掉正常吃三餐，即使坚持这样 2 个月你也会比较原来瘦。早午晚餐早餐一般在 8 点 30 之前吃完，主要包括：1 ~ 2 颗甜玉米、一瓶纯牛奶、一个苹果，如果没有甜玉米我会用燕麦来代替。如果是周末家人会做早餐也会跟 TA 们一起吃两个包子或者一碗小碗鸡蛋面。早餐一般不会过分忌口，当然也不会放开吃。午餐一般在 12 点 30 之前吃完，主要包括：一小碗米饭（大概男生一拳头的量）、两碗蔬菜、一碗肉，肉类主要选鱼肉、鸡肉、牛肉。大概是吃个 6 ~ 7 分饱。按照蔬菜、肉类、米饭的顺序进食，用蔬菜先填肚子，这样吃完不会觉得饿。大概下午 5 点左右开始感觉到肚子饿。晚餐一般在 18 点 30 之前吃完，主要包括：半小碗米饭（大概男生一拳头的量一半）、一碗蔬菜、半碗肉，肉类主要选鱼肉、鸡肉。大概是吃个 4 ~ 5 分饱。按照蔬菜、肉类、米饭的顺序进食。 22 点左 ...继续阅读 (37)

加入新公司不久之后，我很快参与到了LeanCloud的即时通信、消息推送这两个服务从 Clojure 向 Golang 和 Java 的重构中。但是 2022 年初大团队接手了一个坑比较多业务和一部分移交过来的人员，直属 Leader 和我沟通之后让我参与到这个刚交接过来的业务中。于是开启了一段新的挑战，需要注意的是这时候我是以一个普通工程师的角色加入的。从实际情况出发，先了解再参与了解的方式途径包括代码、沟通、观察等等，回过头去看这是当时对团队现状列的一些描述：线上故障频发历史遗留比较重需求、版本管理混乱有着比较差的工程实践团队人员能力相对比较差，经验不够资深更具体的比如，这个业务交接过来的第二天就出了线上故障，此后陆陆续续有出了几个线上故障，后端系统没有任何业务 metirc 无法知晓系统状态，甚至部分代码仓库只使用两个固定分支进行迭代，需求管理混乱等等。作为参与者如果希望重构代码，那么首先就应该熟悉代码；如果希望做架构改动，那么就应该先熟悉架构。如果希望故障能够尽快得到解决，那么即使一开始不熟悉代码，也应该积极参与到故障排查和故障善后中去。总得来说，想改善什么先去了解和参与效率会更高。任何新方案的实施都要以对现状的理解为基础 , 比如说现有的组织结构、对新方法的接受度、具体的业务特征、技术成熟度等。脱离具体的上下文，照搬“普适”的框架，会带来巨大的适配成本。前期花费大量精力在 ...继续阅读 (40)

关于 code review 在开发中的重要性已经有很多的文章讨论，我这里不想再过多重复。但是作为 Tech Lead 在工程实践上仅能保留一条团队规则的话，那么坚持 code review 是我愿意持续坚持的。关于 code review 的各种方面，Google 出了一个最佳实践How to do a code review。同时还有一本书Software Engineering at Google,在ch09花了一整章介绍关于它的方方面面。本文主要介绍自己的一些个人经验和感受，特别是作为 Tech Lead 推进团队 code review 文化的一些思考。从自己开始，从现在开始一个很残酷的现实是国内工程师因为公司业务压力或者个人经历的原因，很多团队可能都没有实施过 code review, 那么作为 Tech Lead 想要推行严格有效得 code review 是比较困难的。这时候 Tech Lead 可以先从做好自己开始，比如从把自己的代码发给别人 review 开始，分享一些自己案例，当遇到有意思的讨论也可以发出来让更多的人参与进来讨论，实际可见的参与感或者价值是最有说服力的。代码在合并到主干之前进行需要 review每一行代码合并到主干之前必须进行 code review，代码必须经过至少一个reviewer 的 review, Merge Request 才能合并 ...继续阅读 (33)

如果从线上故障的次数和影响范围来看 2022 年，于我来说无疑是痛苦的一年。这一年有新业务刚交接过来第二天就发生大规模海外玩家登录不可用，也有犹如刺刀一般的支付系统故障。当救火队长的这一年，写了好几份故障报告，这里总结一下团队里写故障报告的思路。软件工程的历史上无数案例告诉我们随着系统的发展，发生线上事故总是难以避免的。因此事前通过代码评审(我们是如何做代码评审的)、自动化测试来降低线上事故发生的概率。当然事故发生时我们需要以最快的速度将服务恢复到正常状态。而事后更重要的是我们从失败中学习到了什么，事故报告则是进行事故复盘的重要手段。我们团队目前在事后总结的文化和实践上遵循的是Google SRE 的 postmortem-culture，即每一次故障都应该写一份事故故障报告，相信很多公司或者团队都多多少少会借鉴类似的实践。我们遵循的理念对事不对人。学习是避免失败最好的办法.事故故障报告不是一种惩罚措施而是团队学习的一次机会。写故障报告最重要的是：确保实施有效的措施使得未来重现的几率和影响得到降低。随着系统的规范和复杂度的增加，如果我们不能意识到系统中存在的问题并采取措施去改善或者预防故障可能就会成倍增加。什么情况下应该写故障报告为了工作更有效率，我们不可能为每一个 bug 都写一个事故报告，以下我们团队在采用的一些标准：用户可见的宕机时间或者服务质量降低成都达到一定标准。问题解决 ...继续阅读 (35)

前言过去的两年时间里，一直都有参与到团队的工程师招聘。参加了大概有几十场面试，在这个过程中，我也一直在思考如何更好的面试候选人。在这里，我想分享一下我在面试过程中的一些经验和思考。很多人可能会觉得工程师的面试是一个非常客观的过程，但是其实在短短一小时左右的沟通，面试更多的是对候选人形成一个整体的印象，很难说非常客观，有时候是带着不少面试官的主观判断在里面的。面试流程通常我们的面试分为一次电话面试和一次现场面试，当然疫情以来大部分面试都是两轮电话面试。第一轮电话面试由一位一线工程师或者一线主管面试官负责，第二轮电话面试由一位一线工程师（也可以是团队主管） + 部门技术负责人或者部门负责人一起参与。作为团队主管，第一轮面试和第二轮面试我都会有所参加，但我不会同时参与同一位候选人的两轮面试。面试内容以下是团队总结出来的内容大纲，但面试不总是需要严格遵守，只是作为一个指导性大纲：基础知识：基本的数据结构和算法；分而治之等解决问题的高层思路；对概率的基本理解；对时间和空间复杂度的理解；所招聘职位相关的专业问题一点经验确定好一个衡量标准在面试的过程中经常会遇到一些候选满嘴跑火车，面试时间就这样流失了。因此面试官或者团队面试官要达成一致，对候选人有一个大致的衡量标准，比如写出某道编程题占比是多少。避免面试了半天最后什么也没获得。确定好一个衡量标准也有利于彼此对齐招聘要求。适当的开场如果是第一轮面 ...继续阅读 (35)

工作从执行到 Team Leader 的变化并没有给我带来更多的时间可以思考团队的发展等等，反而让我在研发的角色之外需要花更多的时间参与团队管理和更多的沟通。这个过程中有不少客观因素但我自己做得并不好，希望 2023 年可以从容一些。也觉得自己很多事情做得并不好，不过 Leader 和部门负责人还是提名了我优秀员工，最后喜提一份 ` 小礼物 `，感谢这份认可。这一年的工作占据了我不少额外的生活时间，工作总是很忙碌，这和我一年多前加入江宏团队的目的也越来越来远。 2023 年这种忙碌如果客观事实上得不到改善，那我自己会主动通过其他的手段来改善。这一年的种种经历让我对软件工程、历史遗留、团队管理、如何把一个产品做坏也有了更深的理解。此处种种余后再表…….读书2022 年加到微信读书书架里的书挺多的，也买了不少的纸质书。大部分和工作相关主要包括：团队、管理、绩效。读完的包括：《Code Complete》重读《增长黑客》《10 人以下小团队管理手册》《敏捷革命》《我读管理经典》《团队协作的五大障碍》《新管理者如何度过第一个 90 天》《不拘一格：网飞的自由与职责工作法》其他有不少都在下半年上下班骑车的路上用 1.5 倍的倍数听了些需要快速补充的内容。今年写了 3 篇读书笔记，还是希望 2023 年尽量能把读的每一本书简单做一下读书比较，像 2020 年那样每月发一些读书总结也是不错的形式 ...继续阅读 (34)

《团队协作的五大障碍》作者通过一个高管团队的故事，讲述了团队协作中的五大障碍，五大障碍共同形成了一个模式，每一项都可能成为致命杀手。同时介绍要克服这些障碍，需要遵守什么原则。作者说明了两个基本的事实：第一，大多数企业中，真正的团队协作仍然很难实现；第二，企业之所以不能实现良好的团队协作，是因为它们不自觉地陷入了五个很普通但却很危险的沼泽之中，作者称其为团队协作的五大障碍。人们很可能误以为这五大障碍是各自独立的，实际上它们共同形成了一个模式，这使得它们中的每一项都可能成为企业团队的致命杀手。note问题都在点上，但解决方案太理想化了。即书看完了，道理似乎我们都懂了，但在团队协作的改善上缺依旧困难。我个人并不是太喜欢这种讲故事的方式来讲这个内容五大障碍缺乏信任信任含义：相信团队伙伴言行出于好意，无需过分小心、相互戒备。必须放心接受彼此批评。信任状态：成员真正放心暴露弱点，不用担心团队攻击，完全消除戒心，全部精力集中工作，不用勾心斗角、尔虞我诈。缺乏信任的团队成员：隐藏缺点和错误；不愿求助，不愿提出建设性反馈；不愿提供职责外帮助；轻易下定论；不愿承认和向他人学习；浪费时间和精力追求自己特定目标；对别人不满和怨恨；惧怕开会，寻找借口，尽量减少在一起时间。充满信任的团队成员：承认弱点和错误；主动寻求帮助；欢迎提出问题和关注；出现问题相互提醒；赞赏并向他人学习；时间和精力花在解决实际问题而不是 ...继续阅读 (28)

这是公司组织的管理者培训的课程笔记内容。绩效沟通的目的是管理者与员工直接沟通绩效结果，并讨论发展计划，让员工能力得到发展的过程。如何做好绩效面谈肯定成绩提问方式让员工自己总结，例如“这半年你个人觉得收获最大、成长最快的是什么？”正确回应基于员工总结予以回应，例如“除了你提到的成绩以外，我还看到 XX 方面，你也做得不错”探寻改善发问形式，重点复盘改善与提升点，例如“如果下一个季度要做得更好，哪些方面可以提升？”予以回应结合员工复盘予以回应，例如“我也观察到，你在 XX 方面，和计划与目标相比还存在一些差距”沟通绩效结果基于前述沟通，达成共识，例如“综合评估下来，你的绩效结果是 XX ”关注成长“从个人发展和成长角度，哪些可以支持到你？还有哪些困惑需要我们交流？”Tips：多问、多听、少说；提前做好具体事例准备绩效面谈指南开始之前请明确本次沟通的目标——针对员工半年度绩效给予反馈并探讨发展计划准备好例子和客观数据，使对话更加丰富和具体这次沟通应包含的关键内容：介绍本次沟通的目标——你准备对员工半年度绩效表现给予反馈，共同探讨员工的发展计划说明员工的整体绩效表现（绩效结果需明确告知）、公司对本部门整体绩效的评价认可和赞扬做的好的方面需要改进的以及下一步建议如何做询问员工对管理者有何反馈讨论员工下一阶段的目标，明确期望Tips：多问问题，鼓励团队中的员工敞开心扉时间分配： 过去 : 未来 ...继续阅读 (34)