🍊
翻译橙
🍊返回主站🤖参与贡献
  • hello,这里是翻译橙
  • spring boot参考文档
    • 1. 法律
    • 2. 寻求帮助
    • 3. 文档概述
    • 4. 入门
    • 5. 升级Spring Boot
    • 6. 使用 Spring Boot 进行开发
      • 6.1. 构建系统
      • 6.2. 构建你的代码
      • 6.3. 配置类
      • 6.4. 自动配置
      • 6.5. Spring Bean 和依赖注入
      • 6.6. 使用@SpringBootApplication注解
      • 6.7. 运行您的应用程序
      • 6.8. 开发者工具
      • 6.9. 打包您的生产应用程序
      • 6.10. 接下来读什么
    • 7.核心特性
      • 7.1. SpringApplication
      • 7.2. 外部化配置
      • 7.3.Profile配置
      • 7.4.日志记录
      • 7.5.国际化
      • 7.6 面向切面的编程
      • 7.7. JSON
      • 7.8. 任务执行与调度
      • 7.9. 单元测试
        • 7.9.1. 测试范围依赖
        • 7.9.2. 测试 Spring 应用程序
        • 7.9.3. 测试 Spring Boot 应用程序
        • 7.9.4. 测试容器
        • 7.9.5. 测试工具
      • 7.10. Docker Compose 支持
      • 7.11. 测试容器支持
      • 7.12. 创建您自己的自动配置
      • 7.13. Kotlin 支持
      • 7.14 SSL
      • 7.15.接下来要读什么
    • 8. 网络
      • 8.1. Servlet Web 应用程序
        • 8.1.1. “Spring Web MVC 框架”
        • 8.1.2. JAX-RS 和Jersey
        • 8.1.3. 嵌入式 Servlet 容器支持
      • 8.2 反应式网络应用程序
        • 8.2.1. “Spring WebFlux 框架”
        • 8.2.2. 嵌入式反应式服务器支持
        • 8.2.3. 反应式服务器资源配置
      • 8.3. 优雅关机
      • 8.4. spring安全
        • 8.4.1. MVC安全
        • 8.4.2. WebFlux 安全
        • 8.4.3. OAuth2
        • 8.4.4. SAML 2.0
      • 8.5. spring 会话
      • 8.6.GraphQL
      • 8.7. Spring HATEOAS
      • 8.8.接下来读什么
    • 9. 数据
      • 9.1. SQL数据库
      • 9.2. 使用 NoSQL 技术
      • 9.3. 接下来读什么
    • 10. 消息
      • 10.1. JMS
      • 10.2. AMQP
      • 10.3. Apache Kafka 支持
      • 10.4. Apache Pulsar 支持
      • 10.5. RSocket
      • 10.6. Spring Integration
      • 10.7. WebSockets
      • 10.8. What to Read Next
    • 11. IO
      • 11.1. 缓存
      • 11.2. Hazelcast
      • 11.3. Quartz 调度程序
      • 11.4. 发送电子邮件
      • 11.5. 验证
      • 11.6. 调用 REST 服务
      • 11.7. web services
      • 11.8. 使用 JTA 进行分布式事务
      • 11.9. 接下来读什么
    • 12. 容器镜像
  • Spring核心功能
    • 1.IOC容器和Bean简介
      • 1.2. 容器概述
      • 1.3. Bean概述
      • 1.4. 依赖项
        • 1.4.1. 依赖注入
        • 1.4.2. 详细的依赖关系和配置
        • 1.4.3. 使用depends-on
        • 1.4.4. 延迟初始化的 Bean
        • 1.4.5. 自动装配协作者
        • 1.4.6. 方法注入
    • 2. Resources
      • 2.1. 介绍
      • 2.2. Resource接口
      • 2.3. 内置Resource实现
      • 2.4. ResourceLoader接口
      • 2.5. ResourcePatternResolver接口
      • 2.6. ResourceLoaderAware接口
      • 2.7. 资源作为依赖
      • 2.8. 应用程序上下文和资源路径
    • 3. 验证、数据绑定和类型转换
      • 3.1. 使用 Spring 的 Validator 接口进行验证
      • 3.2. 将代码解析为错误消息
      • 3.3. Bean 操作和BeanWrapper
      • 3.4. spring类型转换
      • 3.5. spring字段格式
      • 3.6. 配置全局日期和时间格式
      • 3.7. Java Bean 验证
    • 4. SpEL表达式
    • 5. Spring 面向切面编程
      • 5.1. AOP 概念
      • 5.2. Spring AOP 的能力和目标
      • 5.3. AOP 代理
      • 5.4. @AspectJ 支持
        • 5.4.1. 启用@AspectJ 支持
        • 5.4.2. 声明一个切面
        • 5.4.3. 声明切入点
        • 5.4.4. 声明切点
        • 5.4.5. 切面说明
        • 5.4.6. 切面实例化模型
        • 5.4.7. AOP 示例
      • 5.5. 基于模式的 AOP 支持
      • 5.6. 选择要使用的 AOP 声明样式
      • 5.7. 混合切面类型
      • 5.8. 代理机制
      • 5.9. @AspectJ 代理的程序化创建
      • 5.10. 在 Spring 应用程序中使用 AspectJ
      • 5.11.更多资源
    • 6. Spring AOP API
      • 6.1. Spring中的切入点API
      • 6.2. Spring 中的 Advice API
      • 6.3. Spring 中的 Advisor API
      • 6.4. 使用ProxyFactoryBean创建 AOP 代理
      • 6.5. 简洁的代理定义
      • 6.6. 以编程方式创建 AOP 代理ProxyFactory
      • 6.7. 操作切面对象
      • 6.8. 使用“自动代理”工具
      • 6.9. 使用TargetSource实现
      • 6.10. 定义新的切面类型
    • 7. 空指针安全
    • 8. 数据缓冲器和编解码器
    • 9. 日志
    • 10. 附录
      • 10.1. XML 模式
      • 10.2. 自定义XML Schema
        • 10.2.1. 创作 Schema
        • 10.2.2. 编码一个NamespaceHandler
        • 10.2.3. 使用BeanDefinitionParser
        • 10.2.4. 注册处理程序和模式
        • 10.2.5. 在 Spring XML 配置中使用自定义扩展
        • 10.2.6. 更详细的例子
      • 10.3. 应用程序启动步骤
  • 使用redis实现分布式锁
  • Java 安全标准算法名称
  • JDK 9 JEP
  • JDK 10 JEP
  • 人件
    • 《人件》
    • 第一部分 管理人力资源
      • 01 此时此刻,一个项目正在走向失败
      • 02 干酪汉堡,做一个,卖一个
      • 03 维也纳在等你
      • 04 质量——如果时间允许
      • 05 再谈帕金森定律
      • 06 苦杏素
    • 第二部分 办公环境
      • 07 家具警察
      • 08 “朝九晚五在这里啥也完成不了。”
      • 09 在空间上省钱
      • 间奏曲:生产效率度量和不明飞行物
      • 10 大脑时问与身体时间
      • 11 电话
      • 12 门的回归
      • 13 采取保护步骤
    • 第三部分 正确的人
      • 14 霍恩布洛尔因素
      • 15 谈谈领导力
      • 16 雇一名杂耍演员
      • 17 与他人良好合作
      • 18 童年的终结
      • 19 在这儿很开心
      • 20 人力资本
    • 第四部分 高效团队养成
      • 21 整体大于部分之和
      • 22 黑衣团队
      • 23 团队自毁
      • 24 再谈团队自毁
      • 25 竞争
      • 26 一顿意面晚餐
      • 27 敞开和服
      • 28 团队形成的化学反应
    • 第五部分 沃土
      • 29 自我愈复系统
      • 30 与风险共舞
      • 3l 会议、独白和交流
      • 32 终极管理罪恶得主是……
      • 33 “邪恶”电邮
      • 34 让改变成为可能
      • 35 组织型学习
      • 36 构建社区
    • 第六部分 快乐地工作
      • 37 混乱与秩序
      • 38 自由电子
      • 39 霍尔加·丹斯克
由 GitBook 提供支持
在本页
  • 作品集
  • 技能测试
  • 组织一场试演

这有帮助吗?

在GitHub上编辑
  1. 人件
  2. 第三部分 正确的人

16 雇一名杂耍演员

马戏团经理:你玩杂耍有多少年了啊? 候选人:嗯,大约六年了。 经理:你能玩三球、四球和五球吗? 候选人:是的,都可以。 经理:你能玩带火焰的吗? 候选人:当然。 经理:……刀子、斧子、打开的雪茄盒、伸缩帽子呢? 候选人:我可以拿任何东西来杂耍。 经理:你杂耍过程中会配上一系列有趣的啪嗒声吗? 候选人:非常搞笑的。 经理:听起来不错啊,我想你被雇佣啦。 候选人:呓……您不想看看我怎么杂耍的吗? 经理:呃,我好像从来没想过。

雇一名杂耍演员却不先看看他的表演,可真够滑稽的,这可是生活常识啊。但要是派你去招聘一位工程师、设计师、程序员或者一名团队经理,这样的常识却被抛在了脑后。你不会去看他的设计、程序或者其他东西。面试完全靠说。

你想雇一个人来制造一种产品,这种产品很可能跟他以前做的类似。你当然需要看看候选人以前生产的产品样品。这应该是显而易见的,却往往被开发团队的管理者给忽略了。当你负责职位面试时,似乎有一条约定成俗的边界。这种不成文的规矩认为:可以只跟候选人聊聊过去的工作,但不用看到实物;其实,只要你问了候选人,大部分人都会很高兴地带来一件样品。

作品集

在我们联合参加加拿大西部的一个教学项目时,我们接到当地技术学院一个计算机教授的电话。他提议说哪天晚上下课后来我们的宾馆聊聊,并愿意给我们买杯啤酒来换取些想法。对于这样的邀请,我们很少会拒之门外。那天晚上,我们从他身上学到的东西,可能比他从我们身上学到的还要多。

这位老师非常坦诚地谈到如何评价他的工作是否成功:他需要他的学生毕业后能够找到一份好的工作,而且越多越好。“哈佛的文凭可能本身就具有价值和说服力,但我们的文凭没有。如果今年学生找不到好工作,明年就不会有学生了,那我也就失业了。”所以,他找到了一剂良方,能够让他的学生在就业市场上具有吸引力。他教给他们各种建立系统的技术方法,同时也让学生有机会在附近公司或机构的真实应用中去工作。但是.这剂良方最核心的部分,则是让每个学生自己收集作品集,以展示他们的工作成果。

他讲述了如何指导学生在每次面试过程中展示他们的作品集:

我带来了一些我工作的样例来二像这个是我在一个项目中用 C++编写的子过程,这一组 SAP 脚本则来自于另外一个项目。这部分我们使用了克鲁斯提倡的 loop-with-exit 扩展,除此之外都是完全结构化的代码,贵公司应该也是这样的标准二这里是代码相应的设计,还有根据需求的分层数据流设计图以及相关的数据字典……

从那以后,我们经常听到这所不知名的学院以及那些作品集。我们甚至见过来自于三角创业园、北卡罗纳州和佛罗里达州坦帕的招聘专员,经常不远千里来到这所遥远的加拿大校园,以求发现毕业生中的千里马。

诚然,这位教授聪明的设计使得毕业生们在就业市场上具备很强的竞争力,但在那晚的谈话过程中,最让我们吃惊的还是他提到:面试官经常都会被这样的作品集震惊。这说明,这些面试官并不要求所有候选人都带着作品集来参加面试:但为什么不呢?有什么比让候选人带着自己的工作案例来面试更合理的呢?

技能测试

如果重视新聘员工所具备的用于工作中的各种技能,那么,我们为何不设计一个测试来度量这些技能呢?我们这个行业和技能测试的想法之间有过很长一段不够稳定的“暖昧”关系。在上世纪 60 年代,这个想法是很流行的:到现在,你和你的组织可能已经放弃这个概念了;如果你没有,我们给你一个应该放弃的理由:这种测试度量了错误的东西。

技能测试一般都会针对被雇用者进入公司后马上会面临的任务来进行。他会被测试是否胜任于职位需要的统计分析、程序设计或其他知识。在几乎所有的技术领域,你都能买到这种技能测试,它们也或多或少能够预测一个新进员工的表现。但这又如何?这位被成功招聘来的员工可能在做这些任务的几年后,变成了团队领导、项目经理或者项目总负责人。测试时所度量的任务他可能只做了两年,之后的 20 年时间,他都在忙其他事情。

我们发现,大部分技能测试都针对左脑。这是因为一名新员工的任务大部分都依赖左脑。但在接下来的职业生涯中,他们做的事情会很大程度上依靠右脑,比如说管理就需要整体思考、启发性判断和机遇经验的直觉判断。所以,技能测试可能造成你招进来的人,短期表现良好却无法获得长期成功。也许你应该尝试着只雇用那些技能测试失败的人。

读到这里,你已经预料到了我们并不鼓励在招聘中采用技能测试。这并不是说技能测试就不好.你就该坚决不用。相反,你应该去用,只是不该用于招聘。通过购买或自己开发的经典技能测试是给员工提供的很好的自我评价工具。一个健康组织所必需的,是能够为员工经常性地提供独立的自我评价机会。(第 37 章中会有更多讨论。)

组织一场试演

在我们所在的行业,社会成分比技术成分多,更多是依靠员工和其他人交流的能力而不是他们跟机器交流的能力。所以在招聘过程中,至少需要关注那些社会和人际交流的特征。我们发现,最有效的方法就是为应聘者组织一场试演。

这个想法很简单。你让应聘者按自己过去工作的某个方面准备一个 10 或 15 分钟的演讲,可以是关于一种新技术的第一手体验,或者是从痛苦经历中学到的管理知识,或者是关于一个很有趣的项目。应聘者自己选择话题,然后你定一个日子并且邀请未来可能和他一起工作的人来当听众。

应聘者当然会紧张,甚至可能不接受这样的安排。你应该解释清楚所有应聘者都会在试演时感到紧张,然而,之所以要组织这样的会,就是要考察应聘者的交流技巧,同时,也给未来同事们一个参加招聘过程的机会。

在试演完成、应聘者离开后,你可以组织一次听众讨论。每个人都评价一下应聘者跟工作的契合度,以及是否能够融入团队。虽然决定最后是否招聘仍然是你的职责,但来自未来同事们的反馈是无价的。更为重要的是,这位新招进来的员工可能在未来很容易就能融人到团队中,因为其他团队成员在招聘过程中都表达了自己的意见。

我的第一次试演经历是招聘顾问和讲师。我折磨那些候选人的动机很简单:我想知道他们是否能够自然地解释清楚或易或难的问题,或者能够被教会如何去解释这些问题,抑或根本就不能向别人解释清楚。我同时也希望听到其他人的意见,所以我让当时在办公室的同事们都参加了演讲。在 5 年时间内,我们组织了大约 200 场试演。

很快,试演作为融合新人和老员工的催化剂作用就显现出来了。一次成功的试演就像是一次同行认证;反之似乎也成立,一次失败的试演也能提升已有员工的士气,它不停地告诉大家,你之所以能够被雇用,并不是机缘巧合,凭借好运气,在合适的时间让自己的简历出现在了我的办公桌上。 -TRL

关于试演的一个警告:确保应聘者讲述的是跟你组织从事的工作紧密相关的事情,要不很容易就被一些极左的话题讨论给蒙蔽了,比如讨论“三胞胎的养老计划”或者“软饮料对白萝卜生长的影响”。你一定会被演讲者在这个话题上表达出的强烈热情而吸引,但是,这种热情在未来的工作中却根本见不到。

上一页15 谈谈领导力下一页17 与他人良好合作

最后更新于5个月前

这有帮助吗?