我经历过的英语面试

以上所有面试并除了Morgan Stanley因为技术问题没回答好挂了之外其他都通过了面试本身。英文的技术面试重点依旧是技术，但是经过我的练习，我至少可以做到尽可能减少表达不流畅带来的负面影响。

我训练的主要目标是提升表达的流畅度，对口语的口音没有太多要求。

碎片时间利用的方法

英语刷算法题

英文面试中手撕算法题的关键依旧是讲清楚算法题，只不过多了一个附加条件——用英语。我在原来写自己的题解、梳理思路的基础上只是替换了语言。先保证自己能用中文清晰的写出算法题思路和需要注意的要点。

做英语算法题，看英语题解，用英文关键词搜索 尽可能营造沉浸式环境，同时减少对英语的陌生感和恐惧感，避免看到英语算法题就头晕。还可以学习相关术语。

大胆写 不需要在意语法 是Broken English也没关系 如果一开始觉得直接说很困难可以先写出来，作为缓冲。写的时候可以不在意语法，不一定要是完整的句子，把要点写出来，再考虑连起来。

模仿学习矫正是必须要下的功夫 参考母语者是如何讲题的可以帮助自己修正讲题的方式。我参考的是NeetCode。他擅长用样例讲解算法，并且用语非常基础，易于模仿。在学习模仿的过程中也可以积累常用的讲解算法题的表达。

整理文件的时候发现于是发出来 其实是一个补档

考完试了来回顾一下这一个学期我都在干什么。

考试周的时候感到非常空虚，总是沉迷于阈值很高的娱乐而无所事事，经过一段时间才能调整适应并没有ddl追着打的日子。但是转念一想，在一个学期被ddl追着打的日子里，我又有什么收获呢? 乍一想好像还真没有。

翻开我的日程本，刚开学的三月份过的还是相当忙碌的。寒假结束了STEP项目的申请（失败）和美赛，马不停蹄的又开始参加shopee的比赛以及准备gsoc。

shopee的比赛纯属被大佬带飞，我也认识到自己并不适合短时间突击某个技术模块，厚积薄发才是王道。（尤其是在美赛结果出来以后更是印证了这一点）。

gsoc虽然最终落选，但是在准备的过程中啃了一篇论文以及工程级别的源代码，认识到做研究和做工业的不同。做研究需要独创性，并且需要证明自己的方法有效，至于代码实现，只是作为证明的一部分。同时打破心理舒适区，拓展了一下自己的能力边界，看懂全英文的论文，搞明白代码的互相依赖关系并不是不可能的！

之后就是连着的面试。STEP的惨痛教训另外写过。面腾讯和微软的时候基础知识和算法不够扎实，不出意外的挂了。5月份学期快结束的时候，面字节因为对方不愿意收大二的也挂了。还有一个量化的岗位因为时间不合适我被我拒了面试机会。通过一连串的面试，虽然没有获得996的机会（不是，但是多少了解了自己的不足以及接下来弥补的方向。同时在这期间，学会了如何大胆的请教前辈以及利用connection争取机会。

另外有一个NUS的summer camp出于财务问题被我残忍拒绝了。经此一役确认接下来留学的打算估计要推到自己攒够钱之后了。家里能够提供的支持是有限的，我也不忍心再让父母掏钱。

获得这样的结果我并不意外，并不能算是有顶级天赋又没有下定决心狠狠努力的我显然并不能苛求太多。从另一个角度说，失败是成功的逆位，通过排除自己目前不能做到什么，可以为接下来的假期敲响警钟。

课外活动的丰富尝（shi）试（bai）来源于上个学期无所事事的教训。但是在课外也一无所成的情况下，似乎乍一看是没有任何收获的。这可能是源于我高中一贯以来的思维：大家都做了就等于都没做。但是显然，在有限的时间内，课内的实践也应当成为宝贵的经历。至少在努力过后要有所提炼，有所感悟。

原文是我外刊时文共读的作业，但是我认为这门课让我学到的东西可以拓展写一下，于是改写成了这篇文章。关于碎片化学习英语，应该会写一个系列，覆盖近一年来关于听说读写这四个方面我的练习。

Intro

过去的三年时间里，除了大一还有英语必修课使我能在繁忙的专业课程之余专门留出时间给英语学习，我总是很难在专业课夹击中找到如上大学之前那样集中学习英语的时间，连四六级英语考试都是匆忙上阵的。

系统有意识的学习英语多半是在课堂上：有专门主题的教材，有系统的笔记，有及时的作业和反馈。这并不是说我在平常不会接触、练习、使用英语；但是与课堂相比，总是缺少刻意练习和记录，因此我总是把系统、刻意练习的期待寄托在完整的、可以像课堂一样的时间段，寄希望于教材这样系统的学习材料。但是实际上，这是一种会阻碍我前进的“完美主义”。学习任何事情都不需要等到一切就绪。

Learning in Pieces

语言原本就是思想的载体，是交流的工具；我所学习、所练习的一切，原本就是为了更好的倾听他人的观点，表达我的想法。因此即便是对不同主题，基于不同体裁看似零散的练习，也总是有相通的地方；而能从多种多样的文章中找到共同的部分——比如国际顶尖媒体写作者都是怎样导入，怎样吸引读者注意，引起读者思考——也同样是一种能力。对于我这样有阅读英语原文——包括新闻和技术文章——的习惯的人来说，实际上每一篇文章都是一次学习的好机会。

饭是一口口吃的，但是每一口吃什么，可以根据此时此地的情况定制。读什么样的文章，读文章的时候注意什么，都可以通过不同的选择来激发自己的学习兴趣。比如对同一篇文章，可以着重积累词汇，也可以学习作者安排文章结构的方式，或是观察作者如何导入一个主题、事件、专业名词；或者对不同的文章，采取不同的策略。对于略读的文章，可以扫几眼概览架构；对于精读的文章，可以掏出小本本记单词分析句子。总之可以灵活安排，就可以一定程度上减少“等我有时间再做”这样的无效flag。

我时常会有阅读专业相关的英语博客的时候，这种时候除了注意专业知识，我还可以积累一些常用专业术语的表达，并且观察写作者是如何让文章保持简明易懂的。而对于商业、时事新闻，我可以多积累一些常用名词，以及一些通俗搭配，了解一些文化背景知识。

Make some Output

上外刊课程的时候，系统整理好的笔记和选择题答题记录是作业的一部分。不过这也倒逼了我输出笔记。输出倒逼输入的好处就不再赘述了，个人觉得还是非常大程度的避免我偷懒or忘记学到的东西了。

实习经历

实习开始前有一个有意思的小插曲，我申请过一次换组。微软暑期实习分组和项目本身是开盲盒，算法分到开发的也大有人在。可能是因为我上一段实习主要做客户端开发的工作，最开始发邮件给我分到的组主要是做前端的。于是我发邮件问组里有没有后端的项目能让我去做，对方虽然答复我说组里主要做前端没有后端项目，但是愿意帮我去向大老板申请能不能给我换组。于是后来我成功换到了我后来实习的组。我的manager也知道我想要做后端于是让我的mentor给我安排了相关的任务。

我得到的经验是还是需要尽力去争取，说不定就成了呢。这件事还给我的manager留下了我”明确知道自己喜欢什么并且勇于争取“的印象。算是一种肯定（？）

我们组是一个新组，文档有，但是要么基于其他组，要么不够完善，所以基本只能看个大概有所了解。更直接的方式是问mentor和同事们，比如我在第一天参加站会的时候就请大家介绍了一下组里在做的产品，有了个大概的认识。可以说作为新人，我是在和大家一起成长的。但好在同事之间非常欢迎互助，不止一个不是我mentor的同事鼓励我多多提问。

对于有点自闭社恐的人来说，还有一个了解组里技术背景的方式是站会。一个能对新人暴露足够多信息的站会在我看来需要包括以下要素：

• 每个人需要提到自己的block和进度，详细到技术名词
• 谈到自己的任务的时候会提及上下文，即任务的上下游部门是哪些，采用了什么技术，达成什么目标，正在与谁协作
• 提到的技术工具 组里有文档或者群聊记录有提及

我重构信息的方式是，先不求甚解，尝试通过大家讨论block的时候的信息在脑子里画一个依赖图，对于能查到文档的或我自己的项目也用到的技术，去看看文档；听到新的技术名词的时候问问自己，猜想这是用来解决什么问题的，必要的时候直接问。经过大概两周的时间，我就能描述出组里做什么，每个同事做什么模块。这对定向求助以及理解自己在组里的位置非常有帮助。

组里主要是基于Scrum流程来安排工作的。除了每天的站会之外。每周会有一些固定会议，大家一起讨论当前遇到的问题，基于Azure DevOps看板盘点当前大家的任务进度并分配新的任务；还会安排专门的knowledge sharing和happy hour供大家交流学习和团建。

和学校里非常不同，工作当中沟通讨论的时间和写代码的时间可以说是对半。写代码的时候为了写代码而准备的时间有时候又比写代码本身要长。所以，写代码很重要，但是不是工作的全部。

个人成长

Not Finished Yet in Previous AW

• choose product and checkout; use message

• big collection of goods: extract and save in the repos——patch aw06 products use h2db? 修改pos-product

• test case sa-spring/spring-webflux测试用例可以写成mvn项目

• 记得恢复各地的eureka enable 其中cart需要在serviceimpl里恢复loadbalance yml文件

• cart传输的数据需要修改

Guideline to my Micropos

启动gateway 可以通过http://localhost:2222/来访问Micropos，其中后缀添加product，carts，order，delivery访问对应的服务。也可以对各自的服务单独调试

Obstacles

• 迁移到windows下环境后delivery启动失败出现Unsatisfied dependency expressed through field ‘eurekaServerBootstrap’
• 类似问题 carts启动失败：查询后添加
  • I got the same error on java 11. Adding jaxb api dependency to the pom solved my issue

Reference

sa-spring/employee-reactive

针对delivery系统先尝试

EmployeeController 负责处理网页请求，返回的是用Mono或者Flux包装的数据结构

webclient 不管处理怎样的请求 都会显示取两个请求来处理

• EmployeeRepository/Employee 基础设施
  • repository是内存中 可以模仿之前某次作业里的持久化 或者改进时再做

Simple version： 发送一个请求立刻传送 模拟高占时的计算任务

• OrderInfo（需要添加买家名字和地址 order调整时在做，暂定是）应该在order中 迁移；

  • Stirng id
  • Items 信息（联调实现）

• DeliveryInfo pos-api 生成随机时长 显示在路上（log）最后告知已经送达

  • String 信息
  • 是否已经送达（？）

Todo

• rabbitmq 配置

  stream来发送 在yml里配置

• order创建好DeliveryDto再发送 才能用mapper 在order中订阅

• 可以用web client来发送请求

delivery变成integration

大致思路：

aw07中的delivery不再作为微服务的一部分（去掉discovery和gateway配置）

pos-cart中添加发送消息的部分；发送的消息有load，字符串（与aw08样例中直接get不同）；添加接收

pos-delivery 保持不变

Tech Solution

• pos-order

替换成改写demo中的inbound/outbound

inboud：处理发送来的post请求，提取string信息，调用placeOrder函数进行中间处理转换

1
2
3
4
5
6

inboundGateway(uri)
.requestMapping(r -> r.methods(Https.POST)
.consumes("text/plain"))
.<String>handle((s)-> return placeOrder(s))
.requestPayloadType(String.class)
.get();

就业分享

认识自己 再去考虑工作的去向

想是没有用的 去尝试才会知道

大学期间 转型是代价相对小的

但是需要有一个标准

技巧+实力 对问题有思考

https://spring.io/projects/spring-cloud-stream

https://github.com/sa-spring/stream-loan

https://piotrminkowski.com/2020/06/05/introduction-to-event-driven-microservices-with-spring-cloud-stream/

调研

开发

添加orderService，配置好事件驱动

source/发送者用的是supplier，连续的发送事件，但是我的期望设计是由特定事件驱动，需要用到streamBridge.参考

处理者也可以返回消息，需要使用consumer参考

测试

先测试事件驱动架构，在自动化生成请求的情况下；

20220105-20220513 字节 iOS岗位实习

借用KISS框架做一个简单小结

Keep-需要保持的

• 相信自己有解决问题的能力，遇到技术/业务上不懂的地方先尝试自己弄懂；
• 学会提问，提问的时候介绍清楚背景和自己目前所做的努力；
• 分隔开工作学习生活，保持完全投入和完全抽离。在工作时间段只想工作中的事情，其他时间段保存精力或者专心处理其他，忙碌的时候这一点尤为重要，可以减少不必要的内耗；
• 留意工作中开发和学校中项目的不同，多反思多学习；
• 从要跳槽/写简历的角度看待自己的工作；
• 写代码的时候保持记录，写好文档；根据文档做代码收敛和优化；

Improvement-需要改进的

• 写代码尽可能遵照调研-技术方案-开发-自检-代码说明的流程，让代码思路设计更加完备，简洁，符合规范；

• 读原有代码的时候理解逻辑，做到和自己需求相关的闭包内容都了解清楚；

• 沟通！沟通！沟通！无论是业务需求、技术问题还是代码规范，自己有了思路以后不要埋头苦干，多向mentor以及对接的同学进行确认；

Start-需要开始的

• 工作之余借当前项目进行技术钻研，多读代码
• 在调研和写tech solution的阶段多咨询mentor

Stop-需要停止的

• 停止假设对接人是完美的，停止“非我职责”的想法，遇到问题多问多push