> For the complete documentation index, see [llms.txt](https://nixum.gitbook.io/note/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nixum.gitbook.io/note/gong-zuo-si-nian-zong-jie.md).

# 毕业后四年工作总结 - 第一阶段结束

### 工作经历

从19年毕业的时候，给自己定了一个期限，希望能在第三年做出点成绩，或者能跳到一家好一点的厂子，虽然比预期晚了近一年，但还算基本实现（自认为）。

目前为止(2023.05.09)，主要的技术栈还是围绕着后端 + 云原生展开，经历的业务是广告 + 电商，幸好，毕业之后遇到的团队都非常不错，几任主管都很nice（巧的是他们几乎都是之前UC系的），都给了我非常大的帮助。

* 2018.07 \~ 2020.05

  从实习到校招乃至毕业的第一年，做的是广告方向的业务，类似网盟平台，但主要是业务框架的开发，比如类GraphQL协议语法糖的实现、账号服务架构、广告主接入流程低代码等方面，量的话，高峰时一天有一亿点击，还是很猛的。

  开发使用的是Java，但又不使用 Spring 全家桶，除了底层的Web框架用的是Netty，像微服务间的通信协议、RPC、业务框架啥的，都是团队自研的。CTO带队，当时的Leader和CTO本身对技术很有追求，对方案的设计和代码的合理性都非常严格，这对刚毕业的我来说成长上帮助比较大。

  自研的框架在我看来，整体上是一个多Reactor多线程 + 事件驱动 + 状态机的模型（blog上有这个模型的简化版类图），能极大程度压榨CPU的性能，整体上吞吐确实比Spring全家桶那套要高一点，设计上确实挺巧妙的，后来甚至把整个事件驱动抽出来做成一个PaaS框架， 搭配自研的类 GraphQL 接口，实现低代码的功能，任何方向的业务写完配置就能直接往里套，就有CRUD接口可以用了，当然，代价就是实现很复杂，写得我及其痛苦。

  这对于刚毕业的我来说真的高维打击，很多东西都不懂，每天都要干得很晚，甚至会为某一个功能实现不出来感到焦虑，足够难，但也足够有趣，是成长得比较快的一个阶段。
* 2020.05 \~ 2020.11

  由于公司内部原因，之前所在的基础架构部门解散了，当时又由于疫情刚开始，还是有点害怕失业的，还好后面转入业务部门，不过也从Java转成go + gin那一套，从事跨境电商方向的业务开发。

  业务方面没什么好说的，难度对比之前真的降维打击，当然成长也比较慢，好处是这个阶段开始接触到云原生、Kubernetes + Istio那一套，这个时候还只是以用为主，初步对这些东西有了概念，当时的Leader也很支持我们自己去探索，就利用公司闲置的KVM搭了一套K8s集群，算是入了个门，开始云原生探索道路。
* 2020.11 \~ 2023.04

  在当时公司电商业务技术负责人的邀请下一起跳槽到一家做出海的创业公司，主要也是从事跨境电商方向的业务开发，自研电商平台，创业的方向总体还是围绕着电商在做，从数码3c电商平台到本地生活类型的电商平台，因此也有幸参与到了整个业务线、后端基建的从0到1。

  得益于之前的经历，进入公司的第一件事就是为后端团队搭建基础设施，使用AWS EKS搭建了kubernetes环境，在此基础上，采用EFK方案做日志收集、采用Prometheus、Grafana方案做指标采集和资源利用率看板等一系列的监控告警工具，基于 Gitlab 搭建整套CI/CD流程，算是基本把整个后端的基建搭建起来，有了监控告警和日志查询，动态扩缩容，基本上服务开发后就没有烦恼，自动化部署和维护起来真的很方便。

  在此期间也重新认识了kubernetes，对它整个架构和原理有了更深一步的理解，基本上一些常规的问题和排查思路都非常熟悉，不得不说，Kubernetes真的是一座大山，里面的理念和方案设计真的挖都挖不完，但是，个人感觉像Kubernetes这一块，如果想要更进一步的提升，还得有足够复杂的场景才行，只依赖一两个demo或者我们这种小集群（10台机器）还是远远不够；

  基建搭完之后，逐渐转向业务开发，先是基于以前的项目抽出一套业务开发的脚手架，对应的目录结构做分层，团队的小伙伴需要起新服务时直接命令式生成脚手架，可以直接进行业务代码的开发即可；（这里也立一下Flag，未来有时间要继续完善一下那个脚手架，反正后面做副业可能也会用到）

  之后才是真正的做业务开发，负责平台的核心交易线，主导开发了订单和支付服务，这里比较好的一点是前期设计的时候就考虑中台的方案，尽量将整个交易流程标准化，并提供一套接口方便各个业务方接入，在后面公司频繁变换方向的时候，仍然能提供很好的订单和支付功能的支撑。
* 总之，这四年总结下来，基本上从后端的开发到云原生的开发部署运维这一块，都有一定的理解，对方案的设计，架构，设计模式，代码的组织也有了自己的思考，具备独立规划和完成的能力，在后端中kubernetes还算是玩得比较溜（当然云原生这块还是比不了专门搞容器开发的，但对于一个后端来说暂时够用了）；业务方面也熟悉了交易，履约相关的功能，对电商和广告有一定的认识。

### 求职感想

从离职到入职，中间gap一个月，就靠着平时的积累，离职后复习了一周就开始投简历，今年行情确实很差，没那么多机会了，Boss上来来去去也是那几家，然后我还是瞄准了百人以上，有一定规模且盈利的公司，选择就更少了，进面的有13家左右，最终offer四家，还有两家是拿到心仪offer后没有继续推进面试流程的。

在整个求职过程，也是不断发现不足和补齐不足的过程，甚至比上班还累，每一次面完都快虚脱，回头还得复盘和复习，每一次面试没过就意味着少了一次机会，异常焦虑，时刻处于自我怀疑和信心十足的跌宕起伏中...

今时今日，面试已经不像以前那么容易，机会是面一个少一个，如果想提升面试成功率，拿到更多的offer，平时就要有所积累了。

**对于简历**，个人推荐是半年更新一次，即使没有跑路的意愿也需要更新，再不济也要记录一下这段时间的工作内容。记录时，以STAR法则作为线索去写，就算是普通的CRUD，也可以通过设计模式去美化它，当然前提还是需要你真的能理解。

记录的时候，需要记两份，一份是用STAR法则记录详细的内容，包括背景和场景、实现、优缺点、可改进的点，这一份是针对面试官询问的时候，能牢牢把握住你经历的项目内容，不会一问三不知，讲述的时候也要可以按照STAR法则去讲，这样就能很清晰的讲出来，面试过程中能流利的表达也是一个很重要的点；另一份是对详细内容的浓缩，提炼成一句有亮点的话写在简历上的。简历通常需要不断修改，可以给其他人看，根据他人的建议进行修改，一份好的简历基本是要迭代个三四遍吧。

另外，简历上不宜出现过多业务名词，除非是对口的业务方向，因为面试的公司不同，业务也不同，不同业务的面试官可能会看不懂这些名词，最好的方式是将业务抽象为技术模型，思考它的优缺点，这样的好处是，如果遇到相同的业务场景，不管是在面试中还是工作中，都可以去套用，也能引导面试官从技术角度提问。

**对于基础**，数据库、网络、操作系统是必问的，占比大概是50%、30%、20%，这一块就比较吃基础了，微服务、服务治理、分布式架构、云原生，甚至一些业务解决方案，都是在这些基础上进行延申和借鉴的，打好基础真的很重要。

如果想要速成，推荐小林coding那几个专题，应该足够应付大多数场景了。如果想更进一步，就急不来了，一些MIT的课程，一些经典的书，博客文章，慢慢啃吧。

**对于八股**，说实话我现在还是不太清楚八股是不是指别人整理好的一些的面试题Q\&A，如果光靠这些Q\&A的话，我觉得是远远不够的，这种稍微问深一点就得露馅了吧。当然，Q还是有很好的提示作用的，至少Q可以抄，但A还是得自己去找，不断的去思考，理解和延申，不断的从Q里进行发散，才能真正转换为自己的东西；

**对于system design**，这个就比较吃工作经验了，有些场景你没遇到过，没仔细思考过，当场回答起来是比较费时费力的，效果也不太好。

解决办法可以是上面有提到的把自己遇到业务场景转换为技术模型，平时多看点系统设计的书，一些大佬的解决方案，或者是平时自己看到的一些功能，思考一下别人是怎么实现，通过这些方式来积累了，这也是我目前做的不够好的，还需要总结出一个指导思想出来。

**对于算法**，这个真的是性价比极低的投入，极低的ROI，基本都是靠量堆起来的，靠量变引起质变，反正个人能力有限，跟大佬们还是没得比，基本都是刷了忘，忘了刷，除开那些简单题，很少能达到一次性bug free的程度，但是至少，个人觉得leetcode Top 100还是要过个几遍来保持手感的。

**对于面试**，面试过程能录音最佳，面试完就要及时复盘，及时记录，有时候自己觉得很有信心的题目，实际上回答时却磕磕绊绊，遗漏细节，没有条理，所以才需要及时复盘，形成一个回答问题的指导思想，个人觉得STAR算一个比较好的回答方式。

总之，面试这种东西，一方面看积累，一方面面的多了，熟悉了回答的一个大概思路，自然就懂得一些套路，**最最最重要的还是运气**哈哈哈，毕竟前期再多的准备也只是给自己一些底气罢了。

### 未来期望

第一阶段就算是结束了，下一个阶段还没想好要定多久，可能3年，或者4年？目前好像还看不到太远，身边也没有可以参考的目标系。

当然，自己本身好奇心也还是有，对很多东西都很感兴趣，虽然，大部分还是处于光说不练的假把式状态哈哈哈。期望是能在第二阶段找到一份能做下去的副业，或者能持续探索的技术方向。

做技术有个好处也有坏处，好处是有什么产品的想法可以快速通过自己的技术去实现，最近也和朋友合作了一款小品级应用，已完成基本的开发、监控和告警，尝试推广中，目标是今年能有小一千的用户，这样服务器成本也能cover了，能赚点点零花钱。

对我来说，比较感兴趣的东西还是偏底层，或者框架类型这种脱离业务范畴，偏通用一点的东西，比如云原生相关、中间件、框架基建类的应用实现，但要真正的落地，还是需要有大规模的量来进行验证，真正投入到生产环境中，才能知道自己的实现的方案好还是不好，这点只能尽量在工作中找找机会了。

然后，也罗列一下接下来想要去做的东西：

1. 目前这份工作业务方向是金融相关的，所以期望自己能多学习一些股票、基金类相关知识，本身理财也是挺重要的一环；
2. 工作还是业务侧相关的开发为主，应该会非常无聊，业余应该会尝试从：音视频、存储、IM、ES 、k8s一些组件进行相关的学习；
3. 英语，目前来看英语还是非常重要的，无论是信息获取还是日常使用，光会读写还是不太行，接下来目标是达到一个非常熟练的听说读写，期望是能达到张口就来，一听就懂那种；
4. AI 或者 Web3，这两个方向本身就有比较大的未知和可能的存在，如果作为独立开发者来说，可能基于这两个方向可以做一些应用层相关的开发，会有比较大的回报？
5. 发展点其他兴趣爱好，比如磨练一下拍照技术、羽毛球甚至社交，健身好像也可以纳入计划中了；


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://nixum.gitbook.io/note/gong-zuo-si-nian-zong-jie.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.