2017年技术教练认证流程回顾

最新推荐文章于 2022-10-19 09:02:20 发布

danxibaoxxx

最新推荐文章于 2022-10-19 09:02:20 发布

阅读量345

点赞数 1

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/danxibaoxxx/article/details/97896565

本文回顾2017年技术教练认证流程，涵盖海选编程题、多轮评估、黑客松项目及综合面试，强调代码质量、团队协作与敏捷实践。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2017年技术教练认证流程回顾

[TOC]

本文档记录2017年的技术教练认证的流程，其中很多内容是事后回忆的，因此题目有些出入。
教练认证每年的流程(套路)都不大一样，因此只能起一定的参考作用，
希望对后来人起一定的指导作用，能够做到有的放矢。

第一轮

第一轮是海选，先报名参加，然后按照通知的截止时间之前，完成
给定的题目。这关报名人数很多，因此淘汰率也很高。通过不了这
关，以后就没认证的事了，其意义不言而喻。

这关会出一道编程题，当然有难有易，相比与往年，这次的题目就比较简单。

题目

题目如下：

给定单词列表words（字符串数组）和一个长度L，格式化成若干行文本数组，要求：
1、每段文本字符长度为L，并且文本中单词（非开头和结尾）左右都有空格。
2、使用贪婪算法生成文本，即每段文本中尽可能多的容纳单词。为了让每段文本长度达到L，可以补充' '。
3、单词之间的空格应该等间隔分布，如果文本中空格不能均匀分布，左边的空格应该比右边的多。
4、最后一行文本中，单词间不能有空格，即只能有一个单词。

例如,
words: ["This", "is", "an", "example", "of", "text", "justification."]
L: 16.

返回文本数组:

[
   "This    is    an",
   "example  of text",
   "justification.  "
]
说明：每个单词长度不超过L。

编程要求：
1、给出测试用例和源码
2、代码足够clean code

总结

按照历年教练的指导，这部分的关键就是下面几点：

实现题目要求的功能，不能跑题
代码要尽量简洁，代码量要尽量小和复杂度要尽量低
单元测试要尽量全面些，如果可能尽量采用TDD方式

第二轮

第二轮还是考察编程能力，集中第一轮通过的所有认证教练，通过一天
的时间，实现给定的题目要求。这一轮的特点总结如下：

时间比较短，基本上是上午做题，下午评审
题目是按照迭代的方式出的

题目

Sprint 1

LRU是Least Recently Used，最近最少使用算法。

是内存管理的一种页面置换算法，也就是首先淘汰最近最久未使用的页面。

要求：
- 提供get(key)，put(key, value)，delete(key)接口
- 达到容量限额时，首先淘汰最长时间未被使用的缓存节点
sprint2

MRU是Most Recently Used，最近被使用替换算法。

该算法在进行数据块的替换时，选择最近被访问的数据块进⾏行替换。

要求:
- 提供get(key)，put(key, value)，delete(key)接口
- 达到容量限额时，首先淘汰最近被访问的缓存节点
sprint3

LFU是Least Frequently Used，也就是淘汰一定时期内被访问次数最少的页。

要求：
- 提供get(key)，put(key, value)，delete(key)接口
- key可以是字符串或数字
- 当达到容量限额时，首先淘汰被访问次数最少的缓存节点
NOTE: 由于时间关系，这题没有要求实现。

实现

题目不是很难，在网上也有很多可参考的代码，通过双向链表+Hash Map可以实现。
由于没有限制开发语言，采用C++的标准库可以简化代码的实现。如果自己实现
双向链表和Hash Map还是比较繁琐的。

基本上所有的大家是使用了C++标准库的std::list和std::map来实现，但是
由于map中存储的直接是数据value，导致从list中移动或者删除的操作效率
不高，只要O(N)，达不到O(1)的要求。由于std::list并没有暴露节点的数据
结构，只暴露了迭代器，对于std::list来说，所有的操作都是基于迭代器，
而迭代器中其实就是节点的封装，所以可以在map中保存list的迭代器，这样
可以实现list操作的O(1)要求。当然，如果自己实现双向链表，map中保存
链表节点，其实是一样的。

总结

评审考察的重点如下：

代码重复度低
代码实现效率高
测试用例全面
注意迭代开发引起的代码重构

第三轮

第三轮采用黑客松的方式，实现idoc项目中的三个需求。

代码托管路径：http://gitlab.zte.com.cn/10042941/iDoc_Hacker

流程

第一天

需求澄清和分组，参加的认证教练包括技术类和管理类，采用一个管理教
练和两个技术教练结对开发的方式进行。

选好需求之后，就要做任务拆分和故事拆分，做一些预研的准备。
第二天到第四天

迭代开发实现需求，需要按照敏捷开发方式进行，那么一些基本的事情就
不可避免。
- 每日站会
- 任务墙更新
- 代码重构
- 每日日报
也可以部署下CI之类的，尽量能够增加一些亮点。
第五天

上午继续开发和演示准备，下午进行客户参与的演示介绍会。演示完毕之
后，评委会给定分数。
第六天

上午进行了代码评审，下午进行了个人总结评审。下午的个人总结比较
重要，因为部长和金泽铎等其他教练都参加了。

总结

为期六天的黑客松开发任务比较紧张，除了团队内的讨论分析，每天下午3点
或者4点的时候，还要进行演示和评审。真正用来开发写代码的时间并不是很
多，因此，每日加班那个没法避免的。

技术教练也要积极参加，对需求的拆分，故事优先级调整和实现方案要给予
支撑。因为这次带有教练认证的性质，因此考评重点看的是过程。还有一个
重点就是测试用例，每次教练评审的时候，都会特别关注这方面。

日报的内容可以包含下面几个方面：

今日成果
明日安排
工作亮点
工作总结

公司对技术教练的选拔看中以下几个方面的能力：

系统观念
团队贡献
学习能力
客户思维

因此，在个人总结的报告中，需要从上面几个方面出发，进行总结。
而不能停留在开发人员的思维上，例如：代码质量、代码量。通常
包含以下几个主题就行了。

对团队建设的贡献
- 可以是项目工程、CI、代码风格、重构等各个方面
- 可以是对需求的划分、故事的划分的影响
- 可以是对任务的优先级的影响
- 可以是对团队成员成长的影响
培训过程中学习到知识
- 学习到哪些技能和知识
- 如何应用掌握的技能和知识
问题及其思考
- 残留的问题及其解决方案
- 更好的设计方案
- 整个系统层面的问题

第四轮

第四轮为综合面试，时间为一个下午。主要包含两个内容：笔试和实战。
这一轮需要提前做一些准备，否则会很吃力。

笔试

笔试出了7道题，时间限制为50分钟。区别技术和管理类，有几道题目不一样。
题目大致如下：

日常开发哪些活动体现敏捷的价值？
教练需要关注的重点和要求？
公司的敏捷开发落地情况？（记不清了）
如何看正交设计、OO和SOLD原则？
系统通讯方式有哪些？有什么优缺点？
系统架构有哪些？有什么优缺点？
最近半年在教练方面有什么提高？后续半年的计划是什么？

经验: 答题不要使用整句，使用关键字。

知识点

敏捷宣言

敏捷软件开发宣言内容：

个体和交互胜过过程和工具（站会）
可以工作的软件胜过面面具到的文档（UT，CI)
客户合作胜过合同谈判（演示会）
响应变化胜过遵循计划

正交设计

正交四原则:

消除重复
分离不同的变化方向
缩小依赖范围
向着稳定的方向依赖

面向对象

三大机制:

封装，隐藏内部实现
继承，复用现有代码
多态，改写对象行为

遵循原则：

针对接口编程，而不是针对实现编程
优先使用对象组合，而不是类继承
封装变化点

设计原则

什么是高内聚，低耦合原则：

高内聚：紧密相关的功能、信息等放在一起；不相关的功能、信息分开管理。
低耦合：互相协作的单元，交互时接口要简洁。彼此内部的变化，尽量不要影响到对方。

几条更具体的设计原则（SOLID五原则）：

缩写	英文名称	中文名称
SRP	The Single Responsibility Principle	单一职责原则
OCP	The Open Closed Principle	开放封闭原则
LSP	The Liskov Substitution Principle	里氏替换原则
ISP	The Interface Segregation Principle	接口分离原则
DIP	The Dependency Inversion Principle	依赖倒置原则
LOD	Law Of Demeter Principle	迪米特原则